Karácsonyra szeretném

Ha szabadon engedhetem a fantáziámat és tényleg csak a szakmai dolgokra gondolok, akkor a lista azokról, amiket szeretnék élőben látni/tesztelni/dolgozni, a következő módon alakulna:

  • Bármilyen szerver, NVDIMM modullal szerelve: Na ezt már sok-sok slide-on, technikai és marketing-anyagban láttam, de élőben még soha. Itt most nem annyira a SDS alkalmazhatóságára nézve érdekel, hanem abban, hogy a VM-ekben ez hogyan használható fel jól. Például egy az egyben rá lehet tenni egy VM-et – a VM home-ot mondjuk nem – ami például valami temporary kötetnek jó lehet. Igazából pont ez érdekel, hogy pontosan mire, hiszen az NVDIMM modul(ok) azok a szerveren lokálisak, ha valami probléma adódik, akkor az érintett VM-et HA nem képes védeni a közös tároló hiányának okán.
  • HPE Proliant DL325/385, csak az EPYC processzor végett. Puszta kíváncsiságból, hogy mire képes. Sok fórumon lemérték és letesztelték már, de jobban érdekel a saját tapasztalat.
  • Egy mobilis, guruló demó szett. Egy kis tároló – ide HCI nem jó – négy ESXi, ez megfejelve egy NSX-T telepítéssel.
  • Egy Nutanix demó kit AHV-val.
  • Valaki aki kifejti nekem, hogy miért a Synergy a legjobb platform a VSAN alá. Ezt rögtön ki is fejtem, de előtte itt a forrás: (link)

Szóval a Synergy-be tehető szerverekbe vagy 2 vagy 4 HDD/SSD illeszthető. Pont. Minden más bővítési lehetőség ezek számosságában és természetesen nem “külső” eszköz használatával – tehát nem külső tároló, iSCSI storage stb – csak a storage modul-lal lehetséges. (A “HPE Synergy – Második rész” már íródik) Ez a modul a D3940 és körülbelül így néz ki:

40 darab SFF lemez fér bele maximum, LFF változata nincs. Ebből máris következik az, hogy hibrid, elsősorban kapacitásra tervezni a megoldással nem lehet, mivel az SFF lemezek sem mérete, sem a méretükhöz mért áruk nem optimális. További fontos információ hogy NVMe támogatás nincs, hogy is lenne, ha ez itt SAS vezérlőn keresztül van csatolva. Egy ilyen modul mérete 2 bay, azaz kettő szerverrel kevesebb fér be egy ilyen frame-be, illetve szükség van legalább egy – de inkább kettő SAS interconnect-re és minden szerverbe SAS mezzanine-ra, amennyiben lemezeket akarunk kiosztani számukra az D3940-ről. Egy ilyen modul önmagában redundanás, mert a középső, szürke/fekete sor a fenti képen az IO module és abból is kettő van, és ha minden lemez dual port-os – javasolt – akkor tényleg nincs olyan, hogy a keretben lévő szerverek ne érnék el a lemezüket/lemezeiket. Na még egyszer az utóbbi mondat, befejezése “a keretben lévő szerverek“. A D3940-ből csak kereten belülre lehet diszkeket kiadni, hiába van több frame. Természetesen több D3940 is betehető egy frame-be, egészen pontosan maximum 4 darab. Ezzel 8 bay-t elfoglalva, hagyva 4-et a VSAN node-ok számára – így SY480 az egyetlen ami szóba jöhet. Az adatlapokon mindenhol az szerepel, hogy ezzel 200 lemez is felhasználható, de nálam a 4 x 40, az 160.

Ezzel a 160 lemezzel – és még 4 x 2-vel a szerverekben – túl is teljesül a VSAN licenszek maximális kihasználhatósága.

Viszont ezzel a teljes HCI környezetünk egy keretben van, ami bár teljesen redundáns, minden eleme hibatűrő és legalább kettő van belőle – hat táp, hat ventillátor, két VC module – vagy ki milyennel vásárolja – két SAS module – viszont elvitathatatlan, hogy ez egy keret. Sok ügyfélnél például egy Oracle RAC vagy az Exchange két lába, két különböző keretben van még adatközponton belül is, és nem azért mert nem redundáns a keret, hanem azért mert ők úgy határoztak, hogy ezekben a rendszerekben a keret a failure domain és nem a szerver.

Innen következik a következő tervezési sarokpont, azaz amennyiben az SDS megoldás failure domain-jét szeretnénk jól kezelni, akkor több keretbe kell elteríteni a VSAN klasztert. A fenti példából az egyik D3940-et az egyik keretbe, a másikat a másikba tenni, majd 2 node ide, 2 node oda. Már látod hová fut ki az egész ugye? Hibrid VSAN esetén R0 és R1 van. Az utóbbinál ha az FTT értéke 1 – azaz egy hibát legyen képes elviselni a rendszer – akkor két VSAN node-on lesz adat, a harmadikon pedig a witness komponens – és ez VM objektumonként változik, hogy melyik node-on, de minden esetben három komponens van. Na most ha az ügyfélnél a failure domain a keret, akkor ez itt egy stretched cluster és kell witness appliance, a kereteken kívül valahol.

Ha a failure domain nem a keret, hanem mégis a hoszt, akkor erre nincs szükség, viszont arra igen, hogy a két keret között legyen megfelelő, alacsony késleltetésű, magas sávszélességű link. Ha a két frame egy VC-be tartozik – lást első cikk – akkor ez rendelkezésre is áll, de ha nem akkor kicsit több munkával, de meg kell valósítani valahogyan.

Na értelmezem újra a korábban kialakult véleményem: Van olyan eset – ami nem a maximálisan kiépített hibrid design – amikor a Synergy jó platform a VSAN számára:

  • egy kereten belüli HCI, hibrid/all flash (részleges vagy teljes kiépítettség) ha a teljes kiépítettségnél elég a 4 node.
  • ha elfogadjuk hogy a keret teljesen hibatűrő és a szerverek esetleges hibájára tervezünk csak.
  • VSAN stretched cluster esetén

Reménykedem….