Centric connect.engage.succeed

Van ESX naar Azure

Geschreven door Redactie Craft - 25 april 2016

Redactie Craft
Vorig jaar was ik betrokken bij een groot migratieproject, waarin wij 40 ESX VM’s (~ 4,5 TB) naar Azure hebben gemigreerd. Deze VM’s zijn onderdeel van de Ontwikkel, Test en Acceptatie (OTA-)omgeving van de klant. In deze blog ga ik dieper in op hoe wij de ESX-to-Azure migratie hebben uitgevoerd en wat onze ervaringen zijn.

De migratie levert de organisatie de volgende voordelen op:

  • VM’s kunnen uitgezet worden als ze niet gebruikt worden (dus geen compute kosten, alleen storage)
  • Voor ontwikkel- en testdoeleinden is het mogelijk snel op en af te schalen, zonder investeringen in extra capaciteit

Infrastructuur setup

Onderstaande afbeelding is een weergave van de infrastructuur, waarop we de migratie hebben uitgevoerd. In mijn blog houd ik de fasen van de conversie aan.

Infrastructuur setup

Voor de conversie van de vmdk’s gebruikten wij het product 5Nine V2V Easy converter. Deze software was geïnstalleerd op twee laptops (8GB memory en 1 TB SSD) met HyperV role. De SSD’s versnellen de migratie aanzienlijk (> 50%), omdat tijdens het Add-AzureVhd-commando op de vhd’s een MD5 hash calculation en Empty Block Detection wordt gedaan.

Voor dit commando is performance van disk de beperkende factor. De laptops waren met een 1 Gbps aangesloten op het netwerk voor een maximale throughput vanaf ESX-hosts naar het internet.

Voorbereiding

Voordat de ESX VM geconverteerd kon worden, troffen we de volgende voorbereidingen:

  • verwijderen snapshots
    Verwijderen snapshots 
  • inloggen op de server met domain administrator account in verband met cached credentials
  • verwijderen van VM Tools
    verwijderen van VM Tools 
    Met het verwijderen van de VM Tools worden ook de vmxnet3-drivers verwijderd en kun je alleen nog inloggen op de server met cached credentials of local administrator account!
  • Zet de VM uit met dit commando: shutdown /f /s /t 00. Omdat de VM Tools niet meer draaien, is een gecontroleerde shutdown via vCenter niet mogelijk.

Conversie naar ESX – HyperV

Zodra de VM’s waren voorbereid op de migratie konden we de migratie starten op de laptops. Om een beeld te geven van die conversie heb ik de screenshots hieronder toegevoegd.

Screenshots conversie naar ESX - HyperV

De volgende opmerkingen zijn van toepassingen bij de conversie van ESX-HyperV:

  • De 59v2v-software maakt rechtstreeks connectie met een ESX host. Als extra stap in de voorbereiding hadden we iedere batch gemigreerd naar een specifieke host binnen het ESX-cluster, zodat vooraf duidelijk was waar de VM draaide.
  • Omdat tijdens de conversie HyperV slechts een stepping stone is richting Azure, hebben we de configuratie van de Target VM verder niet gespecificeerd. Als je een ESX-to-HyperV migratie zou doen, kun je hier de configuratie van HyperV VM verder specificeren.
  • LET OP: Voor upload naar Azure is VHD-formaat nodig. DESELECTEER VHDX! Je kunt dit binnen HyperV nog wel converteren, maar is zonde van de extra tijd.

De 59 V2V-software werkt in twee stadia. In het eerste stadium worden de vmdk’s (en de vmx…) gedownload naar een temporary path op de lokale machine. In het tweede stadium worden de kopieën in de temporary path geconverteerd en rechtstreeks weggeschreven naar HyperV. Tijdens de migratie was de gemiddelde conversiesnelheid ongeveer 50 GB per uur per VM. Per laptop konden we maximaal 3 VM’s parallel converteren en zo maximaal 300 GB per uur halen.

Zodra de conversie was afgerond, was deze zichtbaar in de HyperV console en konden we de VM starten. Via de HyperV-manager maakten we connectie naar de console en logden we in op de VM met het cached credentials- of local administrator-account.

Voor Windows 2003 en 2008 servers dienen de HyperV integration Services handmatig geïnstalleerd te worden door de Integration Services-disk te koppelen via de menu bar van het Console Window.

Handmatig installeren HyperV interegration Services

Doe dit na het inloggen, zodat de autorun.inf werkt. Integration Setup start automatisch. Wel zo handig want de muis werkt niet door het ontbreken van de drivers .

Voor Windows 2003 VM’s moet je ook het Windows Management Framework Core-pakket installeren. En in sommige gevallen ook .NET Frame work 2.0 SP1. Ik had de downloads op een aparte vhd gezet, zodat we deze aan de VM konden koppelen en we vanaf de disk de onderdelen konden installeren, in plaats van iedere keer te downloaden.

VERGEET NIET de .vhd weer te ontkoppelen voordat je de VM upload, anders wordt deze ook geupload naar Azure!

Upload to Azure

Nadat de conversie was afgerond en de VM in HyperV beschikbaar was, konden we starten met de upload van de vhd’s naar de Azure subscription. Deze subscription was in een eerder stadium al geconfigureerd met:

  • storage account
  • geconfigureerd Azure Vnet gekoppeld via SSL VPN met On premise infrastructuur
  • subscription administrator rechten om de VM’s aan te kunnen maken

Voor het creëren van VM’s in de Azure subscription hebben we per VM de volgende stappen uitgevoerd:

  • upload van de vhd’s als blobs in het Azure Storage-account van de subscription (Azure-Uploadvhd)
  • definiëren van de blobs als Azuredisk (Add-AzureDisk)
  • aanmaken van een AzureVM-definitie (New-AzureVMConfig)
  • toevoegen van de datadisken aan de AzureVM-definitie (Add-AzureDataDisk)
  • creëren van de Azure VM op basis van de Azure VM-definitie (New-AzureVM)
  • toekennen van een statisch IP-adres aan de VM (Set-AzureStaticVNetIP)

Om al deze stappen te automatiseren, werd er via Powershell per batch een uploadscript gegenereerd dat er als volgt uitzag:

Add-AzureVhd -LocalFilePath C:\HyperV\T-NLDCA-APL20\T-NLDCA-APL20.vhd -Destination http://StorageAccount01.blob.core.windows.net/t-nldca-apl20/t-nldca-apl20.vhd -NumberOfUploaderThreads 15 
Add-AzureDisk -OS Windows -MediaLocation http://StorageAccount01.blob.core.windows.net/t-nldca-apl20/t-nldca-apl20.vhd -DiskName t-nldca-apl20.vhd 
Add-AzureVhd -LocalFilePath C:\HyperV\T-NLDCA-APL20\00001-T-NLDCA-APL20_1.vhd -Destination http://StorageAccount01.blob.core.windows.net/t-nldca-apl20/t-nldca-apl20_1.vhd -NumberOfUploaderThreads 15 
Add-AzureDisk -MediaLocation http://StorageAccount01.blob.core.windows.net/t-nldca-apl20/t-nldca-apl20_1.vhd -DiskName t-nldca-apl20_1.vhd 
$VMConfig = New-AzureVMConfig -Name t-nldca-apl20 -InstanceSize Medium -DiskName t-nldca-apl20.vhd
$VMConfig | Add-AzureDataDisk -Import t-nldca-apl20_1.vhd -LUN 1 
$VMConfig | Set-AzureSubnet azure-subnet01 
New-AzureVM -ServiceName Azure-Service -VMs $VMConfig 
$VMNew = get-azurevm -ServiceName Azure-Service -Name t-nldca-apl20
Set-AzureStaticVNetIP -IPAddress 10.112.3.18 -VM $VMNew | Update-AzureVM 

Meest belangrijke cmdlet in het script is Add-AzureVHD en dat werkt in drie stappen:

  1. Als eerste stap wordt de gehele disk gescand om een MD5 hash te berekenen. Dit wordt gedaan om uiteindelijk de integriteit van de vhd in Azure te kunnen bepalen.
  2. Als tweede stap wordt de gehele disk nog een keer gescand om het aantal empty data blocks te bepalen. Zo worden alleen de blocks die data bevatten via internet verstuurd.
  3. Tenslotte wordt de data (exclusief empty blocks) geupload naar Azure.

Dit ziet er dan als volgt uit:

Data upload naar Azure

Om de doorlooptijden van de migraties per disk in te schatten, hebben we uiteindelijk de volgende waarden gebruikt:

Waarden doorlooptijden migraties
MD5_Check_snelheid 40 MB/sec 144 GB/uur
Emptyblock_check_snelheid 30 MB/sec 108 GB/uur
UploadAzure_snelheid 25 MB/sec 90 GB/uur

Bij Add-AzureVhd cmdlet kun je met de parameter NumberUploadThreads de doorvoersnelheid tweaken. Iedere uploaderthread is ongeveer 30 Mbps en de defaultwaarde van de cmdlet is 8 (= 240 Mbps). Op een firewall ziet dat er als volgt uit:

Firewall

Tijdens de migratie gebruikten we NumberUploadThreads 15 waarmee we dan de internetverbinding optimaal gebruikten (2 laptops * 15 threads * 30 Mbps = 900 Mbps maximaal). Omdat de migratie tijdens de kerstvakantie werd uitgevoerd, konden we de volledige bandbreedte benutten.

Na het afronden van het script ziet de configuratie van de VM in de Azure portal er als volgt uit:

Configuratie VM in Azure portal

Wil jij Craft blogs volgen over jouw vakgebied? Schrijf je in voor de Craft-update.

Tags:Cloud

     
Reacties
  • IP regio West
    Aniel Balgobiend
    28 april 2016
    Interessante blog!
  • IP Regio West
    Cor Groen
    23 juni 2016
    Thanx Dennis! Interessant!
  • IT
    Jack de Vries
    25 augustus 2016
    Goed geschreven blog, ook een interessant en zeer actueel onderwerp. Maar wat een omslachtige migratie methode is hier gebruikt! Met zo te zien ook veel downtime voor de klant. Ik zou adviseren de volgende keer Azure Site Recovery te gebruiken.

    Ook is een migratie naar classic VM's (zoals te zien is in de screenshots) een gemiste kans. Je moet binnenkort dan alsnog naar ARM.
  • Agrifirm
    Remy
    27 augustus 2016
    Hopelijk hebben jullie de vm's ook verdeeld over meerdere storageaccounts. Komt niet in het verhaal aan bod maar absoluut een aanrader weet ik inmiddels uit ervaring.
Schrijf een reactie
  • Captcha image
  • Verzenden