For about 7 years, the very first projects were moving to our cloud simply and straightforwardly. Images of virtual machines were uploaded to an FTP server or brought in on hard drives. Then, via a special import server, the VMs were uploaded to the cloud.
If it's not an issue for the client to turn off the virtual machine for a day or two (or if there are no other options), then this approach can work. However, if downtime should be a maximum of one hour, this method won't suffice. Today, I will discuss the tools that can help migrate to the cloud with minimal downtime and how our migration process works.
Migration with Veeam Backup and Replication
Veeam Backup and Replication is well-known as a tool for creating backups and replicas. We use it for migration between our sites and for transporting clients from private virtualization to our cloud. The client's virtual machines are replicated to our vCenter, and then the engineer adds them to vCloud Director.
The initial replication is performed while the virtual machine is powered on. At a designated time, the machine on the client's side is turned off. Replication is started again to transfer the changes that occurred since the first replication. After that, the virtual machine starts in our cloud.
Typically, from the moment the machine is powered off on the client's infrastructure to when it is powered on in our cloud, no more than half an hour passes, often only 15–20 minutes.
Meanwhile, the original virtual machine remains on the client's site. If something goes wrong, it can always be rolled back and turned on. This method is also convenient for the client as it does not require Veeam.
Case 1
The client had its own virtual infrastructure based on VMware – 40 VMs totaling 30 TB. The hardware on which the cluster was deployed was already outdated, and the client decided not to invest in new purchases and to move to the public cloud. The requirement for downtime of critical systems was no more than one hour. Veeam Replication was chosen as the tool. Additionally, it was a plus that the client's Internet provider was present in our data center, which allowed for a good connection. The migration took about a month, with downtime during the switch of up to 30 minutes for one group of virtual machines.
Migration using Veeam Cloud Connect
Veeam Cloud Connect – et værktøj, der hjælper med at konfigurere replikering af virtuelle maskiner og starte replikater i cloud-tjenesteudbyderen. Efter opdateringen i året blev det muligt at replikere virtuelle maskiner direkte til vCloud Director. Den eneste betingelse er, at der skal være implementeret en Veeam Backup and Replication på kundens side, som ikke er lavere end version 9. Kort sagt (den detaljerede version ), så ser hele processen således ud.
I vCloud Director oprettes en organisation med nødvendige ressourcer og netværk. I Veeam Cloud Connect opretter vi en konto, som kunden forbinder til fra sin Veeam B&R, vælger DataLine som udbyder og organisation, og konfigurerer opgaver til replikation. Udover at nedetid ved denne migrering vil være på 15–20 minutter, er kunden ikke afhængig af udbyderens support og styrer hele processen selv: opretter replikationsopgaver, selve replikationen, slukker maskinerne og starter dem på den nye placering.
Case 2
Kundens infrastruktur, hvor migrationen blev planlagt, var placeret i Hviderusland. Det var nødvendigt at flytte 90 VM'er med en samlet størrelse på 27 TB, mens internetforbindelsen var 100 mbit/s. Hvis vi lavede backup og straks uploadede det til vores cloud, ville det tage flere dage for nogle VM'er. I mellemtiden ville der være vokset en stor delta på VM'erne, hvilket kunne have negativ indflydelse på maskinernes ydeevne eller, hvad der er værre, pladsen på datalageret ville være udløbet. Vi handlede som følger: først lavede kunden en lokal fuld backup og overførte en kopi til vores cloud via Veeam Cloud Connect. Derefter lavede han og overførte en inkrement til cloud. Den oprindelige virtuelle maskine fortsatte med at arbejde. Efter at have slukket VM'en lavede kunden endnu en inkrement og sendte også til cloud. På vores side deployerede vi en virtuel maskine fra den fulde backup og tilføjede derefter to inkrementer. Denne skema gjorde det muligt at minimere nedetid til 2 timer ved skift til vores platform.
Migration ved hjælp af VMware vCloud Availability
I marts i år udgav VMware vCloud Availability 3.0, som giver mulighed for at migrere virtuelle maskiner mellem forskellige skyer (vCloud Director – vCloud Director) og fra kundens private virtualiseringsmiljø til skyen (vCenter – vCloud Director). Den primære bekvemmelighed er integrationen med vCloud Director-grænsefladen. Dette gør det betydeligt lettere at administrere replikering og minimerer nedetid under omstillingen.
Ved hjælp af dette værktøj migrerede vi en af vores kunder fra vores cloud i Moskva til vores cloud i Sankt Petersborg. Det var nødvendigt at flytte 18 virtuelle maskiner med en samlet kapacitet på 14 TB. Der blev oprettet en organisation for kunden i den sankt-petersborgiske cloud, og de nødvendige netværk blev etableret. Derefter gik kunden fra vCloud Director-grænsefladen til indstillingerne for vCloud Availability, oprettede replikationsopgaver og skiftede til den sankt-petersborgiske platform på et passende tidspunkt. Nedetiden under omstillingen var 12 minutter.
Migreringsskemaet mellem DataLine-skyerne i Sankt Petersborg og Moskva.
vCloud Availability har en mekanisme til at migrere VM'er fra kundens site til vores cloud. Til dette implementeres en specialiseret appliance for vCloud Availability i kundens vCenter. Efter en simpel opsætning oprettes forbindelsen til skyen, og migreringsopgaverne konfigureres. Kunden har også fuld kontrol over hele processen, og migreringstiden minimeres.
Migreringsskemaet for virtuelle maskiner fra en privat installation til skyen.
VMware vCloud Availability har mange andre anvendelsesscenarier, som vi snart vil dele i en separat artikel.
Forberedelse til migration
For at vælge værktøjet og faktisk påbegynde migrationen skal man tage stilling til følgende punkter:
Hvor migrerer vi fra. Hvis du migrerer fra en privat løsning, har du fuldstændig frihed til at vælge værktøjer. Hvis du flytter fra en udbyder, er det mere kompliceret. Sandsynligvis kan man ikke bare forbinde infrastrukturen fra to udbydere og trække VM'er over på grund af sikkerhedsmæssige hensyn. Nogle gange begynder udbyderen, som kunden ønsker at forlade, endda at skabe problemer og trække tiden. At forlade en udbyder kan gøres på den gamle måde: ved at eksportere VM'er til diske og via FTP, eller ved at migrere på applikationsniveau. Det sidste er betinget, og det ser omtrent således ud.
Case 3
Det var nødvendigt at migrere klientens SAP-system fra en europæisk udbyder: 34 VM'er på i alt 54 TB. Klienten fik tildelt ressourcer i vores cloud. Der blev etableret netværksforbindelse mellem os og infrastrukturen hos den europæiske udbyder. Applikationsserverne blev genoprettet med de nødvendige konfigurationer. Store databaser blev migreret ved at uploade sikkerhedskopier til vores cloud. Herefter blev der opsat replikation mellem databaserne på vores og den oprindelige placering. På det aftalte tidspunkt skiftede vi til databaserne i vores cloud.
Datasæt og internetkanal. Vi beder normalt klienten om at fremskaffe en udtrækning fra systemerne med parametre for hukommelse, CPU og diske. Vi vurderer, om kanalen er tilstrækkelig til direkte at sende replikater eller sikkerhedskopier af virtuelle maskiner.
Acceptabel downtime. For forskellige systemer og dertil hørende virtuelle maskiner kan det variere afhængigt af deres kritikalitet for virksomheden. Normalt kommer klienten med færdige krav til nedetid ved migration, og på baggrund af dette vælger vi det passende værktøj og migrationsplanen. Vi forsøger at planlægge det endelige skift til natten eller weekenden, så selv en lille nedetid ikke er synlig for klientens slutbrugere.
Baseret på disse data kan vi vælge værktøj og påbegynde selve migreringen. Her er, hvad der sker herefter.
- Opsætning af netværksforbindelse. Vi organiserer netværksforbindelse mellem vores cloud og klientens infrastruktur. Gennem dette netværk vil de virtuelle maskiner blive kopieret. Hvis Veeam Backup and Replication anvendes, er det en dedikeret linje, sjældent – en VPN-forbindelse. Ved brug af Veeam Cloud Connect sker alt gennem internettet eller den samme dedikerede linje.
Derefter opsættes netværket for VM'er i cloud. Maskinerne flyttes normalt i grupper og ikke på en dag. Efter at VM'erne er flyttet til os og startet, skal de interagere med maskiner, der stadig er tilbage på den oprindelige placering.
- Plan for migrering. Når der er mange maskiner, er det rimeligt at opdele dem i grupper og transportere dem i partier. Sammen med klienten aftaler vi en plan, hvor vi beskriver, hvornår og hvilke maskiner der flyttes, samt hvornår den endelige replikation og skift til den nye placering vil finde sted.
- Testmigration. Vi migrerer den test virtuelle maskine og tjekker, om alt er korrekt konfigureret: netværksforbindelse mellem sites, tilgængelighed af den virtuelle maskine for maskiner på den oprindelige site, brugerrettigheder og andet. En sådan test hjælper med at undgå forsinkelser i den faktiske migrationsfase.
Det var alt fra mig. Stil spørgsmål i kommentarerne og del din migreringserfaring.
Kilde: habr.com
