En av de unge aktørene på markedet for Disaster Recovery-løsninger er Hystax, en russisk oppstart fra 2016. Siden temaet katastrofegjenoppretting er veldig populært og markedet er ekstremt konkurransedyktig, bestemte oppstarten seg for å fokusere på migrering mellom forskjellige skyinfrastrukturer. Et produkt som lar deg organisere en enkel og rask migrering til skyen vil også være svært nyttig for Onlantas kunder - brukere . Det var slik jeg ble kjent med Hystax og begynte å teste funksjonene. Og hva som kom ut av det, vil jeg fortelle i denne artikkelen.
Hovedtrekket til Hystax er dens brede funksjonalitet for å støtte ulike virtualiseringsplattformer, gjesteoperativsystemer og skytjenester, noe som gjør det mulig å overføre arbeidsbelastningene dine fra hvor som helst og hvor som helst.
Dette lar deg lage ikke bare DR-løsninger for å forbedre feiltoleransen til tjenester, men også raskt, fleksibelt migrere ressurser mellom forskjellige nettsteder og hyperskalere for å øke kostnadsbesparelsene og velge den beste løsningen for en bestemt tjeneste for øyeblikket. I tillegg til plattformene som er oppført i tittelbildet, samarbeider selskapet også aktivt med russiske skyleverandører: Yandex.Cloud, CROC Cloud Services, Mail.ru og mange andre. Det er også verdt å merke seg at selskapet i 2020 åpnet et FoU-senter lokalisert i Skolkovo.
Valget av én løsning av et stort antall aktører på markedet indikerer en god prispolitikk og høy anvendelighet av produktet, som vi bestemte oss for å teste i praksis.
Så testoppgaven vår vil bestå av migrering fra mitt VMware-teststed og fysiske maskiner til leverandørens nettsted, også administrert av VMware. Ja, det er mange løsninger som kan utføre en slik migrering, men vi anser Hystax som et universelt verktøy, og å teste migrering i alle mulige kombinasjoner er rett og slett en urealistisk oppgave. Og Oncloud.ru-skyen er bygget spesifikt på VMware, så denne plattformen som mål interesserer oss i større grad. Deretter vil jeg beskrive det grunnleggende operasjonsprinsippet, som generelt er uavhengig av plattformen, og VMware fra alle sider kan erstattes av en plattform fra en annen leverandør.
Det første trinnet er å distribuere Hystax Acura, som er kontrollpanelet til systemet.
Den utvides fra malen. Av en eller annen grunn, i vårt tilfelle, var det ikke helt riktig, og i stedet for den anbefalte 8CPU, ble 16 Gb distribuert med halvparten av ressursene. Derfor må du ikke glemme å endre dem, ellers vil infrastrukturen inne i VM, som alt er bygget på, ganske enkelt ikke starte med containere og portalen vil være utilgjengelig. I De nødvendige ressursene er beskrevet i detalj, samt porter for alle systemkomponenter.
Det var også vanskeligheter med å angi IP-adressen gjennom en mal, så vi endret den fra konsollen. Etter dette kan du gå til admin-nettgrensesnittet og fullføre den innledende konfigurasjonsveiviseren.
Endepunkt – IP eller FQDN til vCenteret vårt.
Innlogging og passord - det er tydelig her.
Target ESXi vertsnavn er en av vertene i klyngen vår som vil bli replikert til.
Target datastore er en av datalagrene i klyngen vår som replikering vil bli utført til.
Hystax Acura Control Panel Public IP – adressen hvor kontrollpanelet vil være tilgjengelig.
En liten avklaring er nødvendig angående verten og datalageret. Faktum er at Hystax-replikering fungerer på verts- og datalagernivå. Deretter vil jeg fortelle deg hvordan du kan endre verten og datalageret for leietakeren, men problemet er annerledes. Hystax støtter ikke arbeid med ressurspooler, dvs. replikaen vil alltid skje med roten til klyngen (på tidspunktet for skriving av dette materialet ga gutta fra Hystax ut en oppdatert versjon, der de raskt implementerte min funksjonsforespørsel angående støtte for ressurspooler). vCloud Director støttes heller ikke, dvs. hvis, som i mitt tilfelle, leietaker ikke har administratorrettigheter til hele klyngen, men bare til en spesifikk ressurspool, og vi ga tilgang til Hystax, så vil han kunne replikere og kjøre disse VM-ene uavhengig, men han vil ikke være i stand til å se dem i VMware-infrastrukturen , som han har tilgang til, og følgelig administrere virtuelle maskiner videre. Klyngeadministratoren må flytte VM-en til riktig ressurspool eller importere den til vCloud Director.
Hvorfor fokuserer jeg så mye på disse punktene? Fordi, så langt jeg forstår konseptet til produktet, bør kunden selvstendig kunne implementere enhver migrering eller DR ved hjelp av Acura-panelet. Men så langt ligger VMware-støtte litt bak støttenivået for OpenStack, hvor lignende mekanismer allerede er implementert.
Men la oss gå tilbake til distribusjon. Først av alt, etter det første oppsettet av panelet, må vi opprette den første leietakeren i systemet vårt.
Alle feltene her er klare, jeg vil bare fortelle deg om Cloud-feltet. Vi har allerede en "standard" sky som vi opprettet under den første konfigurasjonen. Men hvis vi ønsker å kunne legge hver leietaker på sitt eget datalager og i sin egen ressurspool, kan vi implementere dette ved å lage separate skyer for hver av våre kunder.
I skjemaet for å legge til en ny sky spesifiserer vi de samme parameterne som under den første konfigurasjonen (vi kan til og med bruke samme vert), indikerer datalageret som kreves for en spesifikk kunde, og nå i tilleggsparametere kan vi spesifisere den nødvendige ressursen individuelt. pool {"resource_pool" : "DIN_POOL_NAME"}
Som du kanskje har lagt merke til, i form av å opprette en leietaker står det ingenting om tildeling av ressurser eller noen form for kvoter – det er ingenting av dette i systemet. Du kan ikke begrense leietakeren i antall samtidige replikaer, antall maskiner for replikering eller andre parametere. Så vi har opprettet den første leietakeren. Nå er det en ikke helt logisk, men obligatorisk ting – å installere en Cloud-agent. Det er ulogisk, siden agenten lastes ned på siden til en bestemt kunde.
Samtidig er den ikke bundet til den opprettede leietakeren, og alle våre kunder vil jobbe seg gjennom den (eller etter flere, hvis vi distribuerer dem). Én agent støtter 10 samtidige økter. Én økt teller som én bil. Det spiller ingen rolle hvor mange disker den har. Til dags dato er det ingen mekanisme for skaleringsmidler i selve Acura for VMware. Det er enda et ubehagelig øyeblikk - vi er ikke i stand til å se på "bruken" av denne agenten fra Acura-panelet for å konkludere om vi trenger å distribuere mer eller om den nåværende installasjonen er nok. Som et resultat ser stativet slik ut:
Det neste trinnet for å få tilgang til kundeportalen vår er å opprette en konto (og først en rolle som gjelder for denne brukeren).
Nå kan vår kunde bruke portalen uavhengig. Alt han trenger å gjøre er å laste ned agentene fra portalen og installere den på siden hans. Det finnes tre typer agenter: Linux, Windows og VMware.
De to første settes på fysikk eller på virtuelle maskiner på en hvilken som helst hypervisor som ikke er VMware. Det er ikke nødvendig å konfigurere noe ekstra, agenten er lastet ned og vet allerede hvor den skal banke, og bokstavelig talt om et minutt vil bilen være synlig i Acura-panelet. Med VMware-agenten er situasjonen litt mer komplisert. Problemet er at agenten for VMware også lastes ned fra portalen som allerede er forberedt og inneholder den nødvendige konfigurasjonen. Men VMware-agenten trenger, i tillegg til å vite om Acura-portalen vår, også å vite om virtualiseringssystemet den skal distribueres på.
Faktisk vil systemet be oss om å oppgi disse dataene når vi først laster ned VMware-agenten. Problemet er at i vår tidsalder med universell kjærlighet til sikkerhet, vil ikke alle ønske å angi administratorpassordet sitt på andres portal, noe som er ganske forståelig. Fra innsiden, etter distribusjon, kan ikke agenten konfigureres på noen måte (du kan bare endre nettverksinnstillingene). Her ser jeg vanskeligheter med spesielt forsiktige kunder.
Så, etter å ha installert agentene, kan vi gå tilbake til Acura-panelet og se alle bilene våre.
Siden jeg har jobbet med systemet i mer enn en dag, har jeg maskiner i forskjellige tilstander. Alle er i standardgruppen, men det er mulig å opprette separate grupper og overføre maskiner til dem, etter behov. Dette påvirker ikke noe - bare en logisk representasjon av dataene og deres gruppering for mer praktisk arbeid. Det første og viktigste vi må gjøre etter det er å starte migrasjonsprosessen. Vi kan gjøre dette både tvangsmessig manuelt, og sette opp en tidsplan, inkludert i bulk for alle maskiner samtidig.
La meg minne deg på at Hystax ble posisjonert som et produkt for migrering. Derfor er det ikke overraskende at for å kunne kjøre våre replikerte maskiner, må vi lage en DR-plan. Du kan opprette en plan for maskiner som allerede er i synkronisert tilstand. Du kan generere både for én spesifikk VM, og for alle maskiner samtidig.
Settet med parametere når du genererer en DR-plan vil variere avhengig av infrastrukturen du vil migrere til. Et minimalt sett med alternativer er tilgjengelig for et VMware-miljø. Re-IP for maskiner støttes heller ikke. I denne forbindelse er vi interessert i følgende punkter: i VM-beskrivelsen, "subnett"-parameteren: "VMNetwork", der vi binder VM-en til et spesifikt nettverk i klyngen. Rangering – relevant ved migrering av flere VM-er, bestemmer rekkefølgen de lanseres i. Flavour beskriver VM-konfigurasjonen, i dette tilfellet 1CPU, 2GB RAM. I undernettdelen definerer vi at "subnett": "VMNetwork" er knyttet til VMware "VM Network".
Når du oppretter en DR-plan, er det ingen måte å "dele" disker på tvers av forskjellige datalagre. De vil være plassert på samme datalager som ble definert for denne klientskyen, og hvis du har disker av forskjellige klasser, kan dette forårsake noen problemer når du starter maskinen, og etter å ha startet og "separert" VM fra Hystax, vil den også krever en separat migreringsdisker til de nødvendige datalagrene. Da er det bare å lansere DR-planen vår og vente på at bilene våre skal reise seg. P2V/V2V-konverteringsprosessen tar også tid. På min største testmaskin, 100GB med tre disker, tok det maks 10 minutter.
Etter dette bør du sjekke den kjørende VM, tjenestene på den, konsistensen av dataene og utføre andre kontroller.
Da har vi to alternativer:
- Slett – slett den kjørende DR-planen. Denne handlingen vil ganske enkelt slå av den kjørende VM-en. Disse kopiene kommer ingen steder.
- Løsne – riv en replikert bil vekk fra en Acura, dvs. faktisk fullføre migreringsprosessen.
Fordeler med løsningen:
- enkel installasjon og konfigurasjon både fra klienten og fra leverandøren;
- enkelt å sette opp migrering, lage en DR-plan og lansere kopier;
- støtte og utviklere reagerer ganske raskt på problemer som er funnet og fikser dem ved hjelp av plattform- eller agentoppdateringer.
Cons
- Utilstrekkelig Vmware-støtte.
- Fravær av noen kvote for leietakere fra plattformen.
Jeg kompilerte også en funksjonsforespørsel, som vi sendte til leverandøren:
- bruksovervåking og distribusjon fra Acura-administrasjonskonsollen for skyagenter;
- tilgjengelighet av kvoter for leietakere;
- muligheten til å begrense antall samtidige replikasjoner og hastighet for hver leietaker;
- støtte for VMware vCloud Director;
- støtte for ressurspooler (implementert under testing);
- muligheten til å konfigurere VMware-agenten fra siden av selve agenten, uten å legge inn legitimasjon fra klientinfrastrukturen i Acura-panelet;
- "visualisering" av VM-oppstartsprosessen når du kjører DR-planen.
Det eneste som ga meg stor kritikk var dokumentasjonen. Jeg liker egentlig ikke "svarte bokser" og foretrekker når det er detaljert dokumentasjon om hvordan produktet fungerer inni. Og hvis for AWS og OpenStack er produktet beskrevet enda mer eller mindre, så er det veldig lite dokumentasjon for VMware.
Det er en installasjonsveiledning som kun beskriver utplasseringen av Acura-panelet, og hvor det ikke står et ord om behovet for en Cloud-agent. Det er et komplett sett med spesifikasjoner for produktet, noe som er bra. Det er dokumentasjon som beskriver oppsettet "fra og til" ved å bruke AWS og OpenStack som eksempel (selv om det minner meg mer om et blogginnlegg), og det er en veldig liten kunnskapsbase.
Generelt er dette ikke helt dokumentasjonsformatet som jeg er vant til, for eksempel fra større leverandører, så jeg var ikke helt komfortabel. Samtidig fant jeg aldri svar på noen av nyansene i hvordan systemet fungerer "inne" i denne dokumentasjonen - mange spørsmål måtte avklares med teknisk støtte, og dette forsinket ganske mye prosessen med å distribuere standen og gjennomføre testing.
For å oppsummere kan jeg si at jeg generelt likte produktet og selskapets tilnærming til oppgaven. Ja, det er mangler, det er en virkelig kritisk mangel på funksjonalitet (i forbindelse med VMware). Det er klart at for det første er selskapet fortsatt fokusert på offentlige skyer, spesielt AWS, og for noen vil dette være nok. Å ha et så enkelt og praktisk produkt i dag, når mange bedrifter velger en multiskystrategi, er ekstremt viktig. Med tanke på den mye lavere prisen sammenlignet med konkurrentene, gjør dette produktet ekstremt attraktivt.
Vi ser etter et team . Kanskje det er deg?
Kilde: www.habr.com