Nimble dHCI 2.0

Tagja vagyok egy Yammer csoportnak, ahol HPE partnerek osztják meg tapasztalataikat, vitatnak meg kérdéseket és több témában. Az egyik ilyen, a Nimble dHCI és kicsit furcsán érzem magam, amikor arról olvasok, hogy ki hányadik ilyen rendszerét üzemeli be az ügyfélnek, mennyi tapasztalata van vele. Mondanom sem kell, hogy nem hazánkról van szó, hanem általában vagy nyugatra, vagy északra valamelyikről.

Én is beszéltem/írtam már a dHCI-ről korábban, de valahogy egyelőre még nem nagyon került be a körforgásba, annak ellenére, hogy több előnye van mint hátránya. Elég sok fejlesztés is érinti, tekinthető igen nagy fókuszú csomagnak a gyártónál.

Léteznek konvergens és hiperkonvergens rendszerek és mindkettőre jellemző a következő három igényre fókuszált segítségük:

  • Agilitás: gyors telepíthetőség, amely maximális mértékben automatizált.
  • Szabványosítás: a felhasznált hardverek, azok beállítása teljesen mindegy hányszor kerül végrehajtásra, mindig azonos lesz a végállapot. Ha két ilyen rendszert veszek és két teljesen különböző ember “telepíti”, nem lesz különbség.
  • Egyszerűség: az üzemeltetés és a karbantartás legyen egyszerű és szintén automatizált, illetve a rendszer támogatása a teljes megoldásra vonatkozzon.

HCI

Nézzük először a HCI-t. Mindenki ismeri mi ez, sok ilyen van a piacon. Egy dolog közös bennük, alapértelmezetten – és az ajánlottak alapján – x86-os szerverekben elhelyezett tárolók (SSD/HDD) virtualizált közös tárolóvá alakítása, illetve a CPU/RAM/stb erőforrások virtualizációja. A közös tároló funkcionalitásában közös és hozza az vállalati közös tárolók képességeinek jó részét, azonban a tárolás a node-okra vetítve osztott – remélem senki sem használ RAID0-t stb – illetve az ilyen tárolási forgalmat IP hálózaton bonyolítják.

Csak a példa kedvéért ilyen a VSAN (DellEMC VXrail, VSAN Ready Node-ok), a HPE Simplivity, Nutanix, Microsoft S2D stb.

Na mi a fenti példával a baj? A bővíthetőség, de inkább nézzük is meg miért az. Legyen két eset:

  • elfogyott a CPU/RAM a hosztokban
  • elfogyott a tárkapacitás

Teljesen mindegy melyik következett be, a szükséges lépés a bővítés, méghozzá egyenletes bővítés. Ha még van RAM modul/HDD/SSD hely a szerverekben, akkor az szerencse, mert csak fel kell bővíteni a szükséges mértékben mindet – javasolt a kiegyensúlyozott rendszer. Ha nincs rá lehetőség, akkor újabb node-ot kell vásárolni. Itt érezhető a probléma, elfogyott a tárkapacitás, szóval egy újabb node-ot kell beszereznem – és ezzel licenszelni a VMware/HyperV-t, a mentőszoftvert stb az új node-ra is – pusztán a tárhely miatt? Igen! Igaz ez arra is, ha elfogyott a RAM, akkor is vegyek meg egy újabb node-ot, mikor a tárkapacitásra egyáltalán nincs szükségem?

Kis túlzással igen, mert bár vannak úgynevezett “compute only” szerverek, amelyek CPU/RAM erőforrást adnak a közösbe, de tárkapacitást nem, illetve van olyan gyártó ahol a fordítottja is elérhető.

Diszaggregált HCI

Na ezt nevezik diszaggregációnak, mikor szétválasztjuk a compute és storage részeket. Ez most szép pofon, érzem én.

Pont ebben a kategóriában utazik a Nimble dHCI, bár nem teljesen.

Nimble dHCI – alapok

Azt már kifejtettem hogy mi az a diszaggregált hiperkonvergens rendszer. A dHCI mégis más, mivel – kapaszkodj – nincs software defined storage benne. Jogosan merül fel a kérdés, hogy ez mitől hiperkonvergens akkor? A használat módja teszi azzá, a HCI rendszerek mindig könnyen beüzemelhetők voltak, frissíteni sem volt túl bonyolult őket, de mindenképpen egy barátságosabban telepíthető rendszer jellemezte őket.

Picit szebb képen ez az HPE Nimble dHCI.

Ezek elapján nyilván meg lehet építeni hasonlót kézzel is, de itt a tévedés. Tételezzük fel, hogy ez egy új beszerzés és nem használunk fel semmit ami rendelkezésre áll már.

Rendelsz 2-3 HPE Proliant szervert, telepíted őket VMware vSphere ESXi-vel – HPE ESXi custom ISO!!! Veszel két switch-et, beállítod azokat is, majd beszerzel egy bármilyen Nimble tárolót és felkonfigurálod. Ha ez mind megvan, akkor végrehajtod a következőket:

  • kiadsz egy datastore-et a Nimble-ről az ESXi-k számára.
  • leformázod a datastore-t
  • felteszel egy vCenter Server Appliance-ot
  • létrehozod a vCenter-ben a datacenter-t, a cluster-t
  • becsatolod alá az ESXi-ket
  • licenszeled őket
  • stb.

Kérdés, hogy ez mennyi időt vesz igénybe, ha egyszer végrehajtod, majd fél év múlva egy másik telephelyen újra, akkor a két végeredmény egyezik-e majd. Nem fog.

Ezzel szemben a dHCI esetén a folyamat egy lépéssé redukálódik, mivel egyetlen varázsló és a mögötte lévő automatizáció teszi meg mindezt helyetted, ezáltal a lépés(ek?):

  • bekötsz mindent
  • a varázslóba beírod az IP-ket, neveket, licenszeket

A végén pedig kapsz egy vCSA-t, benne egy ESXi klaszterrel, készen arra, hogy az első VM-et létrehozd.

A dHCI rendelése és támogatása is egyetlen pontban valósul meg, a HPE támogatja a teljes stack-et, így ha gond van bármelyik részével, ők dolgoznak a megoldáson, nem teszik rá a telefont valakire csak azért mert a Cisco Nexus switch-el van gond.

Milyen elemekből áll?

A dHCI 2.0 éppen most jelent meg, ami jelentős változásokat hozott mind az automatizáció terén, mind a benne kapható termékek körében.

Compute

Lehet kapni tulajdonképpen az összes HPE Proliant DL3XX és 5XX szerverrel – legalább kettőt kell venni. Greenfield esetén ezek úgy érkeznek a gyárból, hogy az ESXi fel van telepítve alapértelmezetten – nincs bekonfigurálva. Itt a legnagyobb a szabadság, mivel bármilyen processzor, memória (mennyiség) és opció használható, lényeg hogy legyen benne 10Gbit-es inferfész, mivel iSCSI-n keresztül csatlakozik a tárolóra.

Brownfield esetén pedig fel lehet használni akár már meglévő DL szervereket, természetesen a HPE ESXi ISO-val és Nimble Connection Manager-rel előtelepítve.

Network

Greenfield esetén a csomag része kettő darab 10Gbit-es switch is, amely nyilvánvalóan az iSCSI és egyéb forgalmak miatt szükséges.

  • HPE FlexFabric 5700/5710/5940/5945
  • HPE Aruba 8320/8325
  • HPE Mellanox SN2010M/SN2100/SN2410M/SN2700M

Brownfield esetén fontos a 10 Gbit/s támogatása és hogy azért képes legyen az iSCSI forgalmat magabiztosan intézni – flow control, jumbo frame stb.

Storage

Egy darab Nimble tároló, bármekkora méretben, hibrid/all-flash mindkettő, viszont fontos megjegyezni, hogy bár fizikailag a tároló azonos a nem dHCI Nimble tárolókkal, a firmware más a kontrollerekben. Azért is, mert az automatizált telepítéshez és egyéb funkciókhoz szükséges szoftver is a tárolón fut. Ez előre is vetíti azt, hogy a nem dHCI-s Nimble-ből nem lehet dHCI-s Nimble tárolót előállítani, azt csak a gyárban tudják megtenni.

Összefoglalva akkor greenfield és brownfield van, íme alább.

Előnyök

Kétségtelen, hogy a támogatás lényegében egyetlen ponton történik, a HPE Nimble támogatói csapatánál, ők end-to-end – zöldmező esetén – vagy bár a switch-ekre nem vonatkozóan – bár a konfiguráció ellenőrzésében segítenek – segítenek ha baj van.

Az Infosight átitatja a megoldást, a VM szinttől, a szervereken át, a tárolóig mindent lát és segít tervezni, hibát keresni, megoldani.

A frissítések bundle alapúak, tehát a komptibilitást nem kell ellenőrzini és varázslóból minden egyben frissíthető.

Szintén workflow alapon adható hozzá újabb hoszt a rendszerhez, vehető ki belőle. A vCenter-ből ki sem kell lépni, ha új volume kell a Nimble-ről.