En af de unge spillere på markedet for Disaster Recovery-løsninger er Hystax – en russisk startup fra 2016. Da emnet for katastrofegendannelse er meget populært, og konkurrencen på markedet er ekstremt hård, har startupen besluttet at fokusere på migration mellem forskellige cloud-infrastrukturer. Et produkt, der muliggør en nem og hurtig migration til skyen, ville være meget nyttigt også for kunderne hos "Onlanta" — brugerne . Sådan stødte jeg på Hystax og begyndte at teste dets muligheder. Hvad der kom ud af det, vil jeg fortælle om i denne artikel.
Den primære funktion ved Hystax er dens brede funktionalitet til at understøtte forskellige virtualiseringsplatforme, gæste-OS og cloud-tjenester, hvilket giver mulighed for at flytte dine arbejdsbelastninger fra hvor som helst til hvor som helst.
Dette gør det muligt at skabe ikke kun DR-løsninger for at øge servicen tilgængelighed, men også hurtigt og fleksibelt migrere ressourcer mellem forskellige platforme og hyperskalere for at øge besparelserne og vælge den bedste løsning til en bestemt service på det pågældende tidspunkt. Udover de platforme, der er nævnt på titelbilledet, samarbejder virksomheden også aktivt med russiske cloud-udbydere: Yandex.Cloud, KROK "Cloud Services", Mail.ru og mange andre. Det er også værd at bemærke, at virksomheden i 2020 fik et R&D-center beliggende i Skolkovo.
Valget af én løsning af mange aktører på markedet vidner om en god prisstrategi og høj anvendelighed af produktet, hvilket vi også besluttede at teste i praksis.
Så vores testopgave vil bestå af migration fra min testplatform VMware og fysiske maskiner til udbyderens platform også styret af VMware. Ja, der er mange løsninger, der kan udføre en sådan migration, men vi betragter Hystax som et universelt værktøj, og at teste migrationen i alle mulige kombinationer ville simpelthen være en urealistisk opgave. Og cloud-løsningen Oncloud.ru er netop bygget på VMware, derfor interesserer denne platform os i højere grad som mål. Nedenfor vil jeg beskrive den grundlæggende arbejdsprincip, som generelt ikke afhænger af platformen, og VMware kan på enhver side erstattes med en platform fra en anden leverandør.
I det første trin er det nødvendigt at implementere Hystax Acura, som er kontrolpanelet til systemet.
Den implementeres fra en skabelon. Af en eller anden grund var den i vores tilfælde ikke helt korrekt, og i stedet for de anbefalede 8CPU, 16Gb blev det implementeret med halverede ressourcer. Derfor skal man ikke glemme at ændre dem, ellers vil infrastrukturen inden i VM'en, som alt er bygget på, simpelthen ikke starte op, og portalen vil være utilgængelig. I er detaljeret beskrevet med de nødvendige ressourcer samt porte for alle systemkomponenter.
Og der opstod også vanskeligheder med at angive IP-adressen gennem skabelonen, så vi ændrede den fra konsollen. Derefter kan du gå til webgrænsefladen for adminpanelet og udfylde den indledende konfigurationsguide.
Endpoint – IP eller FQDN for vores vCenter.
Login og Password – det er klart.
Target ESXi hostname – en af værterne i vores klynge, hvor replikationen vil finde sted.
Target datastore – en af datalagre i vores klynge, som replikationen vil finde sted til.
Hystax Acura Control Panel Public IP – adressen, hvor kontrolpanelet vil være tilgængeligt.
Der kræves en lille præcisering af værten og datalageret. Det er, at Hystax-replikationen fungerer på niveau med værten og datalageret. Jeg vil senere forklare, hvordan man kan ændre værten og datalageret for tenant'en, men problemet er et andet. Hystax understøtter ikke arbejde med resource pools, hvilket vil sige, at replikationen altid vil finde sted i roden af klyngen (på tidspunktet for skrivningen af dette materiale havde Hystax-teamet udgivet en opdateret version, hvor de hurtigt implementerede mit feature request om støtte til resource pools). vCloud Director understøttes heller ikke, så hvis tenant'en, som i mit tilfælde, ikke har admin-rettigheder til hele klyngen, men kun til en specifik resource pool, og vi har givet adgang til Hystax, vil det kunne replikere og starte disse VMer selv, men det vil ikke kunne se dem i VMware-infrastrukturen, som det har adgang til, og derfor ikke kunne administrere de virtuelle maskiner. Det er nødvendigt, at klyngeadministratoren flytter VM til den ønskede resource pool eller importerer til vCloud Director.
Hvorfor jeg lægger så stor vægt på disse punkter? Fordi, så vidt jeg forstår produktkonceptet, skal kunden have mulighed for selv at udføre en hvilken som helst migration eller DR ved hjælp af Acura-panelet. Men indtil videre halter VMware-supporten lidt bagefter i forhold til støtten til OpenStack, hvor sådanne mekanismer allerede er implementeret.
Men lad os vende tilbage til deployment. Først og fremmest, efter den indledende opsætning af panelet, skal vi oprette den første tenant i vores system.
Alle felter her er forståelige, jeg vil kun fortælle om feltet Cloud. Vi har allerede et "standard" cloud, som vi oprettede under den indledende konfiguration. Men hvis vi ønsker at have mulighed for at placere hver tenant på sin egen datastor og i sin egen resource pool, kan vi gøre det ved at oprette separate clouds for hver af vores kunder.
I formularen til tilføjelse af et nyt cloud angiver vi de samme parametre som under den indledende konfiguration (vi kan endda bruge den samme host), angiver den nødvendige datastor for den specifikke kunde, og nu kan vi i de yderligere parametre angive den nødvendige resource pool {"resource_pool": "YOUR_POOL_NAME"}
Som du måske har bemærket, er der i formularen til oprettelse af en tenant ikke noget om tildeling af ressourcer eller kvoter – der er slet ikke noget af dette i systemet. Det er ikke muligt at begrænse en tenant i antal samtidige replikaer, antallet af maskiner til replikation eller efter andre parametre. Og så, vi har oprettet den første tenant. Nu er der noget, der ikke helt giver mening, men som er obligatorisk - installation af Cloud-agenten. Det giver ikke mening, da agenten downloades på kundens specifikke side.
Det binder sig ikke til den oprettede tenant, og alle vores kunder vil arbejde gennem det (eller flere, hvis vi deployer dem). Én agent understøtter 10 samtidige sessioner. En session betragtes som én maskine. Det er ikke vigtigt, hvor mange diske den har. I dag findes der ikke en mekanisme til at skalere agenterne i selve Acura under VMware. Der er også et andet ubehageligt punkt - vi kan ikke se agentens "udnyttelse" fra Acura-panelet for at afgøre, om vi skal deployere flere, eller om den nuværende installation er tilstrækkelig. Resultatet er, at standen ser følgende ud:
Næste trin for at få adgang til vores kundes portal er at oprette en konto (og først oprette en rolle, der vil blive anvendt på denne bruger).
Nu kan vores kunde bruge portalen selv. Alt, hvad han skal gøre, er at downloade agenterne fra portalen og installere dem på sin side. Der findes tre typer agenter: Linux, Windows og VMware.
De første to installeres på fysisk hardware eller på virtuelle maskiner på enhver hypervisor undtagen VMware. Her kræves der ikke yderligere konfiguration, agenten downloades og ved allerede, hvor den skal stikke hovedet ind, og næsten efter et minut vil maskinen være synlig i Acura-panelet. Situationen med VMware-agenten er lidt mere kompliceret. Problemet er, at agenten til VMware også downloades fra portalen, allerede forberedt og har den nødvendige konfiguration. Men VMware-agenten skal udover at kende vores Acura-portal også vide om det virtualiseringssystem, den vil blive implementeret på.
Egentlig vil systemet bede os om at angive disse data, når agenten til VMware downloades for første gang. Problemet er, at i vores tidsalder med universel kærlighed til sikkerhed, er der ikke mange, der ønsker at angive sin administratoradgangskode på en fremmed portal, hvilket er ganske forståeligt. Indenfor, efter implementeringen, kan agenten ikke konfigureres yderligere (man kan kun ændre dens netværksindstillinger). Her forventer jeg vanskeligheder med særligt forsigtige kunder.
Så, efter installationen af agenterne kan vi vende tilbage til Acura-panelet og se alle vores maskiner.
Da jeg allerede har arbejdet med systemet i et stykke tid, har jeg maskiner i forskellige tilstande. Alle disse er i gruppen Default, men det er muligt at oprette separate grupper og flytte maskiner til dem, som du ønsker. Dette påvirker ikke noget – det er blot en logisk repræsentation af data og deres gruppering for nemmere arbejde. Det første og vigtigste, vi skal gøre derefter, er at igangsætte migrationsprocessen. Vi kan gøre dette enten manuelt som en tvang, eller vi kan indstille en tidsplan, herunder masseaktivering for alle maskiner samtidig.
Jeg vil minde om, at Hystax positionerede sig som et produkt til migration. Så der er intet overraskende i, at vi skal oprette en DR-plan for at kunne starte vores replikerede maskiner. Planen kan laves for maskiner, der allerede er i tilstanden Synced. Vi kan generere en plan for enten en specifik VM eller for alle maskiner samtidig.
Sættet af parametre ved generering af DR-planen vil variere afhængigt af infrastrukturen, som du vil migrere til. For VMware-miljøet er der et minimalt sæt af parametre tilgængelige. Desuden understøttes Re-IP ikke for maskiner. I denne plan interesserer vi os for følgende punkter: i VM-beskrivelsen er parameteren "subnet": "VMNetwork", hvor vi knytter VM til et specifikt netværk i klyngen. Rank – er relevant ved migrering af flere VM'er, og bestemmer rækkefølgen af deres opstart. Flavor – beskriver konfigurationen af VM, i dette tilfælde – 1CPU, 2GB RAM. I subnets-sektionen definerer vi, at "subnet": "VMNetwork" er associeret med netværket "VM Network" i VMware.
Ved oprettelse af DR-planen er der ikke mulighed for at "fordele" diske på forskellige datastores. De vil være på den samme datastore, der var defineret for dette kundesky, og hvis du har diske af forskellige klasser, kan det medføre nogle vanskeligheder ved opstart af maskinen, og efter opstart og "afkobling" af VM fra Hystax, kræver det også en separat migrering af diske til de nødvendige datastores. Derefter tilbage er der kun at lancere vores DR-plan og vente på, at vores maskiner starter. Processen med konvertering fra P2V/V2V tager også tid. På min største testmaskine på 100GB med tre diske tog det maksimalt 10 minutter.
Herefter skal du kontrollere den kørende VM, dens tjenester, dataintegritet og udføre andre kontroller.
Dernæst har vi to muligheder:
- Slet – slet en kørende DR-plan. Denne handling vil blot slukke den kørende VM. Replicatedataene forsvinder ikke.
- Afbryd – adskil den replikerede maskine fra Acura, dvs. faktiske afslutte migrationsprocessen.
Fordele ved løsningen:
- nem installation og opsætning både for klienten og udbyderen;
- nem konfiguration af migration, oprettelse af DR-plan og opstart af replikaer;
- support og udviklere reagerer temmelig hurtigt på fundne problemer og løser dem med platformopdateringer eller agenter.
Ulemper
- Utilstrækkelig support til Vmware.
- Mangel på nogen kvotering for lejere fra platformen.
Jeg har også udarbejdet en Feature Request, som vi sendte til leverandøren:
- overvågning af brug og deployment fra kontrolpanelet Acura for Cloud-agenter;
- tilstedeværelsen af kvoter for lejere;
- muligheden for at begrænse antallet af samtidige replikaer og hastigheden for hver lejer;
- support for VMware vCloud Director;
- support for resource pools (blev implementeret under testningen);
- muligheden for at konfigurere VMware-agenten fra selve agenten, uden at indtaste legitimationsoplysninger fra kundens infrastruktur i Acura-panelet;
- ‘visualisering’ af VM-opstartsprocessen ved opstart af DR-planen.
Det eneste, jeg havde store klager over – dokumentationen. Jeg kan ikke lide ‘black boxes’ og foretrækker, at der er detaljeret dokumentation om, hvordan produktet fungerer indeni. Og selvom produktet er nogenlunde beskrevet for AWS og OpenStack, så er der ekstremt lidt dokumentation for VMware.
Der er en installationsvejledning, der kun beskriver implementeringen af Acura-panelet, og som ikke nævner, at Cloud-agenten også er nødvendig. Der er et komplet sæt specifikationer for produktet, hvilket er godt. Der er dokumentation, der beskriver opsætning ‘fra A til Z’ med eksempler på AWS og OpenStack (selvom det mere minder om et blogindlæg), og der er en meget lille Knowledge Base.
Generelt er det ikke helt den dokumentationsform, jeg er vant til, lad os sige, hos større leverandører, så jeg havde det ikke helt komfortabelt. Samtidig kunne jeg ikke finde svar på nogle af systemets ‘interne’ nuancer i denne dokumentation – jeg måtte ofte uddybe mange spørgsmål hos den tekniske support, hvilket ret meget forlængede processen med at implementere setup og udføre testning.
Sammenfattende kan jeg sige, at jeg generelt har været tilfreds med produktet og virksomhedens tilgang til opgaven. Ja, der er mangler, og der er en virkelig kritisk mangel på funktionalitet (i forbindelse med VMware). Det er tydeligt, at virksomheden først og fremmest er fokuseret på offentlige skyer, især AWS, og for nogle vil det være tilstrækkeligt. At have et så enkelt og brugervenligt produkt i dag, hvor mange virksomheder vælger en multi-cloud strategi, er utroligt vigtigt. I betragtning af den meget lavere pris sammenlignet med konkurrenterne gør det produktet ekstremt attraktivt.
Vi søger en . Måske er det netop dig?
Kilde: habr.com
