En af de unge spillere på markedet for Disaster Recovery-løsninger er Hystax, en russisk startup i 2016. Da emnet disaster recovery er meget populært, og markedet er ekstremt konkurrencedygtigt, besluttede startup'et at fokusere på migrering mellem forskellige cloud-infrastrukturer. Et produkt, der giver dig mulighed for at organisere en enkel og hurtig migrering til skyen, ville være meget nyttigt for Onlantas kunder - brugere . Det var sådan, jeg lærte Hystax at kende og begyndte at teste dens funktioner. Og hvad der kom ud af det, vil jeg fortælle i denne artikel.
Hovedegenskaben ved Hystax er dens brede funktionalitet til at understøtte forskellige virtualiseringsplatforme, gæste-OS og cloud-tjenester, hvilket gør det muligt at flytte dine arbejdsbelastninger fra hvor som helst og hvor som helst.
Dette giver dig mulighed for at skabe ikke kun DR-løsninger for at forbedre fejltolerancen af tjenester, men også hurtigt, fleksibelt migrere ressourcer mellem forskellige sites og hyperscalere for at øge omkostningsbesparelser og vælge den bedste løsning til en bestemt tjeneste i øjeblikket. Ud over de platforme, der er anført i titelbilledet, samarbejder virksomheden også aktivt med russiske cloud-udbydere: Yandex.Cloud, CROC Cloud Services, Mail.ru og mange andre. Det er også værd at bemærke, at virksomheden i 2020 åbnede et R&D-center i Skolkovo.
Valget af én løsning af et stort antal aktører på markedet indikerer en god prispolitik og høj anvendelighed af produktet, som vi besluttede at teste i praksis.
Så vores testopgave vil bestå i at migrere fra mit VMware-teststed og fysiske maskiner til udbyderens websted, der også kører VMware. Ja, der er mange løsninger, der kan implementere sådan en migrering, men vi betragter Hystax som et universelt værktøj, og at teste migreringen i alle mulige kombinationer er simpelthen en urealistisk opgave. Ja, og Oncloud.ru-skyen er bygget specifikt på VMware, så denne platform, som et mål, interesserer os i højere grad. Dernæst vil jeg beskrive det grundlæggende funktionsprincip, som som helhed ikke afhænger af platformen, og VMware kan udskiftes fra enhver side med en platform fra en anden leverandør.
Det første skridt er at implementere Hystax Acura, som er systemets kontrolpanel.
Det udvides fra skabelonen. Af en eller anden grund, i vores tilfælde, var det ikke helt korrekt, og i stedet for den anbefalede 8CPU blev 16 Gb installeret med halvdelen af ressourcerne. Derfor må du ikke glemme at ændre dem, ellers vil infrastrukturen inde i VM'en, som alt er bygget på, simpelthen ikke starte med containere, og portalen vil være utilgængelig. I de nødvendige ressourcer er beskrevet i detaljer, samt porte for alle systemkomponenter.
Og der var også vanskeligheder med at indstille IP-adressen gennem skabelonen, så vi ændrede den fra konsollen. Derefter kan du gå til admin-webgrænsefladen og fuldføre den indledende konfigurationsguide.
Slutpunkt - IP eller FQDN af vores vCenter.
Login og adgangskode - det er tydeligt her.
Target ESXi hostname er en af værterne i vores klynge, som vil blive replikeret til.
Target datastore er et af datalagrene i vores klynge, som vil blive replikeret til.
Hystax Acura Control Panel Public IP - adressen hvor kontrolpanelet vil være tilgængeligt.
En lille afklaring om værten og datalageret er påkrævet. Faktum er, at Hystax-replikering fungerer på værts- og datalagerniveau. Dernæst vil jeg fortælle dig, hvordan du kan ændre værten og datalageret for lejeren, men problemet er anderledes. Hystax understøtter ikke ressourcepooling, dvs. replikaen vil altid ske med roden af klyngen (på tidspunktet for skrivningen af dette materiale udgav fyrene fra Hystax en opdateret version, hvor de hurtigt implementerede min funktionsanmodning vedrørende support til ressourcepuljer). Heller ikke vCloud Director understøttes, dvs. hvis lejeren, som i mit tilfælde, ikke har administratorrettigheder til hele klyngen, men kun til en specifik ressourcepulje, og vi gav adgang til Hystax, så vil han være i stand til selvstændigt at replikere og køre disse VM'er, men han vil ikke være i stand til at se dem i VMware-infrastrukturen , som han har adgang til og følgelig administrere virtuelle maskiner yderligere. Klyngeadministratoren skal flytte VM'en til den korrekte ressourcepulje eller importere den til vCloud Director.
Hvorfor fokuserer jeg så meget på disse øjeblikke? Fordi, så vidt jeg forstår konceptet med produktet, bør kunden selvstændigt kunne implementere enhver migration eller DR ved hjælp af Acura panelet. Men indtil videre er VMware-understøttelse en smule bagud under supportniveauet for den samme OpenStack, hvor sådanne mekanismer allerede er blevet implementeret.
Men tilbage til udbredelsen. Først og fremmest skal vi efter den indledende opsætning af panelet oprette den første lejer i vores system.
Alle felterne her er klare, jeg vil kun fortælle dig om Cloud-feltet. Vi har allerede en "standard" sky, som vi oprettede under den indledende konfiguration. Men hvis vi ønsker at kunne placere hver lejer på sit eget datalager og i sin egen ressourcepulje, kan vi implementere dette ved at skabe separate skyer for hver af vores kunder.
I form af tilføjelse af en ny sky specificerer vi de samme parametre som under den indledende konfiguration (vi kan endda bruge den samme vært), specificerer det datalager, der kræves for en bestemt kunde, og nu i de yderligere parametre kan vi allerede individuelt angive påkrævet puljeressource {"resource_pool" :"YOUR_POOL_NAME"}
Som du måske har bemærket, er der i form af oprettelse af en lejer intet om tildeling af ressourcer eller en form for kvoter – det er der ikke noget af i systemet. Du kan ikke begrænse lejeren i antallet af samtidige replikaer, antallet af maskiner til replikering eller andre parametre. Så vi har oprettet den første lejer. Nu er der en ikke helt logisk, men obligatorisk ting - at installere en Cloud-agent. Det er ulogisk, fordi agenten downloades på en bestemt kundes side.
Samtidig er det ikke bundet til den oprettede lejer, og alle vores kunder vil arbejde igennem det (eller efter flere, hvis vi implementerer dem). Én agent understøtter 10 samtidige sessioner. Én session tæller som én bil. Det er lige meget, hvor mange diske den har. Til dato er der ingen mekanisme til skaleringsmidler i selve Acura til VMware. Der er endnu et ubehageligt øjeblik - vi er ikke i stand til at se på "udnyttelsen" af denne agent fra Acura-panelet for at konkludere, om vi skal implementere mere, eller om den nuværende installation er nok. Som et resultat ser standen således ud:
Det næste trin for at få adgang til vores kundes portal er at oprette en konto (og først, også en rolle, der vil blive anvendt på denne bruger).
Nu kan vores kunde bruge portalen selvstændigt. Alt han skal gøre er at downloade agenter fra portalen og installere dem på sin side. Der er tre typer agenter: Linux, Windows og VMware.
De første to er sat på fysik eller på virtuelle maskiner på enhver ikke-VMware hypervisor. Der kræves ingen yderligere konfiguration her, agenten downloader og ved allerede, hvor han skal banke på, og bogstaveligt talt om et minut vil bilen være synlig i Acura-panelet. Med VMware-agenten er situationen lidt mere kompliceret. Problemet er, at Agent for VMware også downloades fra portalen, der allerede er forberedt og har den nødvendige konfiguration. Men VMware-agenten skal ud over at kende til vores Acura-portal også vide om det virtualiseringssystem, som det vil blive implementeret på.
Faktisk vil systemet bede os om at angive disse data, når du først downloader VMware-agenten. Problemet er, at i vores tidsalder med universel kærlighed til sikkerhed, vil ikke alle ønsker at angive deres administratoradgangskode på en andens portal, hvilket er ganske forståeligt. Indefra kan agenten ikke konfigureres på nogen måde efter implementeringen (du kan kun ændre dens netværksindstillinger). Her forudser jeg vanskeligheder med særligt forsigtige kunder.
Så efter at have installeret agenterne, kan vi gå tilbage til Acura-panelet og se alle vores biler.
Da jeg har arbejdet med systemet i mere end en dag, har jeg maskiner i forskellige tilstande. Alle er i standardgruppen, men det er muligt at oprette separate grupper og overføre maskiner til dem, efter behov. Dette påvirker ikke noget - kun den logiske repræsentation af data og deres gruppering for mere bekvemt arbejde. Det første og vigtigste, vi skal gøre efter det, er at starte migreringsprocessen. Vi kan gøre dette både tvangsmæssigt manuelt og opsætte en tidsplan, herunder i bulk for alle maskiner på én gang.
Lad mig minde dig om, at Hystax var placeret som et produkt til migration. Derfor er det ikke overraskende, at vi for at kunne køre vores replikerede maskiner skal lave en DR-plan. Du kan oprette en plan for maskiner, der allerede er i synkroniseret tilstand. Du kan generere både for en specifik VM og for alle maskiner på én gang.
Sættet af parametre, når du genererer en DR-plan, vil variere afhængigt af den infrastruktur, du vil migrere til. Et minimalt sæt muligheder er tilgængeligt for et VMware-miljø. Re-IP til maskiner er heller ikke understøttet. I denne henseende er vi interesserede i følgende punkter: i beskrivelsen af VM, parameteren "subnet": "VMNetwork", hvor vi binder VM'en til et specifikt netværk i klyngen. Rang - relevant ved migrering af flere VM'er, bestemmer den rækkefølge, de lanceres i. Flavour beskriver VM-konfigurationen, i dette tilfælde 1CPU, 2GB RAM. I sektionen undernet definerer vi, at "undernet": "VMNetwork" er forbundet med "VM-netværket" af VMware.
Når du opretter en DR-plan, er der ingen måde at "dele" diske på tværs af forskellige datalagre. De vil være placeret på det samme datalager, som blev defineret for denne klientsky, og hvis du har diske af forskellige klasser, kan det give nogle vanskeligheder ved start af maskinen, og efter start og "adskillelse" af VM'en fra Hystax, vil den også kræver en separat migreringsdiske til de nødvendige datalagre. Så skal vi bare køre vores DR-plan og vente på, at vores biler rejser sig. P2V/V2V-konverteringsprocessen tager også tid. På min største 100GB testmaskine med tre diske tog dette max 10 minutter.
Derefter skal du tjekke den kørende VM, tjenester på den, datakonsistens og andre kontroller.
Så har vi to muligheder:
- Slet - slet en kørende DR-plan. Denne handling vil simpelthen lukke den kørende VM ned. Disse replikaer kommer ingen steder hen.
- Afmonter - riv den replikerede bil af Acura, dvs. faktisk fuldføre migreringsprocessen.
Fordele ved løsningen:
- nem installation og konfiguration både på klientsiden og på udbydersiden;
- nem opsætning af migration, oprettelse af en DR-plan og lancering af replikaer;
- support og udviklere reagerer ret hurtigt på de fundne problemer og løser dem med platform- eller agentopdateringer.
Cons
- Utilstrækkelig Vmware-understøttelse.
- Fraværet af nogen kvote for lejere fra platformen.
Jeg lavede også en Feature Request, som vi overdrog til leverandøren:
- brugsovervågning og implementering fra Acura Management Console for Cloud Agents;
- tilgængelighed af kvoter for lejere;
- evnen til at begrænse antallet af samtidige replikationer og hastighed for hver lejer;
- understøttelse af VMware vCloud Director;
- støtte til ressourcepuljer (blev implementeret under test);
- evnen til at konfigurere VMware-agenten fra siden af selve agenten uden at indtaste legitimationsoplysninger fra klientinfrastrukturen i Acura-panelet;
- "Visualisering" af processen med at starte en VM ved opstart af en DR-plan.
Det eneste, der gav mig store klager, var dokumentationen. Jeg kan ikke rigtig godt lide "sorte kasser" og foretrækker, når der er detaljeret dokumentation for, hvordan produktet fungerer indeni. Og hvis for AWS og OpenStack er produktet beskrevet endnu mere eller mindre, så er der for VMware meget lidt dokumentation.
Der er en installationsvejledning, der kun beskriver udrulningen af Acura-panelet, og hvor der ikke er et ord om behovet for en Cloud-agent. Der er et komplet sæt specifikationer for produktet, hvilket er godt. Der er dokumentation, der beskriver opsætningen "fra og til" ved at bruge AWS og OpenStack som eksempel (selvom det minder mig mere om et blogindlæg), og der er en meget lille Knowledge Base.
Generelt er dette ikke helt det dokumentationsformat, som jeg er vant til, f.eks. fra større leverandører, så jeg var ikke helt tryg. Samtidig fandt jeg ikke svar på nogle af nuancerne af systemets drift "inde i" i denne dokumentation - jeg var nødt til at afklare en masse spørgsmål med teknisk support, og det trak snarere processen med at installere standen og afprøvning.
Sammenfattende kan jeg sige, at jeg generelt kunne lide produktet og virksomhedens tilgang til opgavens gennemførelse. Ja, der er fejl, der er en virkelig kritisk mangel på funktionalitet (i forbindelse med VMware). Det kan ses, at virksomheden for det første stadig fokuserer på offentlige skyer, især AWS, og for nogle vil det være nok. At have et så enkelt og bekvemt produkt i dag, hvor mange virksomheder vælger en multi-cloud-strategi, er ekstremt vigtigt. I betragtning af den meget lavere pris sammenlignet med konkurrenterne, gør dette produktet yderst attraktivt.
Vi søger et hold . Måske er det dig?
Kilde: www.habr.com