A fiatal játékosok közé tartozik a katasztrófa-helyreállító megoldások piacán a Hystax – egy 2016-os orosz startup. Mivel a katasztrófa-helyreállítás témája rendkívül népszerű, és a piacon nagyon magas a verseny, a startup úgy döntött, hogy a különböző felhőinfrastruktúrák közötti migrációra összpontosít. Az a termék, amely lehetővé teszi az egyszerű és gyors migrációt a felhőbe, nagyon hasznos lenne az „Onlanta” cég ügyfelei számára – a felhasználók számára. . Így találkoztam a Hystax-szal, és elkezdtem tesztelni a képességeit. Hogy mit értünk el ezzel, azt ebben a cikkben mesélem el.
A Hystax fő előnye a széles funkcionalitása, amely támogatja a különböző virtualizációs platformokat, vendég operációs rendszereket és felhőszolgáltatásokat, lehetővé téve a munkaterhelések átvitelét bárhonnan és bárhová.
Ez lehetővé teszi nemcsak DR-megoldások létrehozását a szolgáltatások megbízhatóságának növelése érdekében, hanem gyors és rugalmas migrációt is különböző helyszínek és hiperskálák között a költségek csökkentése és a legjobb megoldás kiválasztása érdekében a konkrét szolgáltatás számára. Az említett platformokon kívül a cég aktívan együttműködik orosz felhőszolgáltatókkal is: Yandex.Cloud, KROK „Felhőszolgáltatások”, Mail.ru és sok más. Érdemes megjegyezni, hogy 2020-ban a cégnek R&D központja is létesült Szkolkovóban.
A piacon lévő sok szereplő által választott egyetlen megoldás jó árpolitikára és a termék magas alkalmazhatóságára utal, amit magunk is meg szeretnénk tapasztalni a gyakorlatban.
Tehát a tesztfeladatunk a migrációból fog állni a saját tesztkörnyezetemből, VMware-ről és fizikai gépekről egy olyan szolgáltató platformra, amely szintén VMware alatt működik. Igen, sok megoldás létezik, amely képes ilyen migrációra, de a Hystax-ot univerzális eszközként tekintjük, és a migráció tesztelése minden lehetséges kombinációban egyszerűen lehetetlen feladat. Ráadásul az Oncloud.ru felhő kifejezetten VMware-en alapul, ezért ez a platform számunkra jobban érdekes. Ezután leírom az alapvető működési elvet, amely alapvetően nem függ a platformtól, és a VMware bármely oldalról más gyártó platformjára lecserélhető.
Az első lépésben telepíteni kell a Hystax Acura-t, amely a rendszer vezérlőpanele.
Ez egy sablonból települ. Valamiért az esetünkben nem volt teljesen megfelelő, és a javasolt 8 CPU és 16 Gb helyett kétszer kisebb erőforrásokkal települt. Ezért ne felejtsük el ezeket módosítani, különben az infrastruktúra konténerek a VM-en belül, amelyre mindez épült, egyszerűen nem indul el, és a portál nem lesz elérhető. A részletesen le van írva a szükséges erőforrások és az összes rendszerkomponens portjai.
Az IP-cím sablonon keresztüli megadása is nehézségekbe ütközött, így azt a konzolból változtattuk meg. Ezt követően lehet áttérni a webes adminisztrátori felületre és kitölteni az elsődleges konfigurációs varázslót.
Endpoint – az IP vagy FQDN a vCenter-ünkhöz.
Login és Password – itt érthető.
Cél ESXi hosztnév – az egyik hoszt a klaszterünkből, amelyre a replikáció történik.
Cél datastore – az egyik datastore a klaszterünkből, amelyre a replikáció zajlik.
Hystax Acura Vezérlőpanel Nyilvános IP – a cím, amelyen a vezérlőpanel elérhető lesz.
Szükség van egy kis pontosításra a hoszttal és a datastore-ral kapcsolatban. A helyzet az, hogy a Hystax replikáció a hoszt és datastore szintjén működik. Később elmondom, hogyan lehet a bérlőhöz átkonfigurálni a hosztot és a datastore-t, de a probléma más. A Hystax nem támogatja a resource pool-ok használatát, azaz a replikáció mindig a klaszter gyökerébe történik (a dokumentum írásakor a Hystax srácai kiadtak egy frissített verziót, amely gyorsan bevezette a resource pool támogatására vonatkozó feature requestemet). A vCloud Director sem támogatott, azaz ha, mint az én esetemben, a bérlőnek nincsenek adminisztrátori jogai az egész klaszteren, csak egy adott resource poolban, és mi hozzáférést adtunk a Hystaxhoz, akkor az önállóan replikálni és elindítani tudja ezeket a VM-eket, de nem fogja tudni látni őket a VMware infrastruktúrában, amelyhez hozzáférése van, és emiatt nem tudja tovább kezelni a virtuális gépeket. Szükséges, hogy a klaszter adminisztrátora áthelyezze a VM-et a megfelelő resource poolba, vagy importálja a vCloud Directorba.
Miért helyezek ilyen nagy hangsúlyt ezekre a pontokra? Mert amennyire értem a termék koncepcióját, az ügyfélnek lehetőséget kell biztosítani arra, hogy önállóan végezze el bármilyen migrációt vagy DR-t az Acura panel segítségével. De egyelőre a VMware támogatása kissé lemaradt az olyan dolgok támogatása mögött, mint az OpenStack, ahol az ilyen mechanizmusok már megvalósultak.
De térjünk 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.
Minden mező itt világos, csak a Cloud mezőről fogok beszélni. Már van egy „alapértelmezett” felhőnk, amelyet a kezdeti konfiguráláskor hoztunk létre. De ha azt szeretnénk, hogy minden bérlő saját adattárolóra és saját erőforrás-nyereményre kerüljön, ezt külön felhők létrehozásával valósíthatjuk meg ügyfeleink számára.
Az új felhő hozzáadási űrlapon azokat a paramétereket adjuk meg, amelyeket a kezdeti konfiguráláskor is használtunk (még ugyanazt a hostot is alkalmazhatjuk), megadva a konkrét ügyfél számára szükséges adattárolót, és most a kiegészítő paraméterekben már egyedileg megadhatjuk a szükséges erőforrás-nyereményt {„resource_pool”: „YOUR_POOL_NAME”}
Ahogy észrevehettétek, a bérlő létrehozásának űrlapján nincs szó a források elkülönítéséről vagy valamilyen kvótáról – a rendszerben semmi ilyesmi nincs. Nem lehet korlátozni a bérlőt a párhuzamos replikák számában, a replikációhoz szükséges gépek számában vagy más paraméterek szerint. Tehát létrehoztuk az első bérlőt. Most van egy nem teljesen logikus, de kötelező dolog – a Cloud-ügynök telepítése. Logikátlan, mert az ügynök a konkrét ügyfél oldalán kerül letöltésre.
Ez nem kötődik a létrehozott tenanthoz, ezért az összes ügyfelünk ezen keresztül fog működni (vagy több, ha telepítjük őket). Egy ügynök 10 egyidejű munkamenetet támogat. Egy munkamenet egy gépként számít. A lemezek számának nincs jelentősége. Jelenleg az Acura-n belül nincs mechanizmus az ügynökök skálázására VMware alatt. Van még egy kellemetlen dolog – nem tudjuk az Acura panelből megnézni az ügynök „használatát”, hogy következtetéseket vonjunk le arról, hogy szükségünk van-e még egy telepítésre, vagy elegendő a jelenlegi. A végeredményben a stand a következőképpen néz ki:
A következő lépés a vásárlónk portáljához való hozzáféréshez egy fiók létrehozása (előzetesen pedig egy szerep, amely ennek a felhasználónak lesz alkalmazva).
Most a vásárlónk önállóan használhatja a portált. Mindössze annyit kell tennie, hogy letölti az ügynököket a portálról és telepíti a saját oldalán. Háromféle ügynök létezik: Linux, Windows és VMware.
Az első kettőt fizikailag vagy bármilyen más hypervisoron futó virtuális gépekre telepítik, kivéve a VMware-t. Itt nem szükséges semmit további módon konfigurálni, az ügynök letöltődik, és már tudja, hova kell csatlakoznia, és szó szerint egy percen belül a gép látható lesz az Acura paneljén. A VMware ügynök helyzete kicsit bonyolultabb. A probléma az, hogy a VMware ügynök is letöltődik a portálról, már előkészített formában és a szükséges konfigurációval. De a VMware ügynöknek nemcsak az Acura portálunkra van szüksége, hanem a virtualizációs rendszerre is, amelyen telepítve lesz.
Valójában ezeket az adatokat kéri a rendszer tőlünk, amikor először letöltjük a VMware ügynököt. A probléma az, hogy a biztonság iránti mindenki által tapasztalt szeretet korában nem mindenki szeretné megadni az admin jelszavát egy idegen portálon, ami teljesen érthető. Belül viszont a telepítés után az ügynököt már nem tudjuk konfigurálni (csak a hálózati beállításait tudjuk megváltoztatni). Itt bonyodalmakra számítok a különösen óvatos vásárlóknál.
Tehát, miután telepítettük az ügynököket, visszatérhetünk az Acura panelhez, és láthatjuk az összes gépünket.
Mivel már régóta dolgozom a rendszerrel, különböző állapotú gépeim vannak. Mindegyik az Alapértelmezett csoportban található, de lehetőség van külön csoportok létrehozására és a gépek áthelyezésére, ahogy szükséges. Ez semmire nem hat ki – csupán logikai adatmegjelenítést és csoportosítást biztosít a kényelmesebb munka érdekében. Az első és legfontosabb dolog, amit meg kell tennünk, az a migrációs folyamat elindítása. Ezt megtehetjük kézi, kényszerített módon, vagy beállíthatunk egy ütemezést, akár egyszerre több gépre is.
Emlékeztetnék arra, hogy a Hystax termékként a migrációra pozicionálta magát. Ezért nem meglepő, hogy a másolt gépeink elindításához DR-tervet kell készítenünk. A tervet azokhoz a gépekhez lehet létrehozni, amelyek már Szinkronizált állapotban vannak. Generálhatunk egy konkrét VM-re, vagy egyszerre az összes gépre.
A DR-terv generálásakor a paraméterek az átmeneteltől függően eltérőek lesznek. A VMware-környezetben minimális paraméterszett érhető el. Re-IP nem támogatott a gépek esetében. Ebben a tervben a következő szempontok érdekelnek minket: a VM leírásában a „subnet” paraméter: „VMNetwork”, ahol a VM-et egy adott hálózathoz kapcsoljuk a klaszterben. A Rang – több VM migrálásakor releváns, meghatározza az elindításuk sorrendjét. A Flavor – a VM konfigurációját írja le, jelen esetben – 1CPU, 2GB RAM. A subnetek szekcióban pontosítjuk, hogy a „subnet”: „VMNetwork” asszociálva van a „VM Network” VMware hálózattal.
A DR-terv létrehozásakor nincs lehetőség a lemezeket különböző adatboltokra szétosztani. Ezek ugyanabban az adatboltban lesznek, amelyet az ügyfél felhőjéhez rendeltünk, és ha különböző osztályú lemezeink vannak, ez problémát okozhat a gép indításakor, valamint a gép Hystax-tól való leválasztása után külön migrálást igényel a lemezek helyes adatboltokra. Ezután csak el kell indítanunk a DR-tervünket, és meg kell várnunk, amíg a gépeink elindulnak. A P2V/V2V konverziós folyamat is időigényes lehet. A legnagyobb tesztgépemen, amely 100 GB és három lemezt tartalmazott, ez a folyamat legfeljebb 10 percet vett igénybe.
Ezután ellenőrizni kell az elindított VM-et, a rajta futó szolgáltatásokat, az adatok konzisztenciáját és el kell végezni egyéb ellenőrzéseket.
Ezután két utunk van:
- Törlés – a futó DR-terv leállítása. Ez a művelet egyszerűen leállítja a futó VM-et. A másolat adatai nem fognak elveszni.
- Leválasztás – a másolt gép leválasztása az Acura-ról, vagyis a migrálás folyamatának tényleges befejezése.
A megoldás előnyei:
- a telepítés és beállítás egyszerűsége ügyfél- és szolgáltató oldalról egyaránt;
- a migrálás, a DR-terv létrehozása és a másolatok elindításának egyszerű beállítása;
- a támogatás és a fejlesztők meglehetősen gyorsan reagálnak a felmerült problémákra, és frissítések révén megoldják azokat.
Hátrányok
- Nem elegendő támogatás a Vmware számára.
- Nincs semmiféle kvótázás a bérlők számára a platform részéről.
Összeállítottam egy Feature Request-t is, amelyet átadtunk a szállítónak:
- a Cloud ügynökök kezeléséből származó használat és telepítés megfigyelése az Acura vezérlőpultjából;
- kvóták a bérlők számára;
- lehetőség a párhuzamos másolásainak számának és sebességének korlátozására minden bérlő esetében;
- a VMware vCloud Director támogatása;
- erőforráspoolok támogatása (amit a tesztelés alatt valósítottak meg);
- a VMware ügynök beállításának lehetősége magától az ügynöktől, anélkül, hogy ügyfélinformációkat kellene megadni az Acura panelen;
- a VM elindításának „vizualizációja” a DR-terv elindításakor.
Az egyetlen dolog, ami jelentős kritikát váltott ki belőlem, az a dokumentáció. Nem kedvelem a „fekete dobozokat”, és inkább szeretem, ha részletes dokumentáció van a termék működéséről. Míg az AWS és az OpenStack esetében a termék leírása még többé-kevésbé rendben van, a VMware vonatkozásában rendkívül kevés dokumentáció áll rendelkezésre.
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 is. Van egy teljes specifikációs csomag a termékről, ami jó. Van egy dokumentáció, amely a beállítást lépésről lépésre írja le az AWS és OpenStack példáján (bár inkább egy blogbejegyzésnek tűnik), és van egy nagyon kicsi Tudásbázis.
Összességében ez nem egészen az a dokumentációs formátum, amelyhez szokva vagyok, mondjuk nagyobb szállítóktól, ezért nem éreztem magam teljesen kényelmesen. Emellett a rendszer működésének néhány részletéről szóló válaszokat nem találtam meg ebben a dokumentációban – nagyon sok kérdést kellett a technikai támogatásnál tisztázni, ami meglehetősen meghosszabbította a tesztelési folyamatot.
Összegzésképpen elmondhatom, hogy összességében a termék és a cég megközelítése a feladat végrehajtásában tetszett. Igen, vannak hiányosságok, és valóban kritikus funkcionalitási elégtelenségek (a VMware-rel kapcsolatban). Látszik, hogy a cég elsősorban a nyilvános felhőkre, különösen az AWS-re összpontosít, és egyesek számára ez elegendő lehet. Ilyen egyszerű és kényelmes termék megléte ma, amikor sok cég a többfelhős stratégiát választja, rendkívül fontos. Figyelembe véve a konkurenciához képest sokkal alacsonyabb árat, ez a terméket rendkívül vonzóvá teszi.
Csapatunkba keresünk . Lehet, hogy éppen Ön az?
Forrás: habr.com
