För ungefÀr 7 Är sedan flyttade de första projekten enkelt och okomplicerat till vÄrt moln. Avbildningar av virtuella maskiner laddades upp pÄ FTP-servern eller transporterades pÄ hÄrddiskar. DÀrefter laddades VM:erna upp till molnet via en sÀrskild importserver.
Om det inte Àr ett problem för kunden att stÀnga av den virtuella maskinen i en dag eller tvÄ (eller om det inte finns andra alternativ), sÄ kan det göras sÄ. Men om stillestÄndet mÄste vara högst en timme, fungerar inte detta sÀtt. Idag kommer jag att berÀtta vilka verktyg som kan hjÀlpa till att migrera till molnet med minimalt stillestÄnd och hur sjÀlva migrationsprocessen fungerar hos oss.
Migration med hjÀlp av Veeam Backup and Replication
Veeam Backup and Replication Àr vÀlkÀnt som ett verktyg för att skapa backup och replikat. Vi anvÀnder det för migration mellan vÄra plattformar och för att flytta kunder frÄn privat virtualisering till vÄrt moln. Kundens virtuella maskiner replikeras till vÄr vCenter, dÀrefter lÀgger ingenjören till dem i vCloud Director.
Den första replikeringen utförs pÄ en pÄslagen virtuell maskin. Vid en överenskommen tid stÀngs maskinen av hos kunden. Replikeringen startar igen för att överföra de Àndringar som skett sedan den första replikeringen. Efter detta startas den virtuella maskinen nu i vÄrt moln.
Normalt tar det inte mer Ă€n en halvtimme frĂ„n avstĂ€ngning av maskinen pĂ„ kundens infrastruktur till att den slĂ„s pĂ„ i vĂ„rt moln, oftast 15â20 minuter.
Samtidigt förblir den ursprungliga virtuella maskinen kvar pÄ kundens plattform. Om nÄgot gÄr fel kan man alltid ÄtergÄ till och slÄ pÄ den. För kunden Àr denna metod Àven praktisk eftersom den inte krÀver att de har Veeam.
Fall 1
Kunden hade sin egen virtuella infrastruktur baserad pĂ„ VMware â 40 VM med en total storlek pĂ„ 30 TB. Utrustningen som klustret var installerat pĂ„ var gammal, och kunden beslutade att inte fixa det utan istĂ€llet flytta till ett offentligt moln. Kravet pĂ„ stillestĂ„nd för kritiska system var högst en timme. Veeam Replication valdes som verktyg. En fördel var ocksĂ„ att kundens internetleverantör fanns i vĂ„r datacenter, vilket möjliggjorde en bra kanal. Migrationen tog cirka en mĂ„nad, och stillestĂ„ndet vid omkopplingen var upp till 30 minuter för en grupp virtuella maskiner.
Migration med hjÀlp av Veeam Cloud Connect
Veeam Cloud Connect â ett verktyg som hjĂ€lper till att konfigurera replikering av virtuella maskiner och köra repliker i molnet hos tjĂ€nsteleverantören. Efter uppdateringen i Ă„rets möjliggjordes replikering av virtuella maskiner direkt till vCloud Director. Det enda villkoret Ă€r att kunden mĂ„ste ha en egen Veeam Backup and Replication som Ă€r minst version 9. Sammanfattat (den detaljerade versionen ), ser hela processen ut pĂ„ följande sĂ€tt.
I vCloud Director skapas en organisation med nödvĂ€ndiga resurser och nĂ€tverk. I Veeam Cloud Connect skapar vi ett konto, kunden ansluter sig till detta frĂ„n sin Veeam B&R, vĂ€ljer DataLine som leverantör och organisation, samt stĂ€ller in jobb för replikering. Utöver att nedetiden vid sĂ„dan migrering ligger inom 15â20 minuter, Ă€r kunden helt oberoende av leverantörens support och hanterar hela processen sjĂ€lv: skapar jobb för replikering, sjĂ€lva replikeringen, stĂ€nger av maskiner och startar dem pĂ„ den nya plattformen.
Fall 2
Kundens infrastruktur, varifrÄn migreringen planerades, lÄg i Vitryssland. Det behövdes flytta 90 VM med en total volym pÄ 27 TB, med en internetkanal pÄ 100 Mbit/s. Om vi gjorde en backup och direkt laddade upp den till vÄrt moln, skulle det för vissa VM ta flera dagar. Under den tiden skulle en stor delta ha vuxit pÄ VM, vilket skulle kunna pÄverka maskinernas prestanda negativt eller, Ànnu vÀrre, att utrymmet pÄ datastoren skulle ta slut. Vi gick tillvÀga pÄ följande sÀtt: först gjorde kunden en lokal fullstÀndig backup och överförde en kopia till vÄrt moln via Veeam Cloud Connect. Sedan gjorde han och skickade en inkrementell backup till molnet. Den ursprungliga virtuella maskinen fortsatte att arbeta. Efter att VM stÀngdes av gjorde kunden en till inkrement och överförde ocksÄ denna till molnet. PÄ vÄr sida implementerade vi den virtuella maskinen frÄn fullbackuppen och applicerade sedan de tvÄ inkrementerna. Denna strategi gjorde det möjligt att minimera nedetid till 2 timmar vid övergÄngen till vÄr plattform.
Migrering med hjÀlp av VMware vCloud Availability
I mars i Ă„r slĂ€ppte VMware vCloud Availability 3.0, som möjliggör migration av virtuella maskiner mellan olika moln (vCloud Director â vCloud Director) och frĂ„n kundens privata virtualiseringsstĂ€ll till molnet (vCenter â vCloud Director). Den största fördelen Ă€r integrationen med vCloud Director-grĂ€nssnittet. Detta förenklar hanteringen av replikering och minimerar stillestĂ„nd vid omkoppling.
Med hjÀlp av detta verktyg migrerade vi en av vÄra kunder frÄn vÄrt moln i Moskva till vÄrt moln i Sankt Petersburg. 18 virtuella maskiner med en total kapacitet pÄ 14 TB behövde flyttas. En organisation skapades för kunden i det petersburgska molnet och nödvÀndiga nÀtverk arrangerades. Sedan gick kunden frÄn vCloud Director-grÀnssnittet till instÀllningarna för vCloud Availability, skapade replikationsjobb och vÀxlade över till den petersburgska plattformen vid en tidpunkt som passade dem. StillestÄndet vid omkopplingen var 12 minuter.
Schema för migration mellan DataLine-molnen i Sankt Petersburg och Moskva.
vCloud Availability har en mekanism för migrering av VM frÄn kundens plattform till vÄrt moln. För detta behövs en speciell vCloud Availability-appliance som installeras i kundens vCenter. Efter en enkel konfiguration ansluts den till molnet och migrationsjobb stÀlls in. Kunden hanterar Àven sjÀlv hela processen, vilket minimerar migrationstiden.
Schema för migrering av virtuella maskiner frÄn en privat installation till molnet.
VMware vCloud Availability har mÄnga andra anvÀndningsscenarier, som vi snart kommer att berÀtta om i en separat artikel.
Förberedelse för migrering
För att vÀlja verktyg och faktiskt pÄbörja migreringen mÄste man bestÀmma sig för följande punkter:
VarifrÄn migrerar vi. Om ni migrerar frÄn en privat lösning har ni full frihet att vÀlja verktyg. Om ni flyttar frÄn en leverantör Àr det mer komplicerat. Det Àr troligtvis inte möjligt att koppla samman infrastruktur frÄn tvÄ leverantörer och bara dra över VM av sÀkerhetsskÀl. Ibland kan leverantören som kunden tÀnker sÀga upp till och med börja skapa problem och dra ut pÄ tiden. Man kan flytta frÄn en leverantör pÄ det gamla sÀttet: genom att exportera VM till diskar och FTP eller migrera pÄ applikationsnivÄ. Namnet pÄ den senare Àr villkorligt och ser ut ungefÀr sÄ hÀr.
Case 3
Det var nödvÀndigt att migrera kundens SAP-system frÄn en europeisk leverantör: 34 virtuella maskiner med en total storlek pÄ 54 TB. Klienten tilldelades resurser i vÄrt moln. En nÀtverksanslutning organiserades mellan oss och den europeiska leverantörens infrastruktur. Applikationsservrarna rullades ut pÄ nytt med nödvÀndiga konfigurationer installerade. Stora databaser migrerades genom att ladda upp sÀkerhetskopior till vÄrt moln. DÀrefter inrÀttades replikering mellan databaserna pÄ vÄr och den ursprungliga platsen. Vid den överenskomna tidpunkten vÀxlade vi till databaserna i vÄrt moln.
Datavolym och internetkanal. Vi ber vanligtvis klienten att tillhandahÄlla en export frÄn systemen med parametrar för minne, CPU, och diskar. Vi bedömer om kanalen Àr tillrÀcklig för att direkt skicka replikat eller sÀkerhetskopior av virtuella maskiner.
Acceptabel driftstopp. För olika system och dÀrmed virtuella maskiner kan det variera beroende pÄ deras affÀrskritiska betydelse. Vanligtvis kommer kunden med fÀrdiga krav pÄ driftstopp vid migrering, och baserat pÄ detta vÀljer vi lÀmpligt verktyg och migrationsplan. Vi försöker planera den slutgiltiga vÀxlingen till natten eller helgen, sÄ att Àven en liten driftstopp inte blir mÀrkbar för kundens slutanvÀndare.
Baserat pÄ dessa uppgifter kan man vÀlja verktyg och pÄbörja sjÀlva migreringen. SÄ hÀr gÄr det vidare.
- Konfiguration av nÀtverksanslutning. Vi organiserar nÀtverksanslutningen mellan vÄrt moln och kundens infrastruktur. Genom detta nÀtverk kommer virtuella maskiner att kopieras. Om Veeam Backup and Replication anvÀnds Àr det en dedikerad kanal, sÀllan en VPN-kanal. Om Veeam Cloud Connect anvÀnds gÄr allt genom internet eller den samma dedikerade kanalen.
DÀrefter konfigureras nÀtverket för virtuella maskiner i molnet. Maskinerna flyttas vanligtvis i grupper och över flera dagar. NÀr virtuella maskiner har flyttats till oss och startats, mÄste de interagera med maskiner som fortfarande Àr kvar pÄ den ursprungliga platsen.
- Migrationsschema. NÀr det finns mÄnga maskiner Àr det rimligt att dela upp dem i grupper och transportera dem i partier. Tillsammans med kunden överenskommer vi en plan dÀr vi specificerar nÀr och vilka maskiner som flyttas och nÀr den slutliga replikeringen och vÀxlingen till den nya platsen kommer att utföras.
- Testmigrering. Vi migrerar den test virtuella maskinen och kontrollerar om allt Àr korrekt instÀllt: nÀtverkskoppling mellan platserna, tillgÀnglighet av den virtuella maskinen för maskiner pÄ den ursprungliga platsen, kontorÀttigheter och annat. Ett sÄdant test hjÀlper till att undvika förseningar under den faktiska migreringen.
Detta Àr allt för mig. StÀll frÄgor i kommentarerna och berÀtta om din migrationsupplevelse.
KĂ€lla: habr.com
