Hystax Cloud Migration: hoppar mellan moln

En av de yngre aktörerna på marknaden för Disaster Recovery-lösningar är företaget Hystax – en rysk startup från 2016. Eftersom ämnet katastrofåterställning är mycket populärt och konkurrensen på marknaden är extremt hög, beslutade startupen att fokusera på migrering mellan olika molninfrastruktur. Produkten som möjliggör enkel och snabb migrering till molnet skulle vara mycket användbar även för kunderna hos "Onlanta" – användare. Oncloud.ru. Så jag stötte på Hystax och började testa dess funktioner. Vad jag kom fram till kommer jag att berätta om i denna artikel.

Hystax huvudfunktion är dess breda funktionalitet när det gäller stöd för olika virtualisering plattformar, gästoperativsystem och molntjänster, vilket gör det möjligt att flytta dina arbetsbelastningar varifrån som helst till var som helst.

Detta möjliggör skapandet av inte bara DR-lösningar för att öka tjänsternas replikabilitet, utan också att snabbt och flexibelt migrera resurser mellan olika plattformar och hyperskalortjänster för att öka kostnadseffektiviteten och välja den bästa lösningen för en specifik tjänst för tillfället. Förutom plattformarna som listas på bilden, samarbetar företaget också aktivt med ryska molnleverantörer: Yandex.Cloud, KROK "Molntjänster", Mail.ru och många andra. Det är också värt att nämna att företaget 2020 etablerade ett R&D-center i Skolkovo. 

Valet av en lösning av många aktörer på marknaden talar om en god prispolitik och hög tillämpbarhet av produkten, vilket vi också beslutade att verifiera i praktiken.

Så vår testuppgift kommer att bestå av migrering från min testmiljö VMware och fysiska maskiner till leverantörens plattform som också körs på VMware. Ja, det finns många lösningar som kan utföra en sådan migrering, men vi ser Hystax som ett universellt verktyg, och att testa migrering i alla möjliga kombinationer är helt enkelt en orealistisk uppgift. Dessutom är molnet Oncloud.ru byggt just på VMware, så denna plattform är i hög grad intressant för oss som mål. Nästa kommer jag att beskriva huvudprincipen för hur det fungerar, vilket i allmänhet inte beror på plattformen, och VMware kan i vilket fall som helst bytas ut mot en plattform från en annan leverantör. 

I det första steget måste Hystax Acura, som är systemets kontrollpanel, installeras.

Den installeras från en mall. Av någon anledning var den i vårt fall inte helt korrekt och istället för de rekommenderade 8CPU, 16Gb installerades den med halva resurserna. Så det är viktigt att inte glömma att ändra dem, annars kommer infrastrukturen inuti VM:n, som allt är uppbyggt på, helt enkelt inte att starta och portalen kommer att bli otillgänglig. I Utrullningskrav beskriver i detalj de nödvändiga resurserna samt portar för alla systemkomponenter. 

Och det uppstod även problem med att ställa in IP-adressen via mallen, så vi ändrade den från konsolen. Efter det kan man gå till webbgränssnittet för adminpanelen och fylla i den första konfigurationsguiden. 

Endpoint – IP eller FQDN för vår vCenter. 
Inloggning och Lösenord – här är det tydligt. 
Måldatornamn för ESXi – en av värdarna i vår kluster som replikeringen kommer att utföras på. 
Måldatastore – en av datastores i vårt kluster som replikeringen kommer att utföras på.
Hystax Acura Kontrollpanelens offentliga IP – adressen som kontrollpanelen kommer att vara tillgänglig på.

Det krävs en liten förtydligande angående värden och datastores. Det är så att Hystax-replikering fungerar på värdnivå och datastore-nivå. Jag kommer senare att berätta hur man kan byta värd och datastore för tenanten, men problemet ligger någon annanstans. Hystax stöder inte arbetet med resurs-pooler, det vill säga replikeringen kommer alltid att ske i rotkatalogen av klustret (vid tidpunkten för att skriva detta material har Hystax-teamet släppt en uppdaterad version där de snabbt implementerade min funktionsförfrågan angående stöd för resurs-pooler). vCloud Director stöds inte heller, dvs om tenanten, som i mitt fall, inte har administrativa rättigheter på hela klustret, utan bara på en specifik resurs-pool, och vi har gett tillgång till Hystax, så kan den självständigt replikera och starta dessa VM:er, men den kan inte se dem i den VMware-infrastruktur till vilken den har tillgång och kan därför inte hantera virtuella maskiner vidare. Det är nödvändigt att klusteradministratören flyttar VM till den nödvändiga resurs-poolen eller importerar den till vCloud Director.

Varför lägger jag så stor vikt vid dessa punkter? För att, såvitt jag förstår produktens koncept, bör kunden ha möjlighet att självständigt genomföra varje migration eller DR med hjälp av Acura-panelet. Men i nuläget ligger stödet för VMware lite efter jämfört med stödet för OpenStack, där sådana mekanismer redan har implementerats. 

Men låt oss återkomma till distributionen. Först och främst, efter den initiala konfigurationen av panelen, behöver vi skapa den första tenanten i vårt system.

Alla fält här är tydliga, jag kommer bara att prata om fältet Cloud. Vi har redan ett "standard" moln som vi skapade vid den första konfigurationen. Men om vi vill ge varje tenant möjlighet att ha sin egen datastor och sin egen resurspool kan vi realisera det genom att skapa separata moln för var och en av våra kunder.

I formuläret för att lägga till ett nytt moln anger vi samma parametrar som vid den ursprungliga konfigurationen (vi kan till och med använda samma värd), anger den datastor som är lämplig för den specifika kunden, och nu i de ytterligare parametrarna kan vi redan individuellt ange den nödvändiga resurspoolen {"resource_pool": "YOUR_POOL_NAME"} 

Som ni kanske har märkt finns det ingenting i formuläret för att skapa en tenant om resursallokering eller några kvoter – inget av detta finns i systemet. Det går inte att begränsa en tenant vad gäller antalet samtidiga repliker, antalet maskiner för replikering eller något annat parameter. Så, vi har skapat den första tenanten. Nu finns det en något ologisk men obligatorisk sak – installationen av Cloud-agenten. Den är ologisk eftersom agenten laddas ner på sidan för den specifika kunden.

Samtidigt kopplas den inte till den skapade tenanten, och genom den kommer alla våra kunder att arbeta (eller genom flera, om vi distribuerar dem). En agent stöder 10 samtidiga sessioner. En session räknas som en maskin. Det spelar ingen roll hur många diskar den har. För närvarande finns det inget mekanism för att skala agenter i Acura på VMware. Det finns också en annan obehaglig punkt – vi har inte möjlighet att se agentens "utnyttjande" från Acura-panelen för att avgöra om vi behöver distribuera fler eller om den aktuella installationen är tillräcklig. Slutresultatet ser ut som följer:

Nästa steg för att få tillgång till vår kunds portal är att skapa ett konto (och först även en roll som ska tillämpas på denna användare).

Nu kan vår kund använda portalen självständigt. Allt de behöver göra är att ladda ner agenter från portalen och installera dem på sin sida. Det finns tre typer av agenter: Linux, Windows och VMware.

De första två installeras på fysisk hårdvara eller virtuella maskiner på vilken hypervisor som helst, förutom VMware. Här krävs ingen ytterligare konfiguration, agenten laddas ner och vet redan vart den ska gå, och efter bara en minut kommer maskinen att visas i Acura-panelen. Situationen med VMware-agenten är något mer komplicerad. Problemet är att agenten för VMware också laddas ner från portalen redan förberedd med nödvändig konfiguration. Men VMware-agenten behöver, förutom att veta om vår Acura-portal, också känna till den virtualiseringssystem som den kommer att distribueras på.

Egentligen är det dessa uppgifter som systemet kommer att be oss ange när vi först laddar ner VMware-agenten. Problemet är att i vår tid av allomfattande säkerhetsmedvetenhet kommer inte alla vilja ange sitt administratörslösenord på en annan portals, vilket är helt förståeligt. Efter att den har distribuerats kan agenten inte konfigureras på något sätt (man kan bara ändra sina nätverksinställningar). Här förutser jag svårigheter med särskilt försiktiga kunder. 

Så, efter installationen av agenterna kan vi återvända till Acura-panelen och se alla våra maskiner.

Eftersom jag redan har arbetat med systemet i flera dagar, har jag maskiner i olika tillstånd. Alla mina maskiner ligger i gruppen Default, men det går att skapa separata grupper och flytta maskiner dit, om det är vad du behöver. Det påverkar inget – det är bara en logisk presentation av data och gruppering för att underlätta arbetet. Det första och absolut viktigaste vi behöver göra efter detta är att starta migrationsprocessen. Vi kan göra detta antingen manuellt och tvingat, eller ställa in ett schema, inklusive att massmigrera alla maskiner samtidigt.

Jag påminner om att Hystax positionerades som en produkt för migration. Så det är inget konstigt att vi behöver skapa en DR-plan för att starta våra replikerade maskiner. Planen kan upprättas för maskiner som redan är i Synced-tillstånd. Den kan genereras antingen för en specifik VM eller för alla maskiner samtidigt.

Mängden parametrar vid generering av DR-planen kommer att skilja sig beroende på den infrastruktur till vilken du ska migrera. För VMware-miljöer finns en minimuppsättning parametrar tillgänglig. Re-IP stöds inte för maskiner. I denna plan är följande punkter av intresse för oss: i beskrivningen av VM-parametern "subnet": "VMNetwork", där vi kopplar VM till ett specifikt nätverk i klustret. Rank – är relevant vid migrering av flera VM och definierar ordning för deras start. Flavor – beskriver konfigureringen av VM, i detta fall – 1CPU, 2GB RAM. I sektionen subnets definierar vi att "subnet": "VMNetwork" är associerad med nätverket "VM Network" VMware. 

Vid skapande av DR-planen finns det ingen möjlighet att "dela upp" diskar över olika datalager. De kommer att ligga på samma datalager som har bestämts för detta kundmoln, och om du har diskar av olika klass kan det orsaka vissa problem vid start av maskinen, och efter start och "avkoppling" av VM från Hystax, kommer det också att kräva en separat migrering av diskarna till de rätta datalagerna. Därefter återstår det bara för oss att starta vår DR-plan och vänta tills våra maskiner startar. Processen för P2V/V2V-konvertering tar också tid. På min största testmaskin på 100 GB med tre diskar tog det som mest 10 minuter.

Efter detta är det viktigt att kontrollera den körande VM:en, tjänsterna på den, dataens konsistens och genomföra andra kontroller. 

Därefter har vi två vägar: 

1. Ta bort – radera den aktiva DR-planen. Denna åtgärd kommer helt enkelt att stänga av den aktiva VM:en. Replika-data försvinner inte. 
2. Frikoppla – koppla bort den replikerade maskinen från Acura, dvs. faktiskt avsluta migrationsprocessen. 

Fördelar med lösningen: 

• enkel installation och konfigurering både från kundens och leverantörens sida; 
• enkel konfigurering av migration, skapande av DR-plan och start av replikat;
• supporten och utvecklarna reagerar ganska snabbt på upptäckta problem och åtgärdar dem genom plattformsuppdateringar eller agenter. 

Nackdelar 

• Otillräckligt stöd för Vmware.
• Avsaknad av eventuell kvotering för hyresgäster från plattformens sida. 

Jag har även sammanställt en funktionbegäran som vi har skickat till leverantören:

1. övervakning av användning och distribution från kontrollpanelen Acura för Cloud-agenter;
2. förekomst av kvoter för hyresgäster; 
3. möjlighet att begränsa antalet samtidiga replikationer och hastighet för varje hyresgäst; 
4. stöd för VMware vCloud Director; 
5. stöd för resurspooler (genomfördes under testningen);
6. möjlighet att konfigurera VMware-agenten från agentens sida, utan att ange autentiseringsuppgifter från kundens infrastruktur i Acura-panelen;
7.  "visualisering" av processen för att starta VM vid aktivering av DR-planen. 

Det enda jag hade stora invändningar mot var dokumentationen. Jag gillar inte riktigt "svarta lådor" och föredrar detaljerad dokumentation om hur produkten fungerar internt. Medan produkten för AWS och OpenStack är hyfsat beskriven, finns det extremt lite dokumentation för VMware. 

Det finns en installationsguide som bara beskriver distributionen av Acura-panelen, där det inte nämns något om att Cloud-agenten också behövs. Det finns en fullständig uppsättning specifikationer för produkten, vilket är bra. Det finns dokumentation som beskriver inställningar "från början till slut" med exempel på AWS och OpenStack (även om den mer påminner om ett blogginlägg), och det finns en mycket liten kunskapsbas. 

Sammanfattningsvis är detta inte riktigt den typ av dokumentation jag är van vid, säg hos större leverantörer, så jag kände mig inte helt bekväm. Samtidigt kunde jag inte hitta svar på vissa aspekter av systemets "inre" funktioner i denna dokumentation – väldigt många frågor var tvungna att bekräftas med teknisk support, vilket kraftigt förlängde processen för att ställa upp plattformen och genomföra tester. 

Sammanfattningsvis kan jag säga att jag överlag gillade produkten och företagets angångssätt för att lösa uppgiften. Ja, det finns brister, och det finns faktiskt allvarliga funktionalitetsproblem (i samband med VMware). Det är tydligt att företaget främst riktar in sig på offentliga moln, särskilt AWS, vilket kanske är tillräckligt för vissa. Att ha en så enkel och användarvänlig produkt idag, när många företag väljer en multicloud-strategi, är extremt viktigt. Med tanke på det mycket lägre priset jämfört med konkurrenterna gör detta produkten väldigt attraktiv.

Vi söker en ledande ingenjör inom övervakningssystem. Kanske är det just du?

Källa: habr.com