{"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\/da\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam","title":{"rendered":"Hystax Cloud Migration: springer op p\u00e5 skyerne","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En af de unge spillere p\u00e5 markedet for Disaster Recovery-l\u00f8sninger er Hystax \u2013 en russisk startup fra 2016. Da emnet for katastrofegenopretning er meget popul\u00e6rt, og der er ekstrem h\u00f8j konkurrence p\u00e5 markedet, besluttede startup'en at fokusere p\u00e5 migration mellem forskellige cloud-infrastrukturer. Et produkt, der muligg\u00f8r nem og hurtig migration til skyen, ville v\u00e6re meget nyttigt for kunderne hos \"Onlanta\" \u2013 brugerne. Oncloud.ru<\/a><\/noindex>. S\u00e5dan st\u00f8dte jeg p\u00e5 Hystax og begyndte at teste dets muligheder. Hvad der kom ud af det, vil jeg fort\u00e6lle om i denne artikel.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDen prim\u00e6re funktion ved Hystax er dens brede funktionalitet til at underst\u00f8tte forskellige virtualiseringsplatforme, g\u00e6ste-OS og cloud-tjenester, hvilket giver mulighed for at flytte dine arbejdsbelastninger fra hvor som helst til hvor som helst.<\/p>\n

Dette g\u00f8r det muligt at skabe ikke kun DR-l\u00f8sninger for at \u00f8ge servicen tilg\u00e6ngelighed, men ogs\u00e5 hurtigt og fleksibelt migrere ressourcer mellem forskellige platforme og hyperskalere for at \u00f8ge besparelserne og v\u00e6lge den bedste l\u00f8sning til en bestemt service p\u00e5 det p\u00e5g\u00e6ldende tidspunkt. Udover de platforme, der er n\u00e6vnt p\u00e5 titelbilledet, samarbejder virksomheden ogs\u00e5 aktivt med russiske cloud-udbydere: Yandex.Cloud, KROK \"Cloud Services\", Mail.ru og mange andre. Det er ogs\u00e5 v\u00e6rd at bem\u00e6rke, at virksomheden i 2020 fik et R&D-center beliggende i Skolkovo.\u00a0<\/p>\n

Valget af \u00e9n l\u00f8sning af mange akt\u00f8rer p\u00e5 markedet vidner om en god prisstrategi og h\u00f8j anvendelighed af produktet, hvilket vi ogs\u00e5 besluttede at teste i praksis.<\/p>\n

S\u00e5 vores testopgave vil best\u00e5 af migration fra min testplatform VMware og fysiske maskiner til udbyderens platform ogs\u00e5 styret af VMware. Ja, der er mange l\u00f8sninger, der kan udf\u00f8re en s\u00e5dan migration, men vi betragter Hystax som et universelt v\u00e6rkt\u00f8j, og at teste migrationen i alle mulige kombinationer ville simpelthen v\u00e6re en urealistisk opgave. Og cloud-l\u00f8sningen Oncloud.ru er netop bygget p\u00e5 VMware, derfor interesserer denne platform os i h\u00f8jere grad som m\u00e5l. Nedenfor vil jeg beskrive den grundl\u00e6ggende arbejdsprincip, som generelt ikke afh\u00e6nger af platformen, og VMware kan p\u00e5 enhver side erstattes med en platform fra en anden leverand\u00f8r.\u00a0<\/p>\n

I det f\u00f8rste trin er det n\u00f8dvendigt at implementere Hystax Acura, som er kontrolpanelet til systemet.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDen implementeres fra en skabelon. Af en eller anden grund var den i vores tilf\u00e6lde ikke helt korrekt, og i stedet for de anbefalede 8CPU, 16Gb blev det implementeret med halverede ressourcer. Derfor skal man ikke glemme at \u00e6ndre dem, ellers vil infrastrukturen inden i VM'en, som alt er bygget p\u00e5, simpelthen ikke starte op, og portalen vil v\u00e6re utilg\u00e6ngelig. I Implementeringskravene<\/a><\/noindex> er detaljeret beskrevet med de n\u00f8dvendige ressourcer samt porte for alle systemkomponenter.\u00a0<\/p>\n

Og der opstod ogs\u00e5 vanskeligheder med at angive IP-adressen gennem skabelonen, s\u00e5 vi \u00e6ndrede den fra konsollen. Derefter kan du g\u00e5 til webgr\u00e6nsefladen for adminpanelet og udfylde den indledende konfigurationsguide.\u00a0<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nEndpoint \u2013 IP eller FQDN for vores vCenter.\u00a0
\nLogin og Password \u2013 det er klart.\u00a0
\nTarget ESXi hostname \u2013 en af v\u00e6rterne i vores klynge, hvor replikationen vil finde sted.\u00a0
\nTarget datastore \u2013 en af datalagre i vores klynge, som replikationen vil finde sted til.
\nHystax Acura Control Panel Public IP \u2013 adressen, hvor kontrolpanelet vil v\u00e6re tilg\u00e6ngeligt.<\/p>\n

Der kr\u00e6ves en lille pr\u00e6cisering af v\u00e6rten og datalageret. Det er, at Hystax-replikationen fungerer p\u00e5 niveau med v\u00e6rten og datalageret. Jeg vil senere forklare, hvordan man kan \u00e6ndre v\u00e6rten og datalageret for tenant'en, men problemet er et andet. Hystax underst\u00f8tter ikke arbejde med resource pools, hvilket vil sige, at replikationen altid vil finde sted i roden af klyngen (p\u00e5 tidspunktet for skrivningen af dette materiale havde Hystax-teamet udgivet en opdateret version, hvor de hurtigt implementerede mit feature request om st\u00f8tte til resource pools). vCloud Director underst\u00f8ttes heller ikke, s\u00e5 hvis tenant'en, som i mit tilf\u00e6lde, 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\u00f8dvendigt, at klyngeadministratoren flytter VM til den \u00f8nskede resource pool eller importerer til vCloud Director.<\/p>\n

Hvorfor jeg l\u00e6gger s\u00e5 stor v\u00e6gt p\u00e5 disse punkter? Fordi, s\u00e5 vidt jeg forst\u00e5r produktkonceptet, skal kunden have mulighed for selv at udf\u00f8re en hvilken som helst migration eller DR ved hj\u00e6lp af Acura-panelet. Men indtil videre halter VMware-supporten lidt bagefter i forhold til st\u00f8tten til OpenStack, hvor s\u00e5danne mekanismer allerede er implementeret.\u00a0<\/p>\n

Men lad os vende tilbage til deployment. F\u00f8rst og fremmest, efter den indledende ops\u00e6tning af panelet, skal vi oprette den f\u00f8rste tenant i vores system.<\/p>\n

\"Hystax<\/a><\/noindex>
\nAlle felter her er forst\u00e5elige, jeg vil kun fort\u00e6lle om feltet Cloud. Vi har allerede et \"standard\" cloud, som vi oprettede under den indledende konfiguration. Men hvis vi \u00f8nsker at have mulighed for at placere hver tenant p\u00e5 sin egen datastor og i sin egen resource pool, kan vi g\u00f8re det ved at oprette separate clouds for hver af vores kunder.<\/p>\n

\"Hystax<\/a><\/noindex>
\nI formularen til tilf\u00f8jelse af et nyt cloud angiver vi de samme parametre som under den indledende konfiguration (vi kan endda bruge den samme host), angiver den n\u00f8dvendige datastor for den specifikke kunde, og nu kan vi i de yderligere parametre angive den n\u00f8dvendige resource pool {\"resource_pool\": \"YOUR_POOL_NAME\"}\u00a0<\/p>\n

Som du m\u00e5ske har bem\u00e6rket, er der i formularen til oprettelse af en tenant ikke noget om tildeling af ressourcer eller kvoter \u2013 der er slet ikke noget af dette i systemet. Det er ikke muligt at begr\u00e6nse en tenant i antal samtidige replikaer, antallet af maskiner til replikation eller efter andre parametre. Og s\u00e5, vi har oprettet den f\u00f8rste 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\u00e5 kundens specifikke side.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDet binder sig ikke til den oprettede tenant, og alle vores kunder vil arbejde gennem det (eller flere, hvis vi deployer dem). \u00c9n agent underst\u00f8tter 10 samtidige sessioner. En session betragtes som \u00e9n 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\u00e5 et andet ubehageligt punkt - vi kan ikke se agentens \"udnyttelse\" fra Acura-panelet for at afg\u00f8re, om vi skal deployere flere, eller om den nuv\u00e6rende installation er tilstr\u00e6kkelig. Resultatet er, at standen ser f\u00f8lgende ud:<\/p>\n

\"Hystax<\/a><\/noindex>
\nN\u00e6ste trin for at f\u00e5 adgang til vores kundes portal er at oprette en konto (og f\u00f8rst oprette en rolle, der vil blive anvendt p\u00e5 denne bruger).<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nNu kan vores kunde bruge portalen selv. Alt, hvad han skal g\u00f8re, er at downloade agenterne fra portalen og installere dem p\u00e5 sin side. Der findes tre typer agenter: Linux, Windows og VMware.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDe f\u00f8rste to installeres p\u00e5 fysisk hardware eller p\u00e5 virtuelle maskiner p\u00e5 enhver hypervisor undtagen VMware. Her kr\u00e6ves der ikke yderligere konfiguration, agenten downloades og ved allerede, hvor den skal stikke hovedet ind, og n\u00e6sten efter et minut vil maskinen v\u00e6re synlig i Acura-panelet. Situationen med VMware-agenten er lidt mere kompliceret. Problemet er, at agenten til VMware ogs\u00e5 downloades fra portalen, allerede forberedt og har den n\u00f8dvendige konfiguration. Men VMware-agenten skal udover at kende vores Acura-portal ogs\u00e5 vide om det virtualiseringssystem, den vil blive implementeret p\u00e5.<\/p>\n

\"Hystax<\/a><\/noindex>
\nEgentlig vil systemet bede os om at angive disse data, n\u00e5r agenten til VMware downloades for f\u00f8rste gang. Problemet er, at i vores tidsalder med universel k\u00e6rlighed til sikkerhed, er der ikke mange, der \u00f8nsker at angive sin administratoradgangskode p\u00e5 en fremmed portal, hvilket er ganske forst\u00e5eligt. Indenfor, efter implementeringen, kan agenten ikke konfigureres yderligere (man kan kun \u00e6ndre dens netv\u00e6rksindstillinger). Her forventer jeg vanskeligheder med s\u00e6rligt forsigtige kunder.\u00a0<\/p>\n

S\u00e5, efter installationen af agenterne kan vi vende tilbage til Acura-panelet og se alle vores maskiner.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDa 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 \u00f8nsker. Dette p\u00e5virker ikke noget \u2013 det er blot en logisk repr\u00e6sentation af data og deres gruppering for nemmere arbejde. Det f\u00f8rste og vigtigste, vi skal g\u00f8re derefter, er at igangs\u00e6tte migrationsprocessen. Vi kan g\u00f8re dette enten manuelt som en tvang, eller vi kan indstille en tidsplan, herunder masseaktivering for alle maskiner samtidig.<\/p>\n

\"Hystax<\/a><\/noindex>
\nJeg vil minde om, at Hystax positionerede sig som et produkt til migration. S\u00e5 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.<\/p>\n

\"Hystax<\/a><\/noindex>
\nS\u00e6ttet af parametre ved generering af DR-planen vil variere afh\u00e6ngigt af infrastrukturen, som du vil migrere til. For VMware-milj\u00f8et er der et minimalt s\u00e6t af parametre tilg\u00e6ngelige. Desuden underst\u00f8ttes Re-IP ikke for maskiner. I denne plan interesserer vi os for f\u00f8lgende punkter: i VM-beskrivelsen er parameteren \"subnet\": \"VMNetwork\", hvor vi knytter VM til et specifikt netv\u00e6rk i klyngen. Rank \u2013 er relevant ved migrering af flere VM'er, og bestemmer r\u00e6kkef\u00f8lgen af deres opstart. Flavor \u2013 beskriver konfigurationen af VM, i dette tilf\u00e6lde \u2013 1CPU, 2GB RAM. I subnets-sektionen definerer vi, at \"subnet\": \"VMNetwork\" er associeret med netv\u00e6rket \"VM Network\" i VMware.\u00a0<\/p>\n

Ved oprettelse af DR-planen er der ikke mulighed for at \"fordele\" diske p\u00e5 forskellige datastores. De vil v\u00e6re p\u00e5 den samme datastore, der var defineret for dette kundesky, og hvis du har diske af forskellige klasser, kan det medf\u00f8re nogle vanskeligheder ved opstart af maskinen, og efter opstart og \"afkobling\" af VM fra Hystax, kr\u00e6ver det ogs\u00e5 en separat migrering af diske til de n\u00f8dvendige datastores. Derefter tilbage er der kun at lancere vores DR-plan og vente p\u00e5, at vores maskiner starter. Processen med konvertering fra P2V\/V2V tager ogs\u00e5 tid. P\u00e5 min st\u00f8rste testmaskine p\u00e5 100GB med tre diske tog det maksimalt 10 minutter.<\/p>\n

\"Hystax<\/a><\/noindex>
\nHerefter skal du kontrollere den k\u00f8rende VM, dens tjenester, dataintegritet og udf\u00f8re andre kontroller.\u00a0<\/p>\n

Dern\u00e6st har vi to muligheder:\u00a0<\/p>\n

    \n
  1. Slet \u2013 slet en k\u00f8rende DR-plan. Denne handling vil blot slukke den k\u00f8rende VM. Replicatedataene forsvinder ikke.\u00a0<\/li>\n
  2. Afbryd \u2013 adskil den replikerede maskine fra Acura, dvs. faktiske afslutte migrationsprocessen.\u00a0<\/li>\n<\/ol>\n

    \nFordele ved l\u00f8sningen:<\/strong>\u00a0<\/p>\n