For omkring 7 år siden flyttede de allerførste projekter enkelt og uhøjtideligt til vores sky. Billeder af virtuelle maskiner blev uploadet til en FTP-server, eller de blev leveret på harddiske. Derefter blev VM'erne uploadet til skyen via en speciel importserver.
Hvis det ikke er et problem for klienten at slukke for den virtuelle maskine i en dag eller to (eller der ikke er andre muligheder), så kan dette gøres. Men hvis nedetiden maksimalt skulle være en time, så virker denne metode ikke. I dag vil jeg fortælle dig, hvilke værktøjer der hjælper dig med at migrere til skyen med minimal nedetid, og hvordan vores migreringsproces i sig selv fungerer.
Migrering med Veeam Backup og Replikering
Alle kender Veeam Backup and Replication som et værktøj til at lave backups og replikaer. Vi bruger det til migrering mellem vores websteder og til at transportere klienter fra privat virtualisering til vores sky. Klientens virtuelle maskiner replikeres til vores vCenter, hvorefter ingeniøren tilføjer dem til vCloud Director.
Primær replikering sker på en tændt virtuel maskine. På det aftalte tidspunkt slukkes klientsidens maskine. Replikering kører igen for at overføre ændringer, der er sket siden den første replikering. Herefter starter den virtuelle maskine i vores sky.
Typisk går der ikke mere end en halv time, fra det øjeblik maskinen slukkes på klientens infrastruktur til det øjeblik den tændes i vores sky, men derimod 15-20 minutter.
I dette tilfælde forbliver den originale virtuelle maskine på klientwebstedet. Hvis noget pludselig går galt, kan du altid rulle tilbage og tænde den. Denne metode er også praktisk for klienten, idet den ikke kræver, at han har Veeam.
Tilfælde 1
Klienten havde sin egen virtuelle infrastruktur baseret på VMware - 40 VM'er med en kapacitet på 30 TB. Udstyret, som klyngen blev implementeret på, var allerede forældet, og klienten besluttede ikke at tænke på at købe nyt og flyttede til den offentlige sky. Nedetidskravet for kritiske systemer var ikke mere end en time. Veeam Replication blev valgt som værktøj. Et andet plus var, at kundens internetudbyder var til stede i vores datacenter, hvilket gjorde det muligt at organisere en god kanal. Migreringen tog omkring en måned, nedetid under skift var op til 30 minutter pr. gruppe af virtuelle maskiner.
Migrer med Veeam Cloud Connect
Veeam Cloud Connect er et værktøj, der hjælper dig med at opsætte virtuel maskinreplikering og starte replikaer i tjenesteudbyderens sky. Efter opdatering til år blev det muligt at replikere virtuelle maskiner direkte til vCloud Director. Den eneste betingelse er, at Veeam Backup and Replication på klientsiden skal være installeret som minimum version 9. Kort sagt (detaljeret version ), så ser hele processen sådan ud.
I vCloud Director skabes en organisation med de nødvendige ressourcer og netværk. I Veeam Cloud Connect opretter vi en konto, klienten opretter forbindelse til den fra sin Veeam B&R, vælger en DataLine-udbyder og organisation og konfigurerer opgaver til replikering. Udover det faktum, at nedetiden under en sådan migrering vil være inden for 15-20 minutter, er klienten ikke på nogen måde afhængig af udbyderens tekniske support og styrer hele processen selvstændigt: opretter replikeringsopgaver, selve replikeringen, slukker maskinerne og starter dem på den nye side.
Tilfælde 2
Klientens infrastruktur, hvorfra migreringen var planlagt, var placeret i Hviderusland. Det var nødvendigt at transportere 90 VM'er med en samlet volumen på 27 TB, på trods af at internetkanalen var på 100 Mbit/sek. Hvis du laver en sikkerhedskopi og straks uploader den til vores sky, vil det for nogle VM'er tage flere dage. I løbet af denne tid ville et stort delta være vokset på VM'en, og det kunne have en negativ indvirkning på maskinernes ydeevne, eller endnu værre, pladsen på datalageret ville være løbet tør. Vi fortsatte som følger: Først lavede klienten en lokal fuld backup og overførte en kopi af den til vores sky via Veeam Cloud Connect. Så lavede og overførte jeg stigningen til skyen. Den originale virtuelle maskine fortsatte med at køre. Efter at have lukket VM'en ned, foretog klienten endnu en stigning og overførte den også til skyen. På vores side installerede vi en virtuel maskine fra en fuld backup og rullede derefter to trin ind på den. Denne ordning gjorde det i sidste ende muligt at minimere nedetiden til 2 timer, når du skiftede til vores side.
Migrering med VMware vCloud Tilgængelighed
I marts i år udgav VMware vCloud Availability 3.0, som giver dig mulighed for at migrere virtuelle maskiner mellem forskellige skyer (vCloud Director - vCloud Director) og fra private klientvirtualiseringsstande til skyen (vCenter - vCloud Director). Den største bekvemmelighed er integration med vCloud Director-grænsefladen. Dette forenkler i høj grad replikeringsstyringsprocessen og minimerer nedetid under overgange.
Ved at bruge dette værktøj migrerede vi en af klienterne fra vores Moskva-sky til vores sky i St. Petersborg. Det var nødvendigt at transportere 18 virtuelle maskiner med en samlet kapacitet på 14 TB. Der blev oprettet en organisation for kunden i St. Petersborg-skyen, og de nødvendige netværk blev organiseret. Derefter gik klienten fra vCloud Director-grænsefladen til vCloud-tilgængelighedsindstillingerne, oprettede replikeringsjob og skiftede til St. Petersborg-webstedet på et passende tidspunkt for ham. Nedetid under skift var 12 minutter.
Migrationsordning mellem DataLine-skyer i St. Petersborg og Moskva.
vCloud Availability har en mekanisme til at migrere VM'er fra klientens websted til vores sky. For at gøre dette implementeres en speciel vCloud Availability-applikation i klientens vCenter. Efter simpel opsætning opretter du forbindelse til skyen og konfigurerer migreringsopgaver. Klienten styrer også hele processen selvstændigt, og migreringstiden holdes på et minimum.
Skema til migrering af virtuelle maskiner fra en privat installation til skyen.
VMware vCloud Tilgængelighed har mange andre use cases; vi vil snart tale om dem i en separat artikel.
Forberedelse til migration
For at vælge et værktøj og faktisk begynde at migrere, skal du tage stilling til følgende punkter:
Hvor migrerer vi fra? Hvis du migrerer fra en privat løsning, så har du fuld frihed til at vælge værktøjer. Hvis du flytter væk fra din udbyder, så er det mere kompliceret. Det vil højst sandsynligt ikke fungere at forbinde to udbyderes infrastrukturer og blot trække og slippe en VM på grund af sikkerhedsmæssige årsager. Nogle gange begynder den udbyder, som klienten er ved at afvise, at være drilsk og går i stå i tide. Du kan flytte væk fra udbyderen på den gammeldags måde: ved at uploade VM'er til diske og FTP eller ved at migrere på applikationsniveau. Navnet på sidstnævnte er betinget, og det ser nogenlunde sådan ud.
Tilfælde 3
Det var nødvendigt at migrere kundens SAP-system fra en europæisk udbyder: 34 VM'er med en kapacitet på 54 TB. Klienten fik tildelt ressourcer i vores sky. Netværksforbindelse blev organiseret mellem os og den europæiske udbyders infrastruktur. Applikationsserverne blev geninstalleret, med de nødvendige konfigurationer rullet over. Store databaser blev migreret ved at uploade sikkerhedskopier til vores sky. Dernæst blev replikering konfigureret mellem databaserne på vores og de originale websteder. På det aftalte tidspunkt skiftede vi til databaser i vores sky.
Datavolumen og internetkanal. Vi beder normalt klienten om at give en upload efter system med hukommelse, CPU og diskparametre. Vi vurderer, om kanalen er nok til direkte at sende replikaer eller sikkerhedskopier af virtuelle maskiner.
Acceptabel nedetid. For forskellige systemer og dermed virtuelle maskiner kan det være forskelligt afhængigt af deres forretningskritik. Normalt kommer klienten med færdige krav til nedetid under migreringen, og ud fra dette vælger vi det passende værktøj og migrationsplan. Vi forsøger at planlægge den endelige omstilling om natten eller i weekenden, så selv mindre nedetid ikke er mærkbar for kundens slutbrugere.
Baseret på disse data kan du vælge et værktøj og begynde selve migreringen. Her er, hvad der derefter sker.
- Opsætning af netværksforbindelse. Vi organiserer netværksforbindelse mellem vores cloud og kundens infrastruktur. Virtuelle maskiner vil blive kopieret over dette netværk. Hvis der bruges Veeam Backup and Replication, er dette en dedikeret kanal, sjældnere en VPN-kanal. Hvis Veeam Cloud Connect, så går alt via internettet eller den samme dedikerede kanal.
Derefter konfigureres netværket til VM'en i skyen. Biler bevæger sig normalt i grupper og i mere end én dag. Når først VM'erne er bragt til os og lanceret, skal de kommunikere med de maskiner, der stadig forbliver på det oprindelige sted.
- Migrationsplan. Når der er mange biler, giver det mening at dele dem op i grupper og transportere dem i partier. Sammen med kunden aftaler vi en plan, hvori vi specificerer hvornår og hvilke maskiner der skal flyttes og hvornår den endelige replikering og omstilling til det nye site skal udføres.
- Test migration. Vi migrerer den virtuelle testmaskine og kontrollerer, om alt er konfigureret korrekt: netværksforbindelse mellem websteder, tilgængelighed af den virtuelle maskine til maskiner på kildestedet, kontorettigheder osv. Denne test hjælper med at undgå problemer i kampens migrationsfase.
Det var alt for mig. Stil spørgsmål i kommentarerne og fortæl os om din migreringsoplevelse.
Kilde: www.habr.com