Migrera on-premsiemaskiner med hjälp av Azure Site Recovery
Att tjänsten Azure Backup and Site Recovery, som namnet föreslår, ger oss möjlighet att ta backup på tjänster och maskiner oavsett om dessa körs i Azure eller on-premise tar vi nog som en självklarhet. Däremot har det inte alltid varit en självklarhet hur site recovery fungerar, varpå jag inspirerades till att göra detta blogginlägg.
Om vi börjar med att titta på hur det fungerar lokalt innan vi blandar in Azure så har det, sen Windows Server 2012, funnits en funktion i Hyper-V som kallas för Hyper-V Replica. Hyper-V Replica ger oss möjlighet till katastrofåterställning genom att replikera våra virtuella maskiner från en site till en annan över port 443. Detta med replikeringsintervaller av förändringar ner till var 30:e sekund. Därefter har man möjlighet att övervaka hälsa för replikeringen, konfigurera om den replikerade maskinen för att fungera med nätverket på den sekundära siten, testa failover och såklart initiera en failover.
När tjänsten site recovery först lanserades till Azure gav den mig, vid första anblick, falska förhoppningar eftersom jag trodde och hoppades att det skulle vara möjligt att replikera maskiner från on-premise och använda Azure som sekundär site. Detta var tyvärr inte möjligt, utan det enda som presenterades var utökade övervakningsmöjligheter för replikering mellan två siter.
Det har gått några år sen dess och numera är det möjligt att replikera våra maskiner till Azure som sekundär site, oavsett om dessa maskiner skulle vara fysiska maskiner, virtuella VMwaremaskiner eller Hyper-V maskiner. Så småningom kommer det även att vara möjligt att replikera maskiner mellan olika Azureprenumerationer. Vad som kanske är ännu mer intressant är att vi faktiskt kan använda denna tjänst för att migrera dessa maskiner till Azure.
Självklart finns det andra tillvägagångssätt för att migrera maskiner till Azure. Skulle vi välja att flytta virtuella diskar till Azure med exempelvis PowerShell och sedan skapa virtuella maskiner utifrån dessa så finns det en del begränsningar bland annat:
• Filformat: Endast .vhd, ej .vhdx
• Disktyp: Endast statisk, ej dynamisk disk
• Generation av Hyper-V VM: Endast generation 1
• Övrigt: Azure VM agent bör vara installerad och maskinen måste vara syspreppad
Visserligen kommer PowerShell att konvertera våra dynamiska diskar till statiska i processen, men inte mer än så. Ser vi till möjligheterna med Azure Site Recovery har vi inga av ovan nämnda begränsningar och kommer då använda Hyper-V Replica för Hyper-V VMs, vilket jag vill demonstrera nedan. Oavsett vilket tillvägagångssätt vi väljer bör vi se till att tillåta RDP-anslutningar samt installera VM agent för Azure på maskinerna som ska migreras.
1. Börja med att skapa ett Recovery Serivices vault som numera är en och samma tjänst.
2. När detta är skapat ska site recovery konfigureras. Kommande steg förutsätter att det redan finns ett virtuellt nätverk samt ett storage account skapat i Azure.
3. Första steget för att konfigurera site recovery är att ange vad som ska replikeras. Här kan man ange om maskinerna i fråga är fysiska eller virtuella samt vilken plattform (Hyper-V/VMware) dessa körs på. Man kan även replikera från en Azureprenumeration till en annan men denna funktion finns i skrivande stund endast som preview.
4. Beroende på vilket val man gör gällande vad det är som ska replikeras kommer man presenteras med olika typer av förberedelser. I detta fallet är Hyper-V valt och man ska då lägga till en Hyper-V Site som döps till lämpligt namn. Därefter ska Hyper-V-hosten förberedas genom att man installerar en Site Recovery Provider på denna och autentiserar mot detta recovery services.
5. Provider är installerad och konfigureras på Hyper-V-host.
6. Host är tillagd i Azure och det är dags att specificera vilket storage account och nätverk som de virtuella maskinerna ska anslutas till i Azure.
7. Koppla/skapa en policy för hur replikering ska ske. Eftersom vi använder Hyper-V Replica kan vi ha en kopieringsfrekvens på 30 sekunder, 5 minuter eller 30 minuter. Det som presenteras på ovan bild är standardvärdena. Femte och sista steget uppmanar administratören att kontrollera att man har den bandbredd som krävs för replikering, där det även finns en länk till ett verktyg för att utvärdera bandbredd.
8. Efter vi talat om för Azure vad som ska replikeras och lagt till site samt host är det möjligt att påbörja replikering. I ovan skärmdump är vår ovan tillagda site vald samt vilket storage account och nätverk som ska användas. En virtuell maskin är sedan vald och vi har talat om för Azure vilket operativsystem som är installerat på denna maskin samt vilka diskar som ska replikeras. Slutligen anger vi vilken replication policy som ska användas.
9. Eftersom vår replication policy angav att replikering ska påbörjas omgående kommer vi se att hosten direkt påbörjar en första full replikering, därefter kommer självklart endast förändringarna att replikeras.
10. Första replikering är slutförd och maskinen i fråga syns i Azure och med hälsostatus ”OK”, vilket den kommer ha så länge 80% av replikeringscyklerna har genomförts problemfritt. Nu kan vi påbörja migrering.
11. Failover påbörjas med valet att (on-premise) VM ska stängas av för att all data ska kunna replikeras över till Azure.
12. Failover slutförd och vi presenteras med möjligheten att välja ”Complete Migration” och maskinen kommer då att flyttas från vårt recovery services vault och vår migrering är slutförd.
