{"id":96767,"date":"2020-10-14T14:43:02","date_gmt":"2020-10-14T12:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam"},"modified":"2020-10-14T14:43:02","modified_gmt":"2020-10-14T12:43:02","slug":"hystax-cloud-migration-skachem-po-oblakam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam","title":{"rendered":"Hystax Cloud Migration: vi hopper gjennom skyene","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En av de unge akt\u00f8rene p\u00e5 markedet for Disaster Recovery-l\u00f8sninger er selskapet Hystax \u2013 en russisk oppstart fra 2016. Siden temaet for katastrofegjenoppretting er sv\u00e6rt popul\u00e6rt og konkurransen p\u00e5 markedet er ekstremt h\u00f8y, bestemte oppstarten seg for \u00e5 fokusere p\u00e5 migrering mellom forskjellige skyinfrastrukturer. Et produkt som muliggj\u00f8r enkel og rask migrering til skyen ville v\u00e6rt sv\u00e6rt nyttig ogs\u00e5 for kundene til \"Onlanta\" \u2013 brukerne. Oncloud.ru<\/a><\/noindex>. Slik ble jeg kjent med Hystax og begynte \u00e5 teste funksjonaliteten. Hva som kom ut av det, skal jeg fortelle om i denne artikkelen.<\/p>\n

\"Hystax<\/a><\/noindex>
\nHovedfunksjonen til Hystax er dens brede muligheter for st\u00f8tte av ulike virtualiseringsplattformer, gjeste-OS og skytjenester, noe som gir mulighet til \u00e5 overf\u00f8re arbeidsbelastningene dine fra hvor som helst til hvor som helst.<\/p>\n

Dette gj\u00f8r det mulig \u00e5 skape ikke bare DR-l\u00f8sninger for \u00e5 \u00f8ke p\u00e5liteligheten til tjenestene, men ogs\u00e5 raskt og fleksibelt migrere ressurser mellom ulike plattformer og hyperskalere for \u00e5 oppn\u00e5 kostnadsbesparelser og velge den beste l\u00f8sningen for den spesifikke tjenesten til enhver tid. I tillegg til plattformene som er nevnt p\u00e5 tittelfotoet, samarbeider selskapet ogs\u00e5 aktivt med russiske skytilbydere: Yandex.Cloud, KROK \u00abSky tjenester\u00bb, Mail.ru og mange andre. Det er ogs\u00e5 verdt \u00e5 merke seg at selskapet fikk et FoU-senter i 2020, som holder til i Skolkovo.\u00a0<\/p>\n

Valget av en l\u00f8sning av mange akt\u00f8rer p\u00e5 markedet indikerer en god prisstrategi og h\u00f8y anvendelighet av produktet, noe vi ogs\u00e5 har tenkt \u00e5 sjekke i praksis.<\/p>\n

S\u00e5 v\u00e5r testoppgave vil best\u00e5 av migrasjon fra min testplattform VMware og fysiske maskiner til plattformen til leverand\u00f8ren, ogs\u00e5 drevet av VMware. Ja, det finnes mange l\u00f8sninger som kan gjennomf\u00f8re en slik migrasjon, men vi vurderer Hystax som et universelt verkt\u00f8y, og \u00e5 teste migrasjon i alle mulige kombinasjoner er ganske enkelt en urealistisk oppgave. Og Oncloud.ru er bygget p\u00e5 nettopp VMware, s\u00e5 vi er i st\u00f8rre grad interessert i denne plattformen som m\u00e5l. 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\u00f8r.\u00a0<\/p>\n

I det f\u00f8rste trinnet m\u00e5 Hystax Acura implementeres, som er kontrollpanelet for systemet.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDet implementeres fra en mal. Av en eller annen grunn var denne ikke helt korrekt i v\u00e5rt tilfelle, og i stedet for de anbefalte 8CPU, 16Gb, ble den satt opp med halvparten av ressursene. Derfor m\u00e5 man huske \u00e5 endre dem, ellers vil ikke infrastrukturen som er bygget opp inne i VM, starte opp, og portalen vil bli utilgjengelig. Implementeringskrav<\/a><\/noindex> beskriver detaljert de n\u00f8dvendige ressursene, samt porter for alle systemkomponentene.\u00a0<\/p>\n

Og det oppsto ogs\u00e5 problemer med \u00e5 tildele IP-adresse via malen, s\u00e5 dette ble endret fra konsollen. Etter dette kan man g\u00e5 til webgrensesnittet til administrasjonspanelet og fylle ut den f\u00f8rste konfigurasjonsveiviseren.\u00a0<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nEndpoint \u2013 IP eller FQDN til v\u00e5r vCenter.\u00a0
\nInnlogging og passord \u2013 dette er klart.\u00a0
\nTarget ESXi hostname \u2013 en av vertene i klyngen v\u00e5r hvor replikasjonen vil skje.\u00a0
\nTarget datastore \u2013 en av datastore-ene i klyngen v\u00e5r hvor replikasjonen vil finne sted.
\nHystax Acura Control Panel Public IP \u2013 adressen hvor kontrollpanelet vil v\u00e6re tilgjengelig.<\/p>\n

Det er n\u00f8dvendig med en liten avklaring ang\u00e5ende verten og datastore. Saken er at Hystax-replikasjonen arbeider p\u00e5 vert- og datastore-niv\u00e5. Senere vil jeg forklare hvordan man kan endre vert og datastore for en leietaker, men problemet ligger et annet sted. Hystax st\u00f8tter 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\u00e5ende st\u00f8tte for ressursgrupper). vCloud Director st\u00f8ttes 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\u00e5 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\u00f8dvendig at klyngeadministratoren flytter VM-en til den n\u00f8dvendige ressursgruppen eller importerer den til vCloud Director.<\/p>\n

Hvorfor legger jeg s\u00e5 mye vekt p\u00e5 disse punktene? Fordi, s\u00e5 langt jeg forst\u00e5r produktkonseptet, m\u00e5 kunden ha muligheten til \u00e5 gjennomf\u00f8re enhver migrasjon eller DR selv ved hjelp av Acura-panelet. Men s\u00e5 langt ligger VMware-supporten litt etter i forhold til st\u00f8tten for OpenStack, hvor slike mekanismer allerede er implementert.\u00a0<\/p>\n

Men la oss g\u00e5 tilbake til distribusjonen. F\u00f8rst, etter den f\u00f8rste oppsett av panelet, m\u00e5 vi opprette den f\u00f8rste tenant i systemet v\u00e5rt.<\/p>\n

\"Hystax<\/a><\/noindex>
\nAlle feltene her er klare, jeg vil bare si noe om Cloud-feltet. Vi har allerede et \u00abstandard\u00bb skytjeneste som vi opprettet under f\u00f8rste konfigurasjon. Men hvis vi \u00f8nsker \u00e5 ha muligheten til \u00e5 plassere hver tenant p\u00e5 sin egen datastor og i sin egen ressursgruppe, kan vi realisere dette ved \u00e5 opprette separate skyer for hver av v\u00e5re kunder.<\/p>\n

\"Hystax<\/a><\/noindex>
\nI skjemaet for \u00e5 legge til en ny sky angir vi de samme parametrene som ved den f\u00f8rste konfigurasjonen (vi kan til og med bruke den samme verten), angir den n\u00f8dvendige datastoren for den spesifikke kunden, og n\u00e5 kan vi i tillegg individuelt angi n\u00f8dvendig ressursgruppe {\u00abresource_pool\u00bb: \u00abYOUR_POOL_NAME\u00bb}.\u00a0<\/p>\n

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 \u00e5 begrense tenanten n\u00e5r det gjelder antall samtidige replikaer, antall maskiner for replikasjon eller etter andre parametere. S\u00e5, vi har opprettet den f\u00f8rste tenant. N\u00e5 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.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDet binder seg ikke til den opprettede tenant, og alle v\u00e5re kunder vil bruke det (eller flere, hvis vi distribuerer dem). \u00c9n agent st\u00f8tter 10 samtidige \u00f8kter. En \u00f8kt regnes som \u00e9n maskin. Det spiller ingen rolle hvor mange disker den har. Per i dag finnes det ingen mekanisme for \u00e5 skalere agenter i Acura under VMware. Det er ogs\u00e5 et annet ubehagelig moment \u2013 vi har ikke mulighet til \u00e5 se p\u00e5 \"utnyttelsen\" av denne agenten fra Acura-panelet for \u00e5 avgj\u00f8re om vi trenger \u00e5 distribuerer flere, eller om n\u00e5v\u00e6rende installasjon er tilstrekkelig. Dermed ser standet slik ut:<\/p>\n

\"Hystax<\/a><\/noindex>
\nNeste steg for tilgang til portalen til v\u00e5r kunde er \u00e5 opprette en konto (og tidligere ogs\u00e5 en rolle som skal brukes av denne brukeren).<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nN\u00e5 kan v\u00e5r kunde bruke portalen selvstendig. Alt han m\u00e5 gj\u00f8re, er \u00e5 laste ned agentene fra portalen og installere dem p\u00e5 sin side. Det finnes tre typer agenter: Linux, Windows og VMware.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDe f\u00f8rste to installeres p\u00e5 fysiske maskiner eller p\u00e5 virtuelle maskiner p\u00e5 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\u00e5 lastes ned fra portalen allerede forberedt med n\u00f8dvendig konfigurasjon. Men VMware-agenten m\u00e5 i tillegg til \u00e5 vite om v\u00e5r Acura-portal ogs\u00e5 vite om virtualiseringssystemet den vil bli distribuerte p\u00e5.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDisse dataene vil systemet be oss om \u00e5 oppgi ved f\u00f8rste nedlasting av VMware-agenten. Problemet er at i v\u00e5r tid hvor sikkerhet er s\u00e5 viktig, er det ikke alle som vil v\u00e6re villige til \u00e5 oppgi sitt administratorpassord p\u00e5 en annen portal, noe som er helt forst\u00e5elig. Innvendig, etter distribusjon, kan ikke agenten konfigureres p\u00e5 annen m\u00e5te (man kan bare endre nettverksinnstillingene). Her forutser jeg vanskeligheter med spesielt forsiktige kunder.\u00a0<\/p>\n

S\u00e5, etter installasjonen av agentene kan vi g\u00e5 tilbake til Acura-panelet og se alle v\u00e5re maskiner.<\/p>\n

\"Hystax<\/a><\/noindex>
\nSiden jeg allerede har jobbet med systemet en stund, har jeg maskiner i forskjellige tilstander. Alle befinner seg i gruppen Default, men det er mulig \u00e5 opprette separate grupper og flytte maskiner dit etter behov. Dette p\u00e5virker ikke noe annet \u2013 det er kun en logisk representasjon av dataene og gruppering for mer praktisk arbeid. Det f\u00f8rste og viktigste vi m\u00e5 gj\u00f8re etter dette er \u00e5 starte migrasjonsprosessen. Vi kan gj\u00f8re dette enten manuelt som en tvungen handling, eller vi kan sette opp en tidsplan, inkludert en masseprosess for alle maskiner samtidig.<\/p>\n

\"Hystax<\/a><\/noindex>
\nJeg minner om at Hystax er posisjonert som et produkt for migrasjon. Derfor er det ikke overraskende at vi m\u00e5 opprette en DR-plan for \u00e5 starte v\u00e5re 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.<\/p>\n

\"Hystax<\/a><\/noindex>
\nSett med parametere ved generering av DR-planen vil variere avhengig av infrastrukturen som du skal migrere til. For VMware-milj\u00f8er er det et minimumssett av parametere tilgjengelig. Re-IP st\u00f8ttes ikke for maskiner. I denne planen er vi interessert i f\u00f8lgende elementer: i beskrivelsen av VM er parameteren \u00absubnet\u00bb: \u00abVMNetwork\u00bb, hvor vi knytter VM til et spesifikt nettverk i klyngen. Rangering \u2013 relevant ved migrering av flere VM-er, bestemmer rekkef\u00f8lgen for deres oppstart. Flavor \u2013 beskriver konfigurasjonen av VM, i dette tilfellet \u2013 1CPU, 2GB RAM. I seksjonen subnets definerer vi at \u00absubnet\u00bb: \u00abVMNetwork\u00bb er assosiert med nettverket \u00abVM Network\u00bb i VMware.\u00a0<\/p>\n

Ved opprettelse av DR-plan er det ikke mulig \u00e5 \u00abfordele\u00bb disker p\u00e5 forskjellige datalagre. De vil v\u00e6re plassert p\u00e5 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 \u00abfrigj\u00f8ring\u00bb av VM fra Hystax, vil det ogs\u00e5 kreve en separat migrering av diskene til de n\u00f8dvendige datalagerne. Deretter m\u00e5 vi bare starte DR-planen v\u00e5r og vente p\u00e5 at maskinene v\u00e5re skal starte opp. Prosessen for konvertering fra P2V\/V2V tar ogs\u00e5 tid. P\u00e5 den st\u00f8rste testmaskinen min p\u00e5 100GB med tre disker tok det maks 10 minutter.<\/p>\n

\"Hystax<\/a><\/noindex>
\nEtter dette b\u00f8r vi sjekke den kj\u00f8rende VM-en, tjenestene p\u00e5 den, datakonsistensen og utf\u00f8re andre kontroller.\u00a0<\/p>\n

Deretter har vi to alternativer:\u00a0<\/p>\n

    \n
  1. Slett \u2013 fjern den aktive DR-planen. Denne handlingen vil bare slukke den aktive VM. Dataene fra replikaen vil ikke g\u00e5 noe sted.\u00a0<\/li>\n
  2. Frakobling \u2013 l\u00f8sne den replikerte maskinen fra Acura, dvs. faktisk fullf\u00f8re migrasjonsprosessen.\u00a0<\/li>\n<\/ol>\n

    \nFordeler med l\u00f8sningen:<\/strong>\u00a0<\/p>\n