Q1: Dlouhodobý provoz - jak se řeší upgrade ESXi/vsan ?
A1:
Krátká odpověď:
Update/upgrade se řeší standardně jako upgrade ESXi, takže většinou pomocí VMware Update Manageru.
vSphere a vSAN jsou svázané v rámci jednoho ESXi image.
Dlouhá odpověď:
Jednoduchý management včetně dlouhodobého provozu (tzv. Day2 operací) je oblast na kterou se VMware hodně zaměřuje. vSAN je velmi jednoduchá platforma na používání a navíc velmi robustní a výkoný storage system. To, na čem je ale každá infrastrukturní platforma závislá jsou drivery a firmwary component, jako jsou Storage Controlery, disky a síťové karty.
Pojďme si nejdříve říct, jakým způsobem se zajišťuje udržování driverů a firmware u vSphere 6.x.
vSphere administrátor typicky používá VMware Update Manager pro update ESXi softwaru (VMware hypervisor). Drivery jsou většinou součástí ESXi image, který je buď vanilla image of VMwaru a nebo Custom image od dodavatele hardwaru. V případě potřeby jiných validovaných driverů je možné takové drivery stáhnou jako tzv. VIB Depot (zip file) a buď použít VMware Update Manager (GUI) nebo esxcli (příkazovou řádku).
Problematičtější je to s firmwary, které VUM neřeší a administrator je musí řešit nástroji serverového vendora.
Navíc si VMware administrator musí udělat vlastní analýzu validovaných kombinace driverů a verzí firmware v rámci VMware vSAN HCL.
Dell EMC OpenManage Integration for VMware vCenter je rozšíření vCentra o lepší visibilitu na serverový hardware a s možností update firmware.
Je to dobré vylepšení pro správu systému, ale nezbavuje to administrátora zodpovědnosti a práce s výběrem validní kombinace driverů a verzí firmware v rámci vSphere updatování.
Toto je jedna z největších přidaných hodnot VxRAILu, kde je verze hypervizoru, driver a všechny firmwary včetně BIOSu a firmware síťových karet dodávána jako jeden jediný validovaný image, který se dá celému VxRAIL clusteru a VxRAIL manager zajistí rolling update nebo upgrade celého clusteru.
JAK JE TO VE VSPHERE 7?
VMware si uvědomuje potřebu zjednodušení driver a firmware managementu, který je ještě vice důležitý právě při provozu vSAN.
Vylepšení v oblasti životního cyklu (update/upgrade) je spojeno s funkcionalitou ve vSphere 7, ve které byl uveden tzv. vSphere Lifecycle Manager.
vLCM je z dlouhodobého hlediska náhrada VMware Update Manageru, nicméně je dobré si uvědomit, že vLCM je ve vSphere 7 uvedeno ve verzi 1, takže do doby než se vLCM plně ujme, zákazníci si na něj zvyknou a VMware technologii doladí na základě reálného feedbacku zákazníků, tak je možné nadále používat VUM. Mimochodem VxRAIL s vSphere 7 bude v prvních verzích používat VUM a na vLCM přejde postupně. vLCM je zasadní změna v konceptu updatu a upgradu vSphere. VUM pracuje s ESXi hostama, vLCM pracuje s vSphere Clusterama.
Další změna je použití principu tzv. Desired State (očekávaný stav), takže vSphere administrátor si pomocí centrálních vLCM politik definuje požadovaný profil, který se vLCM snaží aplikovat a udržet konzistentní na celém vSphere / vSAN Clusteru a ne pouze na konkrétním ESXi hostu.
V případě odchylky reálného od požadovaného stavu je administrátor informován pomocí warningu a může to začít řešit a iniciovat nápravu primo pomocí vLCM.
vLCM profilem je definovaný
•
Základní ESXi image, ve kterém jsou nativní drivery hardwarových komponent
•
Druhá část profilu jsou Vendor add-ony, ve kterých mohou být specifická rozšíření konkrétního vendora jako je např. OpenManage Administrator agent
•
Třetí části profilu jsou Firmware a Driver add-ony, ve kterém jsou i BIOSy a firmwary ke konkretním hardwarovým komponentám. Je potřeba si uvědomit, že VMware do verze vSphere 7 nikdy neřešil napřímo firmware management a v oblasti firmwarů se spoléhal na systém management hardwarových vendorů
Takže z těchto třech věcí se skládá vLCM DESIRED IMAGE, který se automaticky aplikuje na ESXi hosty v rámci vSphere clusteru, na kterém je profil nastaven.
Na co bych chtěl upozornit ...
•
vLCM ve vSphere 7.0 už sice pokrývá celý HW stack, ale automatizovaná validace oproti HCL je zatím jen na storage I/O controllery, takže updaty BIOSu a firmwaru hardwarových komponent mohou být sice aplikovány přes vLCM, ale nejsou validovány oproti HCL a zodpovědnost za správnou kombonaci driverů a firmwarů je stále na vSphere administrátorovi
•
vLCM sice podporuje update vSAN clusteru, ale nepodporuje update vSAN witness appliancí v rámci 2-node vSAN a stretchovaných clusterů.
•
vLCM také nedělá update vCenter serveru, to řeší případně až SDDC Manager v rámci VCF
Takže nemějte od této první verze extrémní očekávání. Podobnou funkionalitu je již roky možné dosáhnout na Dell hardwaru pomocí OpenManage Integration for VMware vCenter. Mimochodem vLCM využívá pro firmware management právě OMIVV, nicméně vLCM je řešení přímo od VMware v dalších verzích půjde dál a bude zjednodušovat systém managementu pro vSphere adminy. vLCM ve vSphere/vSAN 7 je první verze end-to-end system managementu, který je integrovan přímo Vmwarem do vSphere, takže je to velmi dobrý signál pro zákazníky, že VMware to se zjednodušováním system managementu myslí vážně.
Ono to je totiž extrémně důležité právě pro vSANu, kde špatné drivery nebo firmwary řadičů, disků nebo síťových karet mají negativní vliv na stabilitu a výkon celého distribuovaného storage systému.
Nakonec je potřeba si říct, že VxRAIL lifecycle management je pořád někde úplně jinde. Single IMAGE BUNDLE zvalidovaný a supportovaný DellEMC by měli zákazníci ocenit. A když už se bavíme o VxRAILu, tak v rámci VxRailu se i v první verzi vSphere/vSAN 7 používá klasický VUM přístup, nikoliv vLCM desired state. Do budoucna VxRAIL přejde na vLCM, ale pro zákazníka to bude absolutně transparentní.
Q2: Jelikož jde v AF konfigurací 100% zápisů do cache disku, prochází jím všechny zápisy, jak se zde řeší škálovatelnost ?
A2:
Krátká odpověď:
Je potřeba si uvědomit, že Write Intensive disk zvládne teoreticky až 100 000 IOPS (4KB IO), nicméně v případě potřeby škálovatelnosti je možné v rámci jednoho vSAN nodu použít více diskových group (až 5), jelikož každá disková group má vlastní cache disk. Větším počtem disk group se zvětšuje výkon jednoho vSAN nodu. vSAN je ale distribuovaná scale-out storage, takže dalším způsobem škálování je přidání dalšího nodu do vSAN clusteru.
Dlouhá odpověď:
Ve vSAN jse 100% zápisů do cache disků nejen u All Flash (AF), ale i u Hybridní vSAN. U hybridní vSAN se cache disk používá i pro cachování read operací, což se nedělá u All Flash vSANy, jelikož kapacitní SSD, nemají s read operacemi žádný problém a navíc je jich většinou v diskové skupině více, takže agregovaná read performance je větší než výkon jednoho cache disku. Write operace jdou přes write cache/buffer proto, aby se šetřila životnost kapacitních disků, které jsou většinou Read Intesive a neposkytují tak velké TBW jako Write Intensive disky.
vSAN disková skupina se skládá vždy z jednoho cache disku (typicky Write Intensive) a maximálně 7-mi kapacitních (typicky Read Intensive) disků. Jako cache disk se používají write intensive disky, které fungují vždy jako Write Buffer.
SASové Write Intensive disky podle technických specifikací zvládají více jak 120 000 IOPS (4KB IO), takže každá disková skupina zvládne takovýto zápisový výkon a po zápisu I/O do cache se posílá ACK k iniciátoru a tím je z jeho pohledu I/O odbaveno, takže write latence a response time je dána cachovým diskem. Kapacitní disky by pak měly být vyladěny tak, aby zvládly destaging z cache do kapacitního tieru. Destaging je optimalizovaný pro minimalizaci write operací, aby se prodlužovala životnost Read Intensive disků v kapacitním tieru.
Nestačí-li výkon write cache SSD disku, tak je možné v rámci jednoho vSAN nodu použít více diskových group (až 5), jelikož každá disková group má vlastní cache disk. Větším počtem disk group se zvětšuje výkon jednoho vSAN nodu. vSAN je ale distribuovaná scale-out storage, takže dalším způsobem škálování je přidání dalšího nodu do vSAN clusteru.
Q3: Jaký vliv na výkon má resync dat při výpadku/maintenance nodů v reálném prostředí a s jakou délkou resync se musí počítat ?
A3:
Krátká odpověď:
Záleží na více faktorech, takže odpověď je ... IT DEPENDS.
Viz dlouhá odpověď.
Dlouhá odpověď:
Při maintenance módu je možné zvolit, jestli chci vSAN data na backendu přesunout a tím zajistit stejnou ochranu dat I během maintenance módu a nebo jestli se jedná o krátkodobý maintenance a zariskuju nižší a nebo žádnou ochranu dat. V případě, že mám storage politikou nastavenou ochranu dat, proti výpadku dvou nodů FTT=2, pak se nejedná o velké riziko.
V případě, že se rozhodnu vSAN data z maintenance nodu přesouvat, pak je délka resyncu daná rychlostí diskového čtení na zdrojovém nodu a rychlostí sítě. Jiná rychlost tedy bude na Hybridní vSAN na gigabitové sítí a jiná rychlost na All Flash vSAN s 25 Gb sítí.
vSAN má nástroj “Data Migration Pre-check”, která umí ukázat kolik dat je potřeba přesunou z nodu, který se přepíná do maintenance módu.
Níže uvádím příklad z mého labu, kde mám hybridní vSAN připojenou na gigabitovou síť a v případě přechodu do maintenance módu s plnou migrací dat by vSAN musela na backendu přesunout 338 GB dat, což by při rychlosti sítě 1 Gb a předpokladu propustnosti 100MB/s trvalo řádově hodinu.
 |
| vSAN Data Migration Pre-check |
Z tohoto důvodu je vhodné ve fázi designu vSAN zvažovat ALL FLASH variantu a 25Gb networking, což má pozitivní vliv i na rychlost případné evakuace dat.
Dalším design rozhodnutím je případná dvojitá ochrana dat FTT=2, která zajišťuje dostupnost disku i při nedostupnosti dvou vSAN nodů.
Je dobré si uvědomit, že FTT=2 potřebuje 5 vSAN nodů pro ochranu RAID 1 a nebo 6 nodů pro ochranu RAID 6
Druhou možností je použití stretchovaného clusteru a tím zajištění primární a sekundární dostupnosti dat.
Q4: Jak se řeší rozpad vsan clusteru, tj. pokud padne více node než je politika ochrany, jak pak probíhá uvedení do provozu
A4: Disky se přepnou do nedostupného módu podobného stavu APD (All Path Down) na tradiční storage a VM disky nejsou dostupne. Viz. screenshot níže, kde je nasimulovaná takováto chyba a chování uvnitř operačního systému FreeBSD, kde je vidět, že systém sice běží, ale nemá k dispozici disk.
 |
| Nedosutpný vDisk na vSAN z pohledu Guest OS |
Je potřeba zmínit, že každý operační systém se s takovýmto stavem vyrovnává jinak. Například MS Windows se do nekonečna pokoušejí o kontaktování nedostupného disku a věří, že se disk vrátí. Linuxové operační systémy většinou přepínají afektovaný disk do read/only modu. Operační systém FreeBSD, který jsem použil pro nasimulování tohoto problému se při nedostupnosti pokoušel o přístup k disku, který nebyl k dispozici. Po uvedení disku do provozu se operační systém vrátil k běžnému provozu. Je potřeba si uvědomit, že nedostupnost disku může mít různý dopad na různé aplikace uvnitř operačního systému.
Q5: Jsou preferované NIC, které mají pro vsan optimální výkon?
A5: vSAN pracuje s jakoukoliv supportovanou síťovou kartou na HCL ESXi. Pro All Flash vSAN je minimum 10 Gb NIC, ale v dnešní době bych rozhodně zvažovat 25 Gb NIC. vSAN pro optimální provoz potřebuje stabilní a výkonou síť, ale žádné jiné pereference vSAN nemá.
Q6: Jsou dostupné testy výhody použití 25g vs. 10ge pro vsan (myslím na oddělených NIC)?
A6: Našel jsem prezentaci z VMworldu 2017, kde jsou vedeny výsledky z performance testů, kde je vidět, že vSAN umí saturovat 25 Gb.
Prezentace je dostupná zde
Q7: NVMe vs. SAS SSD, tady je volba asi jasná, že?
A7: Úplně jasná volba to není, jelikož rozhodnutí většinou není jen o výkonu, ale i o škálovatelnosti a ceně celého řešení.
NVMe mají výhodu v tom, že jsou připojeny přímo do PCI a každé NVMe má vlastní storage controller. Navíc NVMe mají typicky větší výkon jak pro čtení, tak pro zápis. Specifikace SAS SSD, SATA SSD a NVMe je dostupná zde
Nicméně je potřeba si uvědomit, že Intel CPU Cascade Lake podporují maximálně 48 PCIe lanes per socket, takže 24 NVMe disků je na serveru PE R740 podporováno, ale musí být osazen oběma CPU a NVMe mohou teoreticky saturovat plných 96 lanes, což se reálně asi nestane, ale máme li v systému ještě 4x 25 Gb síťové karty a například 3 GPU, pak už by ve špičkách mohla být PCIe sběrnice přetížená.
Intel Cascade Lake PCIe architektura je znázorněna na následujícím schématu.
Dalším aspektem je cena. SAS SSD disky jsou v současné době cca o 30% dražší než SATA SSD disky a NVMe disky jsou ještě asi o 30% dražší než SAS SSD disky, takže je potřeba zvážit, jestli mám extrémní požadavky na diskový výkon a nižší latency.
Q8: Jak udělat sizing ssd cache ? je možné využití monitorovat ? co se stane, když je cache málo -> write jdou na kapacitní disky a sníží se jejich životnost ? Jak lze pak cache rozšířit ?
A8:
Informace nutné pro technický design, sizing a škálovatelnost SSD cache už jsem do většího detailu zodpověděl v odpovědi na otázku Q2.
vSAN cache je distibuovaná v rámci celého vSAN clusteru, každopádně všechny cache disky je možné monitorovat přímo z vSphere clienta a nebo ještě detailněji v dalších nástrojích. Níže je screenshot z vSphere Clienta.
Že je cache málo, se pozná u All Flash řešení tím, že se hodně destaguje z cache do kapacitních disků a tím pádem se zvyšuje congestion a tím pádem i response time pro disky ve virtuálních serverech.
vSAN umožňuje monitorovat congestion (přetížení) nižších vSAN vrstev (subsystémů). Congestion je ukazatelem přetížení určitého subsystému a v takovém případě dochází ke queueingu I/O operací a zvýšení response timů. Ukázka congestion grafu z vSAN monitoringu je na screenshotu níže.
Write I/O nikdy nejdou napřímo na kapacitní disky, takže jejich životnost se nesnižuje.
Velkou zátěž na cache nebo její nedostatečnou kapacitu je možné vyřešit několika způsoby
1.
rozložením backendu na více diskových skupin, kde každá disková skupina má vlastní cache disk (SCALE UP)
2.
rozložením celkového vSAN workloadu na více nodů (SCALE OUT)
3.
zrychlením destagingu, což je možné docílit pomocí více kapacitních disků
4.
v případě malého cache disku je možné cache disk vyměnit za větší, nicméně vSAN efektivně nepoužívá více jak 600 GB pro aktivní cachování a vyšší kapacita se začne využívat po odumření starých SSD buněk takže větším kapacitním diskem se docílí delší životnosti cache disku.
Q9: Je použitelný raid5 ? Jaký má vliv použití raid5 na výkon ?
A9:
Krátká odpověď:
Ano. vSAN podporuje RAID 5 (single parity erasure coding) a dokonce i RAID 6 (double parity erasure coding).
Jakákoliv implementace RAID 5 má write penalty 4, takže každé frontendové write I/O potřebuje na backendu 4 I/O operace.
Dlouhá odpověď:
Striktně technicky se nejedná o RAID (Redundant Array of Independent Disks), ale o RAIN (Redundant Array of Independent Nodes), jelikož redundance se nazajišťuje v rámci jednotlivých fyzických serverů (vSAN nodů), ale napříč nody.
vSAN RAID 5 je tedy ochrana proti výpadku jednoho nodu a vSAN RAID 6 proti výpadku až dvou nodů.
vSAN RAID 5 je technicky RAID 3+1, takže technické minimum pro RAID 5 jsou 4 nody a doporučených nodů je 5, aby v případě dlouhodobého výpadku jednoho z nodů bylo možné data zrebuildovat (resynchronizovat) na nějaký další node a zajistit ochranu dat.
vSAN RAID 6 je technicky RAID 4+2, takže technické minimum je 6 nodů a doporučovaných je 7 nodů.
Dlužno říci, že vSAN RAID 5 i RAID 6 jsou podporované jen na All Flash vSAN, takže na Hybridní vSAN, kde se používají v kapacitním tieru rotační disky, byste erasure coding hledali marně. Důvodem jsou vyšší nároky na I/O operace na backendu a rychlost rebuildu v případě výpadku jednoho z nodů.
Tím se dostáváme k podotázce ohledně výkonu. Každá implementace RAID 5 má negativní vliv na write operace, protože je při každé zápisové operaci potřeba dopočítat paritu. Zapisuje-li se jedna nová I/O operace, pak je potřeba před zapsáním segmentu na disk, přečíst původní segment (+1 I/O) a odpovídající paritu (+1 I/O) a při zápisu zapsat nejen nový segment (+1 I/O), ale i nově dopočítanou paritu (+1 I/O), takže celkově je pro 1 write I/O v RAID 5 potřeba 4 write I/O operace, čemuž se říká tzv. write penalty.
RAID 5 má tedy write penalty 4 a RAID 6 má write penalty 6.
