Toto je mýtus, který je v oblasti serverového hardwaru zcela běžný. V praxi jsou hyperkonvergovaná řešení (když je vše v jednom) potřeba pro mnoho věcí. Historicky první architektury vyvinuly Amazon a Google pro své služby. Pak bylo myšlenkou vytvořit výpočetní farmu z identických uzlů, z nichž každý měl své vlastní disky. To vše sjednotil nějaký systémotvorný software (hypervizor) a rozdělilo se na virtuální stroje. Hlavním cílem je minimální úsilí pro obsluhu jednoho uzlu a minimum problémů při škálování: stačí koupit dalších tisíc nebo dva stejné servery a připojit je poblíž. V praxi se jedná o ojedinělé případy a mnohem častěji se bavíme o menším počtu uzlů a trochu jiné architektuře.
Ale plus zůstává stejné - neuvěřitelná snadnost škálování a správy. Nevýhodou je, že různé úlohy různě spotřebovávají zdroje a někde bude hodně lokálních disků, jinde málo RAM a tak dále, to znamená, že pro různé typy úloh se využití zdrojů sníží.
Ukázalo se, že za snadné nastavení zaplatíte o 10–15 % více. To je to, co vyvolalo mýtus v názvu. Dlouho jsme hledali, kde by se technologie optimálně uplatnila, a našli jsme. Faktem je, že Cisco nemělo vlastní úložné systémy, ale chtělo kompletní serverový trh. A vytvořili Cisco Hyperflex – řešení s lokálním úložištěm na uzlech.
A to se najednou ukázalo jako velmi dobré řešení pro zálohovací datová centra (Disaster Recovery). Teď vám řeknu proč a jak. A ukážu vám klastrové testy.
Kde je potřeba
Hyperkonvergence je:
- Přenos disků do výpočetních uzlů.
- Plná integrace úložného subsystému s virtualizačním subsystémem.
- Přenos/integrace se síťovým subsystémem.
Tato kombinace vám umožňuje implementovat mnoho funkcí úložného systému na úrovni virtualizace a to vše z jednoho ovládacího okna.
V naší společnosti jsou projekty na navrhování redundantních datových center velmi žádané a často se volí hyperkonvergované řešení kvůli hromadě možností replikace (až po metrocluster) hned po vybalení.
V případě záložních datových center se obvykle bavíme o vzdáleném zařízení na místě na druhé straně města nebo úplně v jiném městě. Umožňuje vám obnovit kritické systémy v případě částečného nebo úplného selhání hlavního datového centra. Prodejní data se tam neustále replikují a tato replikace může být na úrovni aplikace nebo na úrovni blokového zařízení (úložiště).
Proto nyní budu hovořit o návrhu systému a testech a poté o několika reálných aplikačních scénářích s údaji o úsporách.
Testy
Naše instance se skládá ze čtyř serverů, z nichž každý má 10 SSD disků o velikosti 960 GB. K dispozici je vyhrazený disk pro ukládání operací zápisu do mezipaměti a ukládání virtuálního stroje služby. Samotné řešení představuje čtvrtá verze. První je upřímně hrubý (soudě podle recenzí), druhý je vlhký, třetí je již poměrně stabilní a toto lze nazvat vydáním po skončení beta testování pro širokou veřejnost. Během testování jsem nezaznamenal žádné problémy, vše funguje jako hodinky.
Změny ve verzi 4Byla opravena spousta chyb.
Zpočátku mohla platforma pracovat pouze s hypervizorem VMware ESXi a podporovala malý počet uzlů. Také proces nasazení nekončil vždy úspěšně, některé kroky bylo nutné restartovat, byly problémy s aktualizací ze starších verzí, data v GUI se ne vždy zobrazovala korektně (i když stále nejsem spokojený se zobrazením grafů výkonu ), někdy se objevily problémy na rozhraní s virtualizací.
Nyní jsou všechny problémy z dětství opraveny, HyperFlex zvládne ESXi i Hyper-V a navíc je možné:
- Vytvoření roztaženého clusteru.
- Vytvoření clusteru pro kanceláře bez použití Fabric Interconnect, od dvou do čtyř uzlů (nakupujeme pouze servery).
- Schopnost pracovat s externími úložnými systémy.
- Podpora kontejnerů a Kubernetes.
- Vytvoření zón dostupnosti.
- Integrace s VMware SRM, pokud vestavěná funkčnost není uspokojivá.
Architektura se příliš neliší od řešení svých hlavních konkurentů, nevytvořili kolo. Vše běží na virtualizační platformě VMware nebo Hyper-V. Hardware je hostován na proprietárních serverech Cisco UCS. Jsou tací, kteří platformu nenávidí pro relativní složitost prvotního nastavení, spoustu tlačítek, netriviální systém šablon a závislostí, ale jsou i tací, kteří se naučili zen, inspirovali se myšlenkou a už nechtějí pracovat s jinými servery.
Budeme zvažovat řešení pro VMware, protože řešení bylo původně vytvořeno pro něj a má více funkcí; Hyper-V bylo přidáno po cestě, aby drželo krok s konkurencí a splnilo očekávání trhu.
Existuje shluk serverů plný disků. K dispozici jsou disky pro ukládání dat (SSD nebo HDD - podle vašeho vkusu a potřeb), pro cachování je jeden SSD disk. Při zápisu dat do datového úložiště se data ukládají na cachovací vrstvu (vyhrazený SSD disk a RAM servisního VM). Paralelně je do uzlů v klastru odeslán blok dat (počet uzlů závisí na faktoru replikace klastru). Po potvrzení ze všech uzlů o úspěšném nahrávání je potvrzení nahrávání odesláno do hypervizoru a následně do VM. Zaznamenaná data jsou deduplikována, komprimována a zapsána na úložné disky na pozadí. Velký blok se přitom na úložné disky zapisuje vždy a sekvenčně, což snižuje zatížení úložných disků.
Deduplikace a komprese jsou vždy povoleny a nelze je zakázat. Data se čtou přímo z úložných disků nebo z mezipaměti RAM. Pokud je použita hybridní konfigurace, jsou čtení také ukládána do mezipaměti na SSD.
Data nejsou vázána na aktuální umístění virtuálního stroje a jsou rovnoměrně distribuována mezi uzly. Tento přístup umožňuje zatížit všechny disky a síťová rozhraní rovnoměrně. Je zde zřejmá nevýhoda: nemůžeme co nejvíce snížit latenci čtení, protože neexistuje žádná záruka místní dostupnosti dat. Ale věřím, že je to menší oběť ve srovnání s přijatými výhodami. Navíc zpoždění sítě dosáhla takových hodnot, že prakticky neovlivňují celkový výsledek.
Za celou logiku provozu diskového subsystému je zodpovědný speciální servisní řadič VM Cisco HyperFlex Data Platform, který je vytvořen na každém storage nodu. V naší konfiguraci servisního VM bylo přiděleno osm vCPU a 72 GB RAM, což není tak málo. Připomenu, že samotný hostitel má 28 fyzických jader a 512 GB RAM.
Servisní virtuální počítač má přístup k fyzickým diskům přímo předáním řadiče SAS virtuálnímu počítači. Komunikace s hypervisorem probíhá prostřednictvím speciálního modulu IOVisor, který zachycuje I/O operace, a pomocí agenta, který umožňuje posílat příkazy do API hypervisoru. Agent je zodpovědný za práci se snímky a klony HyperFlex.
Diskové prostředky jsou připojeny k hypervisoru jako sdílené složky NFS nebo SMB (v závislosti na typu hypervizoru hádejte, který je kde). A pod kapotou se jedná o distribuovaný souborový systém, který vám umožňuje přidat funkce plnohodnotných úložných systémů pro dospělé: alokaci tenkého svazku, kompresi a deduplikaci, snímky pomocí technologie Redirect-on-Write, synchronní/asynchronní replikaci.
Servisní VM poskytuje přístup k rozhraní WEB správy subsystému HyperFlex. Existuje integrace s vCenter a lze z něj provádět většinu každodenních úkolů, ale například datová úložiště je pohodlnější vyjmout ze samostatné webové kamery, pokud jste již přešli na rychlé rozhraní HTML5 nebo používáte plnohodnotného Flash klienta s plnou integrací. Na webové kameře služby můžete sledovat výkon a podrobný stav systému.
V clusteru existuje další typ uzlu – výpočetní uzly. Mohou to být rackové nebo blade servery bez vestavěných disků. Tyto servery mohou provozovat virtuální počítače, jejichž data jsou uložena na serverech s disky. Z hlediska přístupu k datům není mezi typy uzlů žádný rozdíl, protože architektura zahrnuje abstrakci od fyzického umístění dat. Maximální poměr výpočetních uzlů k uzlům úložiště je 2:1.
Použití výpočetních uzlů zvyšuje flexibilitu při škálování zdrojů clusteru: pokud potřebujeme pouze CPU/RAM, nemusíme kupovat další uzly s disky. Navíc můžeme přidat blade klec a ušetřit za umístění serverů do racku.
Výsledkem je hyperkonvergovaná platforma s následujícími funkcemi:
- Až 64 uzlů v clusteru (až 32 uzlů úložiště).
- Minimální počet uzlů v clusteru jsou tři (dva pro cluster Edge).
- Mechanismus redundance dat: zrcadlení s replikačním faktorem 2 a 3.
- Metro cluster.
- Asynchronní replikace virtuálních počítačů do jiného clusteru HyperFlex.
- Organizace přepínání virtuálních počítačů do vzdáleného datového centra.
- Nativní snímky využívající technologii Redirect-on-Write.
- Až 1 PB využitelného prostoru při replikačním faktoru 3 a bez deduplikace. Nebereme v úvahu replikační faktor 2, protože to není možnost pro seriózní prodeje.
Dalším velkým plusem je snadná správa a nasazení. O veškerou složitost nastavení serverů UCS se postará specializovaný VM připravený inženýry Cisco.
Konfigurace zkušební stolice:
- 2 x Cisco UCS Fabric Interconnect 6248UP jako řídicí cluster a síťové komponenty (48 portů pracujících v režimu Ethernet 10G/FC 16G).
- Čtyři servery Cisco UCS HXAF240 M4.
Vlastnosti serveru:
procesor
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
Síť
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G ethernetové porty
Úložiště HBA
Cisco 12G Modular SAS Pass through Controller
Úložné disky
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Více možností konfiguraceKromě vybraného hardwaru jsou aktuálně k dispozici následující možnosti:
- HXAF240c M5.
- Jeden nebo dva procesory od Intel Silver 4110 po Intel Platinum I8260Y. Druhá generace k dispozici.
- 24 paměťových slotů, proužky od 16 GB RDIMM 2600 do 128 GB LRDIMM 2933.
- Od 6 do 23 datových disků, jeden vyrovnávací disk, jeden systémový disk a jeden spouštěcí disk.
Kapacitní disky
- HX-SD960G61X-EV 960GB 2.5palcový Enterprise Value 6G SATA SSD (1X výdrž) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 palce Enterprise Value 6G SATA SSD (1X výdrž) SAS 3.8 TB.
- Ukládání disků do mezipaměti
- HX-NVMEXPB-I375 375GB 2.5palcový Intel Optane Drive, extrémní výkon a odolnost.
- HX-NVMEHW-H1600* 1.6 TB 2.5 palce Ent. Perf. NVMe SSD (3X výdrž) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 palce Ent. Perf. 12G SAS SSD (10X výdrž) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5palcový Ent. Perf. 12G SAS SED SSD (10X výdrž) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5" Enterprise performance 12G SAS SSD (3x výdrž).
Systémové/logové jednotky
- HX-SD240GM1X-EV 240GB 2.5palcový Enterprise Value 6G SATA SSD (Vyžaduje upgrade).
Spouštěcí jednotky
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Připojte se k síti přes 40G, 25G nebo 10G Ethernet porty.
FI může být HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Samotný test
K testování diskového subsystému jsem použil HCIBench 2.2.1. Jedná se o bezplatný nástroj, který vám umožňuje automatizovat vytváření zátěže z více virtuálních strojů. Samotné zatížení je generováno obvyklým fio.
Náš cluster se skládá ze čtyř uzlů, replikační faktor 3, všechny disky jsou Flash.
Pro testování jsem vytvořil čtyři datová úložiště a osm virtuálních strojů. U testů zápisu se předpokládá, že disk mezipaměti není plný.
Výsledky testu jsou následující:
100% čtení 100% náhodné
0 % Čtení 100 % Náhodné
Hloubka bloku/fronty
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36 ms 374348 IOPS
2.47 ms 414116 IOPS
4,86 ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Tučným písmem jsou označeny hodnoty, po jejichž překročení nedochází ke zvýšení produktivity, někdy je viditelná i degradace. Je to dáno tím, že jsme limitováni výkonem sítě/řadičů/disků.
- Sekvenční čtení 4432 MB/s.
- Sekvenční zápis 804 MB/s.
- Pokud jeden řadič selže (selhání virtuálního počítače nebo hostitele), pokles výkonu je dvojnásobný.
- Pokud selže úložný disk, čerpání je 1/3. Přestavba disku zabere 5 % zdrojů každého řadiče.
Na malém bloku jsme omezeni výkonem řadiče (virtuálního stroje), jeho CPU je zatíženo na 100 % a při navýšení bloku jsme limitováni šířkou pásma portu. 10 Gbps nestačí k odemknutí potenciálu systému AllFlash. Bohužel parametry poskytnutého demo stojanu nám neumožňují otestovat provoz na 40 Gbit/s.
Podle mého dojmu z testů a studia architektury díky algoritmu, který umisťuje data mezi všechny hostitele, získáme škálovatelný, předvídatelný výkon, ale to je také omezení při čtení, protože by bylo možné vymáčknout více z místních disků, zde může ušetřit produktivnější síť, například je k dispozici FI s rychlostí 40 Gbit/s.
Omezením může být také jeden disk pro cachování a deduplikaci, ve skutečnosti v tomto testbedu můžeme zapisovat na čtyři SSD disky. Bylo by skvělé mít možnost zvýšit počet jednotek pro ukládání do mezipaměti a vidět rozdíl.
Skutečné použití
K uspořádání zálohovacího datového centra můžete použít dva přístupy (neuvažujeme o umístění zálohy na vzdálené místo):
- Aktivní pasivní. Všechny aplikace jsou hostovány v hlavním datovém centru. Replikace je synchronní nebo asynchronní. Pokud selže hlavní datové centrum, musíme aktivovat záložní. To lze provést ručně/skripty/orchestrační aplikace. Zde dostaneme RPO úměrné frekvenci replikace a RTO závisí na reakci a dovednostech správce a kvalitě vývoje/ladění plánu přepínání.
- Aktivní-Aktivní. V tomto případě se jedná pouze o synchronní replikaci, dostupnost datových center je určována kvorem/arbitrem umístěným výhradně na třetím místě. RPO = 0 a RTO může dosáhnout 0 (pokud to aplikace umožňuje) nebo rovné době převzetí služeb při selhání uzlu ve virtualizačním clusteru. Na úrovni virtualizace je vytvořen roztažený (Metro) cluster, který vyžaduje úložiště Active-Active.
Obvykle vidíme, že klienti již v hlavním datovém centru implementovali architekturu s klasickým úložným systémem, a tak navrhujeme další pro replikaci. Jak jsem již zmínil, Cisco HyperFlex nabízí asynchronní replikaci a vytváření roztaženého virtualizačního clusteru. Zároveň nepotřebujeme dedikovaný úložný systém úrovně Midrange a vyšší s drahými replikačními funkcemi a Active-Active přístupem k datům na dvou úložných systémech.
Scénář 1: Máme primární a záložní datová centra, virtualizační platformu na VMware vSphere. Všechny produktivní systémy jsou umístěny v hlavním datovém centru a replikace virtuálních strojů se provádí na úrovni hypervizoru, což zabrání tomu, aby byly virtuální počítače zapnuté v záložním datovém centru. Replikujeme databáze a speciální aplikace pomocí vestavěných nástrojů a udržujeme virtuální počítače zapnuté. Pokud selže hlavní datové centrum, spustíme systémy v záložním datovém centru. Věříme, že máme asi 100 virtuálních strojů. Zatímco je primární datové centrum v provozu, v pohotovostním datovém centru mohou běžet testovací prostředí a další systémy, které lze vypnout, pokud se primární datové centrum přepne. Je také možné, že použijeme obousměrnou replikaci. Z hardwarového hlediska se nic nezmění.
V případě klasické architektury nainstalujeme do každého datového centra hybridní úložný systém s přístupem přes FibreChannel, vrstvením, deduplikací a kompresí (ne však online), 8 servery pro každou lokalitu, 2 přepínače FibreChannel a 10G Ethernet. Pro správu replikace a přepínání v klasické architektuře můžeme využít nástroje VMware (Replication + SRM) nebo nástroje třetích stran, které budou o něco levnější a někdy i pohodlnější.
Obrázek ukazuje schéma.
Při použití Cisco HyperFlex získáte následující architekturu:
Pro HyperFlex jsem použil servery s velkými zdroji CPU/RAM, protože... Některé prostředky půjdou do VM řadiče HyperFlex, z hlediska CPU a paměti jsem dokonce trochu překonfiguroval konfiguraci HyperFlex, abych si nehrál s Cisco a zaručil zdroje pro zbývající VM. Můžeme ale opustit přepínače FibreChannel a nebudeme potřebovat ethernetové porty pro každý server, místní provoz se přepíná v rámci FI.
Výsledkem byla následující konfigurace pro každé datové centrum:
Servery
8 x 1U Server (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Hybridní úložný systém s FC Front-End (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet switch 10G 12 portů
-
SAN
2 x FC switch 32/16Gb 24 portů
2 x Cisco UCS FI 6332
Licence
VMware Ent Plus
Replikace a/nebo orchestrace přepínání virtuálních počítačů
VMware Ent Plus
Neposkytoval jsem licence na replikační software pro Hyperflex, protože je pro nás k dispozici ihned po vybalení.
Pro klasickou architekturu jsem zvolil dodavatele, který se etabloval jako kvalitní a levný výrobce. U obou variant jsem uplatnil standardní slevu na konkrétní řešení a ve výsledku jsem dostal reálné ceny.
Řešení Cisco HyperFlex vyšlo o 13 % levněji.
Scénář 2: vytvoření dvou aktivních datových center. V tomto scénáři navrhujeme roztažený cluster na VMware.
Klasická architektura se skládá z virtualizačních serverů, SAN (FC protokol) a dvou úložných systémů, které mohou číst a zapisovat na svazek natažený mezi nimi. Na každý úložný systém vkládáme užitečnou kapacitu pro skladování.
V HyperFlex jednoduše vytvoříme Stretch Cluster se stejným počtem uzlů na obou stránkách. V tomto případě se použije replikační faktor 2+2.
Výsledkem je následující konfigurace:
klasické architektury
HyperFlex
Servery
16 x 1U Server (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
SHD
2 x úložný systém AllFlash (150 TB SSD)
-
LAN
4 x Ethernet switch 10G 24 portů
-
SAN
4 x FC switch 32/16Gb 24 portů
4 x Cisco UCS FI 6332
Licence
VMware Ent Plus
VMware Ent Plus
Ve všech výpočtech jsem nezohlednil síťovou infrastrukturu, náklady datového centra atd.: ty budou stejné pro klasickou architekturu i pro řešení HyperFlex.
Z hlediska nákladů se ukázal HyperFlex o 5 % dražší. Zde stojí za zmínku, že pokud jde o zdroje CPU/RAM, měl jsem u Cisco výkyv, protože v konfiguraci jsem kanály řadiče paměti zaplnil rovnoměrně. Náklady jsou o něco vyšší, ale ne o řád, což jasně ukazuje, že hyperkonvergence není nutně „hračkou pro bohaté“, ale může konkurovat standardnímu přístupu k budování datového centra. To může být také zajímavé pro ty, kteří již mají servery Cisco UCS a odpovídající infrastrukturu pro ně.
Mezi výhody patří absence nákladů na správu SAN a úložných systémů, online komprese a deduplikace, jediný vstupní bod pro podporu (virtualizace, servery, jsou to také úložné systémy), úspora místa (ale ne ve všech scénářích), zjednodušení provozu.
Co se týče podpory, zde ji získáte od jednoho dodavatele – Cisco. Soudě podle mých zkušeností se servery Cisco UCS se mi to líbí; nemusel jsem to otevírat na HyperFlex, všechno fungovalo stejně. Inženýři reagují pohotově a dokážou vyřešit nejen typické problémy, ale i složité okrajové případy. Někdy se na ně obracím s otázkami: „Je to možné, nasuň to? nebo „Něco jsem zde nakonfiguroval a nechce to fungovat. Pomoc!" - trpělivě tam najdou potřebného průvodce a upozorní na správné kroky, neodpoví: "Řešíme pouze hardwarové problémy."
reference
- Můj mail - [chráněno e-mailem]
Zdroj: www.habr.com