A Cisco hiperhajlító rendszere, avagy megvásárolt megoldása a hiperkonvergens rendszerek házon belül hozására. Igazán kevés gyártó mondhatja el magáról, hogy a sajátja, az ténylegesen saját fejlesztés és nem valami más startup/apróbb cég terméke, amit végső soron egy akvizícióval szerzett. Nincs ez másképp a Cisco esetén sem, mert a Springpath beolvasztásával lett nekik is valamilyen ajánlatuk, ha valaki mindenképpen hidas logóval ellátott rendszert szeretne a témában.
Elsőre nem volt szimpatikus a Hyperflex, de minél többet tanulok a témában és ásom bele magam a többi hasonszőrű SDS megoldásba, annál jobban tetszik az övék.
Mik az okok?
- faltól-falig képesek a provizionálásra.
- hibrid kiépítés esetén is van deduplikáció és tömörítés.
Az első az akkor igaz, ha a kiépítés nem három node-os, azaz nem Edge. Ez utóbbi a minimum is egyébként, tehát amennyiben elegendő három node és sosem lesz négy, akkor nem szükséges – természetesen Cisco – fabric interconnect-eket vásárolni, hanem elég valami 10Gbit – 1Gbit is lehet, de nem javaslom – képes switch és kész is a rendszer. De ha nem elég – azaz nem Edge – akkor szükség van FI-re – egy párra pl – és akkor a telepítés során képes az UCS Manager-ben profilozni a szervereket stb. Az mondjuk nem igaz hogy a FI-t nulláról bekonfigurálja, de ha az egyszer be van állítva hálózati szempontból akkor az első, vagy a tizenhatodik node telepítése semmiben sem tér el, automatikus lesz.
Hogyan telepíthető egy ilyen Edge klaszter? Sajnos nem zero touch és véleményem szerint lehetne optimalizálni is a folyamatot.
A fizikai bekötés magáért beszél, redundánsan kell bekötni a két 10Gbit-es uplink-et – 40Gbit NEM támogatott Edge-nél, hiába vannak benne 40Gbit-es VIC-ek. Az OOB/CIMC-nek nem szükséges dedikált uplink, de én sosem hittem az in band menedzsmentben, tartsuk azt külön, sőt külön switch-en.
Ha nincs a CIMC VLAN-ban DHCP, akkor máris manuális interakció kell, be kell állítani az IP-ket.
Ez volt az egyszerű rész. Szükség van még egy telepítőre is, azaz egy olyan OVF formátumban – HyperV-re is van – létező gépre, amin a varázsló fut. Ennek folyamatát nem írom le, mindenki importált már hasonlót VMware-be. Miután az elindul és elérhető a felülete egy böngészőből, ne lépjünk be! És itt a legnagyobb probléma a folyamattal. Kézzel kell lefuttatni egy szkriptet, ami a CIMC-ekre kapcsolódva elvégzi a következőket:
- boot sorrend
- vNIC-ek létrehozása – kiéítéstől függően
- VMware ESXi-k elnevezése, mgmt vmkernel IP-k beállítása
Az nem fér a fejembe, hogy ezt miért nem bírja lefuttatni a grafikus varázsló….megkérdezem a gyártót.
A lépések:
- a bekötéstől függően 1G vagy 10G kiválasztása.
- a korábban beállított CIMC IP-k beadása, minden szerveré, vesszővel elválasztva
- a CIMC jelszavak – alapesetben a képen látható a felhasználó és jelszó
- a kívánt ESXi mgmt vmkernel IP-k
- felhasználó az ESXi-khez – alapesetben a képen látható a felhasználó és a jelszó
- alhálózati maszk, átjáró, menedzsment VLAN – ha nem natív a trönkön
- DNS szerver
Ha ezek megvannak akkor úgy 10 perc alatt végez is szkript. Viszont nagyon fontos hogy ne legyünk belépve egyik CIMC-re sem, mert akkor hibára fut a folyamat!
Immáron a Cisco HX Data Platform Installer web felületére szükséges belépni – eddig SSH-n voltunk. (root/Cisco123 vagy a telepítéskor megadott jelszó) Jelen példában HX Edge kerül telepítésre, így a „Create cluster”-nél az „Edge Cluster” kiválasztása szükséges.
És máris szembesülünk egy másik problémával. Ha eddig nem változtattuk meg a CIMC felhasználó/jelszó párost, akkor most szükséges lesz megtenni minden szerveren, kézzel. Ezen kívül be kell adni a vCenter Server-t – enélkül nem lehet HF-et telepíteni. Érdemes ezt tárgyalni picit….ha egy kis cég vesz egy HX Edge-et és nincs még vCenter-ük, akkor ideiglenesen egy szerver amin az feltehető, majd ha kész a klaszter, akkor rámozgatni. Ennek értelmében a vCenter Server részleteit ki lehet tölteni, illetve az ESXi-k root felhasználójának jelszavát is be lehet írni, illetve itt is kierőszakolja a változtatást, de szerecsére ezt maga teszi meg, nem nekünk kell.
A következő ablakban a további IP-k beadása történik. Tudom….tudom. Már megint? SSH-n beírtad már egyszer az első két oszlop tartalmát. Na itt is be kell írni, illetve még hármat. Ez utóbbi három IP lesz a minden egyes node-on futó controller, IP-je, az amin menedzselhető és amin keresztül a Hyperflex klasztert formálják. Ennek IP-je a Cluster IP Address alább.
A következő ablakban konfigutálni kell a kívánt klaszter nevét. Ez nem az a név amit a vCenter mutat majd, ez a Hyperflex szintjén használt név. Viszont én itt javaslom, hogy legyen azonos a vCenter klaszter kívánt nevével, átláthatóbb. Viszont nem tehető már létező klaszterbe egy Hyperflex telepítés – ezt fogja létrehozni a – VMware terminológia szerint – datacenter-ben. Ez a datacenter lehet már létező, csak a klaszternek kell újnak lennie. HX edge esetén a védelem szintje (Replication Factor) csak kettő lehet. Ez azt jelenti, hogy RAID1 lesz, egy node-ot veszthet a rendszer és még működni fog. További adatok beírása után – DNS,NTP,DNS domain, VLAN a menedzsmentre és a belső kommunikációra – indítható a telepítés. Viszont meglepő lesz az, hogy a Data VLAN mégis micsoda? Ez a klaszter azon hálózata, amin a node-ok egymással beszélgetnek, írnak-olvasnak. Ezen valami elképesző módon control VM-ek APIPA címmel lesznek konfigurálva! 🙂 Ezért is javasolt ezt az forgalmat egy szegmensbe tenni és nem route-olni semerre.
És kész, indítható a stopper, max 37 perc. Ha sikeres volt minden, akkor a Cluster IP-n keresztül be kell lépni a HX Connect-be és kezelni a datastore-okat. Alapból nincs közös storage, nekünk kell létrehozni és a rendszer automatikusan becsatolja azt minden hosztra NFS-en.
De ne rohanjunk. Vissza kell lépni SSH-n a már korábban is használt HX Data Platform installer VM-re – megint!! – és ott lefuttatni a post_install szkriptet. Én ezt erősen opcionálisnak gondolom, mert amit ez csinál azt kézzel is be lehet állítani és én jobban szeretem, mint azt hogy egy sorban leírt dolgot hagyok jóvá egy Y billentyű lenyomásával. Ezeket hajtaná végre:
- vSphere licenszelés
- HA/DRS bekapcsolás
- SSH kikapcsolása az ESXi-ken
- vMotion bekapcsolása vMotion vSwitch-en lévő vmkernel-en – ez a kedvencem, mivel itt hozna létre egy vmkernel interfészt.
- VM portgroup-ok létrehozása
- Health check….ami annyit ír hogy ha minden oké hogy „HEALTHY” 🙂
Miután 10G-ről van szó és fizikailag ugyanazon a kábelen megy minden forgalom, ezért a külön vMotion vmkernel léte erősen megkérdőjelezhető. Hacsak nem akarjuk egy külön VLAN-ba terelni azt vagy később több interfész bekötésével ténylegesen más uplink-re tenni, akkor érdemesebb a menedzsment vmkernel-én engedélyezni a vMotion-t.
A telepítési útmutató javasolja a datastore heartbeat-et, de ezt nem javaslom. Azért mert VSAN esetén egyenesen tilos használni, itt sem látom értelmét, mivel a datastore-ok írása-olvasása ugyanazon a hálózaton történik – fizikai kábel szintjén – mint az a kommunikáció, amit egy klaszterben lévő node-ok a HA műdödése során használnak.
A Cisco Hyperflex licenszelés-t pedig a következőknek megfelelően kell elvégezni link.
