Hystax Cloud Migration: vi hopper gjennom skyene

En av de unge aktørene innen Disaster Recovery-løsninger er Hystax – et russisk oppstartsselskap fra 2016. Siden temaet katastrofegjenoppretting er svært populært, og konkurransen i markedet er ekstremt høy, valgte oppstarten å fokusere på migrasjon mellom ulike skyinfrastrukturer. Et produkt som muliggjør enkel og rask migrasjon til skyen, ville være svært nyttig for kundene til «Onlanta» — brukerne. Oncloud.ru. Slik ble jeg kjent med Hystax og begynte å teste funksjonaliteten. Hva som kom ut av det, skal jeg fortelle om i denne artikkelen.

Hovedfunksjonen til Hystax er dens brede muligheter for støtte av ulike virtualiseringsplattformer, gjeste-OS og skytjenester, noe som gir mulighet til å overføre arbeidsbelastningene dine fra hvor som helst til hvor som helst.

Dette gjør det mulig å skape ikke bare DR-løsninger for å øke påliteligheten til tjenestene, men også raskt og fleksibelt migrere ressurser mellom ulike plattformer og hyperskalere for å oppnå kostnadsbesparelser og velge den beste løsningen for den spesifikke tjenesten til enhver tid. I tillegg til plattformene som er nevnt på tittelfotoet, samarbeider selskapet også aktivt med russiske skytilbydere: Yandex.Cloud, KROK «Sky tjenester», Mail.ru og mange andre. Det er også verdt å merke seg at selskapet fikk et FoU-senter i 2020, som holder til i Skolkovo. 

Valget av en løsning av mange aktører på markedet indikerer en god prisstrategi og høy anvendelighet av produktet, noe vi også har tenkt å sjekke i praksis.

Så vår testoppgave vil bestå av migrasjon fra min testplattform VMware og fysiske maskiner til plattformen til leverandøren, også drevet av VMware. Ja, det finnes mange løsninger som kan gjennomføre en slik migrasjon, men vi vurderer Hystax som et universelt verktøy, og å teste migrasjon i alle mulige kombinasjoner er ganske enkelt en urealistisk oppgave. Og Oncloud.ru er bygget på nettopp VMware, så vi er i større grad interessert i denne plattformen som mål. Videre vil jeg beskrive hovedprinsippet for arbeidet, som i stor grad ikke avhenger av plattformen, og VMware kan fra hvilken som helst side byttes ut med en plattform fra en annen leverandør. 

I det første trinnet må Hystax Acura implementeres, som er kontrollpanelet for systemet.

Det implementeres fra en mal. Av en eller annen grunn var denne ikke helt korrekt i vårt tilfelle, og i stedet for de anbefalte 8CPU, 16Gb, ble den satt opp med halvparten av ressursene. Derfor må man huske å endre dem, ellers vil ikke infrastrukturen som er bygget opp inne i VM, starte opp, og portalen vil bli utilgjengelig. Implementeringskrav beskriver detaljert de nødvendige ressursene, samt porter for alle systemkomponentene. 

Og det oppsto også problemer med å tildele IP-adresse via malen, så dette ble endret fra konsollen. Etter dette kan man gå til webgrensesnittet til administrasjonspanelet og fylle ut den første konfigurasjonsveiviseren. 

Endpoint – IP eller FQDN til vår vCenter. 
Innlogging og passord – dette er klart. 
Target ESXi hostname – en av vertene i klyngen vår hvor replikasjonen vil skje. 
Target datastore – en av datastore-ene i klyngen vår hvor replikasjonen vil finne sted.
Hystax Acura Control Panel Public IP – adressen hvor kontrollpanelet vil være tilgjengelig.

Det er nødvendig med en liten avklaring angående verten og datastore. Saken er at Hystax-replikasjonen arbeider på vert- og datastore-nivå. Senere vil jeg forklare hvordan man kan endre vert og datastore for en leietaker, men problemet ligger et annet sted. Hystax støtter ikke arbeid med ressursgrupper, det vil si at replikasjonen alltid vil skje i roten av klyngen (da dette materialet ble skrevet, hadde folkene fra Hystax utgitt en oppdatert versjon, hvor de raskt implementerte mitt feature request angående støtte for ressursgrupper). vCloud Director støttes heller ikke, det vil si at hvis leietakeren, som i mitt tilfelle, ikke har administrative rettigheter for hele klyngen, men bare for en spesifikk ressursgruppe, og vi gir tilgang til Hystax, så vil det kunne replikere og starte opp disse VM-ene selvstendig, men det vil ikke kunne se dem i VMware-infrastrukturen, som det har tilgang til, og dermed administrere virtuelle maskiner videre. Det er nødvendig at klyngeadministratoren flytter VM-en til den nødvendige ressursgruppen eller importerer den til vCloud Director.

Hvorfor legger jeg så mye vekt på disse punktene? Fordi, så langt jeg forstår produktkonseptet, må kunden ha muligheten til å gjennomføre enhver migrasjon eller DR selv ved hjelp av Acura-panelet. Men så langt ligger VMware-supporten litt etter i forhold til støtten for OpenStack, hvor slike mekanismer allerede er implementert. 

Men la oss gå tilbake til distribusjonen. Først, etter den første oppsett av panelet, må vi opprette den første tenant i systemet vårt.

Alle feltene her er klare, jeg vil bare si noe om Cloud-feltet. Vi har allerede et «standard» skytjeneste som vi opprettet under første konfigurasjon. Men hvis vi ønsker å ha muligheten til å plassere hver tenant på sin egen datastor og i sin egen ressursgruppe, kan vi realisere dette ved å opprette separate skyer for hver av våre kunder.

I skjemaet for å legge til en ny sky angir vi de samme parametrene som ved den første konfigurasjonen (vi kan til og med bruke den samme verten), angir den nødvendige datastoren for den spesifikke kunden, og nå kan vi i tillegg individuelt angi nødvendig ressursgruppe {«resource_pool»: «YOUR_POOL_NAME»}. 

Som du kanskje har lagt merke til, er det ingenting i skjemaet for opprettelse av tenant som gjelder for ressursallokering eller kvoter - dette er ikke noe systemet har. Det er ikke mulig å begrense tenanten når det gjelder antall samtidige replikaer, antall maskiner for replikasjon eller etter andre parametere. Så, vi har opprettet den første tenant. Nå er det en litt ulogisk, men obligatorisk ting - installasjonen av Cloud-agenten. Den er ulogisk fordi agenten lastes ned fra siden til den spesifikke kunden.

Det binder seg ikke til den opprettede tenant, og alle våre kunder vil bruke det (eller flere, hvis vi distribuerer dem). Én agent støtter 10 samtidige økter. En økt regnes som én maskin. Det spiller ingen rolle hvor mange disker den har. Per i dag finnes det ingen mekanisme for å skalere agenter i Acura under VMware. Det er også et annet ubehagelig moment – vi har ikke mulighet til å se på "utnyttelsen" av denne agenten fra Acura-panelet for å avgjøre om vi trenger å distribuerer flere, eller om nåværende installasjon er tilstrekkelig. Dermed ser standet slik ut:

Neste steg for tilgang til portalen til vår kunde er å opprette en konto (og tidligere også en rolle som skal brukes av denne brukeren).

Nå kan vår kunde bruke portalen selvstendig. Alt han må gjøre, er å laste ned agentene fra portalen og installere dem på sin side. Det finnes tre typer agenter: Linux, Windows og VMware.

De første to installeres på fysiske maskiner eller på virtuelle maskiner på hvilken som helst hypervisor som ikke er VMware. Her kreves det ikke noe ekstra konfigurasjon, agenten lastes ned og vet allerede hvor den skal henvende seg, og rett etter et minutt vil maskinen vises i Acura-panelet. Situasjonen med VMware-agenten er litt mer komplisert. Problemet er at agen for VMware også lastes ned fra portalen allerede forberedt med nødvendig konfigurasjon. Men VMware-agenten må i tillegg til å vite om vår Acura-portal også vite om virtualiseringssystemet den vil bli distribuerte på.

Disse dataene vil systemet be oss om å oppgi ved første nedlasting av VMware-agenten. Problemet er at i vår tid hvor sikkerhet er så viktig, er det ikke alle som vil være villige til å oppgi sitt administratorpassord på en annen portal, noe som er helt forståelig. Innvendig, etter distribusjon, kan ikke agenten konfigureres på annen måte (man kan bare endre nettverksinnstillingene). Her forutser jeg vanskeligheter med spesielt forsiktige kunder. 

Så, etter installasjonen av agentene kan vi gå tilbake til Acura-panelet og se alle våre maskiner.

Siden jeg allerede har jobbet med systemet en stund, har jeg maskiner i forskjellige tilstander. Alle befinner seg i gruppen Default, men det er mulig å opprette separate grupper og flytte maskiner dit etter behov. Dette påvirker ikke noe annet – det er kun en logisk representasjon av dataene og gruppering for mer praktisk arbeid. Det første og viktigste vi må gjøre etter dette er å starte migrasjonsprosessen. Vi kan gjøre dette enten manuelt som en tvungen handling, eller vi kan sette opp en tidsplan, inkludert en masseprosess for alle maskiner samtidig.

Jeg minner om at Hystax er posisjonert som et produkt for migrasjon. Derfor er det ikke overraskende at vi må opprette en DR-plan for å starte våre replikerte maskiner. Planen kan lages for maskiner som allerede er i synkronisert tilstand. Den kan genereres for enten en spesifikk VM eller for alle maskiner samtidig.

Sett med parametere ved generering av DR-planen vil variere avhengig av infrastrukturen som du skal migrere til. For VMware-miljøer er det et minimumssett av parametere tilgjengelig. Re-IP støttes ikke for maskiner. I denne planen er vi interessert i følgende elementer: i beskrivelsen av VM er parameteren «subnet»: «VMNetwork», hvor vi knytter VM til et spesifikt nettverk i klyngen. Rangering – relevant ved migrering av flere VM-er, bestemmer rekkefølgen for deres oppstart. Flavor – beskriver konfigurasjonen av VM, i dette tilfellet – 1CPU, 2GB RAM. I seksjonen subnets definerer vi at «subnet»: «VMNetwork» er assosiert med nettverket «VM Network» i VMware. 

Ved opprettelse av DR-plan er det ikke mulig å «fordele» disker på forskjellige datalagre. De vil være plassert på det samme datalageret som ble definert for denne kunde-skyen, og hvis du har disker av forskjellige klasser, kan dette skape noen vanskeligheter ved oppstart av maskinen, og etter oppstart og «frigjøring» av VM fra Hystax, vil det også kreve en separat migrering av diskene til de nødvendige datalagerne. Deretter må vi bare starte DR-planen vår og vente på at maskinene våre skal starte opp. Prosessen for konvertering fra P2V/V2V tar også tid. På den største testmaskinen min på 100GB med tre disker tok det maks 10 minutter.

Etter dette bør vi sjekke den kjørende VM-en, tjenestene på den, datakonsistensen og utføre andre kontroller. 

Deretter har vi to alternativer: 

1. Slett – fjern den aktive DR-planen. Denne handlingen vil bare slukke den aktive VM. Dataene fra replikaen vil ikke gå noe sted. 
2. Frakobling – løsne den replikerte maskinen fra Acura, dvs. faktisk fullføre migrasjonsprosessen. 

Fordeler med løsningen: 

• enkel installasjon og oppsett både fra kundens og leverandørens side; 
• enkel migrasjonsoppsett, oppretting av DR-plan og oppstart av replikater;
• støtte og utviklere reagerer ganske raskt på oppdagede problemer og løser dem via oppdateringer av plattformen eller agenter. 

Ulemper 

• Utilstrekkelig støtte for Vmware.
• Mangel på noen form for kvotering for leietakere fra plattformen. 

Jeg har også laget en funskjonsforespørsel som vi har sendt til leverandøren:

1. overvåking av bruken og distribusjon fra kontrollpanelet Acura for Cloud-agenter;
2. tilgjengelighet av kvoter for leietakere; 
3. muligheten for å begrense antall samtidige replikeringer og hastighet for hver leietaker; 
4. støtte for VMware vCloud Director; 
5. støtte for ressurspuljer (ble implementert under testing);
6. muligheten for å konfigurere VMware-agenten fra agentens side, uten å måtte legge inn legitimasjon fra klientens infrastruktur i Acura-panelet;
7.  «visualisering» av oppstartsprosessen for VM når DR-planen aktiveres. 

Det eneste jeg hadde store klager på – dokumentasjonen. Jeg liker ikke helt «svartsbokser» og foretrekker detaljert dokumentasjon om hvordan produktet fungerer internt. Og hvis produktet for AWS og OpenStack er beskrevet rimelig, så er dokumentasjonen for VMware ekstremt begrenset. 

Det finnes en Installationsguide som bare beskriver distribusjonen av Acura-panelet, og som ikke nevner at det også trengs en Cloud-agent. Det er et komplett sett med spesifikasjoner for produktet, noe som er bra. Det finnes dokumentasjon som beskriver oppsettet «fra A til Å» med eksempler på AWS og OpenStack (selv om det minner mer om et blogginnlegg), og det finnes en svært begrenset kunnskapsdatabase. 

Generelt er dette ikke helt den type dokumentasjon jeg er vant til, for å si det slik, hos større leverandører, så jeg følte meg ikke helt komfortabel. Samtidig fant jeg ikke svar på noen av de spesifikke detaljene om systemets indre funksjoner i denne dokumentasjonen – svært mange spørsmål måtte jeg avklare med teknisk støtte, og dette forsinket oppsettet og testingen en god del. 

Avslutningsvis kan jeg si at jeg generelt likte produktet og tilnærmingen selskapet har til utførelsen av oppgaven. Ja, det er mangler, det er virkelig kritisk utilstrekkelig funksjonalitet (i forbindelse med VMware). Det er tydelig at selskapet primært fokuserer på offentlige skyer, spesielt AWS, og for noen vil dette være tilstrekkelig. Tilgjengeligheten av et så enkelt og brukervennlig produkt i dag, når mange selskaper velger en multisky-strategi, er ekstremt viktig. Gitt den mye lavere prisen sammenlignet med konkurrentene, gjør dette produktet ekstremt attraktivt.

Vi søker etter en senior systemovervåkingsingeniør. Kanskje det er nettopp deg?

Kilde: habr.com