A Disaster Recovery megoldások piacának egyik fiatal szereplője a Hystax, egy orosz startup 2016-ban. Mivel a katasztrófa utáni helyreállítás témája nagyon népszerű, és a piacon rendkívüli a verseny, a startup úgy döntött, hogy a különböző felhő-infrastruktúrák közötti migrációt helyezi előtérbe. Egy olyan termék, amely lehetővé teszi a felhőbe való egyszerű és gyors migráció megszervezését, nagyon hasznos lenne az Onlanta ügyfelei - felhasználók számára . Így ismertem meg a Hystaxot, és kezdtem el tesztelni a funkcióit. És mi lett belőle, ebben a cikkben elmondom.
A Hystax fő jellemzője a széleskörű funkcionalitás, amely támogatja a különféle virtualizációs platformokat, vendég operációs rendszert és felhőszolgáltatásokat, ami lehetővé teszi a munkaterhelések áthelyezését bárhonnan és bárhonnan.
Ezzel nem csak DR-megoldások hozhatók létre a szolgáltatások hibatűrésének javítása érdekében, hanem gyorsan, rugalmasan migrálhatók az erőforrások a különböző telephelyek és a hiperskálázók között, így növelhető a költségmegtakarítás, és kiválasztható az adott szolgáltatás pillanatnyilag legjobb megoldása. A címképen felsorolt platformokon kívül a cég aktívan együttműködik az orosz felhőszolgáltatókkal is: a Yandex.Cloud, a CROC Cloud Services, a Mail.ru és még sokan mások. Azt is érdemes megjegyezni, hogy 2020-ban a vállalat egy K+F központot nyitott Skolkovóban.
Az, hogy a piacon nagyszámú szereplő egy megoldást választott, jó árpolitikát és a termék magas alkalmazhatóságát jelzi, amit a gyakorlatban is kipróbáltunk.
Tehát a tesztfeladatunk a VMware teszthelyemről és a fizikai gépeimről a VMware-t is futtató szolgáltató webhelyére való migrálásból áll. Igen, sok olyan megoldás létezik, amivel megvalósítható egy ilyen migráció, de a Hystax-ot univerzális eszköznek tartjuk, és a migráció minden lehetséges kombinációban történő tesztelése egyszerűen irreális feladat. Igen, és az Oncloud.ru felhő kifejezetten VMware-re épül, így ez a platform, mint célpont, jobban érdekel bennünket. Ezután leírom a működési alapelvet, amely összességében nem függ a platformtól, és a VMware bármely oldalról lecserélhető egy másik gyártó platformjára.
Az első lépés a Hystax Acura telepítése, amely a rendszer vezérlőpultja.
A sablonból bővül. Valamiért esetünkben ez nem volt teljesen korrekt és az ajánlott 8CPU helyett 16Gb került kiépítésre fele erőforrással. Ezért ne felejtse el megváltoztatni őket, különben a virtuális gépen belüli infrastruktúra, amelyre minden épül, egyszerűen nem indul el a konténerekkel, és a portál elérhetetlen lesz. BAN BEN részletesen le van írva a szükséges erőforrások, valamint az összes rendszerkomponens portjai.
És az IP-cím sablonon keresztüli beállításánál is nehézségek adódtak, ezért a konzolról megváltoztattuk. Ezt követően léphet az adminisztrációs webes felületre, és befejezheti a kezdeti konfigurációs varázslót.
Végpont – a vCenterünk IP-címe vagy FQDN-je.
Bejelentkezés és jelszó – itt egyértelmű.
A cél ESXi gazdagépneve a fürtünk egyik olyan gazdagépe, amelyre replikálódik.
A céladattár a fürtünk egyik adattárolója, amelyre a replikáció kerül végrehajtásra.
Hystax Acura Control Panel Public IP – az a cím, ahol a központ elérhető lesz.
Szükséges egy kis pontosítás a gazdagépről és az adattárról. A helyzet az, hogy a Hystax replikáció a gazdagép és az adattár szintjén működik. Ezután elmondom, hogyan módosíthatja a gazdagépet és az adattárat a bérlő számára, de a probléma más. A Hystax nem támogatja az erőforrás-összevonást, pl. a replika mindig a fürt gyökerével fog megtörténni (az anyag írásakor a Hystax srácai kiadtak egy frissített verziót, ahol gyorsan végrehajtották az erőforráskészletek támogatására vonatkozó szolgáltatáskérésemet). A vCloud Director szintén nem támogatott, pl. ha – mint az én esetemben – a bérlőnek nincs adminisztrátori joga a teljes fürthöz, hanem csak egy adott erőforráskészlethez, és hozzáférést adtunk a Hystaxhoz, akkor képes lesz önállóan replikálni és futtatni ezeket a virtuális gépeket, de nem láthatja őket a VMware infrastruktúrájában, amelyhez hozzáfér, és ennek megfelelően tovább kezelheti a virtuális gépeket. A fürt rendszergazdájának át kell helyeznie a virtuális gépet a megfelelő erőforráskészletbe, vagy importálnia kell a vCloud Directorba.
Miért koncentrálok ennyire ezekre a pillanatokra? Mert amennyire én értem a termék koncepcióját, az ügyfélnek képesnek kell lennie az Acura panel segítségével bármilyen migrációt vagy DR-t önállóan megvalósítani. De eddig a VMware támogatása némileg elmarad ugyanazon OpenStack támogatási szintjétől, ahol már bevezették az ilyen mechanizmusokat.
De vissza a telepítéshez. Először is, a panel kezdeti beállítása után létre kell hoznunk az első bérlőt a rendszerünkben.
Itt minden mező tiszta, csak a Felhő mezőről mesélek. Már van egy "alapértelmezett" felhő, amelyet a kezdeti konfiguráció során hoztunk létre. De ha azt szeretnénk, hogy minden bérlőt a saját adattárába és saját erőforráskészletébe helyezhessünk, akkor ezt úgy tudjuk megvalósítani, hogy külön felhőket hozunk létre minden ügyfelünk számára.
Új felhő hozzáadása formájában megadjuk ugyanazokat a paramétereket, mint a kezdeti konfigurációnál (akár ugyanazt a gazdagépet is használhatjuk), megadjuk az adott ügyfélhez szükséges adattárat, és most a további paraméterekben már egyedileg megadhatjuk a szükséges erőforráskészlet {"resource_pool" :"YOUR_POOL_NAME"}
Amint azt már észrevetted, a bérlő létrehozása során nincs szó az erőforrások elosztásáról vagy valamiféle kvótákról - ebből semmi nincs a rendszerben. Nem korlátozhatja a bérlőt az egyidejű replikák, a replikációhoz szükséges gépek számában vagy más paraméterekkel. Tehát létrehoztuk az első bérlőt. Most van egy nem teljesen logikus, de kötelező dolog - egy Cloud ügynök telepítése. Logikátlan, mert az ügynök egy adott ügyfél oldaláról töltődik le.
Ugyanakkor nincs a létrehozott bérlőhöz kötve, minden ügyfelünk át fog dolgozni (vagy több után, ha telepítjük őket). Egy ügynök 10 egyidejű munkamenetet támogat. Egy munkamenet egy autónak számít. Nem mindegy, hogy hány lemeze van. A mai napig nincs mechanizmus az ügynökök skálázására magában az Acurában a VMware számára. Van még egy kellemetlen momentum - nem tudjuk megnézni ennek az ügynöknek a "kihasználását" az Acura panelről, hogy megállapítsuk, kell-e többet telepítenünk, vagy elég a jelenlegi telepítés. Ennek eredményeként az állvány így néz ki:
Ügyfeleink portáljának eléréséhez a következő lépés egy fiók létrehozása (és először egy szerepkör létrehozása, amely erre a felhasználóra vonatkozik).
Ügyfelünk mostantól önállóan is használhatja a portált. Mindössze annyit kell tennie, hogy letölti az ügynököket a portálról, és telepíti őket az oldalára. Háromféle ügynök létezik: Linux, Windows és VMware.
Az első kettőt a fizika vagy a virtuális gépek helyezik el bármely nem VMware hipervizoron. Itt nincs szükség további konfigurációra, az ügynök letölti és már tudja, hova kell kopogtatni, és szó szerint egy perc múlva az autó látható lesz az Acura panelen. A VMware ügynök esetében a helyzet kicsit bonyolultabb. A probléma az, hogy az Agent for VMware is letöltődik a portálról, amely már előkészítve és a szükséges konfigurációval rendelkezik. A VMware ügynöknek azonban az Acura portálunk ismerete mellett tudnia kell a virtualizációs rendszerről is, amelyen telepíteni fogják.
Valójában a rendszer kérni fogja, hogy adjuk meg ezeket az adatokat, amikor először letölti a VMware ügynököt. A probléma az, hogy a biztonság univerzális szeretetének korában nem mindenki akarja majd valaki más portálján megadni a rendszergazdai jelszavát, ami teljesen érthető. Belülről a telepítés után az ügynök semmilyen módon nem konfigurálható (csak a hálózati beállításait módosíthatja). Itt nehézségeket látok a különösen óvatos ügyfelekkel kapcsolatban.
Így az ügynökök telepítése után visszatérhetünk az Acura panelhez és megnézhetjük az összes autónkat.
Mivel több mint egy napja dolgozom a rendszerrel, különböző állapotú gépeim vannak. Mindegyik az Alapértelmezett csoportba tartozik, de igény szerint lehetőség van külön csoportok létrehozására és gépek átvitelére. Ez semmit nem befolyásol - csak az adatok logikai megjelenítését és csoportosítását a kényelmesebb munka érdekében. Az első és legfontosabb dolog, amit ezután meg kell tennünk, hogy elindítsuk a migrációs folyamatot. Ezt megtehetjük manuálisan is, és ütemezést is beállíthatunk, beleértve az összes gépre egyszerre tömegesen.
Hadd emlékeztesselek arra, hogy a Hystaxot migrációs termékként pozícionálták. Ezért nem meglepő, hogy replikált gépeink futtatásához DR tervet kell készítenünk. Létrehozhat egy tervet azokhoz a gépekhez, amelyek már szinkronizált állapotban vannak. Létrehozhat egy adott virtuális géphez és az összes géphez egyszerre.
A DR-terv létrehozásakor a paraméterek készlete attól függően változik, hogy milyen infrastruktúrára kíván áttelepülni. A lehetőségek minimális készlete elérhető a VMware környezethez. A gépek IP-címének újracseréje szintén nem támogatott. Ezzel kapcsolatban a következő pontokra vagyunk kíváncsiak: a virtuális gép leírásában az „alhálózati” paraméter: „VMNetwork”, ahol a virtuális gépet egy adott hálózathoz kötjük a fürtben. Rang – több virtuális gép áttelepítésekor releváns, meghatározza az indítási sorrendet. Az íz a virtuális gép konfigurációját írja le, jelen esetben 1 CPU, 2 GB RAM. Az alhálózatok részben meghatározzuk, hogy az "alhálózat": a "VMNetwork" a VMware "VM hálózatához" van társítva.
A DR-terv létrehozásakor nincs mód a lemezek „felosztására” a különböző adattárak között. Ugyanabban az adattárban fognak elhelyezkedni, mint ami ehhez a kliensfelhőhöz lett definiálva, és ha különböző osztályú lemezei vannak, ez némi nehézséget okozhat a gép indításakor, illetve a virtuális gép indítása és a Hystaxról való „leválasztása” után is külön migrációs lemezt igényel a szükséges adattárolókhoz. Ezután már csak le kell futtatnunk a DR-tervünket, és várnunk kell, amíg az autóink felemelkednek. A P2V/V2V konverziós folyamat is időt vesz igénybe. A legnagyobb, három lemezes 100 GB-os tesztgépemen ez maximum 10 percig tartott.
Ezt követően ellenőriznie kell a futó virtuális gépet, a rajta lévő szolgáltatásokat, az adatok konzisztenciáját és egyéb ellenőrzéseket.
Ekkor két lehetőségünk van:
- Törlés – futó DR-terv törlése. Ez a művelet egyszerűen leállítja a futó virtuális gépet. Ezek a replikák nem mennek sehova.
- Leválasztás - letépni a replikált autót az Acuráról, i.e. ténylegesen fejezze be a migrációs folyamatot.
A megoldás előnyei:
- egyszerű telepítés és konfigurálás mind az ügyfél, mind a szolgáltató oldalon;
- a migráció beállításának egyszerűsége, a DR-terv létrehozása és a replikák elindítása;
- A támogatás és a fejlesztők meglehetősen gyorsan reagálnak a talált problémákra, és platform- vagy ügynökfrissítésekkel kijavítják azokat.
Hátrányok
- Elégtelen Vmware támogatás.
- A bérlők kvótájának hiánya a platformon.
Készítettem egy Feature Request is, amit átadtunk az eladónak:
- a használat figyelése és telepítése az Acura Management Console for Cloud Agents szolgáltatásból;
- kvóták rendelkezésre állása a bérlők számára;
- az egyidejű replikációk számának és sebességének korlátozása minden bérlő esetében;
- a VMware vCloud Director támogatása;
- erőforrás-készletek támogatása (a tesztelés során valósult meg);
- a VMware ügynök konfigurálása az ügynök oldaláról anélkül, hogy az Acura panelen a kliens infrastruktúrából kellene megadni a hitelesítési adatokat;
- A virtuális gép indításának folyamatának „vizualizálása” DR-terv indításakor.
Az egyetlen dolog, ami nagy panaszokat okozott, az a dokumentáció volt. Nem igazán szeretem a "fekete dobozokat", és jobban szeretem, ha részletes dokumentáció van a termék működéséről. És ha az AWS és az OpenStack esetében még többé-kevésbé le van írva a termék, akkor a VMware esetében nagyon kevés a dokumentáció.
Van egy Telepítési útmutató, amely csak az Acura panel telepítését írja le, és ahol egy szó sincs arról, hogy szükség van egy Cloud ügynökre. Teljes specifikáció van a termékhez, ami jó. Van olyan dokumentáció, amely leírja a beállítást "tól és ig" az AWS és az OpenStack példájával (bár ez inkább egy blogbejegyzésre emlékeztet), és van egy nagyon kicsi tudásbázis.
Általánosságban elmondható, hogy ez nem egészen az a dokumentációs formátum, amit mondjuk a nagyobb gyártóktól szoktam, így nem voltam teljesen kényelmes. Ugyanakkor ebben a dokumentációban a rendszer működésének egyes árnyalataira nem találtam választ ebben a dokumentációban - rengeteg kérdést kellett technikai támogatással tisztáznom, és ez inkább elhúzta az állvány telepítésének folyamatát, ill. tesztelés.
Összegezve elmondhatom, hogy összességében tetszett a termék és a cég hozzáállása a feladat végrehajtásához. Igen, vannak hibák, valóban kritikus a funkcionalitás hiánya (a VMware-rel együtt). Látható, hogy a cég mindenekelőtt továbbra is a nyilvános felhőkre, különösen az AWS-re koncentrál, és néhánynak ez is elég lesz. Rendkívül fontos egy ilyen egyszerű és kényelmes termék megléte manapság, amikor sok vállalat többfelhős stratégiát választ. Tekintettel a versenytársakhoz képest jóval alacsonyabb árra, ez rendkívül vonzóvá teszi a terméket.
Csapatot keresünk . Talán te vagy az?
Forrás: will.com