For omtrent 7 år siden flyttet de aller første prosjektene enkelt og upretensiøst til nettskyen vår. Virtuelle maskinbilder ble lastet opp til en FTP-server, eller de ble levert på harddisker. Deretter ble VM-ene lastet opp til skyen gjennom en spesiell importserver.
Hvis det ikke er et problem for klienten å slå av den virtuelle maskinen i en dag eller to (eller det ikke er andre alternativer), så kan dette gjøres. Men hvis nedetiden skal være maksimalt en time, vil ikke denne metoden fungere. I dag skal jeg fortelle deg hvilke verktøy som vil hjelpe deg med å migrere til skyen med minimal nedetid og hvordan selve migreringsprosessen fungerer.
Migrering med Veeam backup og replikering
Alle kjenner Veeam Backup and Replication som et verktøy for å lage sikkerhetskopier og replikaer. Vi bruker den til migrering mellom nettstedene våre og for å transportere klienter fra privat virtualisering til skyen vår. Klientens virtuelle maskiner blir replikert til vCenteret vårt, hvoretter ingeniøren legger dem til vCloud Director.
Primær replikering skjer på en aktivert virtuell maskin. Til avtalt tid slås klientsiden av maskinen. Replikering kjører igjen for å overføre endringer som har skjedd siden den første replikeringen. Etter dette starter den virtuelle maskinen i skyen vår.
Fra det øyeblikket maskinen slås av på klientens infrastruktur til det øyeblikket den slås på i skyen vår, går det vanligvis ikke mer enn en halv time, men heller 15–20 minutter.
I dette tilfellet forblir den originale virtuelle maskinen på klientsiden. Hvis noe plutselig går galt, kan du alltid rulle tilbake og slå den på. Denne metoden er også praktisk for klienten ved at den ikke krever at han har Veeam.
Sak 1
Klienten hadde sin egen virtuelle infrastruktur basert på VMware - 40 VM-er med en kapasitet på 30 TB. Utstyret som klyngen ble distribuert på var allerede utdatert, og klienten bestemte seg for ikke å bry seg om å kjøpe nye og flyttet til den offentlige skyen. Nedetidskravet for kritiske systemer var ikke mer enn en time. Veeam Replication ble valgt som verktøy. Et annet pluss var at kundens internettleverandør var til stede i datasenteret vårt, noe som gjorde det mulig å organisere en god kanal. Migreringen tok omtrent en måned, nedetid under bytte var opptil 30 minutter per gruppe virtuelle maskiner.
Migrer med Veeam Cloud Connect
Veeam Cloud Connect er et verktøy som hjelper deg med å sette opp virtuell maskinreplikering og starte replikaer i tjenesteleverandørens sky. Etter oppdatering til år ble det mulig å replikere virtuelle maskiner direkte til vCloud Director. Den eneste betingelsen er at på klientsiden må Veeam Backup and Replication være distribuert minst versjon 9. Kort sagt (detaljert versjon ), så ser hele prosessen slik ut.
I vCloud Director opprettes en organisasjon med nødvendige ressurser og nettverk. I Veeam Cloud Connect oppretter vi en konto, klienten kobler seg til den fra sin Veeam B&R, velger en DataLine-leverandør og organisasjon og konfigurerer oppgaver for replikering. I tillegg til at under en slik migrering vil nedetiden være innen 15–20 minutter, er ikke klienten på noen måte avhengig av leverandørens tekniske støtte og styrer hele prosessen uavhengig: oppretter replikeringsoppgaver, selve replikeringen slår seg av. maskinene og starter dem på den nye siden.
Sak 2
Klientens infrastruktur, hvorfra migreringen var planlagt, var lokalisert i Hviterussland. Det var nødvendig å transportere 90 VM-er med et samlet volum på 27 TB, til tross for at internettkanalen var på 100 Mbit/sek. Hvis du tar en sikkerhetskopi og umiddelbart laster den opp til skyen vår, vil det for noen VM-er ta flere dager. I løpet av denne tiden ville et stort delta vokst på VM, og dette kan ha en negativ innvirkning på ytelsen til maskinene, eller enda verre, plassen på datalageret ville ha gått tom. Vi gikk frem som følger: Først laget klienten en lokal full sikkerhetskopi og overførte en kopi av den til skyen vår via Veeam Cloud Connect. Så laget og overførte jeg inkrementet til skyen. Den originale virtuelle maskinen fortsatte å kjøre. Etter å ha slått av VM, foretok klienten en ny økning og overførte den også til skyen. På vår side distribuerte vi en virtuell maskin fra en fullstendig sikkerhetskopi, og rullet deretter to trinn på den. Denne ordningen gjorde det til slutt mulig å minimere nedetiden til 2 timer når du byttet til siden vår.
Migrering med VMware vCloud Tilgjengelighet
I mars i år ga VMware ut vCloud Availability 3.0, som lar deg migrere virtuelle maskiner mellom ulike skyer (vCloud Director - vCloud Director) og fra private klientvirtualiseringsstander til skyen (vCenter - vCloud Director). Den viktigste bekvemmeligheten er integrasjon med vCloud Director-grensesnittet. Dette forenkler replikeringsadministrasjonsprosessen betydelig og minimerer nedetid under overganger.
Ved å bruke dette verktøyet migrerte vi en av klientene fra Moskva-skyen vår til skyen vår i St. Petersburg. Det var nødvendig å transportere 18 virtuelle maskiner med en total kapasitet på 14 TB. En organisasjon ble opprettet for klienten i St. Petersburg-skyen og de nødvendige nettverkene ble organisert. Deretter gikk klienten fra vCloud Director-grensesnittet til vCloud Availability-innstillingene, opprettet replikeringsjobber og byttet til St. Petersburg-nettstedet på et passende tidspunkt for ham. Nedetid under bytte var 12 minutter.
Migrasjonsopplegg mellom DataLine-skyer i St. Petersburg og Moskva.
vCloud Availability har en mekanisme for å migrere VM-er fra klientens nettsted til skyen vår. For å gjøre dette, er en spesiell vCloud Availability-applikasjon distribuert i klientens vCenter. Etter enkelt oppsett kobler du til skyen og konfigurerer migreringsoppgaver. Klienten styrer også hele prosessen uavhengig og migreringstiden holdes på et minimum.
Opplegg for å migrere virtuelle maskiner fra en privat installasjon til skyen.
VMware vCloud Availability har mange andre brukstilfeller; vi vil snakke om dem i en egen artikkel snart.
Forbereder migrasjon
For å velge et verktøy og faktisk begynne å migrere, må du bestemme deg for følgende punkter:
Hvor migrerer vi fra? Hvis du migrerer fra en privat løsning, har du full frihet til å velge verktøy. Hvis du flytter fra leverandøren din, er det mer komplisert. Mest sannsynlig vil det ikke fungere å koble sammen infrastrukturene til to leverandører og ganske enkelt dra og slippe en VM på grunn av sikkerhetsårsaker. Noen ganger begynner leverandøren som klienten er i ferd med å nekte å være rampete og stopper opp for tid. Du kan bevege deg bort fra leverandøren på gammeldags måte: ved å laste opp VM-er til disker og FTP, eller ved å migrere på applikasjonsnivå. Navnet på sistnevnte er betinget, og det ser omtrent slik ut.
Sak 3
Det var nødvendig å migrere klientens SAP-system fra en europeisk leverandør: 34 VM-er med en kapasitet på 54 TB. Klienten ble tildelt ressurser i skyen vår. Nettverkstilkobling ble organisert mellom oss og infrastrukturen til den europeiske leverandøren. Applikasjonsserverne ble distribuert på nytt, med de nødvendige konfigurasjonene rullet over. Store databaser ble migrert gjennom opplasting av sikkerhetskopier til skyen vår. Deretter ble replikering konfigurert mellom databasene på våre og de opprinnelige sidene. Til avtalt tid gikk vi over til databaser i skyen vår.
Datavolum og Internett-kanal. Vi ber vanligvis klienten om å gi en opplasting etter system med minne-, CPU- og diskparametere. Vi vurderer om kanalen er nok til å sende kopier eller sikkerhetskopier av virtuelle maskiner direkte.
Akseptabel nedetid. For forskjellige systemer og følgelig virtuelle maskiner kan det være forskjellig avhengig av deres forretningskritikk. Vanligvis kommer klienten med ferdige krav til nedetid under migrering, og basert på dette velger vi riktig verktøy og migreringsplan. Vi prøver å planlegge den endelige overgangen om natten eller i helgene slik at selv mindre nedetid ikke er merkbar for kundens sluttbrukere.
Basert på disse dataene kan du velge et verktøy og starte selve migreringen. Her er hva som skjer videre.
- Sette opp nettverkstilkobling. Vi organiserer nettverkstilkobling mellom skyen vår og kundens infrastruktur. Virtuelle maskiner vil bli kopiert over dette nettverket. Hvis Veeam Backup and Replication brukes, er dette en dedikert kanal, sjeldnere en VPN-kanal. Hvis Veeam Cloud Connect, så går alt via Internett eller samme dedikerte kanal.
Deretter er nettverket konfigurert for VM i skyen. Biler beveger seg vanligvis i grupper og i mer enn én dag. Når VM-ene er brakt til oss og lansert, må de kommunisere med maskinene som fortsatt er på det opprinnelige stedet.
- Migrasjonsplan. Når det er mange biler, er det fornuftig å dele dem inn i grupper og frakte dem i grupper. Sammen med oppdragsgiver blir vi enige om en plan der vi spesifiserer når og hvilke maskiner som skal flytte og når den endelige replikeringen og overgangen til den nye siden skal utføres.
- Testmigrering. Vi migrerer den virtuelle testmaskinen og sjekker om alt er riktig konfigurert: nettverkstilkobling mellom nettsteder, tilgjengelighet av den virtuelle maskinen til maskiner på kildesiden, kontorettigheter, etc. Denne testen hjelper til med å unngå problemer i stridsmigrasjonsstadiet.
Det var alt for meg. Still spørsmål i kommentarfeltet og fortell oss om din migrasjonsopplevelse.
Kilde: www.habr.com