Migratiearchitectuur zonder agent

In dit artikel worden de replicatieconcepten beschreven bij het migreren van VMware-VM's met behulp van de migratie- en moderniseringsmethode van het hulpprogramma zonder agent.

Notitie

Deze end-to-end documentatie voor VMware-migratiescenario's is momenteel beschikbaar als preview-versie. Zie de productdocumentatie van Azure Migrate voor meer informatie over het gebruik van Azure Migrate.

Replicatieproces

De replicatieoptie zonder agent werkt met behulp van VMware-momentopnamen en DE CBT-technologie (Block Tracking) van VMware om gegevens van virtuele-machineschijven te repliceren. In het volgende blokdiagram ziet u verschillende stappen die nodig zijn bij het migreren van uw virtuele machines met behulp van het hulpprogramma Migratie en modernisering.

Wanneer replicatie is geconfigureerd voor een virtuele machine, wordt eerst een initiële replicatiefase doorlopen. Tijdens de initiële replicatie wordt een VM-momentopname gemaakt en wordt een volledige kopie van gegevens van de momentopnameschijven gerepliceerd naar beheerde schijven in uw doelabonnement.

Nadat de initiële replicatie voor de VIRTUELE machine is voltooid, gaat het replicatieproces over naar een fase van incrementele replicatie (deltareplicatie). In de incrementele replicatiefase worden gegevenswijzigingen die zijn aangebracht sinds het begin van de laatste voltooide replicatiecyclus gerepliceerd en naar de beheerde replicaschijven geschreven, zodat de replicatie gesynchroniseerd blijft met wijzigingen op de VIRTUELE machine.

VMware-technologie voor bloktracering (CBT) wordt gebruikt om wijzigingen tussen replicatiecycli bij te houden. Aan het begin van de replicatiecyclus wordt een VM-momentopname gemaakt en het bijhouden van wijzigingen in blokken wordt gebruikt om de wijzigingen tussen de huidige momentopname en de laatst gerepliceerde momentopname op te halen. Alleen de gegevens die zijn gewijzigd sinds de vorige voltooide replicatiecyclus, worden gerepliceerd om de replicatie voor de virtuele machine gesynchroniseerd te houden. Aan het einde van elke replicatiecyclus wordt de momentopname vrijgegeven en wordt momentopnameconsolidatie uitgevoerd voor de virtuele machine.

Wanneer u de migratiebewerking uitvoert op een replicerende virtuele machine, is er een replicatiecyclus voor verschillen op aanvraag waarmee de resterende wijzigingen sinds de laatste replicatiecyclus worden gerepliceerd. Nadat de on-demand cyclus is voltooid, worden de beheerde replicaschijven die overeenkomen met de virtuele machine gebruikt om de virtuele machine in Azure te maken. Vlak voordat u migratie/failover activeert, moet u de on-premises virtuele machine afsluiten. Als u de virtuele machine afsluit, zorgt u ervoor dat er geen gegevens verloren gaan tijdens de migratie.

Zodra de migratie is geslaagd en de VM wordt opgestart in Azure, moet u ervoor zorgen dat u de replicatie van de VIRTUELE machine stopt. Als u de replicatie stopt, worden de tussenliggende schijven (seed-schijven) verwijderd die tijdens de gegevensreplicatie zijn gemaakt. Daarnaast voorkomt u dat er extra kosten in rekening worden gebracht voor de opslagtransacties op deze schijven.

Replicatiecycli

Notitie

Zorg ervoor dat u controleert op momentopnamen die aanwezig zijn bij eerdere replicatiepogingen of vanuit andere apps van derden. Wijzigingen bijhouden kan niet worden ingeschakeld op de VIRTUELE machine als momentopnamen al aanwezig zijn voor de VIRTUELE machine. Verwijder de bestaande momentopnamen of schakel het bijhouden van wijzigingenblokken in op de virtuele machine.

Replicatiecycli verwijzen naar het periodieke proces voor het overdragen van gegevens uit een on-premises omgeving naar beheerde Azure-schijven. Een volledige replicatiecyclus bestaat uit de volgende stappen:

1. Een VMware-momentopname maken voor elke schijf die is gekoppeld aan de VIRTUELE machine
2. Gegevens uploaden naar logboekopslagaccount in Azure
3. Momentopname vrijgeven
4. VMware-schijven samenvoegen

Een cyclus wordt gezegd te voltooien zodra de schijven zijn geconsolideerd.

Onderdelen die betrokken zijn bij replicatie

On-premises onderdelen: Azure Migrate-apparaat heeft de volgende onderdelen die verantwoordelijk zijn voor replicatie

• DRA-agent
• Gatewayagent

Azure-onderdelen: De volgende tabel bevat een overzicht van verschillende Azure Artifacts die worden gemaakt tijdens het gebruik van de methode zonder agent van VMware VM-migratie.

Onderdeel	Regio	Abonnement	Beschrijving
Recovery Services-kluis	De regio van het Azure Migrate-project	Azure Migrate-projectabonnement	Wordt gebruikt voor het organiseren van gegevensreplicatie
Service Bus	Doelregio	Azure Migrate-projectabonnement	Wordt gebruikt voor communicatie tussen cloudservice en Azure Migrate-apparaat
Logboekopslagaccount	Doelregio	Azure Migrate-projectabonnement	Wordt gebruikt voor het opslaan van replicatiegegevens, die worden gelezen door de service en worden toegepast op de beheerde schijf van de klant
Gatewayopslagaccount	Doelregio	Azure Migrate-projectabonnement	Wordt gebruikt voor het opslaan van computerstatussen tijdens replicatie
Sleutelkluis	Doelregio	Azure Migrate-projectabonnement	Beheert verbindingsreeks s voor servicebus- en toegangssleutels voor het logboekopslagaccount
Virtuele Azure-machine	Doelregio	Doelabonnement	VM die is gemaakt in Azure wanneer u migreert
Azure Managed Disks	Doelregio	Doelabonnement	Beheerde schijven die zijn gekoppeld aan Azure-VM's
Netwerkinterfacekaarten	Doelregio	Doelabonnement	De NIC's die zijn gekoppeld aan de VM's die zijn gemaakt in Azure

Vereiste machtigingen

Wanneer u de replicatie voor het eerst start, moet de aangemelde gebruiker de volgende rollen krijgen:

• Eigenaar of inzender en beheerder van gebruikerstoegang voor de resourcegroep van het Azure Migrate-project en de doelresourcegroep

Voor de volgende replicaties moet de aangemelde gebruiker de volgende rollen krijgen:

• Eigenaar of inzender voor de resourcegroep van het Azure Migrate-project en de doelresourcegroep

Naast de hierboven beschreven rollen heeft de aangemelde gebruiker de volgende machtiging nodig op abonnementsniveau - Microsoft.Resources/subscriptions/resourceGroups/read

Gegevensintegriteit

Er zijn twee fasen in elke replicatiecyclus die zorgt voor gegevensintegriteit tussen de on-premises schijf (bronschijf) en de replicaschijf in Azure (doelschijf).

1. Eerst wordt gecontroleerd of elke sector die is gewijzigd in de bronschijf wordt gerepliceerd naar de doelschijf. Validatie wordt uitgevoerd met bitmaps. De bronschijf is onderverdeeld in sectoren van 512 bytes. Elke sector in de bronschijf wordt toegewezen aan een beetje in de bitmap. Wanneer de gegevensreplicatie wordt gestart, wordt bitmap gemaakt voor alle gewijzigde blokken (in deltacyclus) op de bronschijf die moet worden gerepliceerd. Op dezelfde manier wordt er een bitmap gemaakt wanneer de gegevens worden overgedragen naar de Azure-doelschijf. Zodra de gegevensoverdracht is voltooid, vergelijkt de cloudservice de twee bitmaps om ervoor te zorgen dat er geen gewijzigd blok wordt gemist. Als er geen overeenkomst is tussen de bitmaps, wordt de cyclus als mislukt beschouwd. Aangezien elke cyclus opnieuw wordt gesynchroniseerd, wordt de niet-overeenkomende cyclus in de volgende cyclus opgelost.

2. Vervolgens zorgen we ervoor dat de gegevens die naar de Azure-schijven worden overgebracht, hetzelfde zijn als de gegevens die zijn gerepliceerd vanaf de bronschijven. Elk gewijzigd blok dat wordt geüpload, wordt gecomprimeerd en versleuteld voordat het wordt geschreven als een blob in het logboekopslagaccount. We berekenen de controlesom van dit blok vóór compressie. Deze controlesom wordt opgeslagen als metagegevens, samen met de gecomprimeerde gegevens. Bij de decompressie wordt de controlesom voor de gegevens berekend en vergeleken met de controlesom die in de bronomgeving is berekend. Als er sprake is van een onjuiste overeenkomst, worden de gegevens niet naar de Azure-schijven geschreven en wordt de cyclus als mislukt beschouwd. Aangezien elke cyclus opnieuw wordt gesynchroniseerd, wordt de niet-overeenkomende cyclus in de volgende cyclus opgelost.

Beveiliging

Het Azure Migrate-apparaat comprimeert gegevens en versleutelt deze voordat het wordt geüpload. Gegevens worden verzonden via een beveiligd communicatiekanaal via https en maken gebruik van TLS 1.2 of hoger. Bovendien versleutelt Azure Storage uw gegevens automatisch wanneer deze worden bewaard in de cloud (versleuteling-at-rest).

Replicatiestatus

Wanneer een VIRTUELE machine replicatie ondergaat (gegevenskopie), zijn er enkele mogelijke statussen:

• Initiële replicatie in de wachtrij: de VM wordt in de wachtrij geplaatst voor replicatie (of migratie), omdat er mogelijk andere VM's zijn die de on-premises resources gebruiken (tijdens replicatie of migratie). Zodra de resources gratis zijn, wordt deze VM verwerkt.
• Initiële replicatie wordt uitgevoerd: de VM wordt gepland voor de initiële replicatie.
• Initiële replicatie: de VM ondergaat de initiële replicatie. Wanneer de VM de initiële replicatie ondergaat, kunt u niet doorgaan met de testmigratie en migratie. In deze fase kunt u de replicatie alleen stoppen.
• Initiële replicatie (x%): de initiële replicatie is actief en wordt uitgevoerd met x%.
• Deltasynchronisatie: de VIRTUELE machine ondergaat mogelijk een deltareplicatiecyclus waarmee het resterende gegevensverloop sinds de laatste replicatiecyclus wordt gerepliceerd.
• Onderbreken wordt uitgevoerd: de VIRTUELE machine ondergaat een actieve replicatiecyclus voor delta's en wordt in enige tijd onderbroken.
• Onderbroken: de replicatiecycli zijn onderbroken. De replicatiecycli kunnen worden hervat door een cv-replicatiebewerking uit te voeren.
• Hervat in de wachtrij: de VM wordt in de wachtrij geplaatst om de replicatie te hervatten, omdat er momenteel andere VM's zijn die de on-premises resources gebruiken.
• Hervatten wordt uitgevoerd (x%): de replicatiecyclus wordt hervat voor de VIRTUELE machine en is met x% voortgezet.
• Replicatie stoppen die wordt uitgevoerd: het opschonen van replicatie wordt uitgevoerd. Wanneer u de replicatie stopt, worden de tussenliggende beheerde schijven (seed-schijven) die tijdens de replicatie zijn gemaakt, verwijderd. Meer informatie.
• Volledige migratie wordt uitgevoerd: het opschonen van de migratie wordt uitgevoerd. Wanneer u de migratie voltooit, worden de tussenliggende beheerde schijven (seed-schijven) die tijdens de replicatie zijn gemaakt, verwijderd. Meer informatie.
• – : Wanneer de VM is gemigreerd en/of wanneer u de replicatie hebt gestopt, verandert de status in '-'. Zodra u de replicatie stopt/de migratie voltooit en de bewerking is voltooid, wordt de VIRTUELE machine verwijderd uit de lijst met replicerende machines. U vindt de virtuele machine op het tabblad virtuele machines in de wizard Repliceren.

Overige statussen

• Initiële replicatie is mislukt: de initiële gegevens kunnen niet worden gekopieerd voor de virtuele machine. Volg de richtlijnen voor herstel om dit op te lossen.
• Herstellen in behandeling: er is een probleem opgetreden in de replicatiecyclus. U kunt de koppeling selecteren om inzicht te hebben in mogelijke oorzaken en acties om te herstellen (indien van toepassing). Als u ervoor hebt gekozen om replicatie automatisch te herstellen door Ja te selecteren toen u replicatie van de VIRTUELE machine hebt geactiveerd, probeert het hulpprogramma deze voor u te herstellen. Selecteer anders de virtuele machine en selecteer Replicatie herstellen. Als u niet hebt gekozen voor automatisch herstellen van replicatie of als de bovenstaande stap niet voor u werkte, stopt u de replicatie voor de virtuele machine, stelt u de gewijzigde bloktracking op de virtuele machine opnieuw in en configureert u de replicatie opnieuw.
• Replicatie in de wachtrij herstellen: de VM wordt in de wachtrij geplaatst voor replicatieherstel, omdat er andere VM's zijn die de on-premises resources gebruiken. Zodra de resources gratis zijn, wordt de VIRTUELE machine verwerkt voor herstelreplicatie.
• Opnieuw synchroniseren (x%): de VM ondergaat een hersynchronisatie van gegevens. Dit kan gebeuren als er een probleem/niet overeenkomt tijdens de gegevensreplicatie.
• Replicatie stoppen/volledige migratie is mislukt: selecteer de koppeling om inzicht te hebben in de mogelijke oorzaken van fouten en acties die moeten worden hersteld (indien van toepassing).

Notitie

Sommige VM's worden in de wachtrij geplaatst om minimale impact op de bronomgeving te garanderen vanwege het IOPS-verbruik van de opslag. Deze VM's worden verwerkt op basis van de planningslogica, zoals beschreven in de volgende sectie.

Migratie-/testmigratiestatus

• Testmigratie in behandeling: de VM bevindt zich in de replicatiefase van verschillen en u kunt nu testmigratie (of migratie) uitvoeren.
• Testmigratie opschonen in behandeling: nadat de testmigratie is voltooid, voert u een testmigratie op om kosten in Azure te voorkomen.
• Gereed om te migreren: de VIRTUELE machine is gereed om te worden gemigreerd naar Azure.
• Migratie wordt in de wachtrij geplaatst: de VIRTUELE machine wordt in de wachtrij geplaatst voor migratie, omdat er andere VM's zijn die de on-premises resources gebruiken tijdens replicatie (of migratie). Zodra de resources gratis zijn, wordt de VIRTUELE machine verwerkt.
• Testmigratie/migratie wordt uitgevoerd: de VM ondergaat een testmigratie/migratie. U kunt de koppeling selecteren om de lopende migratietaak te controleren.
• Datum, tijdstempel: de migratie-/testmigratiedatum en tijdstempel.
• –: De initiële replicatie wordt uitgevoerd. U kunt een migratie of testmigratie uitvoeren nadat het replicatieproces is overgestapt op een deltasynchronisatiefase (incrementele replicatie).

Overige statussen

• Voltooid met informatie: De migratie-/testmigratietaak is voltooid met informatie. U kunt de koppeling selecteren om de laatste migratietaak te controleren op mogelijke oorzaken en acties om te herstellen (indien van toepassing).
• Mislukt: de migratie-/testmigratietaak is mislukt. U kunt de koppeling selecteren om de laatste migratietaak te controleren op mogelijke oorzaken en acties die moeten worden hersteld.

Planningslogica

Initiële replicatie wordt gepland wanneer replicatie is geconfigureerd voor een VIRTUELE machine. Dit wordt gevolgd door incrementele replicaties (deltareplicaties).

Delta-replicatiecycli worden als volgt gepland:

• De eerste deltareplicatiecyclus wordt onmiddellijk gepland nadat de initiële replicatiecyclus is voltooid
• Volgende deltareplicatiecycli worden gepland volgens de volgende logica: min[max[1 uur, (vorige tijd van deltareplicatiecyclus/2)], 12 uur]

De volgende deltareplicatie wordt dus niet eerder dan één uur en uiterlijk 12 uur gepland. Als een VIRTUELE machine bijvoorbeeld vier uur duurt voor een deltareplicatiecyclus, wordt de volgende deltareplicatiecyclus in twee uur gepland en niet in het volgende uur.

Notitie

De planningslogica verschilt nadat de initiële replicatie is voltooid. De eerste deltacyclus wordt onmiddellijk gepland nadat de initiële replicatie is voltooid en de volgende cycli volgen de planningslogica die hierboven wordt beschreven.

• Wanneer u migratie activeert, wordt vóór de migratie een replicatiecyclus voor verschillen op aanvraag (replicatiecyclus vóór failover delta) uitgevoerd voor de VIRTUELE machine.

Prioriteitsaanduiding van VM's voor verschillende fasen van replicatie

• Doorlopende VM-replicaties krijgen prioriteit boven geplande replicaties (nieuwe replicaties)
• De cyclus vóór failover (replicatie van verschillen op aanvraag) heeft de hoogste prioriteit gevolgd door de initiële replicatiecyclus. De deltareplicatiecyclus heeft de minste prioriteit.

Wanneer een migratiebewerking wordt geactiveerd, wordt de replicatiecyclus op aanvraag voor de VIRTUELE machine gepland en worden andere lopende replicaties teruggezet als ze concurreren voor resources.

Beperkingen:

We gebruiken de volgende beperkingen om ervoor te zorgen dat we de IOPS-limieten voor de SAN's niet overschrijden.

• Elk Azure Migrate-apparaat ondersteunt de replicatie van 52 schijven parallel
• Elke ESXi-host ondersteunt 8 schijven. Elke ESXi-host heeft een NFC-buffer van 32 MB. We kunnen dus 8 schijven op de host plannen (elke schijf neemt 4 MB buffer in beslag voor IR, DR).
• Elk gegevensarchief kan maximaal 15 momentopnamen van schijven bevatten. De enige uitzondering hierop is wanneer er meer dan 15 schijven aan een VM zijn gekoppeld.

Uitschalen van replicatie

Azure Migrate ondersteunt gelijktijdige replicatie van 500 virtuele machines. Wanneer u van plan bent om meer dan 300 virtuele machines te repliceren, moet u een uitschaalapparaat implementeren. Het uitschaalapparaat is vergelijkbaar met een primair Azure Migrate-apparaat, maar bestaat alleen uit een gatewayagent om gegevensoverdracht naar Azure te vergemakkelijken. In het volgende diagram ziet u de aanbevolen manier om het uitschaalapparaat te gebruiken.

U kunt het uitschaalapparaat op elk gewenst moment implementeren na het configureren van het primaire apparaat, maar is pas vereist als er 300 VIRTUELE machines gelijktijdig worden gerepliceerd. Wanneer er 300 VM's gelijktijdig worden gerepliceerd, moet u het uitschaalapparaat implementeren om door te gaan.

Replicatie stoppen/migratie voltooien

Wanneer u de replicatie stopt, worden de tussenliggende beheerde schijven (seed-schijven) die tijdens de replicatie zijn gemaakt, verwijderd. U kunt de replicatie alleen stoppen tijdens een actieve replicatie. U kunt volledige migratie selecteren om de replicatie te stoppen nadat de VM is gemigreerd.

De VM waarvoor de replicatie is gestopt, kan worden gerepliceerd door replicatie opnieuw in te schakelen. Als de virtuele machine is gemigreerd, kunt u de replicatie en migratie opnieuw hervatten.

Als best practice moet u altijd de migratie voltooien nadat de VIRTUELE machine is gemigreerd naar Azure om ervoor te zorgen dat er geen extra kosten in rekening worden gebracht voor opslagtransacties op de tussenliggende beheerde schijven (seed-schijven). In sommige gevallen zult u merken dat het stoppen van de replicatie tijd kost. Dit komt doordat wanneer u de replicatie stopt, de doorlopende replicatiecyclus wordt voltooid (alleen wanneer de VIRTUELE machine in deltasynchronisatie is) voordat de artefacten worden verwijderd.

Impact van verloop

We proberen de hoeveelheid gegevensoverdracht in elke replicatiecyclus te minimaliseren door de gegevens zoveel mogelijk te laten vouwen voordat we de volgende cyclus plannen. Omdat replicatie zonder agent in gegevens wordt gevouwen, is het verlooppatroon belangrijker dan de verloopsnelheid. Wanneer een bestand opnieuw en opnieuw wordt geschreven, heeft de snelheid niet veel invloed. Een patroon waarin elke andere sector wordt geschreven, veroorzaakt echter een hoog verloop in de volgende cyclus.

Beheer van replicatie

Beperking

U kunt de replicatiebandbreedte verhogen of verlagen met behulp van NetQosPolicy. Het AppNamePrefix dat in NetQosPolicy moet worden gebruikt, is 'GatewayWindowsService.exe'.

U kunt een beleid maken op het Azure Migrate-apparaat om replicatieverkeer van het apparaat te beperken door een beleid zoals deze te maken:

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

Notitie

Dit is van toepassing op alle replicerende VM's van het Azure Migrate-apparaat tegelijk.

U kunt ook de replicatiebandbreedte verhogen en verlagen op basis van een schema met behulp van het voorbeeldscript.

Venster Blackout

Azure Migrate biedt een op configuratie gebaseerd mechanisme waarmee klanten het tijdsinterval kunnen opgeven waarin ze niet willen dat replicaties worden voortgezet. Dit tijdsinterval wordt het blackout-venster genoemd. De noodzaak van een black-outvenster kan zich voordoen in meerdere scenario's, zoals wanneer de bronomgeving beperkt is of wanneer klanten alleen replicatie willen doorlopen tijdens niet-kantooruren, enzovoort.

Notitie

• De bestaande replicatiecycli aan het begin van het black-outvenster worden voltooid voordat de replicatie wordt onderbroken.
• Voor elke migratie die tijdens het black-outvenster wordt gestart, wordt de uiteindelijke replicatie niet uitgevoerd, waardoor de migratie mislukt.

Er kan een black-outvenster voor het apparaat worden opgegeven door het bestand te maken/bij te werken GatewayDataWorker.json in C:\ProgramData\Microsoft Azure\Config. Een typisch bestand zou van het formulier zijn:

{
    
    "BlackoutWindows": "List of blackout windows"
    
}

De lijst met black-outvensters is een door | gescheiden tekenreeks van de notatie DayOfWeek; StartTime; Duur". De duur kan worden opgegeven in dagen, uren en minuten. De blackoutvensters kunnen bijvoorbeeld worden opgegeven als:

{
    
    "BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h | Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"
    
}

De eerste waarde in het bovenstaande voorbeeld geeft een black-outvenster aan dat elke maandag om 7:00 uur lokale tijd (tijd op het apparaat) en 7 uur duurt.

Zodra de GatewayDataWorker.json met deze inhoud is gemaakt/bijgewerkt, moet de gatewayservice op het apparaat opnieuw worden opgestart om deze wijzigingen van kracht te laten worden.

In het uitschaalscenario respecteren het primaire apparaat en het uitschaalapparaat de blackoutvensters onafhankelijk van elkaar. Als best practice raden we u aan om de vensters consistent te houden tussen apparaten.

Volgende stappen

VMware-VM's migreren met migratie zonder agent.