Körülbelül 7 évvel ezelőtt a legelső projektek egyszerűen és problémamentesen költöztek a felhőnkbe. A virtuális gépek képei FTP-szerverre lettek feltöltve, vagy merevlemezeken hozták őket. Ezután egy külön import szerver segítségével töltöttük fel a VM-eket a felhőbe.
Ha a kliensnek nem probléma, hogy 1-2 napra leállítja a virtuális gépet (vagy nincs más lehetősége), akkor ez is megoldható. De ha az állásidő maximálisan egy óra lehet, akkor ez a módszer nem megfelelő. Ma arról fogok beszélni, hogy milyen eszközök segíthetnek a felhőbe való migrálásban minimális leállással és hogyan zajlik a migráció folyamata nálunk.
Migráció a Veeam Backup és Replication segítségével
A Veeam Backup és Replication ismeretes, mint a biztonsági mentések és replikák készítésére szolgáló eszköz. Ezt használjuk arra, hogy migrálj a saját helyszíneink között, és hogy a privát virtualizációval rendelkező ügyfeleket átköltöztessük a felhőnkbe. Az ügyfél virtuális gépei replikálódnak a vCenterünkre, majd az engineer hozzáadja őket a vCloud Directorhoz.
Az elsődleges replikáció egy bekapcsolt virtuális gépen történik. Egy előre egyeztetett időpontban a kliens oldalán leállítják a gépet. A replikáció újraindul, hogy átviheti azokat a változásokat, amelyek az első replikáció óta történtek. Ezt követően a virtuális gép már a felhőnkben indul el.
Általában a kliens infrastruktúráján történő leállítástól a felhőnkben való indításig nem telik el több mint fél óra, sokkal inkább 15-20 perc.
Ily módon a kliens helyszínén megmarad az eredeti virtuális gép. Ha valami rosszul sül el, mindig vissza lehet térni és újra be lehet kapcsolni. Ez a módszer az ügyfél számára is kényelmes, mivel nem igényli a Veeam meglétét.
1. eset
Az ügyfélnek saját VMware alapú virtuális infrastruktúrája volt – 40 VM, összesen 30 TB-nyi tárolással. Az a hardver, amelyen a klasztert kiépítették, már elavult, és az ügyfél úgy döntött, hogy nem kíván új berendezésekbe fektetni, ezért a nyilvános felhőbe költözik. Az érzékeny rendszerek leállására vonatkozó követelmény nem haladhatta meg az egy órát. A Veeam Replication-re esett a választás. Előny volt az is, hogy az ügyfél internetszolgáltatója a mi adatközpontunkban jelen volt, ami jó kapcsolat kiépítését tette lehetővé. A migráció körülbelül egy hónapot vett igénybe, a váltás idején a leállás legfeljebb 30 perc volt egy virtuális gép csoport számára.
Migráció a Veeam Cloud Connect segítségével
A Veeam Cloud Connect – egy eszköz, amely segít a virtuális gépek replikálásának beállításában és a replikák indításában a szolgáltató felhőjében. Az év frissítése után lehetőséggé vált, hogy a virtuális gépeket közvetlenül a vCloud Directorba replikáljuk. Az egyetlen feltétel az, hogy a kliens oldalán a Veeam Backup and Replication-nak legalább 9-es verziónak kell lennie. Röviden (a részletes verzió ), az egész folyamat a következőképpen zajlik.
A vCloud Directorban létrejön egy szervezet a szükséges erőforrásokkal és hálózatokkal. A Veeam Cloud Connectban létrehozzuk a fiókot, a kliens csatlakozik hozzá a saját Veeam B&R-jéből, kiválasztja a DataLine szolgáltatót és a szervezetet, beállítja a replikálási feladatokat. Ezenkívül a migráció egyszerűsége 15–20 percen belül lesz, a kliens nem függ a szolgáltató támogatásától, és önállóan irányítja az egész folyamatot: létrehozza a replikálási feladatokat, magát a replikálást, kikapcsolja a gépeket és elindítja azokat az új helyszínen.
2. eset
A kliens infrastruktúrája, ahonnan a migrációt terveztek, Beloruszban volt. 90 virtuális gépet kellett átkonvertálni, összesen 27 TB-os mennyiségben, miközben az internetkapacitás 100 mbit/sec volt. Ha készítenénk egy biztonsági mentést, és azonnal feltöltenénk a felhőbe, akkor néhány virtuális gép esetében ez több napot is igénybe vett volna. Ebben az időszakban a virtuális gépeken nagy delta keletkezett volna, ami negatívan befolyásolta volna a gépek teljesítményét, vagy ami még rosszabb, a tárolón elfogyott volna a hely. Így jártunk el: először a kliens készített egy helyi teljes biztonsági mentést, és átkonvertálta a másolatát a felhőnkbe a Veeam Cloud Connect használatával. Ezután készített és továbbított egy inkrementális mentést a felhőbe. Az eredeti virtuális gép folytatta a működést. A VM kikapcsolása után a kliens készített még egy inkrementális mentést, és ezt is átkonvertálta a felhőbe. A saját oldalunkon egy virtuális gépet indítottunk el a teljes mentésből, majd hozzátettük a két inkrementális mentést. Ez a séma végül lehetővé tette a leállás minimalizálását 2 órára, amikor áttértünk a platformunkra.
Migrálás a VMware vCloud Availability segítségével
2023 márciusában a VMware kiadta a vCloud Availability 3.0-t, amely lehetővé teszi a virtuális gépek migrálását különböző felhők között (vCloud Director – vCloud Director), valamint a kliens privát virtualizációs standjairól a felhőbe (vCenter – vCloud Director). A fő előny az integráció a vCloud Director felületével. Ez jelentősen egyszerűsíti a replikáció kezelését és minimalizálja a leállásokat az átváltás során.
Ezzel az eszközzel migráltunk egy ügyfelet moszkvai felhőnkből a pétervári felhőnkbe. 18 virtuális gépet kellett szállítanunk, összesen 14 TB kapacitással. Az ügyfél számára létrehoztunk egy szervezetet a pétervári felhőben, és megszerveztük a szükséges hálózatokat. Ezután az ügyfél a vCloud Director felületen keresztül rátért a vCloud Availability beállításaira, létrehozta a replikációs feladatokat, és a számára kényelmes időben váltott a pétervári telephelyre. Az átváltás során a leállás 12 percet tett ki.
A DataLine felhők közötti migrációs séma Péterváron és Moszkvában.
A vCloud Availability rendelkezik VM migrációs mechanizmussal az ügyfél telephelyéről a felhőnkbe. Ennek érdekében a kliens vCenterében egy speciális vCloud Availability applikációnak kell települnie. Az egyszerű beállításokat követően csatlakozik a felhőhöz, és beállítja a migrációs feladatokat. Az ügyfél ugyanakkor teljes mértékben irányítja az egész folyamatot, és a migrációs idő minimalizálásra kerül.
A virtuális gépek migrációs sémája privát telepítésből a felhőbe.
A VMware vCloud Availability számos egyéb felhasználási forgatókönyvvel rendelkezik, és hamarosan beszámolunk róluk egy külön cikkben.
Felkészülés a migrációra
A megfelelő eszköz kiválasztásához és a migráció megkezdéséhez figyelembe kell venni a következő szempontokat:
Honnan migrálunk. Ha privát megoldásról migrál, teljes szabadsága van az eszközök kiválasztásában. Ha egy szolgáltatótól átköltözik, az már bonyolultabb. Valószínűleg nem lehet a két szolgáltató infrastruktúráját összekapcsolni, és egyszerűen áthelyezni a VM-et biztonsági megfontolások miatt. Néha a szolgáltató, akit az ügyfél el akar hagyni, kifejezetten hátráltathatja a folyamatot és időt húzhat. Az átköltözés a régi módszerrel történhet: a VM-ek lementésével lemezekre és FTP-n keresztül, vagy alkalmazás szintjén is migrálható. Az utóbbit képletesen nevezzük így, és körülbelül így néz ki.
3. eset
A SAP client system needed to be migrated from a European provider: 34 VMs with a total of 54 TB. Resources were allocated to the client in our cloud. A network connection was established between us and the European provider's infrastructure. Application servers were redeployed with the necessary configurations applied. Large databases were migrated by uploading backups to our cloud. Following that, replication between the databases in our and the source environments was set up. At the agreed time, we switched to the databases in our cloud.
Data volume and internet channel. We usually ask the client to provide an export of system parameters, including memory, CPU, and disks. We assess whether the channel is sufficient to directly send replicas or backups of virtual machines.
Acceptable downtime. For different systems and, consequently, virtual machines, it may vary depending on their criticality for the business. Usually, the client comes with ready requirements regarding downtime during migration, and based on this, we choose an appropriate tool and migration plan. We try to schedule the final switch during nighttime or weekends to ensure that even minor downtime goes unnoticed by the client's end users.
Based on this data, we can choose the tool and proceed with the migration itself. Here’s what happens next.
- Setting up the network connectivity. We establish network connectivity between our cloud and the client's infrastructure. Virtual machines will be copied over this network. If Veeam Backup and Replication is used, it’s a dedicated channel; less often, it’s a VPN channel. If Veeam Cloud Connect is used, everything goes through the internet or the same dedicated channel.
Next, the network for the VMs in the cloud is configured. Machines usually move in groups and over multiple days. After the VMs are transferred to us and launched, they need to interact with machines that are still on the original site.
- Migration schedule. When there are many machines, it makes sense to divide them into groups and transport them in batches. Together with the client, we agree on a plan that outlines when and which machines will move and when the final replication and switch to the new site will occur.
- Test migration. Migráljuk a teszt virtuális gépet, és ellenőrizzük, hogy minden helyesen van beállítva: hálózati kapcsolódás a helyszínek között, a virtuális gép elérhetősége az eredeti helyszínen lévő gépek számára, a fiókjogok és egyéb beállítások. Ez a teszt segít elkerülni a késéseket a tényleges migráció során.
Ezzel én befejeztem. Kérdéseket tehettek fel a megjegyzésekben, és meséljetek a migrációs tapasztalataitokról.
Forrás: habr.com
