Sa'n 7 jier lyn ferhuze de alderearste projekten gewoan en pretentieloos nei ús wolk. Ofbyldings fan firtuele masines waarden opladen nei in FTP-tsjinner, of se waarden levere op hurde skiven. Dan, fia in spesjale ymportserver, waarden de VM's opladen nei de wolk.
As it gjin probleem is foar de kliïnt om de firtuele masine foar in dei of twa út te skeakeljen (of d'r binne gjin oare opsjes), dan kin dit dien wurde. Mar as de downtime maksimaal in oere wêze moat, dan sil dizze metoade net wurkje. Hjoed sil ik jo fertelle hokker ark jo sille helpe om nei de wolk te migrearjen mei minimale downtime en hoe't ús migraasjeproses sels wurket.
Migraasje mei Veeam Reservekopy en Replikaasje
Elkenien ken Veeam Reservekopy en replikaasje as in ark foar it meitsjen fan backups en replika's. Wy brûke it foar migraasje tusken ús siden en foar it ferfier fan kliïnten fan privee virtualisaasje nei ús wolk. De firtuele masines fan 'e kliïnt wurde replikearre nei ús vCenter, wêrnei't de yngenieur se tafoegje oan vCloud Director.
Primêre replikaasje bart op in oandreaune firtuele masine. Op de ôfpraat tiid wurdt de kliïntsidemasine útskeakele. Replikaasje rint wer om wizigingen oer te dragen dy't binne bard sûnt de earste replikaasje. Hjirnei begjint de firtuele masine yn ús wolk.
Typysk, fan it momint dat de masine útskeakele is op 'e ynfrastruktuer fan' e kliïnt oant it momint dat it yn ús wolk ynskeakele is, giet net mear as in heal oere, mar earder 15-20 minuten.
Yn dit gefal bliuwt de orizjinele firtuele masine op 'e kliïntside. As der ynienen wat mis giet, kinne jo altyd werom rôlje en it oansette. Dizze metoade is ek handich foar de klant yn dat it net fereasket dat hy Veeam hat.
Geval 1
De klant hie syn eigen firtuele ynfrastruktuer basearre op VMware - 40 VM's mei in kapasiteit fan 30 TB. De apparatuer wêrop it kluster waard ynset wie al ferâldere, en de klant besleat gjin muoite om nije te keapjen en ferhuze nei de iepenbiere wolk. De downtime eask foar krityske systemen wie net mear as in oere. Veeam Replication waard keazen as it ark. In oar pluspunt wie dat de ynternetprovider fan 'e kliïnt oanwêzich wie yn ús datasintrum, wat it mooglik makke om in goed kanaal te organisearjen. De migraasje duorre sawat in moanne, downtime by it wikseljen wie oant 30 minuten per groep firtuele masines.
Migrearje mei Veeam Cloud Connect
Veeam Cloud Connect is in ark dat jo helpt om replikaasje fan firtuele masines yn te stellen en replika's te starten yn 'e wolk fan' e tsjinstferliener. Nei it bywurkjen nei jier waard it mooglik om firtuele masines direkt nei vCloud Director te replikearjen. De iennichste betingst is dat oan 'e kliïntkant Veeam Reservekopy en Replikaasje op syn minst ferzje 9 ynset wurde moat. Koartsein (detaillearre ferzje ), dan sjocht it hiele proses der sa út.
Yn vCloud Director wurdt in organisaasje makke mei de nedige boarnen en netwurken. Yn Veeam Cloud Connect meitsje wy in akkount, de kliïnt ferbynt dermei fan syn Veeam B&R, selekteart in DataLine-provider en organisaasje, en konfigurearret taken foar replikaasje. Neist it feit dat tidens sa'n migraasje downtime binnen 15-20 minuten sil wêze, is de kliïnt op gjin inkelde manier ôfhinklik fan 'e technyske stipe fan' e provider en beheart it heule proses selsstannich: makket replikaasjetaken, de replikaasje sels, skeakelt út de masines en begjint se op 'e nije side.
Geval 2
De ynfrastruktuer fan 'e kliïnt, wêrfan't de migraasje pland wie, wie yn Wyt-Ruslân. It wie nedich om 90 VM's te ferfieren mei in totale folume fan 27 TB, nettsjinsteande it feit dat it ynternetkanaal 100 Mbit / sek wie. As jo in reservekopy meitsje en it daliks uploade nei ús wolk, dan soe it foar guon VM's ferskate dagen duorje. Yn dizze tiid soe in grutte delta groeid hawwe op 'e VM, en dit kin in negative ynfloed hawwe op' e prestaasjes fan 'e masines of, noch slimmer, de romte op' e datastore soe útrûn wêze. Wy gienen as folget: earst makke de kliïnt in lokale folsleine reservekopy en stjoerde in kopy dêrfan oer nei ús wolk fia Veeam Cloud Connect. Doe makke ik en oerbrocht de ynkommens nei de wolk. De orizjinele firtuele masine bleau te rinnen. Nei it ôfsluten fan 'e VM makke de kliïnt in oare ynkommens en ferpleatst it ek nei de wolk. Oan ús kant hawwe wy in firtuele masine ynset fan in folsleine reservekopy, en doe rôle twa ynkommens derop. Dit skema makke it úteinlik mooglik om downtime te minimalisearjen oant 2 oeren by it wikseljen nei ús side.
Migraasje mei VMware vCloud Beskikberens
Yn maart fan dit jier hat VMware vCloud Beskikberens 3.0 frijlitten, wêrmei jo firtuele masines kinne migrearje tusken ferskate wolken (vCloud Director - vCloud Director) en fan partikuliere client-virtualisaasjestân nei de wolk (vCenter - vCloud Director). It wichtichste gemak is yntegraasje mei de vCloud Director-ynterface. Dit ferienfâldiget it proses fan replikaasjebehear sterk en minimalisearret downtime tidens oerstap.
Mei dit ark hawwe wy ien fan 'e kliïnten migrearre fan ús Moskou-wolk nei ús wolk yn Sint-Petersburch. It wie nedich om 18 firtuele masines te ferfieren mei in totale kapasiteit fan 14 TB. In organisaasje waard makke foar de klant yn 'e wolk fan Sint-Petersburch en de nedige netwurken waarden organisearre. Folgjende, fan 'e vCloud Director-ynterface, gie de kliïnt nei de ynstellings fan vCloud Beskikberens, makke replikaasjebanen en skeakele oer nei de Sint-Petersburch-side op in handige tiid foar him. Downtime by it wikseljen wie 12 minuten.
Migraasjeskema tusken DataLine-wolken yn Sint-Petersburch en Moskou.
vCloud Beskikberens hat in meganisme foar it migrearjen fan VM's fan 'e side fan' e kliïnt nei ús wolk. Om dit te dwaan, wurdt in spesjale vCloud Availability-applikaasje ynset yn it vCenter fan 'e kliïnt. Nei ienfâldige opset ferbine jo mei de wolk en konfigurearje migraasjetaken. De klant beheart ek it hiele proses selsstannich en de migraasjetiid wurdt op in minimum beheind.
Skema foar it migrearjen fan firtuele masines fan in privee ynstallaasje nei de wolk.
VMware vCloud Beskikberens hat in protte oare gebrûksgefallen; wy sille der gau oer prate yn in apart artikel.
Tariede op migraasje
Om in ark te kiezen en eins te begjinnen mei migrearjen, moatte jo beslute oer de folgjende punten:
Wêr migrearje wy wei? As jo migrearje fan in privee oplossing, dan hawwe jo folsleine frijheid by it kiezen fan ark. As jo fuortgean fan jo provider, dan is it yngewikkelder. Meast wierskynlik, it keppeljen fan de ynfrastruktuer fan twa providers en gewoan slepen en droppe fan in VM sil net wurkje fanwege feiligens redenen. Soms begjint de provider dy't de klant op it punt is om te wegerjen mislik te wêzen en bliuwt foar de tiid. Jo kinne fuortgean fan de provider op de âlderwetske manier: troch VM's op te laden nei skiven en FTP, of troch te migrearjen op it applikaasjenivo. De namme fan de lêste is betingst, en it sjocht der sa út.
Geval 3
It wie nedich om it SAP-systeem fan 'e kliïnt te migrearjen fan in Jeropeeske provider: 34 VM's mei in kapasiteit fan 54 TB. De klant waard boarnen tawiisd yn ús wolk. Netwurkferbining waard organisearre tusken ús en de ynfrastruktuer fan 'e Europeeske provider. De applikaasje-tsjinners waarden opnij ynset, mei de nedige konfiguraasjes rôle oer. Grutte databases waarden migrearre troch it uploaden fan backups nei ús wolk. Dêrnei waard replikaasje konfigureare tusken de databases op ús en de orizjinele siden. Op de ôfpraat tiid gongen wy oer op databases yn ús wolk.
Data folume en ynternet kanaal. Wy freegje de kliïnt normaal om in upload troch systeem te leverjen mei parameters foar ûnthâld, CPU en skiif. Wy evaluearje oft it kanaal genôch is om direkt replika's of backups fan firtuele masines te stjoeren.
Akseptabel downtime. Foar ferskate systemen en, dus, firtuele masines, kin it ferskille ôfhinklik fan har saaklike krityk. Meastentiids komt de klant mei klearmakke easken foar downtime by migraasje, en basearre op dit selektearje wy it passende ark en migraasjeplan. Wy besykje de definitive oerstap nachts of yn it wykein te plannen sadat sels lytse downtime net merkber is foar de einbrûkers fan de klant.
Op grûn fan dizze gegevens kinne jo in ark selektearje en de migraasje sels begjinne. Hjir is wat der folgjende bart.
- It ynstellen fan netwurkferbining. Wy organisearje netwurkferbining tusken ús wolk en de ynfrastruktuer fan 'e kliïnt. Firtuele masines sille wurde kopiearre oer dit netwurk. As Veeam Reservekopy en replikaasje wurdt brûkt, dan is dit in tawijd kanaal, minder faak in VPN-kanaal. As Veeam Cloud Connect, dan giet alles fia it ynternet of itselde tawijd kanaal.
Dan is it netwurk konfigureare foar de VM yn 'e wolk. Auto's bewege normaal yn groepen en foar mear as ien dei. Sadree't de VM's nei ús binne brocht en lansearre, moatte se kommunisearje mei de masines dy't noch op 'e orizjinele side bliuwe.
- Migraasje skema. As d'r in protte auto's binne, is it logysk om se yn groepen te splitsen en se yn batches te ferfieren. Tegearre mei de klant, wy iens oer in plan dêr't wy oantsjutte wannear en hokker masines sille ferpleatse en wannear't de definitive replikaasje en oerstap nei de nije side wurdt útfierd.
- Testmigraasje. Wy migrearje de test firtuele masine en kontrolearje oft alles goed is konfigurearre: netwurkferbining tusken siden, beskikberens fan 'e firtuele masine nei masines op' e boarneside, akkountrjochten, ensfh. Dizze test helpt om problemen te foarkommen yn 'e fjochtsmigraasjestadium.
Dat is alles foar my. Stel yn 'e opmerkingen fragen en fertel ús oer jo migraasjeûnderfining.
Boarne: www.habr.com