HPE Simplivity – második rész – Hands on

Biztosan nem új, de a HPE-nek is van SDS megoldása és erről korábban már olvashattál nálam.

Elmélet

Gyakorlat

Lehetőségem nyílt egy picit nagyobb környezetben bemutatni mit is tud a Simplvity.

Geneva (mint Genf) és Grenoble telephelyeken vannak egy-egy Simplivity klaszter – kis érdekesség hogy Genf a HPE Customer Innovation Center (CIC) lokációja, ahol annó volt szerencsém látni még az első napokban a Synergy-t és a HPE POD DC-ket.

Grenoble már elég régen még az ITO-ban is fő adatközpont volt Franciaországban és így volt az egyenrangú párjával is, Isle d’Abeau-ben. Sok ügyfélnek helyeztük el itt régen a szervereit. Na de ennyit a nosztalgiázásról, szóval itt nem Isle d’Abeau-van hanem Geneva, nem Franciaország, hanem Svájc.

Mindkét klaszterben két node van és egy arbiter természetesen. A vCenter Server-ek (VCSA) enhanced linked mode (ELM)-ben vannak, ezért az egyikbe bejelentkezve, látjuk a másik által kezelt entitásokat is. A Simplivity szintjén ez a “közös” működést Federation-nek hívják és ez klaszterek között is történik – federáció akkor létrejön ha két node van egy klaszterben.

Az arbiterről ejtsünk még pár szót, mert az kötelező elem minden telepítésben és SOHA ne legyen egy olyan gépbe telepítve, amely magán a Simplivity klaszteren fut mint virtuális gép.

A Simplivity nem egy kernel integrált megoldás ezért minden node-ján fut egy control VM. Egy ilyen VM-nek a konzolja látható a fenti képen, így világos minden reláció a vCenter-ek, azokban a VMware terminus szerinti Datacenter és Cluster, illetve a már Simplivity terminológia szerinti zóna és azok hosztjai. Szerencsére egészséges az általános állapot mindkét klaszterben. A zóna felfogható availability domain-nek is, bár értelmezzük failure domain-ként. Két node-nál nyilvánvalóan nincs sok értelme erről beszélni, de ha például van egy klaszterben négy Simplivity node és ezek párban vannak egy-egy rack-ben/adatszobában elhelyezve, akkor már sejthető miért kell ezeket zónákba rendezni. Egész egyszerűen azért, mert a Simplvity mindent “kétszer” tárol, azaz minden VM-nek lesz egy másolata a tárolási rétegben és ezt a második példányt érdemes két különböző zónában elhelyezni, hogy ha véletlen egy zónában mindkét hoszt kiesik, akkor ne legyen egy újraindulásnál nagyobb leállás. Ahogyan a VSAN-nál, úgy itt sincs adminisztrátori fennhatóság abban, hová tegye az adott VM-et, mármint melyik hosztra, erre van tulajdonképp a zóna.

Az Omnistack VM-ek mérete a hoszt tárolási kapacitásától függ. Az általam használt környezetben ezek a VM-ek 4 vCPU-val és 68GB RAM-mal vannak konfigurálva és ez kötelezően reserved a VMware-ben. Ezeknek a VM-eknek valahol kell egy VMDK is, de hogy lehetne azon a datastore-on, amelyet ők prezentálnak NFS-en? Egyszerűen úgy, hogy minden hosztban van egy RAID1 tükör is erre és csak erre a célra.

Ezen van maga a VM és ebből fakadóan máshová tilos átmozgatni, nem kell és nem is szabad közös tárolóra kerülnie.

VM-Centric Management

Lényegében erről szól a hiperkonvergens infrastruktúra, mármint hogy nincs szükség külön tárolóra, SAN-ra, HBA-kra és az ehhez szükséges tudásra, ahhoz hogy közös és magasan redundáns tárolót adhassunk a szervereink alá. Tehát egy felületről mindent végrehajtani, üzemeltetni és felügyelni. Ennek első eleme a vCenter-be beépülő plugin, amely két nézetben és felhasználásban mutatja meg magát.

Datastore létrezohás

Lényegében lehet magán a klaszteren jobb gombbal kattintva a lehet datastore-t létrehozni és a mentésben globálisan kereseni – erről még később lesz szó.

Hozzunk is létre egy datastore-t, sok adatot úgysem kér. A nevét kell megadni, a mentési házirendet – mondtam már, de majd kitárgyalom – és a kívánt méretét.

Fontos megjegyezni, hogy ez thin, azaz nem kerül lefoglalásra semmi és igazából sok értelme több datastore-et létrehozni nincs sok, mivel mindegyik azonos fizikai lemezeken van, így csak a több mentési házirend használatakor lehet jelentősége. Ezeket amúgy akár már létező datastore-on is meg lehet változtatni, de a már azon a datastore-on lévő VM-ek-nek a házirendje nem fog az újra változni.

Hoszt karbantartása

Ha egy ESXi hoszton kattintunk, akkor például kivonható az adott hoszt az egész klaszterből, leállítható a korábban említett VM-is.

Mentés

Egy VM-en állva viszont világossá válik, hogy miről is szól a HCI.

Egyszerűen lehet klónozni és menetni – VSS integráltan is – vagy éppen visszaállítani a VM-eket. Keresni is lehet a mentésekben. De maradjunk egyelőre a mentésnél. Ez a Simplivity nagy előnye véleményem szerint, mármint hogy mind a klónozást, mint a mentéseket nagyon gyorsan elvégzi és hatékonyan tárolja.

Mikor létrehoztam a datastore-t, akkor kérdezte hogy milyen alapértelmezett policy-t szeretnék hozzárendelni. Nem meglepő módon ez egy VMware policy, amit a “Global Inventory List” alatt találunk meg.

A környezetben akármennyi ilyen policy-t létre lehet hozni, most én is csinálok egy újat. Egy házirenden belül lehet több szabály is, lentebb az első sorban azt állítottam be, hogy óránként legyen VSS integrált mentés, azt egy napig tartsa meg és lokálisan tárolja.

A második szabály ezen felül naponta egyszer ment, egy hétig őrzi meg és a Geneva klaszteren tárolja. Tehát ha ezt a szabályt egy Geneva lokáción lévő VM-hez rendelem, akkor mindkét helyen lesz mentése.

Picit jobban áttekinthetően így néz ki a végeredmény.

De mennyi ilyen mentés lehet? Naponta 2,177,280 napi és 750,000 darab, akár soha le nem járó megőrzéssel bíró lehet egy federációban.

Klónozás

Leklónozok egy gépet és hozzárendelem ezt a policy-t. A klónozás egészen érdekes, mert valójában a tárolási rétegben nem történik szó szerint klónozás, csak a szükséges metaadatokkal dolgozik a Simplivity úgy, hogy a klón számára, a már letárolt (deduplikált) blokkok lévő pointer-ek létrejöjjenek. Emiatt egy klónozás, kb két másodperc, mindegy mekkora a példányosítandó gép. Nem árt azonban vigyázni, mert ha megnézzük jobb gomb után, két Clone opció is van. Egy a VMware sajátja, a másik a plugin-en keresztül a Simplivity natív módon.

A második lépésben lehet megadni hogy konzisztens módon történjen-e a klónozás. A harmadik opció az extra, ha kívánjuk, akkor függetleníthetjük ezt a VMware Tools-tól és végső soron akár a Windows-al és alkalmazásaival direktben VSS integrálva tud működni a klónozás és a későbbi mentés is.

A fenti gép 500GB méretű és ennyit használ is, a klónozás ennek ellenére meg is történt 7 másodperc alatt.

Most átmozgatom a korábban létrehozott newman_DS01 datastore-ra a klónt.

Várom a tippeket, hogy ez mennyi ideig tart majd….hát nyolc másodpercig!

Amint eljön az ütemeztett mentés ideje, már kereshetjük is a mentéseket. Ezeket vagy a klaszteren vagy a VM-en állva is meg lehet tenni. Természetesen a VM-en kiválasztva, csak annak a VM-nek a mentéseit mutatja. Ez látszik lentebb is, sőt, kapásból két mentést is látunk. Az alsó a helyi mentés – emlékezz a fentebb létrehozott policy-re – a felső pedig a másik telephelyre replikált példány. A Sent size oszlop 4.2 MB adatot mutat, aminek több oka lehet, de általában soha nem látunk olyat, hogy a forrás VM-ben megváltozott blokkok összes méretével egyenlő az érték. Miért? Azért, mert ami a Grenoble klaszteren már ott van és nem egyedi blokk, azokat a mentés során sem replikálja át a Simplivity.

A visszaállítási módok adnak pár opciót:

  • eredeti helyre VM
  • új VM entitásba a régi VM
  • fájlok visszaállítása

Elnevezhetünk mentést tetszés szerint, átmásolhatjuk egy másik Simplivity klaszterre – ha például a policy-nk ezt nem tartalmazná alapból vagy egy manuálisan indított helyi mentést szeretnénk megőrizni egy másik klaszterben. Törölhető egy mentés, de zárolható is, illetve a lejárati dátum is beállítható. Ez utóbbinak is csak akkor van értelme, ha manuális a mentés, akkor végtelen a lejárat dátuma – figyelni kell rá.

Állítsunk vissza egy VM-et. Szabadon kiválasztható, hogy melyik példányból szeretném a visszaállítást és az elképesztő mágia, hogy a Grenoble klaszterben lévő távoli mentésből is képes vagyok a Genf-ben található klaszterre visszaállítani. Tehát minden elképzelhető kombináció működik.

A visszaállítás megtörténik, négy másodperc alatt. Pont ezzel turnézik a HPE hogy 2TB-os VM-et egy perc alatt képes visszaállítani és ezzel aligha lehet versenyezni. Azért tudja ezt megtenni, mert szintén nem történik semmi sem, csak a szükséges egyedi blokkokra mutató pointerek állnak össze a szükséges konstellációba.

Fájlokat is vissza lehet állítani, de csak NTFS kötetről és kell hozzá, szóval Microsoft Windows esetén tud működni.

Kiválasztok egy VM-et és kijelölök pár könyvtárat a visszaállításra.

A visszaállítás során egy ISO fájl jön létre, benne a kijelölt és visszaállítandó adatokkal. Ezt csatolja be a kívánt VM-re a Simplivity. Természetesen klaszterek között is van lehetőség a visszaállításra.

Kapacitás és teljesítmény

Itt is több nézetben deríthető fel minden. A klaszter szintjén állva látható a teljes egészre vonatkozó performancia.

Az Open top contributors és a diagramon egy mérés kiválasztásával kinyerhető az abban a pillanatban jellemző VM-ek performanciája is.

A VM-en bármilyen skálán, bármilyen adatot ki lehet nyerni.

Na de mennyi hely van? Ez természetesen klaszter szintű információ, így ott tudjuk megnézni.

Értelmezzük a fentieket. A logikai felhasználás 925 TB, amelyből a valós VM-ek 8.88 TB mérettel rendelkeznek, viszont minden mentést egésznek számol a rendszer. Szóval minél több mentésünk van, annál nagyobb a felhasznált logikai méret. Mivel a Simplivity a hatékony deduplikációra és tömörítésre épül már a génjei szintjén, ezért ha 100 mentésben és 1 VM-ben azonos egyetlen blokk, akkor azt nem 101-szer tárolja le, hanem 1-szer. Ebből fakad a 135,4:1-hez arány a fenti ábrán és ebből fakad az is, hogy a fizikai lemezeken ez az egész 6.83 TB-ot foglal csak el. Tehát ebből az is fakad, hogy a VM-ek között is sok a közös blokk.

Összefoglaló

Bár nem túl látványos mindaz amit tud a Simplivity, de a csak és kizárólag a vCenter felületéről úgy hoztam létre egy datastore-t, hogy nem kellett a tárolón tenni semmit – tehát nem kell egy másik felületre menni azért, főleg mert nincs is eredeti értelembe vett tároló. Erre már mondható, hogy akár egy Nimble/3PAR vagy egy Compellent/Unity is integrálható így. Úgy készítettem VSS integrált mentést egy másik telephelyre, hogy nem kellett külső szoftver, de végképp nem egy újabb felület. A teljesítményt és kapacitást is a vCenter-ből end-to-end ki tudtam nyerni, hogy ki sem léptem onnan. Az életciklussal kapcsolatos frissítési feladatok még nem épültek be a vCenter-be, de azt egyetlen eszközzel végre lehet hajtani.

Pont erről szól a HCI, hogy egyszerűen lehet végrehajtani a korábban szerteágazó módon, több felületen megtett feladatokat. Nem szükséges valakinek vizsgázott 3PAR mérnöknek lennie, hogy adjon területet, felkent TSM adminnak lennie, hogy mentsen egy VM-et – itt aláírom, hogy a klaszteren tartott mentés, azért nem teljes mentés, azaz szükség van valami mentési rendszerre, hogy a Simplivity-ből kivihető legyen a mentés .

Látható a gyártói elkötelezettség és eltökéltség a Simplivity termék iránt, mert van már végre AMD Epyc alapú – főleg ROBO felhasználásra – Simplivity is, illetve csak szoftveres megoldás is Intel alapon. Ez utóbbi kettőben nincs benne a speciális FPGA, ezért ezek még költséghatékonyabbak, de alacsonyabb teljesítményt nyújtanak. Ebből kiindulva például ha Simplivity mentésről beszélünk, akkor van már lehetőség olyanra is, hogy egy Intel alapú és FPGA-val rendelkező all flash Simplvitiy replikálja a mentéseket egy pörgő lemezesre vagy éppen egy EPYC alapúra.

Létezik Apollo 2600 formátumban is, ami az én kedvencem – ebben sincs FPGA.

Annyi látszik, hogy sok lemez fér bele, de amiért nekem tetszik azt a hátulja árulja el.

Bizony, ez négy szerver, szóval mindegyiknek adható 6 darab SSD akár és egy dobozban, 2U méretben kaphatunk egy igen erős, redundáns megoldást. Nyilván kell hozzá két külső switch – 10Gbit-es stb – de 4U-ból mindenképpen megvan egy nagyobb vállalati iroda teljes IT-ja.

Go HCI!