HPE Simplivity – első rész

A közepébe vágok…felmerülhet a kérdés, hogy miért ilyen sok a HPE tartalom a blogon. A válasz egyszerű: tőlük kapok tesztre eszközöket és szerencsére szabad kezet is, írhatom azt amit szeretnék. Ha a DellEMC, Cisco vagy akárki biztosítana hasonló lehetőséget, akkor azokat szintén kivesézném.

Mi az a HCI?

Maga a HCI nem egy új megközelítés, de az elmúlt 3-4 évben került rá a fókusz. A processzorok fejlődése, az SSD-k előretörése, a 10Gbit+ portok elterjedése gyorsítottan katalizálta a kategória kifejlődését. Arról van szó, hogy adott egy teljesen szabványos x86 alapú rendszer – ami szinte minden esetben Intel Xeon processzort(okat) jelent – amiben van pár HDD+SSD, valamilyen compute-virtualizációs réteg és maga a tárolót elérhetővé tévő szoftveres megoldás. A legjobb HCI rendszerek, a tároló menedzsmentjét a virtualizációs menedzsmenttel egyesítik. Így például a vCenter-be épülő plug-in-ekkel.

Erre a sémára felépítve sok megoldás született, hogy csak párat említsek:

  • VSAN:
    • DellEMC VXrail
    • VSAN ready node
    • Build your own
  • Nutanix
  • HPE HC + StoreOnce VSA
  • HPE Simplivity
  • Netapp HCI
  • Microsoft S2D
  • Cisco Hyperflex

A VSAN ugye eredendően egy vSphere ESXi “funckió” ezért korábban több hardvergyártónál is volt olyan dobozos, készen érkező rendszer amiben ténylegesen üzemre készen lehetett megvenni a rendszert, ez volt a VXrail. Aztán ez szépen lassan, különböző okok miatt, mára a DellEMC-re szűkült – nem mellesleg a VMware a DellEMC családjába tartozik. Ma már a VXrail, a kulcsrakész VSAN, csak a DellEMC kínálatában található meg. Ha VSAN kell mindenképpen, akkor léteznek VSAN ready node-ok, sok-sok gyártó kínálatában és ezek plecsnivel rendelkeznek abban a tekintetben, hogy működnek a VSAN-nal. Az építsd magadról nincs mit mondani, ha egyenként az eszközök egyébként VSAN kompatibilisek, akkor építhető belölük működő rendszer, de a támogatás a komponensek tekintetében egyedi lesz, a frissítés pedig rémálom.

A Nutanix egy jó megoldás, több virtualizációval elérhető, de nem lövöm el a puskaport, lesz még a jövőben róla szó.

A HPE HC + VSA a kedvencem. Emlékszem egy oktatásra a HP-nál – igen, akkor még HP volt – ahol késhegyre menő vitát folytattam az oktatóval arról, hogy a Lefthand P2000 aka StoreOnce VSA, egy kakukktojás. Egy letűnt kor, kőkorszaki fosszíliája. Ez egy virtuális gép, aminek oda van adva sok kapacitás, hogy tegye elérhetővé a többi hoszt számára iSCSI-n. Ez, soha az életben nem lehet – és nem is lett – jobb, mint egy picit mélyebben integrálódó SDS – Software Defined Storage.

Netapp HCI: Úgy vagyok vele, hogy se jót sem rosszat, amíg nem láttam és tapasztaltam. Ők próbálkoznak a diszaggregált HCI-val is, ami nem ördögtől való, de ez hol HCI, a szó tradicionális értelmében?

A HPE Simplivity egy megvásárolt termék, néhány éve megvette a HP/HPE. Kellett is nekik a korábban említett VSA helyett.

Egy ilyen node lényegében egy DL380 szerver – jelenleg Gen10 – ami tartalmaz pár SSD-t és egy speciális kártyát, amit OmniStack Accelerator Card-nak (OAC) hívnak. Ezen a kártyán van sok minden, csomó kondenzátor, NVRAM és egy speciális ASIC végzi rajta a deduplikációt/tömörítést, ezáltal tehermentesítve az x86 CPU-t.

A fenti ábrán van egy érdekes részlet, méghozzá a RAID-vezérlő. Sok megoldásnál, Ms SDS/VMware VSAN, jó az ha a RAID-vezérlő inkább csak HBA módban fut, nem végez semmiféle cache-elést, RAID-et pedig végképp nem kezel. A lényeg náluk az, hogy a lemezeket egy az egyben adják át az SDS szoftver számára. A Simplivity-nél, viszont a védelem első vonala pedig pontosan a RAID-vezérlő. Az ő feladata a szükséges blokkok letárolása a lemezeken, méhozzá RAID5/6 védelemmel. A Simplivity a védelem egyik szintjét delegálja arra a kártyára, ami ezt a legjobban csinálja.

Az OAC önmagában csak ez egyik része a megoldásnak, kell még hozzá egy – a beépített és hátul lévő lemezeken lévő – OmniCube controller VM is. Ez végzi a tároló prezentálását NFS-en, a metaadatok tárolását és a definiált beállítások mentén a replikációt, mentést és minden egyebet. Ez a virtuális gép minden node-on ott van egy Simplivity klaszterben és VMware terminológiában rezervált memóriával rendelkezik. Kell is neki, mivel ha a metaadatok kikerülnek host swap-ba, akkor úgy tíz nagyságrenddel lassabb lenne minden storage művelet. Összehasonlítva más megoldásokkal itt a kártya a legfőbb különbség, illetve a következő ábra értelmében az a fajta mentési/visszaállítási szolgáltatás, amit beépítve tartalmaz.

Ennek definiálása akár datastore policy alapon vagy virtuális gép szintjén is megvalósítható a szükséges mentési/megőrzési és védelmi stratégia mentén. Kihangsúlyozom ez elsődleges mentés, mivel az a mentés amit magán a mentett rendszeren tárolunk – jobb esetben egy másik HPE Simplivity klaszteren – nem teljes kópia. Nyilvánvaló, hogy több hibaeseménynek kell együttesen fellépnie, hogy az aktív adat elveszése mellett a mentett adat is használhatatlanná váljon, de ekkor is gondolni kell a külső mentésre, amihez pedig kell valami szoftver ami képes például szalagos egység kezelésére vagy szofisztikáltabb katalógus szintű mentési módra. Ettől függetlenül a mentés módja és megvalósítása, amolyan “mindenképpen használd” funkció, mert nagyon gyors és nagyon kevés helyet igényel, méghozzá ezért:

  1. A VM írni próbál a saját VMDK lemezére
  2. Mivel a Simplivity klaszterben NFS-en prezentált minden datastore, ezért a datastore-t kezelő OmniStack Virtual Controller megkapja az írási műveletet.
  3. Mielőtt bármit csinálna elküldi az I/O-t a párjának – a példában két Simplvitiy node van – majd párhuzamosan feldolgozzák azt, az OmniStack kártyán lévő RAM-ba helyezve azt – nyugalom, védi tápellátás és flash is.
  4. Ha végeztek a feldolgozással és a második Virtual Controller is visszaigazolta az írás feldolgozását
  5. akkor az elsődleges Virtual Controller visszaigazolja a hoszt számára az írás megtörténtét
  6. Teljesen függetlenül a teljes fenti művelettől az Virtual Controller optimalizálja az ilyen írási műveleteket és és teljes sorba rendezett blokkokba írja le a RAID-vezérlő segítségével.

Az olvasás módja nem ilyen bonyolult, ott elegendő az egyik példányról olvasni:

  1. A virtuális gép szeretne olvasni a lemezéről.
  2. Az olvasási művelet a Virtual Controller-hez kerül – azon a gépen ahol a VM fut. A VC minden blokk elhelyezkedéséről tud, amit valaha a klaszter bármely tagja leírt.
  3. a: Amennyiben a VC cach-ében megtalálható a kért blokk, akkor kiszolgálja.
    b: Ha nincs a RAM-ban, akkor az SSD-ről olvassa fel a szükséges blokkot.
  4. A kért blokk átadásra kerül a VM számára az NFS-en keresztül.

Hogy hol van a trükk a rendszerben? Ott, hogy 8K-s blokkokkal dolgozva, minden egyes blokkot csak kétszer ír le egy klaszterben a tárolásra használt SSD kötetre. Tehát mikor bejön egy írás, akkor a Virtual Controller rögvest megnézi, hogy leírta-e már ezt a blokkot ő vagy más VC a klaszterben. Ha nem írta még le, akkor nincs kérdés, tárolnia kell, majd a szükséges metaadatot a saját RAM-jában lejegyezve, nyugtázni az írást.

Ha azonban ez a 8K-s blokkot már leírta, akkor csak egy pointer kerül bejegyzésre, írás valójában nem történik. Ezáltal az alábbi videóban jól látható, hogy az SDS réteg elég erősen szűri az írások mennyiségét és nyilvánvalóan jó hatással van a tárolási kapacitás effektív kihasználására.

Ez a képesség teszi lehetővé azt is, hogy snapshot-okat, mentéseket készítsen a rendszer egy másodperc alatt. Szintén így képes visszaállítani akár egy 1TB méretű VM-et 60 másodperc alatt vagy éppen leklónozni bármit. Itt tényleges klónozás nincs, csak a mutatókat módosítja úgy hogy létrejön egy újabb VM, teljesen azonos lemeztartalommal mint az eredeti. Ugyanakkor fontos az, hogy a VMware terminológiában ez nem linked clone, hanem teljesen független VM.

Hány node-ra van szükség?

Kettőre minimum és ha csak kettő van akkor be lehet őket kötni egymással közvetlenül is, anélkül hogy az ügyfélnek számolni kelljen 10Gbit-es switch-ekkel. Mondanom sem kell, de az SDS-nél a gyors hálózat kiemelten fontos. Ez látható az alábbi kép bal oldalán.

A két node, egymással redundáns 10Gbit-en van összekötve, míg a LOM-ként kért interfészeken történik minden más, nem Simplivity generált forgalom, mint a vMotion, a menedzsment forgalom és a VM-ek produktív elérése. Szerintem sejthető, mi a legnagyobb hátránya ennek a közvetlen összeköttetésnek…..az hogy hármat bekötni redundánsan és nem daisy chain-be bekötni, nem nagyon lehet a tudomány jelenlegi állása szerint. Szóval ha három vagy több node kell, akkor a jobb oldalon látható, redundáns switch-pár féle bekötést javaslom, illetve akkor is, ha záros határidőn belül a kettő node mellé, kerülne egy harmadik is.

A szemfülesebb emberek már gondolom azon agyalnak, hogy hogyan lesz itt klaszter, ha két node van csak. Hogy jön össze a klaszterekben oly hőn áhított többség a split-brain elkerülésére?

Arbiter

Az Arbiter segítségével. Jelenleg ez egy Windows-t igényel és egy ténylegesen zéró szükséglettel bíró szolgáltatás. A gyártó dokumentációja – alább – megköveteli azt, hogy természetesen ne saját magán a klaszteren futtassuk azt a VM-et, amibe ez telepítve van:

Overview Review these requirements before installing the SimpliVity Arbiter on the computer hosting a vCenter Server, or on a different Windows computer. Important The Arbiter application ensures the resiliency of the Federation by acting as a tie-breaking vote in datacenter or cluster failure scenarios that include an even number of OmniStack hosts. It must run on the computer hosting vCenter Server or on another Windows computer. Do not install it on a virtual machine that resides on an OmniStack host or any host that uses a SimpliVity datastore. Installing the Arbiter on a computer outside the Federation ensures its availability.

A Windows-os vCenter Server alkonyán már nem nagyon javaslom csak azért Windows-ra térni a vCenter Server-el, mert rajta kell futtatni az Arbitert. Bármilyen gép jó, csak a node-ok érjék el és ne önmagukon fusson. Fontos, hogy egy és csak egy Arbiter lehet egy klaszterben – magától értetődik amúgy.

De miért jó ha több node van egy klaszterben?

Azért mert minden adatot duplán tárol egy klaszter, függetlenül attól, hogy mennyi node alkotja, így ha a klasztert két node-os hiba éri (esélye azért ennek elég alacsony), akkor:

  • ha 2 node van, akkor mindkettőn ott van az adat, de mindkettő elérhetetlen – 100%-a a gépeknek kiesik.
  • ha 3 node van, akkor máris csak 33% a virtuális gépek kitettsége, dupla hiba esetén.
  • ha 4 node van, akkor 16,7%.
  • ha 5 node van, akkor 10%.

Maximálisan 16 szerver lehet egy klaszterben. Viszont mivel NFS-en prezentált a tároló, ezért kiadható bármilyen kiszolgálónak, ami lehet igazából bármi. Ez mondjuk a migráció idejére is javallott, de akár permanens módon is működhet.

Ez azért van, mert minden egyes VM-nél létrejön egy párosítás. Azaz kiválasztásra kerül egy elsődleges és egy másodlagos node is. Ha több node van, akkor több a kombináció is.

RAINKombinációk
Node ANode B1 db – AB
Node ANode BNode C3 db – AB,AC,BC
Node ANode BNode CNode D6db – AB,AC,AD,BC,BD,CD
Node ANode BNode CNode DNode E10db – AB,AC,AD,AE,BC,BD,BE,CD,CE,DE

A hibatűrés szintjei

A beépített mentés, fájl- és VM-szintű visszaállíthatóságot tesz lehetővé, eredeti helyre, új VM formájában is.

A node-ban ott van a RAID5/6 védelem, a szerver minden redundáns komponense – hűtés,táp,NIC stb.

Klaszterek szintjén a fentebb is ismeretett RAIN védelem és maga a virtualizáció HA képessége (vSphere HA vagy Microsoft Hyper-V Failover Cluster)

Klaszterek között a federáció lehetősége, ami DR-re ad lehetőséget, mentéssel.

Hogy skálázódik?

Több lehetőség is van a bővítésre, attól függően miben fogyott el a környezet. Ha tárolási kapacitásban, akkor lehet csak SSD-kkel bővíteni a node-okat. Természetesen szimmetrikusan és nem egyetlen lemezenként, hanem csomagban.

Ha a számítási kapacitás fogyott el vagy éppen már a teljes kapacitást elérték a node-ok, akkor egy-egy újabb node vásárlásával lehet bővíteni.

Ilyen modellek vannak:

A RAID oszlopban, fontos észrevenni az eXtraSmall és a Small kiépítés esetén a RAID5 védelmet. Ezekben a lemezek száma miatt csak ez elérhető. Itt számolni kell azzal, hogy ha egy node-ban kiesik egy lemez, majd még egy – kicsi az esély – akkor az a node lényegében csak compute-ként szolgál majd a diszkek cseréjéig. Tehát nem lesz használhatatlan, rajta futnak tovább a VM-ek, kiesés nincs, de ő nem vess részt a tároló lokális előállításában.

A következő részben a Simplivity telepítésével, menedzsmentjével és hálózati részleteivel foglalkozom.