Azure Premium Storage gebruiken met SQL Server op virtuele machines

Overzicht

Azure Premium SSD's vormen de volgende generatie opslag die lage latentie en hoge doorvoer-IO biedt. Het werkt het beste voor belangrijke I/O-intensieve workloads, zoals SQL Server op IaaS Virtual Machines.

Dit artikel bevat planning en richtlijnen voor het migreren van een virtuele machine waarop SQL Server wordt uitgevoerd voor het gebruik van Premium Storage. Dit omvat azure-infrastructuur (netwerken, opslag) en stappen voor gast-Windows-VM's. In het voorbeeld in de bijlage ziet u een volledige end-to-end-migratie van het verplaatsen van grotere VM's om te profiteren van verbeterde lokale SSD-opslag met PowerShell.

Het is belangrijk om inzicht te hebben in het end-to-end-proces voor het gebruik van Azure Premium Storage met SQL Server op IAAS-VM's. Dit omvat:

• Identificatie van de vereisten voor het gebruik van Premium Storage.
• Voorbeelden van het implementeren van SQL Server op IaaS in Premium Storage voor nieuwe implementaties.
• Voorbeelden van het migreren van bestaande implementaties, zowel zelfstandige servers als implementaties met behulp van SQL AlwaysOn-beschikbaarheidsgroepen.
• Mogelijke migratiemethoden.
• Volledig end-to-end-voorbeeld met azure-, Windows- en SQL Server-stappen voor de migratie van een bestaande AlwaysOn-implementatie.

Zie SQL Server in Azure Virtual Machinesvoor meer achtergrondinformatie over SQL Server in Azure Virtual Machines.

Auteur: Daniel Sol Technische Beoordelaars: Luis Carlos Vargas Herring, Sanjay Mishra, Pravin Mital, Juergen Thomas, Gonzalo Ruiz.

Vereisten voor Premium Storage

Er zijn verschillende vereisten voor het gebruik van Premium Storage.

Machinegrootte

Voor het gebruik van Premium Storage moet u virtuele machines (VM) uit de DS-serie gebruiken. Als u eerder geen DS Series-machines in uw cloudservice hebt gebruikt, moet u de bestaande VM verwijderen, de gekoppelde schijven behouden en vervolgens een nieuwe cloudservice maken voordat u de VM opnieuw maakt als DS*-rolgrootte. Zie Virtuele machine en cloudservicegrootten voor Azurevoor meer informatie over grootten van virtuele machines.

Clouddiensten

U kunt alleen DS*-VM's gebruiken met Premium Storage wanneer ze worden gemaakt in een nieuwe cloudservice. Als u SQL Server AlwaysOn in Azure gebruikt, verwijst de AlwaysOn-listener naar het IP-adres van azure interne of externe load balancer dat is gekoppeld aan een cloudservice. In dit artikel wordt uitgelegd hoe u migreert terwijl de beschikbaarheid in dit scenario behouden blijft.

Regionale VNETS

Voor DS*-VM's moet u het virtuele netwerk (VNET) configureren dat als regionale host fungeert voor uw VM's. Dit 'verbreedt' het VNET om de grotere VM's in andere clusters in te richten en communicatie tussen deze clusters mogelijk te maken. In de volgende schermopname toont de gemarkeerde locatie regionale VNET's, terwijl in het eerste resultaat een 'smal' VNET wordt weergegeven.

U kunt een Microsoft-ondersteuningsticket indienen om te migreren naar een regionaal VNET. Vervolgens brengt Microsoft een wijziging aan. Wijzig de eigenschap AffinityGroup in de netwerkconfiguratie om de migratie naar regionale VNET's te voltooien. Exporteer eerst de netwerkconfiguratie in PowerShell en vervang de eigenschap AffinityGroup in het element VirtualNetworkSite door een eigenschap Location. Geef Location = XXXX op waar XXXX een Azure-regio is. Importeer vervolgens de nieuwe configuratie.

Denk bijvoorbeeld aan de volgende VNET-configuratie:

<VirtualNetworkSite name="danAzureSQLnet" AffinityGroup="AzureSQLNetwork">
<AddressSpace>
  <AddressPrefix>10.0.0.0/8</AddressPrefix>
  <AddressPrefix>172.16.0.0/12</AddressPrefix>
</AddressSpace>
<Subnets>
...
</VirtualNetworkSite>

Als u dit wilt verplaatsen naar een regionaal VNET in Europa - west, wijzigt u de configuratie in het volgende:

<VirtualNetworkSite name="danAzureSQLnet" Location="West Europe">
<AddressSpace>
  <AddressPrefix>10.0.0.0/8</AddressPrefix>
  <AddressPrefix>172.16.0.0/12</AddressPrefix>
</AddressSpace>
<Subnets>
...
</VirtualNetworkSite>

Opslagrekeningen

U moet een nieuw opslagaccount maken dat is geconfigureerd voor Premium Storage. Houd er rekening mee dat het gebruik van Premium Storage is ingesteld in het opslagaccount, niet op afzonderlijke VHD's, maar wanneer u een VM uit de DS*-serie gebruikt, kunt u VHD's koppelen vanuit Premium- en Standard Storage-accounts. U kunt dit overwegen als u de OS VHD niet naar het Premium Storage-account wilt zetten.

De volgende opdracht New-AzureStorageAccountPowerShell met de "Premium_LRS" Type maakt een Premium Storage-account:

$newstorageaccountname = "danpremstor"
New-AzureStorageAccount -StorageAccountName $newstorageaccountname -Location "West Europe" -Type "Premium_LRS"   

Cache-instellingen voor VHD's

Het belangrijkste verschil tussen het maken van schijven die deel uitmaken van een Premium Storage-account, is de instelling voor de schijfcache. Voor SQL Server Data-volumeschijven is het raadzaam om 'Leescaching' te gebruiken. Voor transactielogboekvolumes moet de instelling voor de schijfcache worden ingesteld op 'Geen'. Dit verschilt van de aanbevelingen voor Standard Storage-accounts.

Zodra de VHD's zijn gekoppeld, kan de cache-instelling niet meer worden gewijzigd. U moet de VHD loskoppelen en opnieuw koppelen met een bijgewerkte cache-instelling.

Windows-opslagruimten

U kunt Windows-opslagruimten gebruiken zoals u deed met eerdere Standard Storage. Hiermee kunt u een virtuele machine migreren die al gebruikmaakt van Opslagruimten. In het voorbeeld in bijlage (stap 9 en vooruit) ziet u de PowerShell-code voor het extraheren en importeren van een virtuele machine met meerdere gekoppelde VHD's.

Opslaggroepen zijn gebruikt met een Standard Azure-opslagaccount om de doorvoer te verbeteren en de latentie te verminderen. Mogelijk vindt u waarde in het testen van opslaggroepen met Premium Storage voor nieuwe implementaties, maar ze voegen wel extra complexiteit toe met de opslaginstallatie.

Bepalen welke virtuele Azure-schijven zijn toegewezen aan opslaggroepen

Omdat er verschillende aanbevelingen voor cache-instellingen zijn voor gekoppelde VHD's, kunt u besluiten om de VHD's te kopiëren naar een Premium Storage-account. Wanneer u ze echter opnieuw aan de nieuwe VM van de DS-serie wilt koppelen, moet u mogelijk de cache-instellingen wijzigen. Het is eenvoudiger om de aanbevolen cache-instellingen van Premium Storage toe te passen wanneer u afzonderlijke VHD's hebt voor de SQL-gegevensbestanden en logboekbestanden (in plaats van één VHD die beide bevat).

Als u Echter Windows-opslagruimten gebruikt die bestaan uit meerdere VHD's, moet u uw oorspronkelijke scripts bekijken om te bepalen welke gekoppelde VHD's zich in welke specifieke pool bevinden, zodat u de cache-instellingen dienovereenkomstig kunt instellen voor elke schijf.

Als u geen oorspronkelijk script hebt om aan te geven welke VHD's aan de opslaggroep zijn toegewezen, kunt u de volgende stappen gebruiken om de toewijzing van de schijf-/opslaggroep te bepalen.

Voer voor elke schijf de volgende stappen uit:

1. Haal een lijst op met schijven die zijn gekoppeld aan de VIRTUELE machine met de opdracht Get-AzureVM:

Get-AzureVM -ServiceName <servicename> -Name <vmname> | Get-AzureDataDisk

1. Noteer de schijfnaam en LUN.

   

2. Extern bureaublad in de virtuele machine. Ga vervolgens naar Computerbeheer | Apparaatbeheer | schijfstations. Bekijk de eigenschappen van elk van de 'Microsoft Virtual Disks'

   

3. Het LUN-nummer hier is een referentie naar het LUN-nummer dat u opgeeft bij het koppelen van de VHD aan de VM.

4. Ga voor 'Microsoft Virtual Disk' naar het tabblad Details, ga vervolgens in de lijst Eigenschappen naar stuurprogrammasleutel. Noteer in de waardede verschuiving, die 0002 is in de volgende schermopname. De 0002 geeft de PhysicalDisk2 aan waarnaar de opslaggroep verwijst.

   

5. Exporteer de gekoppelde schijven voor elke opslagpool:

Get-StoragePool -FriendlyName AMS1pooldata | Get-PhysicalDisk

U kunt deze informatie nu gebruiken om gekoppelde VHD's te koppelen aan fysieke schijven in opslaggroepen.

Nadat u VHD's hebt toegewezen aan fysieke schijven in opslaggroepen, kunt u ze vervolgens loskoppelen en kopiëren naar een Premium Storage-account en deze vervolgens koppelen met de juiste cache-instelling. Zie het voorbeeld in de Bijlage, stap 8 tot en met 12. Deze stappen laten zien hoe u een vm-gekoppelde VHD-schijfconfiguratie kunt extraheren naar een CSV-bestand, de VHD's kopieert, de cache-instellingen voor de schijfconfiguratie wijzigt en ten slotte de VIRTUELE machine opnieuw implementeert als een VM uit de DS-serie met alle gekoppelde schijven.

VM-opslagbandbreedte en VHD-opslagdoorvoer

De hoeveelheid opslagprestaties is afhankelijk van de opgegeven DS*-VM-grootte en de VHD-grootten. De VM's hebben verschillende vergoedingen voor het aantal VHD's dat kan worden gekoppeld en de maximale bandbreedte die ze ondersteunen (MB/s). Zie Virtuele machine en cloudservicegrootten voor Azurevoor de specifieke bandbreedtenummers.

Verhoogde IOPS worden bereikt met grotere schijven. U moet dit overwegen wanneer u nadenkt over uw migratiepad. Zie de tabel voor IOPS en schijftypenvoor meer informatie.

Houd er ten slotte rekening mee dat VM's verschillende maximale schijfbandbreedten hebben die ze ondersteunen voor alle gekoppelde schijven. Onder hoge belasting kunt u de maximale schijfbandbreedte die beschikbaar is voor die VM-rolgrootte, verzadigen. Een Standard_DS14 ondersteunt bijvoorbeeld maximaal 512 MB/s; Daarom kunt u met drie P30-schijven de schijfbandbreedte van de VIRTUELE machine verzadigen. In dit voorbeeld kan de doorvoerlimiet echter worden overschreden, afhankelijk van de combinatie van lees- en schrijf-IO's.

Nieuwe implementaties

In de volgende twee secties ziet u hoe u VIRTUELE SQL Server-machines kunt implementeren in Premium Storage. Zoals eerder vermeld, hoeft u de besturingssysteemschijf niet noodzakelijkerwijs op Premium-opslag te plaatsen. U kunt ervoor kiezen dit te doen als u van plan bent om intensieve IO-workloads op de VHD van het besturingssysteem uit te voeren.

In het eerste voorbeeld wordt het gebruik van bestaande Azure Gallery Afbeeldingen gedemonstreerd. In het tweede voorbeeld ziet u hoe u een aangepaste VM-afbeelding gebruikt die u in een bestaand standaardopslagaccount hebt.

Een nieuwe virtuele machine maken met Premium Storage en Galerie-afbeelding

In het onderstaande voorbeeld ziet u hoe u de VHD van het besturingssysteem op premium-opslag plaatst en Premium Storage-VHD's koppelt. U kunt de besturingssysteemschijf echter ook in een Standard Storage-account plaatsen en vervolgens VHD's koppelen die zich in een Premium Storage-account bevinden. Beide scenario's worden gedemonstreerd.

$mysubscription = "DansSubscription"
$location = "West Europe"

#Set up subscription
Set-AzureSubscription -SubscriptionName $mysubscription
Select-AzureSubscription -SubscriptionName $mysubscription -Current  

Stap 1: Een Premium Storage-account maken

#Create Premium Storage account, note Type
$newxiostorageaccountname = "danspremsams"
New-AzureStorageAccount -StorageAccountName $newxiostorageaccountname -Location $location -Type "Premium_LRS"  

Stap 2: Een nieuwe cloudservice maken

$destcloudsvc = "danNewSvcAms"
New-AzureService $destcloudsvc -Location $location

Stap 3: Een VIP voor cloudservices reserveren (optioneel)

#check exisitng reserved VIP
Get-AzureReservedIP

$reservedVIPName = "sqlcloudVIP"
New-AzureReservedIP –ReservedIPName $reservedVIPName –Label $reservedVIPName –Location $location

Stap 4: Een VM-container maken

#Generate storage keys for later
$xiostorage = Get-AzureStorageKey -StorageAccountName $newxiostorageaccountname

##Generate storage acc contexts
$xioContext = New-AzureStorageContext –StorageAccountName $newxiostorageaccountname -StorageAccountKey $xiostorage.Primary   

#Create container
$containerName = 'vhds'
New-AzureStorageContainer -Name $containerName -Context $xioContext

Stap 5: besturingssysteem-VHD plaatsen op Standard of Premium Storage

#NOTE: Set up subscription and default storage account which is used to place the OS VHD in

#If you want to place the OS VHD Premium Storage Account
Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount  $newxiostorageaccountname  

#If you wanted to place the OS VHD Standard Storage Account but attach Premium Storage VHDs then you would run this instead:
$standardstorageaccountname = "danstdams"

Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount  $standardstorageaccountname

Stap 6: VM maken

#Get list of available SQL Server Images from the Azure Image Gallery.
$galleryImage = Get-AzureVMImage | where-object {$_.ImageName -like "*SQL*2014*Enterprise*"}
$image = $galleryImage.ImageName

#Set up Machine Specific Information
$vmName = "dsDan1"
$vnet = "dansvnetwesteur"
$subnet = "SQL"
$ipaddr = "192.168.0.8"

#Remember to change to DS series VM
$newInstanceSize = "Standard_DS1"

#create new Availability Set
$availabilitySet = "cloudmigAVAMS"

#Machine User Credentials
$userName = "myadmin"
$pass = "mycomplexpwd4*"

#Create VM Config
$vmConfigsl = New-AzureVMConfig -Name $vmName -InstanceSize $newInstanceSize -ImageName $image  -AvailabilitySetName $availabilitySet  ` | Add-AzureProvisioningConfig -Windows ` -AdminUserName $userName -Password $pass | Set-AzureSubnet -SubnetNames $subnet | Set-AzureStaticVNetIP -IPAddress $ipaddr

#Add Data and Log Disks to VM Config
#Note the size specified '-DiskSizeInGB 1023', this attaches 2 x P30 Premium Storage Disk Type
#Utilising the Premium Storage enabled Storage account

$vmConfigsl | Add-AzureDataDisk -CreateNew -DiskSizeInGB 1023 -LUN 0 -HostCaching "ReadOnly"  -DiskLabel "DataDisk1" -MediaLocation "https://$newxiostorageaccountname.blob.core.windows.net/vhds/$vmName-data1.vhd"
$vmConfigsl | Add-AzureDataDisk -CreateNew -DiskSizeInGB 1023 -LUN 1 -HostCaching "None"  -DiskLabel "logDisk1" -MediaLocation "https://$newxiostorageaccountname.blob.core.windows.net/vhds/$vmName-log1.vhd"

#Create VM
$vmConfigsl  | New-AzureVM –ServiceName $destcloudsvc -VNetName $vnet ## Optional (-ReservedIPName $reservedVIPName)  

#Add RDP Endpoint
$EndpointNameRDPInt = "3389"
Get-AzureVM -ServiceName $destcloudsvc -Name $vmName | Add-AzureEndpoint -Name "EndpointNameRDP" -Protocol "TCP" -PublicPort "53385" -LocalPort $EndpointNameRDPInt  | Update-AzureVM

#Check VHD storage account, these should be in $newxiostorageaccountname
Get-AzureVM -ServiceName $destcloudsvc -Name $vmName | Get-AzureDataDisk
Get-AzureVM -ServiceName $destcloudsvc -Name $vmName |Get-AzureOSDisk

Een nieuwe virtuele machine maken voor het gebruik van Premium Storage met een aangepast image.

In dit scenario ziet u waar u bestaande aangepaste images hebt die zich in een standaard Storage-account bevinden. Zoals vermeld is, als u de VHD van het besturingssysteem in Premium Storage wilt plaatsen, moet u het bestaande image dat in het Standard Storage-account zit, kopiëren en overdragen naar een Premium Storage-account voordat het kan worden gebruikt. Als u een on-premises installatiekopie hebt, kunt u deze methode ook gebruiken om deze rechtstreeks naar het Premium Storage-account te kopiëren.

Stap 1: Opslagaccount maken

$mysubscription = "DansSubscription"
$location = "West Europe"

#Create Premium Storage account
$newxiostorageaccountname = "danspremsams"
New-AzureStorageAccount -StorageAccountName $newxiostorageaccountname -Location $location -Type "Premium_LRS"  

#Standard Storage account
$origstorageaccountname = "danstdams"

Stap 2: Cloudservice maken

$destcloudsvc = "danNewSvcAms"
New-AzureService $destcloudsvc -Location $location

Stap 3: Bestaande afbeelding gebruiken

U kunt een bestaande afbeelding gebruiken. U kunt ook een afbeelding van een bestaande machinemaken. Houd er rekening mee dat de computer waarop u een image maakt, geen DS*-computer hoeft te zijn. Zodra u de afbeelding hebt, worden in de volgende stappen uitgelegd hoe u deze kopieert naar het Premium Storage-account met de Start-AzureStorageBlobCopy PowerShell cmdlet.

#Get storage account keys:
#Standard Storage account
$originalstorage =  Get-AzureStorageKey -StorageAccountName $origstorageaccountname
#Premium Storage account
$xiostorage = Get-AzureStorageKey -StorageAccountName $newxiostorageaccountname

#Set up contexts for the storage accounts:
$origContext = New-AzureStorageContext  –StorageAccountName $origstorageaccountname -StorageAccountKey $originalstorage.Primary
$destContext = New-AzureStorageContext  –StorageAccountName $newxiostorageaccountname -StorageAccountKey $xiostorage.Primary  

Stap 4: Blob kopiëren tussen opslagaccounts

#Get Image VHD
$myImageVHD = "dansoldonorsql2k14-os-2015-04-15.vhd"
$containerName = 'vhds'

#Copy Blob between accounts
$blob = Start-AzureStorageBlobCopy -SrcBlob $myImageVHD -SrcContainer $containerName `
-DestContainer vhds -Destblob "prem-$myImageVHD" `
-Context $origContext -DestContext $destContext  

Stap 5: Controleer regelmatig de kopieerstatus:

$blob | Get-AzureStorageBlobCopyState

Stap 6: Een image-schijf toevoegen aan de Azure-schijfrepository binnen het abonnement

$imageMediaLocation = $destContext.BlobEndPoint+"/"+$myImageVHD
$newimageName = "prem"+"dansoldonorsql2k14"

Add-AzureVMImage -ImageName $newimageName -MediaLocation $imageMediaLocation

Stap 7: de VIRTUELE machine bouwen

Hier bouwt u de VIRTUELE machine vanuit uw installatiekopieën en koppelt u twee Premium Storage-VHD's:

$newimageName = "prem"+"dansoldonorsql2k14"
#Set up Machine Specific Information
$vmName = "dansolchild"
$vnet = "westeur"
$subnet = "Clients"
$ipaddr = "192.168.0.41"

#This needs to be a new cloud service
$destcloudsvc = "danregsvcamsxio2"

#Use to DS Series VM
$newInstanceSize = "Standard_DS1"

#create new Availability Set
$availabilitySet = "cloudmigAVAMS3"

#Machine User Credentials
$userName = "myadmin"
$pass = "theM)stC0mplexP@ssw0rd!"


#Create VM Config
$vmConfigsl2 = New-AzureVMConfig -Name $vmName -InstanceSize $newInstanceSize -ImageName $newimageName  -AvailabilitySetName $availabilitySet  ` | Add-AzureProvisioningConfig -Windows ` -AdminUserName $userName -Password $pass | Set-AzureSubnet -SubnetNames $subnet | Set-AzureStaticVNetIP -IPAddress $ipaddr

$vmConfigsl2 | Add-AzureDataDisk -CreateNew -DiskSizeInGB 1023 -LUN 0 -HostCaching "ReadOnly"  -DiskLabel "DataDisk1" -MediaLocation "https://$newxiostorageaccountname.blob.core.windows.net/vhds/$vmName-Datadisk-1.vhd"
$vmConfigsl2 | Add-AzureDataDisk -CreateNew -DiskSizeInGB 1023 -LUN 1 -HostCaching "None"  -DiskLabel "LogDisk1" -MediaLocation "https://$newxiostorageaccountname.blob.core.windows.net/vhds/$vmName-logdisk-1.vhd"



$vmConfigsl2 | New-AzureVM –ServiceName $destcloudsvc -VNetName $vnet

Bestaande implementaties die geen AlwaysOn-beschikbaarheidsgroepen gebruiken

Er zijn verschillende overwegingen voor SQL Server-implementaties die geen AlwaysOn-beschikbaarheidsgroepen gebruiken en die wel. Als u AlwaysOn niet gebruikt en een bestaande zelfstandige SQL Server hebt, kunt u upgraden naar Premium Storage met behulp van een nieuwe cloudservice en opslagaccount. Houd rekening met de volgende opties:

• een nieuwe SQL Server-VM maken. U kunt een nieuwe SQL Server-VM maken die gebruikmaakt van een Premium Storage-account, zoals beschreven in Nieuwe implementaties. Maak vervolgens een back-up en herstel uw SQL Server-configuratie- en gebruikersdatabases. De toepassing moet worden bijgewerkt om te verwijzen naar de nieuwe SQL Server als deze intern of extern wordt geopend. U moet alle 'out of db'-objecten kopiëren alsof u een SQL Server-migratie (Side by Side) (SxS) uitvoert. Dit omvat objecten zoals aanmeldingen, certificaten en gekoppelde servers.
• een bestaande SQL Server-VM migreren. Hiervoor moet u de SQL Server-VM offline zetten en deze vervolgens overdragen naar een nieuwe cloudservice, waaronder het kopiëren van alle gekoppelde VHD's naar het Premium Storage-account. Wanneer de virtuele machine online komt, verwijst de toepassing naar de hostnaam van de server zoals voorheen. Houd er rekening mee dat de grootte van de bestaande schijf van invloed is op de prestatiekenmerken. Een schijf van 400 GB wordt bijvoorbeeld afgerond op een P20. Als u weet dat u die schijfprestaties niet nodig hebt, kunt u de VIRTUELE machine opnieuw maken als een DS-serie-VM en Premium Storage-VHD's koppelen van de grootte/prestatiespecificatie die u nodig hebt. Vervolgens kunt u de SQL DB-bestanden loskoppelen en opnieuw koppelen.

Als uw SQL Server extern wordt benaderd, verandert het VIP-adres van de cloudservice. U moet ook eindpunten, ACL's en DNS-instellingen bijwerken.

Bestaande implementaties die gebruikmaken van AlwaysOn-beschikbaarheidsgroepen

In eerste instantie in deze sectie bekijken we hoe AlwaysOn communiceert met Azure Networking. Vervolgens splitsen we migraties op in twee scenario's: migraties waarbij enige downtime kan worden getolereerd en migraties waarbij u minimale downtime moet bereiken.

On-premises SQL Server AlwaysOn-beschikbaarheidsgroepen gebruiken een listener on-premises die een virtuele DNS-naam registreert, samen met een IP-adres dat wordt gedeeld tussen een of meer SQL-servers. Wanneer clients verbinding maken, worden ze doorgestuurd via het IP-adres van de listener naar de primaire SQL Server. Dit is de server die eigenaar is van de AlwaysOn IP-resource op dat moment.

In Microsoft Azure kunt u slechts één IP-adres toewijzen aan een NIC op de VIRTUELE machine, dus om dezelfde abstractielaag te bereiken als on-premises, gebruikt Azure het IP-adres dat is toegewezen aan de interne/externe load balancers (ILB/ELB). De IP-resource die wordt gedeeld tussen de servers, is ingesteld op hetzelfde IP-adres als de ILB/ELB. Dit wordt gepubliceerd in de DNS en clientverkeer wordt via de ILB/ELB doorgegeven aan de primaire SQL Server-replica. De ILB/ELB weet welke SQL Server primair is, omdat het probes gebruikt om de Always On IP-resource te onderzoeken. In het vorige voorbeeld onderzoekt het elk knooppunt met een eindpunt waarnaar door de ELB/ILB wordt verwezen; degene die reageert, is de primaire SQL-server.

Migreren van Always On-implementaties die enige downtime kunnen toestaan

Er zijn twee strategieën voor het migreren van AlwaysOn-implementaties die enige downtime mogelijk maken:

1. meer secundaire replica's toevoegen aan een bestaand AlwaysOn-cluster
2. Migreren naar een nieuw AlwaysOn-cluster

1. Meer secundaire replica's toevoegen aan een bestaand AlwaysOn-cluster

Een strategie is om meer secundaire bestanden toe te voegen aan de AlwaysOn-beschikbaarheidsgroep. U moet deze toevoegen aan een nieuwe cloudservice en de listener bijwerken met het ip-adres van de nieuwe load balancer.

Downtimepunten:

• Clustervalidatie.
• AlwaysOn-failovers testen voor nieuwe secundaire databases.

Als u Windows-opslaggroepen binnen de VIRTUELE machine gebruikt voor een hogere IO-doorvoer, worden deze offline gehaald tijdens een volledige clustervalidatie. De validatietest is vereist wanneer u knooppunten aan het cluster toevoegt. De tijd die nodig is om de test uit te voeren, kan variëren, dus u moet dit testen in uw representatieve testomgeving om een geschatte tijd te krijgen van hoe lang dit duurt.

U moet tijd inrichten waar u handmatige failover- en chaostests kunt uitvoeren op de zojuist toegevoegde knooppunten om ervoor te zorgen dat AlwaysOn High Availability-functies werken zoals verwacht.

1. Maak twee nieuwe SQL-servers in een nieuwe cloudservice met gekoppelde Premium Storage.

2. Kopieer volledige back-ups en herstel met NORECOVERY.

3. Kopieer afhankelijke objecten uit de gebruikersdatabase, zoals gebruikersaanmeldingen, enzovoort.

4. Maak een nieuwe interne load balancer (ILB), of gebruik een externe load balancer (ELB), en stel vervolgens gebalanceerde eindpunten in op de beide nieuwe knooppunten.

   Notitie

   Controleer of alle knooppunten de juiste eindpuntconfiguratie hebben voordat u doorgaat

5. Gebruikers-/toepassingstoegang tot de SQL Server stoppen (als u opslaggroepen gebruikt).

6. Stop SQL Server Engine Services op alle knooppunten (als u opslaggroepen gebruikt).

7. Voeg nieuwe knooppunten toe aan het cluster en voer volledige validatie uit.

8. Zodra de validatie is geslaagd, start u alle SQL Server-services.

9. Back-up van transactielogboeken maken en gebruikersdatabases herstellen.

10. Voeg nieuwe knooppunten toe aan de Always On Availability Group en plaats replicatie in Synchronous.

11. Voeg de IP-adresresource van de nieuwe cloudservice-ILB/ELB toe via PowerShell voor AlwaysOn op basis van het voorbeeld van meerdere sites in de bijlage. Stel in Windows-clustering de Mogelijke eigenaren van de IP-adres resource in op de nieuwe knooppunten die eerder eigenaar waren. Zie de sectie 'IP-adresresource toevoegen aan hetzelfde subnet' van bijlage .

12. Failover naar een van de nieuwe knooppunten.

13. Maak van de nieuwe knooppunten automatische failover-partners en voer testfailovers uit.

14. Verwijder oorspronkelijke knooppunten uit de beschikbaarheidsgroep.

Voordelen

• Nieuwe SQL-servers kunnen worden getest (SQL Server en toepassing) voordat ze worden toegevoegd aan AlwaysOn.
• U kunt de VM-grootte wijzigen en de opslag aanpassen aan uw exacte vereisten. Het zou echter nuttig zijn om alle SQL-bestandspaden hetzelfde te houden.
• U kunt bepalen wanneer de overdracht van de DB-back-ups naar de secundaire replica's wordt gestart. Dit verschilt van het gebruik van Azure Start-AzureStorageBlobCopy commandlet om VHD's te kopiëren, omdat dat een asynchrone kopie is.

Nadelen

• Wanneer u Windows-opslaggroepen gebruikt, is er sprake van downtime voor clusters tijdens de volledige clustervalidatie voor de nieuwe extra knooppunten.
• Afhankelijk van de SQL Server-versie en het bestaande aantal secundaire replica's, kunt u mogelijk niet meer secundaire replica's toevoegen zonder bestaande secundaire replica's te verwijderen.
• Tijdens het instellen van de secundaire databases kan er een lange overdrachtstijd zijn voor SQL-gegevens.
• Er zijn extra kosten tijdens de migratie wanneer nieuwe machines parallel draaien.

2. Migreren naar een nieuw AlwaysOn-cluster

Een andere strategie is het maken van een gloednieuw AlwaysOn-cluster met gloednieuwe knooppunten in een nieuwe cloudservice en vervolgens de clients omleiden om het te gebruiken.

Downtimepunten

Er is downtime wanneer u toepassingen en gebruikers overdraagt naar de nieuwe AlwaysOn-listener. De downtime is afhankelijk van:

• De tijd die nodig is om de laatste back-ups van transactielogboeken te herstellen naar databases op nieuwe servers.
• De tijd die nodig was om clienttoepassingen bij te werken voor het gebruik van een nieuwe AlwaysOn-listener.

Voordelen

• U kunt de werkelijke wijzigingen in de productieomgeving, SQL Server en de build van het besturingssysteem testen.
• U hebt de mogelijkheid om de opslag aan te passen en de vm mogelijk te verkleinen. Dit kan leiden tot kostenreductie.
• Tijdens dit proces kunt u uw SQL Server-build of -versie bijwerken. U kunt ook het besturingssysteem upgraden.
• Het vorige AlwaysOn-cluster kan fungeren als een solide terugdraaidoel.

Nadelen

• U moet de DNS-naam van de listener wijzigen als u wilt dat beide AlwaysOn-clusters tegelijkertijd worden uitgevoerd. Dit verhoogt de beheeroverhead tijdens de migratie, omdat tekststrings van klantapplicaties de nieuwe Listener-naam moeten weerspiegelen.
• U moet een synchronisatiemechanisme tussen de twee omgevingen implementeren om ze zo dicht mogelijk te houden om de uiteindelijke synchronisatievereisten vóór de migratie te minimaliseren.
• Er worden extra kosten toegevoegd tijdens de migratie terwijl de nieuwe omgeving actief is.

AlwaysOn-implementaties migreren voor minimale downtime

Er zijn twee strategieën voor het migreren van AlwaysOn-implementaties voor minimale downtime:

1. Gebruik een bestaande secundaire: enkelvoudige site
2. bestaande secundaire replica('s) gebruiken: multi-site

1. Gebruik een bestaande secundaire: Single-Site

Eén strategie voor minimale downtime is het nemen van een bestaande secundaire cloud en het verwijderen uit de huidige cloudservice. Kopieer vervolgens de VHD's naar het nieuwe Premium Storage-account en maak de virtuele machine in de nieuwe cloudservice. Werk vervolgens de listener bij in clustering en failover.

Downtimepunten

• Er is downtime tijdens het bijwerken van het laatste knooppunt met het Load Balancer-eindpunt.
• Het opnieuw verbinden van de client kan worden vertraagd, afhankelijk van uw client-/DNS-configuratie.
• Er is extra downtime als u ervoor kiest om de AlwaysOn-clustergroep offline te zetten om de IP-adressen te wisselen. U kunt dit voorkomen door een OR-afhankelijkheid en mogelijke eigenaren te gebruiken voor de toegevoegde IP-adresresource. Zie de sectie 'IP-adresresource toevoegen aan hetzelfde subnet' van bijlage .

Voordelen

• Er worden geen extra kosten gemaakt tijdens de migratie.
• Een een-op-een-migratie.
• Verminderde complexiteit.
• Maakt meer IOPS mogelijk voor Premium Storage-SKU's. Wanneer de schijven worden losgekoppeld van de virtuele machine en naar de nieuwe cloudservice worden gekopieerd, kan een hulpprogramma van derden worden gebruikt om de VHD-grootte te verhogen, wat hogere doorvoer biedt. Zie deze forumdiscussievoor meer VHD-grootten.

Nadelen

• Er is een tijdelijk verlies van hoge beschikbaarheid en DR tijdens de migratie.
• Omdat dit een migratie van 1:1 is, moet u een minimale VM-grootte gebruiken die ondersteuning biedt voor uw aantal VHD's, zodat u uw VM's mogelijk niet kunt verkleinen.
• In dit scenario wordt de Azure Start-AzureStorageBlobCopy commandlet gebruikt, die asynchroon is. Er is geen SLA voor de voltooiing van het kopiëren. De tijd van de kopieën varieert, terwijl dit afhankelijk is van wachten in de wachtrij, hangt ook af van de hoeveelheid gegevens die moet worden overgedragen. De kopieertijd neemt toe als de overdracht naar een ander Azure-datacenter gaat dat Ondersteuning biedt voor Premium Storage in een andere regio. Als u slechts 2 knooppunten hebt, kunt u een mogelijke beperking overwegen voor het geval het kopiëren langer duurt dan bij het testen. Dit kan de volgende ideeën bevatten.
  • Voeg een tijdelijk 3e SQL Server-knooppunt toe voor hoge beschikbaarheid vóór de migratie met overeengekomen downtime.
  • Voer de migratie buiten gepland Azure-onderhoud uit.
  • Zorg ervoor dat u het clusterquorum juist hebt geconfigureerd.

Stappen op hoog niveau

In dit document wordt geen volledig end-to-end-voorbeeld gedemonstreerd, maar de bijlage bevat details die kunnen worden gebruikt om dit uit te voeren.

• Verzamel de schijfconfiguratie en verwijder het knooppunt (verwijder geen gekoppelde VHD's).
• Een Premium Storage-account maken en VHD's kopiëren vanuit het Standard Storage-account
• Maak een nieuwe cloudservice en implementeer de SQL2-VM opnieuw in die cloudservice. Maak de VIRTUELE machine met behulp van de gekopieerde oorspronkelijke besturingssysteem-VHD en koppel de gekopieerde VHD's.
• Configureer ILB/ELB en voeg eindpunten toe.
• Listener bijwerken op een van de volgende manieren:
  • De AlwaysOn-groep offline zetten en de AlwaysOn-listener bijwerken met een nieuw ILB-/ELB-IP-adres.
  • Of voeg de IP-adresresource van nieuwe Cloud Service ILB/ELB via PowerShell toe aan Windows-clustering. Stel vervolgens de mogelijke eigenaren van de IP-adresresource in op het gemigreerde knooppunt, SQL2 en stel deze in als OR-afhankelijkheid in de netwerknaam. Zie de sectie 'IP-adresresource toevoegen aan hetzelfde subnet' van bijlage .
• Controleer de DNS-configuratie/doorgifte naar de clients.
• Migreer de SQL1-VM en doorloop stap 2 tot en met 4.
• Als u stap 5ii gebruikt, voegt u SQL1 toe als mogelijke eigenaar voor de toegevoegde IP-adresresource
• Testfailovers.

2. Bestaande secundaire replica('s) gebruiken: meerdere sites

Als u knooppunten in meer dan één Azure-datacenter (DC) hebt of als u een hybride omgeving hebt, kunt u een AlwaysOn-configuratie in deze omgeving gebruiken om downtime te minimaliseren.

De methode is om de AlwaysOn-synchronisatie te wijzigen in Synchroon voor de on-premises of secundaire Azure DC en vervolgens een failover naar die SQL Server uit te voeren. Kopieer vervolgens de VHD's naar een Premium Storage-account en implementeer de machine opnieuw in een nieuwe cloudservice. Werk de listener bij en voer vervolgens een failback uit.

Downtimepunten

De downtime bestaat uit de tijd die nodig is voor een failover naar het alternatieve datacentrum en terug. Het is ook afhankelijk van uw clientconfiguratie/DNS en de herverbinding van de client kan vertraagd zijn. Bekijk het volgende voorbeeld van een hybride AlwaysOn-configuratie:

Voordelen

• U kunt bestaande infrastructuur gebruiken.
• U hebt de mogelijkheid om de Azure-opslag vooraf te upgraden op de DR Azure DC.
• De DR Azure DC-opslag kan opnieuw worden geconfigureerd.
• Er zijn minimaal twee failovers tijdens de migratie, met uitzondering van testfailovers.
• U hoeft GEEN SQL Server-gegevens te verplaatsen met back-up en herstel.

Nadelen

• Afhankelijk van de clienttoegang tot SQL Server kan er een verhoogde latentie optreden wanneer SQL Server wordt uitgevoerd in een alternatieve domeincontroller voor de toepassing.
• De kopieertijd van VHD's naar Premium-opslag kan lang zijn. Dit kan van invloed zijn op uw beslissing over het behouden van het knooppunt in de beschikbaarheidsgroep. Houd hier rekening mee wanneer logboekintensieve werkbelastingen worden uitgevoerd tijdens de vereiste migratie, aangezien het primaire knooppunt de niet-gerepliceerde transacties in zijn transactielogboek moet bewaren. Daarom kan dit aanzienlijk groeien.
• In dit scenario wordt de Azure Start-AzureStorageBlobCopy commandlet gebruikt, die asynchroon is. Er is geen SLA na voltooiing. De tijd van de kopieën varieert, terwijl dit afhankelijk is van wachten in de wachtrij, is het ook afhankelijk van de hoeveelheid gegevens die moet worden overgedragen. Omdat u slechts één node in uw 2e datacenter hebt, moet u risicobeperkingsstappen uitvoeren voor het geval het kopiëren langer duurt dan bij het testen. Deze risicobeperkingsstappen omvatten de volgende ideeën:
  • Voeg een tijdelijk 2e SQL-knooppunt toe voor hoge beschikbaarheid vóór de migratie met overeengekomen downtime.
  • Voer de migratie buiten gepland Azure-onderhoud uit.
  • Zorg ervoor dat u het clusterquorum juist hebt geconfigureerd.

In dit scenario wordt ervan uitgegaan dat u uw installatie hebt gedocumenteerd en weet hoe de opslag is toegewezen om wijzigingen aan te brengen voor optimale instellingen voor schijfcache.

Stappen op hoog niveau

• Maak de on-premises/alternatieve Azure DC tot de primaire SQL Server en stel deze in als de andere Auto Failover Partner (AFP).
• Verzamel informatie over de schijfconfiguratie van SQL2 en verwijder het knooppunt (verwijder geen gekoppelde VHD's).
• Maak een Premium Storage-account en kopieer VHD's uit het Standard Storage-account.
• Maak een nieuwe cloudservice en maak de SQL2-VM met de gekoppelde Premiums Storage-schijven.
• Configureer ILB/ELB en voeg eindpunten toe.
• Werk de Always On Listener bij met het nieuwe ILB/ELB IP-adres en test de failover.
• Controleer de DNS-configuratie.
• Wijzig de AFP in SQL2 en migreer vervolgens SQL1 en doorloop stap 2 – 5.
• Testfailovers.
• De AFP terugzetten naar SQL1 en SQL2

Bijlage: Een AlwaysOn-cluster met meerdere locaties migreren naar Premium Storage

De rest van dit artikel bevat een gedetailleerd voorbeeld van het converteren van een AlwaysOn-cluster met meerdere sites naar Premium-opslag. Ook converteert het de listener van het gebruik van een externe load balancer (ELB) naar een interne load balancer (ILB).

Milieu

• Windows 2k12 / SQL 2k12
• 1 DB-bestanden op SP
• 2 x opslaggroepen per knooppunt

VM:

In dit voorbeeld laten we zien hoe we overstappen van een ELB naar ILB. ELB was beschikbaar vóór ILB, dus dit laat zien hoe u tijdens de migratie overschakelt naar ILB.

Voorafgaande stappen: Verbinding maken met abonnement

Add-AzureAccount

#Set up subscription
Get-AzureSubscription

Stap 1: Nieuw opslagaccount en cloudservice maken

$mysubscription = "DansSubscription"
$location = "West Europe"

#Storage accounts
#current storage account where the vm to migrate resides
$origstorageaccountname = "danstdams"

#Create Premium Storage account
$newxiostorageaccountname = "danspremsams"
New-AzureStorageAccount -StorageAccountName $newxiostorageaccountname -Location $location -Type "Premium_LRS"  

#Generate storage keys for later
$originalstorage =  Get-AzureStorageKey -StorageAccountName $origstorageaccountname
$xiostorage = Get-AzureStorageKey -StorageAccountName $newxiostorageaccountname

#Generate storage acc contexts
$origContext = New-AzureStorageContext  –StorageAccountName $origstorageaccountname -StorageAccountKey $originalstorage.Primary
$xioContext = New-AzureStorageContext  –StorageAccountName $newxiostorageaccountname -StorageAccountKey $xiostorage.Primary  

#Set up subscription and default storage account
Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount $origstorageaccountname
Select-AzureSubscription -SubscriptionName $mysubscription -Current

#CREATE NEW CLOUD SVC
$vnet = "dansvnetwesteur"

##Existing cloud service
$sourceSvc="dansolSrcAms"

##Create new cloud service
$destcloudsvc = "danNewSvcAms"
New-AzureService $destcloudsvc -Location $location

Stap 2: Verhoog de toegestane fouten voor middelen <Optionele>

Voor bepaalde resources die deel uitmaken van uw AlwaysOn-beschikbaarheidsgroep gelden limieten voor het aantal fouten dat in een periode kan optreden, waarbij de clusterservice probeert de resourcegroep opnieuw te starten. Het wordt aanbevolen dit te verhogen terwijl u deze procedure doorloopt. Als u geen handmatige failover uitvoert en failovers activeert door computers af te sluiten, kunt u deze limiet bijna bereiken.

Het is verstandig om de foutvergoeding te verdubbelen. Om dit in Failover-clusterbeheer te doen, gaat u naar de eigenschappen van de Always On-resourcegroep:

Wijzig het maximum aantal fouten naar 6.

Stap 3: IP-adresresource voor clustergroep toevoegen <optionele>

Als u slechts één IP-adres voor de clustergroep hebt en dit is afgestemd op het cloudsubnet, moet u er rekening mee houden dat als u per ongeluk alle clusterknooppunten in de cloud op dat netwerk offline brengt, dan kunnen de cluster-IP-resource en clusternetwerknaam niet online komen. In deze situatie worden updates van andere clusterbronnen voorkomen.

Stap 4: DNS-configuratie

Het implementeren van een soepele overgang is afhankelijk van de wijze waarop DNS wordt gebruikt en bijgewerkt. Wanneer AlwaysOn is geïnstalleerd, wordt er een Windows-clusterresourcegroep gemaakt. Als u Failoverclusterbeheer opent, ziet u dat er minimaal drie resources zijn, de twee waarnaar het document verwijst:

• Virtual Network Name (VNN): de DNS-naam waarmee clients verbinding maken wanneer ze verbinding willen maken met SQL-servers via AlwaysOn.
• IP-adresresource: de IP-adressen die zijn gekoppeld aan de VNN. U kunt meer dan één adres hebben, en in een configuratie met meerdere locaties heeft u een IP-adres per site/subnet.

Wanneer u verbinding maakt met SQL Server, haalt het STUURPROGRAMMA van de SQL Server-client de DNS-records op die zijn gekoppeld aan de listener en probeert verbinding te maken met elk gekoppeld IP-adres van AlwaysOn. Vervolgens bespreken we enkele factoren die dit kunnen beïnvloeden.

Het aantal gelijktijdige DNS-records dat is gekoppeld aan de naam van de listener, is niet alleen afhankelijk van het aantal gekoppelde IP-adressen, maar de instelling RegisterAllIpProviders in FailoverClustering voor de Always ON VNN-resource.

Wanneer u AlwaysOn in Azure implementeert, zijn er verschillende stappen voor het maken van de listener en IP-adressen, moet u de 'RegisterAllIpProviders' handmatig configureren op 1. Dit verschilt van een on-premises Always On-implementatie waarbij deze al is ingesteld op 1.

Als RegisterAllIpProviders 0 is, ziet u slechts één DNS-record in DNS die is gekoppeld aan de listener:

Als 'RegisterAllIpProviders' op 1 staat:

De onderstaande code dumpt de VNN-instellingen en stelt deze voor u in. Voordat de wijziging van kracht wordt, moet u de VNN offline halen en weer online zetten. Hierdoor wordt de listener offline gehaald, waardoor de verbinding van de client wordt onderbroken.

##Always On Listener Name
$ListenerName = "Mylistener"
##Get AlwaysOn Network Name Settings
Get-ClusterResource $ListenerName| Get-ClusterParameter
##Set RegisterAllProvidersIP
Get-ClusterResource $ListenerName| Set-ClusterParameter RegisterAllProvidersIP  1

In een latere migratiestap moet u de Always On-listener bijwerken met een bijgewerkt IP-adres dat verwijst naar een load balancer. Dit houdt in dat de IP-adresbron moet worden verwijderd en opnieuw toegevoegd. Na de IP-update moet u ervoor zorgen dat het nieuwe IP-adres is bijgewerkt in de DNS-zone en dat de clients hun lokale DNS-cache bijwerken.

Als uw clients zich in een ander netwerksegment bevinden en verwijzen naar een andere DNS-server, moet u rekening houden met wat er gebeurt met DNS-zoneoverdracht tijdens de migratie, omdat de tijd voor opnieuw verbinden van de toepassing wordt beperkt door ten minste de zoneoverdrachttijd van nieuwe IP-adressen voor de listener. Als u zich hier onder tijdsbeperking bevindt, moet u het afdwingen van een incrementele zoneoverdracht met uw Windows-teams bespreken en testen en ook de DNS-hostrecord naar een lagere Time To Live -record (TTL) plaatsen, zodat de clients worden bijgewerkt. Zie Incrementele zoneoverdrachten en Start-DnsServerZoneTransfervoor meer informatie.

De TTL voor DNS-record die is gekoppeld aan de listener in AlwaysOn in Azure is standaard 1200 seconden. Mogelijk wilt u dit beperken als u tijdens uw migratie te weinig tijd hebt om ervoor te zorgen dat de clients hun DNS bijwerken met het bijgewerkte IP-adres voor de listener. U kunt de configuratie bekijken en wijzigen door de configuratie van de VNN te dumpen:

$AGName = "myProductionAG"
$ListenerName = "Mylistener"
#Look at HostRecordTTL
Get-ClusterResource $ListenerName| Get-ClusterParameter

#Set HostRecordTTL Examples
Get-ClusterResource $ListenerName| Set-ClusterParameter -Name "HostRecordTTL" 120

Clienttoepassingsinstellingen

Als uw SQL-clienttoepassing ondersteuning biedt voor .NET 4.5 SQLClient, kunt u het trefwoord MULTISUBNETFAILOVER=TRUE gebruiken. Dit trefwoord moet worden toegepast, omdat het een snellere verbinding met sql AlwaysOn-beschikbaarheidsgroep mogelijk maakt tijdens een failover. Het inventariseert alle IP-adressen die zijn gekoppeld aan de AlwaysOn-listener parallel en voert een agressievere snelheid voor het opnieuw proberen van TCP-verbindingen uit tijdens een failover.

Zie MultiSubnetFailover-trefwoord en bijbehorende functiesvoor meer informatie over de vorige instellingen. Zie ook SqlClient-ondersteuning voor hoge beschikbaarheid, herstel na noodgevallen.

Stap 5: Clusterquoruminstellingen

Aangezien u ten minste één SQL Server tegelijk wilt uitschakelen, moet u de instelling voor het clusterquorum wijzigen als u FSW (File Share Witness) met twee knooppunten gebruikt, moet u het quorum instellen om knooppuntmeerderheid toe te staan en dynamische stemmen te gebruiken, zodat één knooppunt permanent blijft.

Set-ClusterQuorum -NodeMajority  

Zie Quorum configureren en beheren in een Windows Server 2012-failoverclustervoor meer informatie over het beheren en configureren van het clusterquorum.

Stap 6: Bestaande eindpunten en ACL's extraheren

#GET Endpoint info
Get-AzureVM -ServiceName $destcloudsvc -Name $vmNameToMigrate | Get-AzureEndpoint
#GET ACL Rules for Each EP, this example is for the Always On Endpoint
Get-AzureVM -ServiceName $destcloudsvc -Name $vmNameToMigrate | Get-AzureAclConfig -EndpointName "myAOEndPoint-LB"  

Sla deze tekst op in een bestand.

Stap 7: Failoverpartners en replicatiemodi wijzigen

Als u meer dan twee SQL-servers hebt, moet u de failover van een andere secundaire server in een andere domeincontroller of on-premises wijzigen in 'Syncous' en deze een automatische failoverpartner (AFP) maken, zodat u hoge beschikbaarheid behoudt terwijl u wijzigingen aanbrengt. U kunt dit doen via TSQL van wijzigen via SSMS:

Stap 8: Secundaire VM verwijderen uit de cloudservice

U moet eerst van plan zijn om een secundair cloudknooppunt te migreren. Als dit knooppunt momenteel primair is, moet u een handmatige failover starten.

$vmNameToMigrate="dansqlams2"

#Check machine status
Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate

#Shutdown secondary VM
Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | stop-AzureVM


#Extract disk configuration

##Building Existing Data Disk Configuration
$file = "C:\Azure Storage Testing\mydiskconfig_$vmNameToMigrate.csv"
$datadisks = @(Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | Get-AzureDataDisk )
Add-Content $file "lun, vhdname, hostcaching, disklabel, diskName"
foreach ($disk in $datadisks)
{
    $vhdname = $disk.MediaLink.AbsolutePath -creplace  "/vhds/"
    $disk.Lun, , $disk.HostCaching, $vhdname, $disk.DiskLabel,$disks.DiskName
    # Write-Host "copying disk $disk"
    $adddisk = "{0},{1},{2},{3},{4}" -f $disk.Lun,$vhdname, $disk.HostCaching, $disk.DiskLabel, $disk.DiskName
    $adddisk | add-content -path $file
}

#Get OS Disk
$osdisks = Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | Get-AzureOSDisk ## | select -ExpandProperty MediaLink
$osvhdname = $osdisks.MediaLink.AbsolutePath -creplace  "/vhds/"
$osdisks.OS, $osdisks.HostCaching, $osvhdname, $osdisks.DiskLabel, $osdisks.DiskName
$addosdisk = "{0},{1},{2},{3},{4}" -f $osdisks.OS,$osvhdname, $osdisks.HostCaching, $osdisks.Disklabel , $osdisks.DiskName
$addosdisk | add-content -path $file

#Import disk config
$diskobjects  = Import-CSV $file

#Check disk config, make sure below returns the disks associated with the VM
$diskobjects

#Identify OS Disk
$osdiskimport = $diskobjects | where {$_.lun -eq "Windows"}
$osdiskforbuild = $osdiskimport.diskName

#Check machibe is off
Get-AzureVM -ServiceName $sourceSvc -Name  $vmNameToMigrate

#Drop machine and rebuild to new cls
Remove-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate

Stap 9: Instellingen voor schijfcaching wijzigen in CSV-bestand en opslaan

Voor gegevensvolumes moeten deze worden ingesteld op READONLY.

Voor TLOG-volumes moeten deze worden ingesteld op NONE.

Stap 10: VHDs kopiëren

#Ensure you have created the container for these:
$containerName = 'vhds'

#Create container
New-AzureStorageContainer -Name $containerName -Context $xioContext

####DISK COPYING####
#Get disks from csv, get settings for each VHDs and copy to Premium Storage accoun
ForEach ($disk in $diskobjects)
{
   $lun = $disk.Lun
   $vhdname = $disk.vhdname
   $cacheoption = $disk.HostCaching
   $disklabel = $disk.DiskLabel
   $diskName = $disk.DiskName
   Write-Host "Copying Disk Lun $lun, Label : $disklabel, VHD : $vhdname has cache setting : $cacheoption"

   #Start async copy
   Start-AzureStorageBlobCopy -srcUri "https://$origstorageaccountname.blob.core.windows.net/vhds/$vhdname" `
    -SrcContext $origContext `
    -DestContainer $containerName `
    -DestBlob $vhdname `
    -DestContext $xioContext
}

U kunt de kopieerstatus van de VHD's controleren op het Premium Storage-account:

ForEach ($disk in $diskobjects)
{
   $lun = $disk.Lun
   $vhdname = $disk.vhdname
   $cacheoption = $disk.HostCaching
   $disklabel = $disk.DiskLabel
   $diskName = $disk.DiskName

   $copystate = Get-AzureStorageBlobCopyState -Blob $vhdname -Container $containerName -Context $xioContext
   Write-Host "Copying Disk Lun $lun, Label : $disklabel, VHD : $vhdname, STATUS = " $copystate.Status
}

Wacht totdat al deze zijn vastgelegd als succesvol.

Voor informatie over afzonderlijke blobs:

Get-AzureStorageBlobCopyState -Blob "blobname.vhd" -Container $containerName -Context $xioContext

Stap 11: Besturingssysteemschijf registreren

#Change storage account
Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount $newxiostorageaccountname
Select-AzureSubscription -SubscriptionName $mysubscription -Current

#Register OS disk
$osdiskimport = $diskobjects | where {$_.lun -eq "Windows"}
$osvhd = $osdiskimport.vhdname
$osdiskforbuild = $osdiskimport.diskName

#Registering OS disk, but as XIO disk
$xioDiskName = $osdiskforbuild + "xio"
Add-AzureDisk -DiskName $xioDiskName -MediaLocation  "https://$newxiostorageaccountname.blob.core.windows.net/vhds/$osvhd"  -Label "BootDisk" -OS "Windows"

Stap 12: Secundaire gegevens importeren in nieuwe cloudservice

De onderstaande code maakt ook gebruik van de hier toegevoegde optie waarmee u de machine kunt importeren en de behoudbare VIP kunt gebruiken.

#Build VM Config
$ipaddr = "192.168.0.5"
#Remember to change to XIO
$newInstanceSize = "Standard_DS13"
$subnet = "SQL"

#Create new Availability Set
$availabilitySet = "cloudmigAVAMS"

#build machine config into object
$vmConfig = New-AzureVMConfig -Name $vmNameToMigrate -InstanceSize $newInstanceSize -DiskName $xioDiskName -AvailabilitySetName $availabilitySet  ` | Add-AzureProvisioningConfig -Windows ` | Set-AzureSubnet -SubnetNames $subnet | Set-AzureStaticVNetIP -IPAddress $ipaddr

#Reload disk config
$diskobjects  = Import-CSV $file
$datadiskimport = $diskobjects | where {$_.lun -ne "Windows"}

ForEach ( $attachdatadisk in $datadiskimport)
{
    $label = $attachdatadisk.disklabel
    $lunNo = $attachdatadisk.lun
    $hostcach = $attachdatadisk.hostcaching
    $datadiskforbuild = $attachdatadisk.diskName
    $vhdname = $attachdatadisk.vhdname

    ###Attaching disks to a VM during a deploy to a new cloud service and new storage account is different from just attaching VHDs to just a redeploy in a new cloud service
    $vmConfig | Add-AzureDataDisk -ImportFrom -MediaLocation "https://$newxiostorageaccountname.blob.core.windows.net/vhds/$vhdname" -LUN $lunNo -HostCaching $hostcach -DiskLabel $label

}

#Create VM
$vmConfig  | New-AzureVM –ServiceName $destcloudsvc –Location $location -VNetName $vnet ## Optional (-ReservedIPName $reservedVIPName)

Stap 13: Maak een ILB op een nieuwe cloudservice en voeg eindpunten met taakverdeling en ACL's toe.

#Check for existing ILB
GET-AzureInternalLoadBalancer -ServiceName $destcloudsvc

$ilb="sqlIntIlbDest"
$subnet = "SQL"
$IP="192.168.0.25"
Add-AzureInternalLoadBalancer -ServiceName $destcloudsvc -InternalLoadBalancerName $ilb –SubnetName $subnet –StaticVNetIPAddress $IP

#Endpoints
$epname="sqlIntEP"
$prot="tcp"
$locport=1433
$pubport=1433
Get-AzureVM –ServiceName $destcloudsvc –Name $vmNameToMigrate  | Add-AzureEndpoint -Name $epname -Protocol $prot -LocalPort $locport -PublicPort $pubport -ProbePort 59999 -ProbeIntervalInSeconds 5 -ProbeTimeoutInSeconds 11  -ProbeProtocol "TCP" -InternalLoadBalancerName $ilb -LBSetName $ilb -DirectServerReturn $true | Update-AzureVM

#SET Azure ACLs or Network Security Groups & Windows FWs

#https://msdn.microsoft.com/library/azure/dn495192.aspx

####WAIT FOR FULL AlwaysOn RESYNCRONISATION!!!!!!!!!#####

Stap 14: AlwaysOn bijwerken

#Code to be executed on a Cluster Node
$ClusterNetworkNameAmsterdam = "Cluster Network 2" # the azure cluster subnet network name
$newCloudServiceIPAmsterdam = "192.168.0.25" # IP address of your cloud service

$AGName = "myProductionAG"
$ListenerName = "Mylistener"


Add-ClusterResource "IP Address $newCloudServiceIPAmsterdam" -ResourceType "IP Address" -Group $AGName -ErrorAction Stop |  Set-ClusterParameter -Multiple @{"Address"="$newCloudServiceIPAmsterdam";"ProbePort"="59999";SubnetMask="255.255.255.255";"Network"=$ClusterNetworkNameAmsterdam;"OverrideAddressMatch"=1;"EnableDhcp"=0} -ErrorAction Stop

#set dependency and NETBIOS, then remove old IP address

#set NETBIOS, then remove old IP address
Get-ClusterGroup $AGName | Get-ClusterResource -Name "IP Address $newCloudServiceIPAmsterdam" | Set-ClusterParameter -Name EnableNetBIOS -Value 0

#set dependency to Listener (OR Dependency) and delete previous IP Address resource that references:

#Make sure no static records in DNS

Verwijder nu het oude IP-adres van de cloudservice.

Stap 15: Controle van DNS-updates

Controleer nu dns-servers in uw SQL Server-clientnetwerken en zorg ervoor dat clustering de extra hostrecord voor het toegevoegde IP-adres heeft toegevoegd. Als deze DNS-servers niet zijn bijgewerkt, kunt u overwegen om een DNS-zoneoverdracht af te dwingen en ervoor te zorgen dat de clients in hun subnet kunnen oplossen naar beide Always On IP-adressen, zodat u niet hoeft te wachten op automatische DNS-replicatie.

Stap 16: AlwaysOn opnieuw configureren

Op dit moment wacht u tot het secundaire knooppunt, dat is gemigreerd, volledig opnieuw is gesynchroniseerd met het on-premises knooppunt. Vervolgens schakelt u over naar het synchrone replicatieknooppunt en maakt u deze tot de AFP.

Stap 17: tweede knooppunt migreren

$vmNameToMigrate="dansqlams1"

Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate

#Get endpoint information
$endpoint = Get-AzureVM -ServiceName $sourceSvc  -Name $vmNameToMigrate | Get-AzureEndpoint

#Shutdown VM
Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | stop-AzureVM

#Get disk config

#Building Existing Data Disk Configuration
$file = "C:\Azure Storage Testing\mydiskconfig_$vmNameToMigrate.csv"
$datadisks = @(Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | Get-AzureDataDisk )
Add-Content $file "lun, vhdname, hostcaching, disklabel, diskName"
foreach ($disk in $datadisks)
{
    $vhdname = $disk.MediaLink.AbsolutePath -creplace  "/vhds/"
    $disk.Lun, , $disk.HostCaching, $vhdname, $disk.DiskLabel,$disks.DiskName
    # Write-Host "copying disk $disk"
    $adddisk = "{0},{1},{2},{3},{4}" -f $disk.Lun,$vhdname, $disk.HostCaching, $disk.DiskLabel, $disk.DiskName
    $adddisk | add-content -path $file
}

#Get OS Disk
$osdisks = Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | Get-AzureOSDisk ## | select -ExpandProperty MediaLink
$osvhdname = $osdisks.MediaLink.AbsolutePath -creplace  "/vhds/"
$osdisks.OS, $osdisks.HostCaching, $osvhdname, $osdisks.DiskLabel, $osdisks.DiskName
$addosdisk = "{0},{1},{2},{3},{4}" -f $osdisks.OS,$osvhdname, $osdisks.HostCaching, $osdisks.Disklabel , $osdisks.DiskName
$addosdisk | add-content -path $file

#Import disk config
$diskobjects  = Import-CSV $file

#Check disk configuration
$diskobjects

#Identify OS Disk
$osdiskimport = $diskobjects | where {$_.lun -eq "Windows"}
$osdiskforbuild = $osdiskimport.diskName

#Check machine is off
Get-AzureVM -ServiceName $sourceSvc -Name  $vmNameToMigrate

#Drop machine and rebuild to new cls
Remove-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate

Stap 18: Instellingen voor schijfcaching wijzigen in CSV-bestand en opslaan

Voor gegevensvolumes moeten de cache-instellingen worden ingesteld op READONLY.

Voor TLOG-volumes moeten de cache-instellingen worden ingesteld op NONE.

Stap 19: Nieuw onafhankelijk opslagaccount maken voor secundair knooppunt

$newxiostorageaccountnamenode2 = "danspremsams2"
New-AzureStorageAccount -StorageAccountName $newxiostorageaccountnamenode2 -Location $location -Type "Premium_LRS"  

#Reset the storage account src if node 1 in a different storage account
$origstorageaccountname2nd = "danstdams2"

#Generate storage keys for later
$xiostoragenode2 = Get-AzureStorageKey -StorageAccountName $newxiostorageaccountnamenode2

#Generate storage acc contexts
$xioContextnode2 = New-AzureStorageContext  –StorageAccountName $newxiostorageaccountnamenode2 -StorageAccountKey $xiostoragenode2.Primary  

#Set up subscription and default storage account
Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount $newxiostorageaccountnamenode2
Select-AzureSubscription -SubscriptionName $mysubscription -Current

Stap 20: VHDS kopiëren

#Ensure you have created the container for these:
$containerName = 'vhds'

#Create container
New-AzureStorageContainer -Name $containerName -Context $xioContextnode2  

####DISK COPYING####
##get disks from csv, get settings for each VHDs and copy to Premium Storage accoun
ForEach ($disk in $diskobjects)
{
   $lun = $disk.Lun
   $vhdname = $disk.vhdname
   $cacheoption = $disk.HostCaching
   $disklabel = $disk.DiskLabel
   $diskName = $disk.DiskName
   Write-Host "Copying Disk Lun $lun, Label : $disklabel, VHD : $vhdname has cache setting : $cacheoption"

   #Start async copy
   Start-AzureStorageBlobCopy -srcUri "https://$origstorageaccountname2nd.blob.core.windows.net/vhds/$vhdname" `
    -SrcContext $origContext `
    -DestContainer $containerName `
    -DestBlob $vhdname `
    -DestContext $xioContextnode2
}

#Check for copy progress

#check individual blob status
Get-AzureStorageBlobCopyState -Blob "danRegSvcAms-dansqlams1-2014-07-03.vhd" -Container $containerName -Context $xioContext

U kunt de VHD-kopieerstatus voor alle VHD's controleren:

ForEach ($disk in $diskobjects)
{
    $lun = $disk.Lun
    $vhdname = $disk.vhdname
    $cacheoption = $disk.HostCaching
    $disklabel = $disk.DiskLabel
    $diskName = $disk.DiskName

    $copystate = Get-AzureStorageBlobCopyState -Blob $vhdname -Container $containerName -Context $xioContextnode2
    Write-Host "Copying Disk Lun $lun, Label : $disklabel, VHD : $vhdname, STATUS = " $copystate.Status
}

Wacht totdat al deze zijn vastgelegd als succesvol.

Voor informatie over afzonderlijke blobs:

#Check individual blob status
Get-AzureStorageBlobCopyState -Blob "danRegSvcAms-dansqlams1-2014-07-03.vhd" -Container $containerName -Context $xioContextnode2

Stap 21: Besturingssysteemschijf registreren

#change storage account to the new XIO storage account
Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount $newxiostorageaccountnamenode2
Select-AzureSubscription -SubscriptionName $mysubscription -Current

#Register OS disk
$osdiskimport = $diskobjects | where {$_.lun -eq "Windows"}
$osvhd = $osdiskimport.vhdname
$osdiskforbuild = $osdiskimport.diskName

#Registering OS disk, but as XIO disk
$xioDiskName = $osdiskforbuild + "xio"
Add-AzureDisk -DiskName $xioDiskName -MediaLocation  "https://$newxiostorageaccountnamenode2.blob.core.windows.net/vhds/$osvhd"  -Label "BootDisk" -OS "Windows"

#Build VM Config
$ipaddr = "192.168.0.4"
$newInstanceSize = "Standard_DS13"

#Join to existing Availability Set

#Build machine config into object
$vmConfig = New-AzureVMConfig -Name $vmNameToMigrate -InstanceSize $newInstanceSize -DiskName $xioDiskName -AvailabilitySetName $availabilitySet  ` | Add-AzureProvisioningConfig -Windows ` | Set-AzureSubnet -SubnetNames $subnet | Set-AzureStaticVNetIP -IPAddress $ipaddr

#Reload disk config
$diskobjects  = Import-CSV $file
$datadiskimport = $diskobjects | where {$_.lun -ne "Windows"}

ForEach ( $attachdatadisk in $datadiskimport)
{
    $label = $attachdatadisk.disklabel
    $lunNo = $attachdatadisk.lun
    $hostcach = $attachdatadisk.hostcaching
    $datadiskforbuild = $attachdatadisk.diskName
    $vhdname = $attachdatadisk.vhdname

    ###This is different to just a straight cloud service change
    #note if you do not have a disk label the command below will fail, populate as required.
    $vmConfig | Add-AzureDataDisk -ImportFrom -MediaLocation "https://$newxiostorageaccountnamenode2.blob.core.windows.net/vhds/$vhdname" -LUN $lunNo -HostCaching $hostcach -DiskLabel $label

}

#Create VM
$vmConfig  | New-AzureVM –ServiceName $destcloudsvc –Location $location -VNetName $vnet -Verbose

Stap 22: Eindpunten en ACL's met load balancing toevoegen

#Endpoints
$epname="sqlIntEP"
$prot="tcp"
$locport=1433
$pubport=1433
Get-AzureVM –ServiceName $destcloudsvc –Name $vmNameToMigrate  | Add-AzureEndpoint -Name $epname -Protocol $prot -LocalPort $locport -PublicPort $pubport -ProbePort 59999 -ProbeIntervalInSeconds 5 -ProbeTimeoutInSeconds 11  -ProbeProtocol "TCP" -InternalLoadBalancerName $ilb -LBSetName $ilb -DirectServerReturn $true | Update-AzureVM


#STOP!!! CHECK in the Azure portal or Machine Endpoints through PowerShell that these Endpoints are created!

#SET ACLs or Azure Network Security Groups & Windows FWs

#https://msdn.microsoft.com/library/azure/dn495192.aspx

Stap 23: Het failover testen

Wacht tot het gemigreerde knooppunt is gesynchroniseerd met het on-premises AlwaysOn-knooppunt. Plaats deze in de synchrone replicatiemodus en wacht totdat deze is gesynchroniseerd. Vervolgens wordt een failover uitgevoerd van on-premises naar het eerste gemigreerde knooppunt. Dit is de AFP. Zodra dat heeft gewerkt, wijzigt u het laatst gemigreerde knooppunt naar de AFP.

Test failovers tussen alle knooppunten en voer chaostests uit om ervoor te zorgen dat failovers naar verwachting en op een tijdige manier werken.

Stap 24: Clusterquoruminstellingen terugzetten / DNS TTL / Failover Pntrs / Synchronisatie-instellingen

IP-adresresource toevoegen op hetzelfde subnet

Als u slechts twee SQL-servers hebt en ze wilt migreren naar een nieuwe cloudservice, maar ze op hetzelfde subnet wilt houden, kunt u voorkomen dat de listener offline wordt gezet om het oorspronkelijke AlwaysOn-IP-adres te verwijderen en het nieuwe IP-adres toe te voegen. Als u de VM's naar een ander subnet migreert, hoeft u dit niet te doen omdat er een extra clusternetwerk is dat verwijst naar dat subnet.

Voordat u de bestaande primaire service overzet, moet u, nadat u de gemigreerde secundaire hebt opgestart en de nieuwe IP-adresresource hebt toegevoegd voor de nieuwe cloudservice, de volgende stappen uitvoeren in de Cluster Failover Manager:

Zie de bijlage, stap 14, om het IP-adres toe te voegen.

1. Voor de huidige IP-adresresource wijzigt u de mogelijke eigenaar in Bestaande primaire SQL Server, in het voorbeeld 'dansqlams4':

   

2. Voor de nieuwe IP-adresresource wijzigt u de mogelijke eigenaar in 'Gemigreerde secundaire SQL Server', in het voorbeeld 'dansqlams5':

   

3. Zodra dit is ingesteld, kunt u een failover uitvoeren en wanneer het laatste knooppunt wordt gemigreerd, moeten de mogelijke eigenaren worden bewerkt, zodat het knooppunt wordt toegevoegd als mogelijke eigenaar:

   

Aanvullende bronnen

• Azure Premium Storage
• virtuele machines
• SQL Server in Azure Virtual Machines