Sowat 7 jaar gelede het die heel eerste projekte eenvoudig en pretensieloos na ons wolk verskuif. Virtuele masjienbeelde is na 'n FTP-bediener opgelaai, of dit is op hardeskywe afgelewer. Toe, deur 'n spesiale invoerbediener, is die VM's na die wolk opgelaai.
As dit nie vir die kliënt 'n probleem is om die virtuele masjien vir 'n dag of twee af te skakel nie (of daar is geen ander opsies nie), dan kan dit gedoen word. Maar as die stilstand 'n maksimum van 'n uur moet wees, sal hierdie metode nie werk nie. Vandag sal ek jou vertel watter gereedskap jou sal help om na die wolk te migreer met minimale stilstand en hoe ons migrasieproses self werk.
Migrasie met Veeam-rugsteun en replikasie
Almal ken Veeam Backup and Replikasie as 'n hulpmiddel om rugsteun en replikas te skep. Ons gebruik dit vir migrasie tussen ons werwe en om kliënte van private virtualisering na ons wolk te vervoer. Die kliënt se virtuele masjiene word na ons vCenter gerepliseer, waarna die ingenieur hulle by vCloud Director voeg.
Primêre replikasie vind plaas op 'n aangedrewe virtuele masjien. Op die ooreengekome tyd word die kliëntkantmasjien afgeskakel. Replikasie loop weer om veranderinge wat sedert die eerste replikasie plaasgevind het, oor te dra. Hierna begin die virtuele masjien in ons wolk.
Tipies, vanaf die oomblik dat die masjien op die kliënt se infrastruktuur afgeskakel word tot die oomblik dat dit in ons wolk aangeskakel word, gaan nie meer as 'n halfuur verby nie, maar eerder 15–20 minute.
In hierdie geval bly die oorspronklike virtuele masjien op die kliëntwebwerf. As iets skielik verkeerd loop, kan jy altyd terugrol en dit aanskakel. Hierdie metode is ook gerieflik vir die kliënt deurdat dit nie vereis dat hy Veeam moet hê nie.
Geval 1
Die kliënt het sy eie virtuele infrastruktuur gehad gebaseer op VMware - 40 VM's met 'n kapasiteit van 30 TB. Die toerusting waarop die groepering ontplooi is, was reeds verouderd, en die kliënt het besluit om nie die moeite te doen om nuwes aan te koop nie en het na die publieke wolk geskuif. Die stilstandtydvereiste vir kritieke stelsels was nie meer as 'n uur nie. Veeam Replication is gekies as die instrument. Nog 'n pluspunt was dat die kliënt se internetverskaffer in ons datasentrum teenwoordig was, wat dit moontlik gemaak het om 'n goeie kanaal te organiseer. Die migrasie het ongeveer 'n maand geneem, stilstand tydens oorskakeling was tot 30 minute per groep virtuele masjiene.
Migreer met Veeam Cloud Connect
Veeam Cloud Connect is 'n instrument wat jou help om virtuele masjienreplikasie op te stel en replikas in die diensverskaffer se wolk te begin. Na opdatering na jaar, het dit moontlik geword om virtuele masjiene direk na vCloud Director te repliseer. Die enigste voorwaarde is dat Veeam Backup en Replikasie aan die kliëntkant ten minste weergawe 9 ontplooi moet word. Kortom (gedetailleerde weergawe) ), dan lyk die hele proses so.
In vCloud Director word 'n organisasie geskep met die nodige hulpbronne en netwerke. In Veeam Cloud Connect skep ons 'n rekening, die kliënt koppel daaraan vanaf sy Veeam B&R, kies 'n DataLine-verskaffer en organisasie, en stel take op vir replikasie. Benewens die feit dat stilstand gedurende so 'n migrasie binne 15–20 minute sal wees, is die kliënt geensins afhanklik van die verskaffer se tegniese ondersteuning nie en bestuur die hele proses onafhanklik: skep replikasietake, die replikasie self, skakel af die masjiene en begin dit op die nuwe webwerf.
Geval 2
Die kliënt se infrastruktuur, vanwaar die migrasie beplan is, was in Belarus geleë. Dit was nodig om 90 VM's met 'n totale volume van 27 TB te vervoer, ten spyte van die feit dat die internetkanaal 100 Mbit/sek was. As jy 'n rugsteun maak en dit dadelik na ons wolk oplaai, sal dit vir sommige VM's 'n paar dae neem. Gedurende hierdie tyd sou 'n groot delta op die VM gegroei het, en dit kan 'n negatiewe impak op die werkverrigting van die masjiene hê of, nog erger, die spasie op die datastoor sou opraak. Ons het soos volg voortgegaan: eerstens het die kliënt 'n plaaslike volledige rugsteun gemaak en 'n kopie daarvan na ons wolk oorgedra via Veeam Cloud Connect. Toe het ek die inkrement gemaak en na die wolk oorgedra. Die oorspronklike virtuele masjien het aanhou loop. Nadat die VM afgeskakel is, het die kliënt nog 'n verhoging gemaak en dit ook na die wolk oorgedra. Aan ons kant het ons 'n virtuele masjien vanaf 'n volledige rugsteun ontplooi en toe twee inkremente daarop gerol. Hierdie skema het dit uiteindelik moontlik gemaak om stilstand tot 2 uur te verminder wanneer na ons webwerf oorgeskakel word.
Migrasie met VMware vCloud Beskikbaarheid
In Maart vanjaar het VMware vCloud Availability 3.0 vrygestel, wat jou toelaat om virtuele masjiene te migreer tussen verskillende wolke (vCloud Director - vCloud Director) en van private kliëntvirtualiseringstande na die wolk (vCenter - vCloud Director). Die belangrikste gerief is integrasie met die vCloud Director-koppelvlak. Dit vergemaklik die replikasiebestuursproses aansienlik en verminder stilstandtyd tydens oorskakelings.
Met hierdie hulpmiddel het ons een van die kliënte van ons Moskou-wolk na ons wolk in St. Petersburg gemigreer. Dit was nodig om 18 virtuele masjiene met 'n totale kapasiteit van 14 TB te vervoer. 'n Organisasie is vir die kliënt in die St. Petersburg-wolk geskep en die nodige netwerke is georganiseer. Vervolgens, vanaf die vCloud Director-koppelvlak, het die kliënt na die vCloud Beskikbaarheid-instellings gegaan, replikasietake geskep en na die St. Petersburg-werf oorgeskakel op 'n gerieflike tyd vir hom. Onderbreking tydens omskakeling was 12 minute.
Migrasieskema tussen DataLine-wolke in St. Petersburg en Moskou.
vCloud Beskikbaarheid het 'n meganisme om VM's van die kliënt se webwerf na ons wolk te migreer. Om dit te doen, word 'n spesiale vCloud Beskikbaarheid-toepassing in die kliënt se vCenter ontplooi. Na eenvoudige opstelling koppel jy aan die wolk en stel migrasietake op. Die kliënt bestuur ook die hele proses onafhanklik en migrasietyd word tot die minimum beperk.
Skema vir die migreer van virtuele masjiene van 'n private installasie na die wolk.
VMware vCloud Beskikbaarheid het baie ander gebruiksgevalle; ons sal binnekort daaroor in 'n aparte artikel praat.
Voorbereiding vir migrasie
Om 'n instrument te kies en werklik te begin migreer, moet jy op die volgende punte besluit:
Waarvandaan migreer ons? As u van 'n private oplossing migreer, het u volledige vryheid om gereedskap te kies. As jy wegbeweeg van jou verskaffer, dan is dit meer ingewikkeld. Heel waarskynlik, om die infrastruktuur van twee verskaffers te koppel en bloot 'n VM te sleep en te laat val, sal weens sekuriteitsredes nie werk nie. Soms begin die verskaffer wat die kliënt op die punt staan om te weier, ondeund te wees en stal vir tyd. U kan op die outydse manier van die verskaffer wegbeweeg: deur VM's op skywe en FTP op te laai, of deur op toepassingsvlak te migreer. Die naam van laasgenoemde is voorwaardelik, en dit lyk so iets.
Geval 3
Dit was nodig om die kliënt se SAP-stelsel van 'n Europese verskaffer te migreer: 34 VM'e met 'n kapasiteit van 54 TB. Aan die kliënt is hulpbronne in ons wolk toegewys. Netwerkverbinding is georganiseer tussen ons en die infrastruktuur van die Europese verskaffer. Die toepassingsbedieners is herontplooi, met die nodige konfigurasies omgedraai. Groot databasisse is gemigreer deur rugsteun na ons wolk op te laai. Vervolgens is replikasie gekonfigureer tussen die databasisse op ons en die oorspronklike webwerwe. Op die ooreengekome tyd het ons oorgeskakel na databasisse in ons wolk.
Datavolume en internetkanaal. Ons vra gewoonlik die kliënt om 'n oplaai per stelsel te verskaf met geheue, SVE en skyf parameters. Ons evalueer of die kanaal genoeg is om direk replikas of rugsteun van virtuele masjiene te stuur.
Aanvaarbare stilstand. Vir verskillende stelsels en, dienooreenkomstig, virtuele masjiene, kan dit verskil afhangende van hul besigheidskrititeit. Gewoonlik kom die kliënt met klaargemaakte vereistes vir stilstand tydens migrasie, en op grond hiervan kies ons die toepaslike instrument en migrasieplan. Ons probeer om die finale oorskakeling snags of oor naweke te skeduleer sodat selfs geringe stilstand nie vir die kliënt se eindgebruikers opmerklik is nie.
Op grond van hierdie data kan u 'n instrument kies en die migrasie self begin. Hier is wat volgende gebeur.
- Stel netwerkverbinding op. Ons organiseer netwerkverbinding tussen ons wolk en die kliënt se infrastruktuur. Virtuele masjiene sal oor hierdie netwerk gekopieer word. As Veeam Backup and Replikasie gebruik word, dan is dit 'n toegewyde kanaal, minder dikwels 'n VPN-kanaal. As Veeam Cloud Connect, dan gaan alles via die internet of dieselfde toegewyde kanaal.
Dan word die netwerk vir die VM in die wolk gekonfigureer. Motors beweeg gewoonlik in groepe en vir meer as een dag. Sodra die VM'e na ons toe gebring en geloods is, moet hulle kommunikeer met die masjiene wat nog op die oorspronklike werf bly.
- Migrasie skedule. Wanneer daar baie motors is, maak dit sin om hulle in groepe te verdeel en in groepe te vervoer. Saam met die kliënt kom ons ooreen op 'n plan waarin ons spesifiseer wanneer en watter masjiene sal beweeg en wanneer die finale replikasie en oorskakeling na die nuwe perseel uitgevoer sal word.
- Toetsmigrasie. Ons migreer die virtuele toetsmasjien en kyk of alles korrek opgestel is: netwerkverbinding tussen werwe, beskikbaarheid van die virtuele masjien na masjiene op die bronwebwerf, rekeningregte, ens. Hierdie toets help om haakplekke in die gevegsmigrasiestadium te vermy.
Dis al vir my. In die kommentaar, vra vrae en vertel ons van jou migrasie-ervaring.
Bron: will.com