Använda Azure Premium Storage med SQL Server på virtuella datorer

Översikt

Azure Premium SSD är nästa generations lagring som ger låg svarstid och hög dataflödes-I/O. Det fungerar bäst för viktiga I/O-intensiva arbetsbelastningar, till exempel SQL Server på virtuella IaaS-datorer.

Den här artikeln innehåller planering och vägledning för migrering av en virtuell dator som kör SQL Server för att använda Premium Storage. Detta omfattar Azure-infrastruktur (nätverk, lagring) och steg för virtuella Windows-gästdatorer. Exemplet i bilagan visar en fullständig migrering från slutpunkt till slutpunkt för hur du flyttar större virtuella datorer för att dra nytta av förbättrad lokal SSD-lagring med PowerShell.

Det är viktigt att förstå processen från slutpunkt till slutpunkt för användning av Azure Premium Storage med SQL Server på virtuella IAAS-datorer. Detta omfattar:

• Identifiering av kraven för att använda Premium Storage.
• Exempel på distribution av SQL Server på IaaS till Premium Storage för nya distributioner.
• Exempel på migrering av befintliga distributioner, både fristående servrar och distributioner med hjälp av SQL AlwaysOn-tillgänglighetsgrupper.
• Möjliga migreringsmetoder.
• Fullständigt exempel från slutpunkt till slutpunkt som visar Azure-, Windows- och SQL Server-steg för migrering av en befintlig AlwaysOn-implementering.

Mer bakgrundsinformation om SQL Server i Azure Virtual Machines finns i SQL Server i Azure Virtual Machines.

Författare: Daniel Sol Tekniska Granskare: Luis Carlos Vargas Herring, Sanjay Mishra, Pravin Mital, Juergen Thomas, Gonzalo Ruiz.

Krav för Premium Storage

Det finns flera krav för att använda Premium Storage.

Datorstorlek

För att använda Premium Storage måste du använda virtuella datorer i DS-serien (VM). Om du inte har använt datorer i DS-serien i molntjänsten tidigare måste du ta bort den befintliga virtuella datorn, behålla de anslutna diskarna och sedan skapa en ny molntjänst innan du återskapar den virtuella datorn som DS*-rollstorlek. Mer information om storlekar på virtuella datorer finns i Storlekar på virtuella datorer och molntjänster för Azure.

Molntjänster

Du kan bara använda virtuella DS*-datorer med Premium Storage när de skapas i en ny molntjänst. Om du använder SQL Server Always On i Azure refererar AlwaysOn Listener till IP-adressen för den interna eller externa Lastbalanseraren i Azure som är associerad med en molntjänst. Den här artikeln fokuserar på hur du migrerar samtidigt som tillgängligheten bibehålls i det här scenariot.

Regionala VNETS

För virtuella DS*-datorer måste du konfigurera det virtuella nätverket (VNET) som är värd för dina virtuella datorer så att de är regionala. Detta "breddar" det virtuella nätverket så att större VM:er kan etableras i andra kluster och möjliggör kommunikation mellan dem. I följande skärmbild visar den markerade platsen regionala virtuella nätverk, medan det första resultatet visar ett "smalt" virtuellt nätverk.

Du kan skapa ett Microsoft-supportärende för att migrera till ett regionalt virtuellt nätverk. Microsoft gör sedan en ändring. Om du vill slutföra migreringen till regionala virtuella nätverk ändrar du egenskapen AffinityGroup i nätverkskonfigurationen. Exportera först nätverkskonfigurationen i PowerShell och ersätt sedan egenskapen AffinityGroup i elementet VirtualNetworkSite med egenskapen Plats . Ange Location = XXXX var XXXX är en Azure-region. Importera sedan den nya konfigurationen.

Du kan till exempel överväga följande VNET-konfiguration:

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

För att flytta detta till ett regionalt virtuellt nätverk i Västeuropa ändrar du konfigurationen till följande:

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

Lagringskonton

Du måste skapa ett nytt lagringskonto som har konfigurerats för Premium Storage. Observera att användningen av Premium Storage anges på lagringskontot, inte på enskilda virtuella hårddiskar, men när du använder en virtuell dator i DS*-serien kan du koppla virtuella hårddiskar från Premium- och Standard Storage-konton. Du kan överväga detta om du inte vill placera den virtuella hårddisken för operativsystemet på Premium Storage-kontot.

Följande New-AzureStorageAccountPowerShell-kommando med typen "Premium_LRS" skapar ett Premium Storage-konto:

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

Cacheinställningar för VHDs (virtuella hårddiskar)

Den största skillnaden mellan att skapa diskar som ingår i ett Premium Storage-konto är inställningen för diskcache. För SQL Server Data-volymdiskar rekommenderar vi att du använder "Läscachelagring". För transaktionsloggvolymer ska inställningen för diskcache anges till "Ingen". Detta skiljer sig från rekommendationerna för Standard Storage-konton.

När de virtuella hårddiskarna har anslutits kan cacheinställningen inte ändras. Du skulle behöva koppla bort och ansluta igen den virtuella hårddisken med en uppdaterad cache-inställning.

Lagringsutrymmen i Windows

Du kan använda Windows-lagringsutrymmen som du gjorde med tidigare Standard Storage. På så sätt kan du migrera en virtuell dator som redan använder lagringsutrymmen. Exemplet i bilaga (steg 9 och framåt) visar Powershell-koden för att extrahera och importera en virtuell dator med flera anslutna virtuella hårddiskar.

Lagringspooler användes med Standard Azure Storage-kontot för att förbättra dataflödet och minska svarstiden. Du kan hitta värdet i testningen av lagringspooler med Premium Storage för nya distributioner, men de lägger till ytterligare komplexitet med lagringskonfigurationen.

Så här hittar du vilka Azure virtuala diskar som motsvarar lagringspooler

Eftersom det finns olika rekommendationer för cacheinställningar för anslutna virtuella hårddiskar kan du välja att kopiera de virtuella hårddiskarna till ett Premium Storage-konto. Men när du kopplar dem till den nya virtuella datorn i DS-serien kan du behöva ändra cacheinställningarna. Det är enklare att tillämpa de rekommenderade cacheinställningarna för Premium Storage när du har separata virtuella hårddiskar för SQL Data-filer och loggfiler (i stället för en enda virtuell hårddisk som innehåller båda).

Men om du använder Windows-lagringsutrymmen som består av flera virtuella hårddiskar måste du titta på dina ursprungliga skript för att identifiera vilka anslutna virtuella hårddiskar som finns i vilken specifik pool, så att du sedan kan ange cacheinställningarna för varje disk.

Om du inte har det ursprungliga skriptet tillgängligt för att visa vilka virtuella hårddiskar som mappas till lagringspoolen kan du använda följande steg för att fastställa mappningen av disk/lagringspool.

Använd följande steg för varje disk:

1. Hämta en lista över diskar som är anslutna till den virtuella datorn med kommandot Get-AzureVM :

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

1. Observera DiskName och LUN.

   

2. Fjärrskrivbord till den virtuella datorn. Gå sedan till Datorhantering | Enhetshanteraren | Diskenheter. Titta på egenskaperna för var och en av "Microsoft Virtual Disks"

   

3. LUN-numret här är en referens till det LUN-nummer som du anger när du kopplar den virtuella hårddisken till den virtuella datorn.

4. För Microsoft Virtual Disk går du till fliken Information och går sedan till Drivrutinsnyckeli egenskapslistan. I Värdet noterar du förskjutningen, som är 0002 i följande skärmbild. 0002 anger den PhysicalDisk2 som lagringspoolen refererar till.

   

5. För varje lagringspool dumpar du de associerade diskarna:

Get-StoragePool -FriendlyName AMS1pooldata | Get-PhysicalDisk

Nu kan du använda den här informationen för att associera anslutna virtuella hårddiskar till fysiska diskar i lagringspooler.

När du har mappat VHD:er till fysiska diskar i lagringspooler kan du sedan lossa dem och kopiera dem till ett Premium Storage-konto, och därefter ansluta dem med rätt cacheinställning. Se exemplet i tillägget, steg 8 till och med 12. De här stegen visar hur du extraherar en VM-ansluten VHD-diskkonfiguration till en CSV-fil, kopierar de virtuella hårddiskarna, ändrar cacheinställningarna för diskkonfigurationen och slutligen distribuerar om den virtuella datorn som en virtuell dator i DS-serien med alla anslutna diskar.

VM-lagringsbandbredd och VHD-lagringsdataflöde

Mängden lagringsprestanda beror på den angivna storleken på den virtuella datorn för DS* och VHD-storlekarna. De virtuella datorerna har olika ersättningar för det antal virtuella hårddiskar som kan kopplas och den maximala bandbredd som de stöder (MB/s). Specifika bandbreddsnummer finns i Storlekar på virtuella datorer och molntjänster för Azure.

Ökad IOPS uppnås med större diskstorlekar. Du bör tänka på detta när du tänker på migreringsvägen. Mer information finns i tabellen för IOPS- och disktyper.

Tänk slutligen på att virtuella datorer har olika maximala diskbandbredder som de stöder för alla anslutna diskar. Under hög belastning kan du mätta den maximala diskbandbredden som är tillgänglig för den virtuella datorns rollstorlek. En Standard_DS14 stöder till exempel upp till 512 MB/s. Med tre P30-diskar kan du därför mätta diskbandbredden för den virtuella datorn. Men i det här exemplet kan dataflödesgränsen överskridas beroende på blandningen av läs- och skriv-IO:er.

Nya distributioner

De kommande två avsnitten visar hur du kan distribuera virtuella SQL Server-datorer till Premium Storage. Som tidigare nämnts behöver du inte nödvändigtvis placera OS-disken på Premium Storage. Du kan välja att göra detta om du planerar att placera några intensiva I/O-arbetsbelastningar på den virtuella hårddisken för operativsystemet.

Det första exemplet visar hur du använder befintliga Azure Gallery-avbildningar. Det andra exemplet visar hur du använder en anpassad VM-avbildning som du har i ett befintligt Standard Storage-konto.

Skapa en ny virtuell dator med Premium Storage med galleriavbildning

Exemplet nedan visar hur du placerar operativsystemets VHD på Premium Storage och ansluter Premium Storage VHD:er. Men du kan också placera OS-disken på ett Standard Storage-konto och sedan koppla virtuella hårddiskar som finns i ett Premium Storage-konto. Båda scenarierna visas.

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

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

Steg 1: Skapa ett Premium Storage-konto

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

Steg 2: Skapa en ny molntjänst

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

Steg 3: Reservera en VIP för molntjänsten (valfritt)

#check exisitng reserved VIP
Get-AzureReservedIP

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

Steg 4: Skapa en vm-container

#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

Steg 5: Placera virtuell hårddisk för operativsystem på Standard- eller 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

Steg 6: Skapa virtuell dator

#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

Skapa en ny virtuell dator för att använda Premium Storage med en anpassad avbildning

Det här scenariot visar var du har befintliga anpassade avbildningar som finns i ett Standard Storage-konto. Som nämnts, om du vill placera den virtuella hårddisken för operativsystemet på Premium Storage, måste du kopiera avbildningen som finns i Standard Storage-kontot och överföra den till Premium Storage innan den kan användas. Om du har en avbildning lokalt kan du också använda den här metoden för att kopiera den direkt till Premium Storage-kontot.

Steg 1: Skapa lagringskonto

$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"

Steg 2 Skapa molntjänst

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

Steg 3: Använd befintlig avbildning

Du kan använda en befintlig avbildning. Eller så kan du ta en avbildning av en befintlig dator. Observera att maskinen som du avbildar inte behöver vara en DS*-maskin. När du har bilden visar följande steg hur du kopierar den till Premium Storage-kontot med PowerShell-kommandoleten Start-AzureStorageBlobCopy .

#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  

Steg 4: Kopiera blob mellan lagringskonton

#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  

Steg 5: Kontrollera kopieringsstatusen regelbundet:

$blob | Get-AzureStorageBlobCopyState

Steg 6: Lägg till diskavbild till Azure-disklagring i prenumerationskonto

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

Add-AzureVMImage -ImageName $newimageName -MediaLocation $imageMediaLocation

Steg 7: Skapa den virtuella datorn

Här skapar du den virtuella datorn från avbildningen och kopplar två virtuella hårddiskar för Premium Storage:

$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

Befintliga distributioner som inte använder AlwaysOn-tillgänglighetsgrupper

Det finns olika överväganden för SQL Server-distributioner som inte använder AlwaysOn-tillgänglighetsgrupper och de som gör det. Om du inte använder AlwaysOn och har en befintlig fristående SQL Server kan du uppgradera till Premium Storage med hjälp av en ny molntjänst och ett nytt lagringskonto. Överväg följande alternativ:

• Skapa en ny virtuell SQL Server-dator. Du kan skapa en ny virtuell SQL Server-dator som använder ett Premium Storage-konto enligt beskrivningen i Nya distributioner. Säkerhetskopiera och återställ sedan din SQL Server-konfiguration och dina användardatabaser. Programmet måste uppdateras för att referera till den nya SQL Server om det används internt eller externt. Du skulle behöva kopiera alla "out of db"-objekt som om du genomförde en parallell SQL Server-migrering. Detta omfattar objekt som inloggningar, certifikat och länkade servrar.
• Migrera en befintlig virtuell SQL Server-dator. Detta kräver att du tar den virtuella SQL Server-datorn offline och sedan överför den till en ny molntjänst, vilket omfattar kopiering av alla anslutna virtuella hårddiskar till Premium Storage-kontot. När den virtuella datorn är online refererar programmet till serverns värdnamn som tidigare. Tänk på att storleken på den befintliga disken påverkar prestandaegenskaperna. Till exempel avrundas en 400 GB-disk upp till en P20. Om du vet att du inte kräver den diskprestandan kan du återskapa den virtuella datorn som en virtuell dator i DS-serien och ansluta virtuella Premium Storage-hårddiskar med den storlek/prestandaspecifikation som du behöver. Sedan kan du koppla från och koppla om SQL DB-filerna.

Om din SQL Server används externt ändras molntjänstens VIP. Du måste också uppdatera slutpunkter, ACL:er och DNS-inställningar.

Befintliga distributioner som använder AlwaysOn-tillgänglighetsgrupper

I det här avsnittet tittar vi först på hur AlwaysOn interagerar med Azure-nätverk. Sedan delar vi upp migreringar i två scenarier: migreringar där viss stilleståndstid kan tolereras och migreringar där du måste uppnå minimal stilleståndstid.

Lokala SQL Server AlwaysOn-tillgänglighetsgrupper använder en lokal lyssnare som registrerar ett virtuellt DNS-namn tillsammans med en IP-adress som delas mellan en eller flera SQL-servrar. När klienter ansluter dirigeras de via lyssnarens IP-adress till den primära SQL-servern. Det här är servern som äger AlwaysOn IP-resursen vid den tidpunkten.

I Microsoft Azure kan du bara ha en IP-adress tilldelad till ett nätverkskort på den virtuella datorn, så för att uppnå samma abstraktionslager som lokalt använder Azure DEN IP-adress som har tilldelats till de interna/externa lastbalanserarna (ILB/ELB). IP-resursen som delas mellan servrarna är inställd på samma IP-adress som ILB/ELB. Detta publiceras i DNS och klienttrafiken skickas via ILB/ELB till den primära SQL Server-repliken. ILB/ELB vet vilken SQL Server som är primär eftersom den använder avsökningar för att avsöka IP-resursen AlwaysOn. I det föregående exemplet avsöker det varje nod med en slutpunkt refererad av ELB/ILB; den som svarar blir den primära SQL Servern.

Migrera AlwaysOn-distributioner som kan tillåta viss stilleståndstid

Det finns två strategier för att migrera AlwaysOn-distributioner som möjliggör viss stilleståndstid:

1. Lägga till fler sekundära repliker i ett befintligt AlwaysOn-kluster
2. Migrera till ett nytt AlwaysOn-kluster

1. Lägg till fler sekundära repliker i ett befintligt AlwaysOn-kluster

En strategi är att lägga till fler sekundärfiler i AlwaysOn-tillgänglighetsgruppen. Du måste lägga till dessa i en ny molntjänst och uppdatera lyssnaren med den nya lastbalanserarens IP-adress.

Stilleståndstider:

• Klusterverifiering.
• Testa Always On-överflyttningar för nya sekundärdatabaser.

Om du använder Windows Storage-pooler i den virtuella datorn för högre I/O-dataflöde tas dessa offline under en fullständig klusterverifiering. Verifieringstestet krävs när du lägger till noder i klustret. Den tid det tar att köra testet kan variera, så du bör testa detta i din representativa testmiljö för att få en ungefärlig tid på hur lång tid det tar.

Du bör avsätta tid för att utföra manuell överflyttning och kaostestning på de nyss tillagda noderna för att säkerställa att Always On-hög tillgänglighet fungerar som förväntat.

1. Skapa två nya SQL-servrar i en ny molntjänst med ansluten Premium Storage.

2. Kopiera över fullständiga säkerhetskopior och återställ med NORECOVERY.

3. Kopiera över "out of user DB"-beroende objekt, till exempel inloggningar osv.

4. Skapa en ny intern lastbalanserare (ILB) eller använd en extern lastbalanserare (ELB) och konfigurera sedan lastbalanserade slutpunkter på båda de nya noderna.

   Anmärkning

   Kontrollera att alla noder har rätt slutpunktskonfiguration innan du fortsätter

5. Stoppa användar-/programåtkomst till SQL Server (om du använder lagringspooler).

6. Stoppa SQL Server Engine Services på alla noder (om du använder lagringspooler).

7. Lägg till nya noder i klustret och kör fullständig validering.

8. När valideringen har slutförts startar du alla SQL Server-tjänster.

9. Säkerhetskopiera transaktionsloggar och återställa användardatabaser.

10. Lägg till nya noder i AlwaysOn-tillgänglighetsgruppen och placera replikeringen i Synkron.

11. Lägg till IP-adressresursen för den nya Cloud Service ILB/ELB via PowerShell för Always On baserat på exemplet med flera webbplatser i tillägget. I Windows-klustring anger du De möjliga ägarna av IP-adressresursen till de nya gamla noderna. Se avsnittet "Lägga till IP-adressresurs i samma undernät" i tillägget.

12. Redundansväxling till en av de nya noderna.

13. Gör de nya noderna till automatisk övergångspartner och testa övergångstester.

14. Ta bort ursprungliga noder från tillgänglighetsgruppen.

Fördelar

• Nya SQL-servrar kan testas (SQL Server och program) innan de läggs till i AlwaysOn.
• Du kan ändra storleken på den virtuella datorn och anpassa lagringen efter dina exakta krav. Det skulle dock vara fördelaktigt att behålla alla SQL-filsökvägar på samma sätt.
• Du kan styra när överföringen av DB-säkerhetskopiorna till sekundära repliker startas. Detta skiljer sig från att använda Azure Start-AzureStorageBlobCopy-kommandoleten för att kopiera virtuella hårddiskar, eftersom det är en asynkron kopia.

Nackdelar

• När du använder Windows Storage-pooler uppstår det avbrott i klustret under den fullständiga valideringen av klustret för de nya noderna.
• Beroende på SQL Server-versionen och det befintliga antalet sekundära repliker kanske du inte kan lägga till fler sekundära repliker utan att ta bort befintliga sekundärrepliker.
• Det kan ta lång tid att överföra SQL-data när du konfigurerar sekundärfilerna.
• Det finns ytterligare kostnader under migreringen medan du har nya datorer som körs parallellt.

2. Migrera till ett nytt AlwaysOn-kluster

En annan strategi är att skapa ett helt nytt Always On-kluster med helt nya noder i den nya molntjänsten och sedan omdirigera klienterna att använda det.

Stilleståndstider

Det finns stilleståndstid när du överför program och användare till den nya AlwaysOn-lyssnaren. Stilleståndstiden beror på:

• Den tid det tar att återställa de slutliga säkerhetskopieringarna av transaktionsloggar till databaser på nya servrar.
• Den tid det tar att uppdatera klientprogram för att använda den nya AlwaysOn-lyssnaren.

Fördelar

• Du kan testa den faktiska produktionsmiljön, SQL Server och operativsystemets byggändringar.
• Du har möjlighet att anpassa lagringen och eventuellt minska storleken på den virtuella datorn. Detta kan leda till kostnadsminskningar.
• Du kan uppdatera din SQL Server-version eller -build under den här processen. Du kan också uppgradera operativsystemet.
• Det tidigare AlwaysOn-klustret kan fungera som ett stabilt återställningsmål.

Nackdelar

• Du måste ändra lyssnarens DNS-namn om du vill att båda AlwaysOn-klustren ska köras samtidigt. Detta lägger till administrativt extraarbete under migreringen eftersom klientapplikationer måste återspegla det nya lyssnarnamnet.
• Du måste implementera en synkroniseringsmekanism mellan de två miljöerna för att hålla dem så nära som möjligt för att minimera de slutliga synkroniseringskraven före migreringen.
• Det finns en extra kostnad under migreringen medan du har den nya miljön igång.

Migrera AlwaysOn-distributioner för minimal stilleståndstid

Det finns två strategier för att migrera AlwaysOn-distributioner för minimal stilleståndstid:

1. Använd en befintlig sekundär: enskild sajt
2. Använd befintliga sekundära repliker: Flera sajter

1. Använd en befintlig sekundär: Single-Site

En strategi för minimal stilleståndstid är att ta ett befintligt moln sekundärt och ta bort det från den aktuella molntjänsten. Kopiera sedan de virtuella hårddiskarna till det nya Premium Storage-kontot och skapa den virtuella datorn i den nya molntjänsten. Uppdatera sedan lyssnaren för klusterkonfiguration och växling vid fel.

Stilleståndstider

• Det uppstår driftstopp när du uppdaterar den sista noden med den lastbalanserade slutpunkten.
• Klientåteranslutningen kan fördröjas beroende på klientens/DNS-konfigurationen.
• Det finns ytterligare stilleståndstid om du väljer att koppla från gruppen AlwaysOn-kluster för att växla ut IP-adresserna. Du kan undvika detta genom att använda ett ELLER-beroende och möjliga ägare för den tillagda IP-adressresursen. Se avsnittet "Lägga till IP-adressresurs i samma undernät" i tillägget.

Fördelar

• Ingen extra kostnad tillkommer under migreringen.
• En en-till-en-migrering.
• Minskad komplexitet.
• Tillåter ökad IOPS från Premium Storage-SKU:er. När diskarna kopplas från den virtuella datorn och kopieras till den nya molntjänsten kan ett verktyg från tredje part användas för att öka VHD-storleken, vilket ger högre dataflöden. Mer information om hur du ökar VHD-storlekar finns i den här forumdiskussionen.

Nackdelar

• Det finns en tillfällig förlust av HA och DR under migreringen.
• Eftersom det här är en 1:1-migrering måste du använda en minsta VM-storlek som stöder ditt antal virtuella hårddiskar, så du kanske inte kan minska storleken på dina virtuella datorer.
• Det här scenariot skulle använda Kommandoleten Azure Start-AzureStorageBlobCopy , som är asynkron. Det finns inget SLA när kopieringen är klar. Tiden för kopiorna varierar, även om detta beror på väntetiden i kön beror det också på mängden data som ska överföras. Kopieringstiden ökar om överföringen går till ett annat Azure-datacenter som stöder Premium Storage i en annan region. Om du bara har två noder bör du överväga en möjlig åtgärd om kopian tar längre tid än vid testning. Detta kan innehålla följande idéer.
  • Lägg till en tillfällig 3:e SQL Server-nod för HA före migreringen med överenskommen stilleståndstid.
  • Kör migreringen utanför det schemalagda Azure-underhållet.
  • Kontrollera att du har konfigurerat klusterkvorumet korrekt.

Steg på hög nivå

Det här dokumentet visar inte ett fullständigt exempel från slutpunkt till slutpunkt, men tillägget innehåller information som kan användas för att utföra detta.

• Samla in diskkonfiguration och ta bort noden (ta inte bort anslutna virtuella hårddiskar).
• Skapa ett Premium Storage-konto och kopiera virtuella hårddiskar från Standard Storage-kontot
• Skapa en ny molntjänst och distribuera om den virtuella SQL2-datorn i den molntjänsten. Skapa den virtuella datorn genom att använda den ursprungligen kopierade virtuella hårddisken för operativsystemet och ansluta de kopierade virtuella hårddiskarna.
• Konfigurera ILB/ELB och lägg till slutpunkter.
• Uppdatera lyssnaren med antingen:
  • Koppla från AlwaysOn-gruppen och uppdatera Always On Listener med ny IP-adress för ILB/ELB.
  • Eller lägga till IP-adressresursen för den nya Cloud Service ILB/ELB via PowerShell i Windows-klustring. Ange sedan Möjliga ägare av IP-adressresursen till den migrerade noden SQL2 och ange detta som OR-beroende i nätverksnamnet. Se avsnittet "Lägga till IP-adressresurs i samma undernät" i tillägget.
• Kontrollera DNS-konfiguration/spridning till klienterna.
• Migrera en virtuell SQL1-dator och gå igenom steg 2–4.
• Om du använder steg 5ii lägger du till SQL1 som möjlig ägare för den tillagda IP-adressresursen
• Testa övergångar vid fel.

2. Använd befintliga sekundära repliker: Multi-Site-miljö

Om du har noder i mer än ett Azure-datacenter (DC) eller om du har en hybridmiljö kan du använda en AlwaysOn-konfiguration i den här miljön för att minimera stilleståndstiden.

Metoden är att ändra AlwaysOn-synkroniseringen till Synkron för det lokala eller sekundära Azure-datacentret och sedan genomföra en failover till den SQL Server. Kopiera sedan de virtuella hårddiskarna till ett Premium Storage-konto och distribuera om datorn till en ny molntjänst. Uppdatera lyssnaren och växla sedan tillbaka.

Stilleståndstider

Stilleståndstiden består av tiden det tar för redundansväxling till det alternativa datacentret och tillbaka. Det beror också på din klient-/DNS-konfiguration och klientåteranslutningen kan fördröjas. Tänk dig följande exempel på en AlwaysOn-hybridkonfiguration:

Fördelar

• Du kan använda befintlig infrastruktur.
• Du har möjlighet att föruppgradera Azure Storage på DR Azure DC först.
• DR Azure DC-lagringen kan konfigureras om.
• Det finns minst två failovers under migreringen, exklusive testväxlingar.
• Du behöver inte flytta SQL Server-data med säkerhetskopiering och återställning.

Nackdelar

• Beroende på klientåtkomst till SQL Server kan svarstiden öka när SQL Server körs i en alternativ domänkontrollant till programmet.
• Kopieringstiden för virtuella hårddiskar till Premium Storage kan ta lång tid. Detta kan påverka ditt beslut om noden ska behållas i tillgänglighetsgruppen. Tänk på detta när loggintensiva arbetsbelastningar körs under migreringen, eftersom den primära noden måste behålla de oreplikerade transaktionerna i transaktionsloggen. Därför kan detta växa avsevärt.
• Det här scenariot skulle använda Kommandoleten Azure Start-AzureStorageBlobCopy , som är asynkron. Det finns inget serviceavtal när det är klart. Tiden för kopiorna varierar, även om detta beror på väntetiden i kön, beror det också på mängden data som ska överföras. Därför har du bara en nod i ditt andra datacenter. Du bör vidta åtgärder om kopiering tar längre tid än vid testning. Dessa åtgärdssteg innehåller följande idéer:
  • Lägg till en tillfällig 2:a SQL-nod för HA före migreringen med överenskommen stilleståndstid.
  • Kör migreringen utanför det schemalagda Azure-underhållet.
  • Kontrollera att du har konfigurerat klusterkvorumet korrekt.

Det här scenariot förutsätter att du har dokumenterat installationen och vet hur lagringen mappas för att göra ändringar för optimala inställningar för diskcache.

Steg på hög nivå

• Gör den lokala/alternativa Azure DC till SQL Server Primary och gör den till den andra automatiska redundanspartnern (AFP).
• Samla in information om diskkonfiguration från SQL2 och ta bort noden (ta inte bort anslutna virtuella hårddiskar).
• Skapa ett Premium Storage-konto och kopiera virtuella hårddiskar från Standard Storage-kontot.
• Skapa en ny molntjänst och skapa den virtuella SQL2-datorn med tillhörande Premiums Storage-diskar.
• Konfigurera ILB/ELB och lägg till slutpunkter.
• Uppdatera Always On Listener med ny IP-adress för ILB/ELB och testa redundansväxling.
• Kontrollera DNS-konfigurationen.
• Ändra AFP till SQL2 och migrera sedan SQL1 och gå igenom steg 2–5.
• Testa redundans.
• Växla tillbaka AFP till SQL1 och SQL2

Bilaga: Migrera ett Always On-kluster för flera platser till Premium Storage

Resten av den här artikeln innehåller ett detaljerat exempel på hur du konverterar ett Always On-kluster för flera platser till Premium Storage. Den konverterar också lyssnaren från att använda en extern lastbalanserare (ELB) till en intern lastbalanserare (ILB).

Miljö

• Windows 2k12 /SQL 2k12
• 1 DB-filer på SP
• 2 x lagringspooler per nod

Virtuell dator:

I det här exemplet ska vi demonstrera övergången från en ELB till ILB. ELB var tillgängligt före ILB, så detta visar hur du växlar till ILB under migreringen.

Försteg: Ansluta till prenumeration

Add-AzureAccount

#Set up subscription
Get-AzureSubscription

Steg 1: Skapa nytt lagringskonto och en molntjänst

$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

Steg 2: Öka antalet tillåtna fel på resurser <Valfritt>

På vissa resurser som tillhör alwayson-tillgänglighetsgruppen finns det gränser för hur många fel som kan inträffa under en period, där klustertjänsten försöker starta om resursgruppen. Vi rekommenderar att du ökar detta medan du går igenom den här proceduren, eftersom om du inte manuellt redundansväxlar och utlöser redundansväxlingar genom att stänga av datorer kan du komma nära den här gränsen.

Det vore klokt att dubbla feltilldelningen. Om du vill göra detta i Klusterhanteraren för växling vid fel går du till Egenskaperna för resursgruppen AlwaysOn:

Ändra maximalt antal fel till 6.

Steg 3: Tilläggs-IP-adressresurs för klustergrupp <valfritt>

Om du bara har en IP-adress för klustergruppen och detta är justerat till molnundernätet, se upp, om du av misstag tar offline alla klusternoder i molnet i nätverket kan inte kluster-IP-resursen och klustrets nätverksnamn komma online. I den här situationen förhindrar den uppdateringar av andra klusterresurser.

Steg 4: DNS-konfiguration

Implementeringen av en smidig övergång beror på hur DNS används och uppdateras. När Always On har installerats skapar den en Windows-klusterresursgrupp. Om du öppnar Failover Cluster Manager ser du att den har minst tre resurser; de två som dokumentet refererar till är:

• Virtuellt nätverksnamn (VNN) – det DNS-namn som klienter ansluter till när de vill ansluta till SQL-servrar via Always On.
• IP-adressresurs – IP-adressen som är associerad med det virtuella nätverket, du kan ha mer än en och i en konfiguration med flera platser har du en IP-adress per plats/undernät.

När du ansluter till SQL Server hämtar SQL Server-klientdrivrutinen de DNS-poster som är associerade med lyssnaren och försöker ansluta till varje AlwaysOn-associerad IP-adress. Därefter diskuterar vi några faktorer som kan påverka detta.

Antalet konkurrerande DNS-poster som är associerade med lyssnarnamnet beror inte bara på antalet associerade IP-adresser, utan även inställningen "RegisterAllIpProviders" i Failover-Klustring för Always On VNN-resursen.

När du distribuerar AlwaysOn i Azure finns det olika steg för att skapa lyssnaren och IP-adresserna. Du måste manuellt konfigurera "RegisterAllIpProviders" till 1. Detta skiljer sig från en lokal AlwaysOn-distribution där den redan är inställd på 1.

Om "RegisterAllIpProviders" är 0 visas bara en DNS-post i DNS som är associerad med lyssnaren:

Om "RegisterAllIpProviders" är 1:

Koden nedan dumpar VNN-inställningarna och ställer in dem automatiskt åt dig. För att ändringen ska börja gälla måste du koppla från det virtuella nätverket och aktivera det igen. Detta tar lyssnaren offline och orsakar avbrott i klientanslutningen.

##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

I ett senare migreringssteg måste du uppdatera AlwaysOn-lyssnaren med en uppdaterad IP-adress som refererar till en lastbalanserare, vilket innebär att en IP-adressresurs tas bort och läggs till. Efter IP-uppdateringen måste du se till att den nya IP-adressen har uppdaterats i DNS-zonen och att klienterna uppdaterar sin lokala DNS-cache.

Om dina klienter finns i ett annat nätverkssegment och refererar till en annan DNS-server måste du tänka på vad som händer med DNS-zonöverföring under migreringen, eftersom programmets återanslutningstid begränsas av minst zonöverföringstiden för alla nya IP-adresser för lyssnaren. Om du är under tidspress här bör du diskutera och testa att genomdriva en inkrementell zonöverföring med dina Windows-team och även sätta ner TTL-värdet för DNS-värdposten så att klienterna uppdateras. Mer information finns i Inkrementella zonöverföringar och Start-DnsServerZoneTransfer.

Som standard är TTL för DNS-posten som är associerad med lyssnaren i Always On i Azure 1200 sekunder. Du kanske vill minska detta om du är under tidsbegränsning under migreringen för att säkerställa att klienterna uppdaterar sin DNS med den uppdaterade IP-adressen för lyssnaren. Du kan se och ändra konfigurationen genom att visa konfigurationen av VNN:

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

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

Inställningar för klientprogram

Om SQL-klientprogrammet stöder .NET 4.5 SQLClient kan du använda nyckelordet MULTISUBNETFAILOVER=TRUE. Det här nyckelordet bör tillämpas eftersom det möjliggör snabbare anslutning till SQL AlwaysOn-tillgänglighetsgruppen under redundansväxlingen. Den genomgår alla IP-adresser som är associerade med Always On-lyssnaren parallellt och utför ett mer aggressivt tempo för återförsök av TCP-anslutningar under ett failover.

Mer information om de tidigare inställningarna finns i MultiSubnetFailover Keyword and Associated Features (MultiSubnetFailover Keyword och Tillhörande funktioner). Se även SqlClient-stöd för hög tillgänglighet, haveriberedskap.

Steg 5: Klusterkvoruminställningar

Eftersom du kommer att ta ut minst en SQL Server åt gången bör du ändra klusterkvoruminställningen. Om du använder Filresursvittne (FSW) med två noder bör du ange kvorum för att tillåta nodmajoritet och använda dynamisk röstning, vilket gör att en enda nod kan stå kvar.

Set-ClusterQuorum -NodeMajority  

Mer information om hur du hanterar och konfigurerar klusterkvorum finns i Konfigurera och hantera kvorumet i ett Windows Server 2012-redundanskluster.

Steg 6: Extrahera befintliga slutpunkter och ACL:er

#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"  

Spara den här texten i en fil.

Steg 7: Ändra redundanspartner och replikeringslägen

Om du har fler än två SQL-servrar bör du ändra omkopplingen för en annan sekundär server i ett annat datacenter eller lokalt till "Synkron" och göra den till en automatisk omkopplingspartner (AFP), så att du bibehåller hög tillgänglighet medan du gör ändringar. Du kan göra detta genom TSQL eller ändra genom SSMS.

Steg 8: Ta bort sekundär virtuell dator från molntjänsten

Du bör planera att migrera en sekundär molnnod först. Om den här noden för närvarande är primär bör du initiera en manuell redundansväxling.

$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

Steg 9: Ändra inställningar för diskcachelagring i CSV-filen och spara

För datavolymer bör dessa anges till READONLY.

För TLOG-volymer ska dessa anges till NONE.

Steg 10: Kopiera VHDS

#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
}

Du kan kontrollera kopieringsstatusen för de virtuella hårddiskarna till Premium Storage-kontot:

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
}

Vänta tills alla dessa har registrerats som lyckade.

Information om enskilda blobar:

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

Steg 11: Registrera OS-disk

#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"

Steg 12: Importera sekundär till ny molntjänst

Koden nedan använder också det tillagda alternativet där du kan importera maskinen och använda den bevarande VIP-funktionen.

#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)

Steg 13: Skapa ILB på New Cloud Svc, Lägg till lastbalanserade slutpunkter och ACL:er

#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!!!!!!!!!#####

Steg 14: Uppdatera alltid på

#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

Ta nu bort den gamla IP-adressen för molntjänsten.

Steg 15: DNS-uppdateringskontroll

Du bör nu kontrollera DNS-servrar på dina SQL Server-klientnätverk och se till att klusterhantering har lagt till den extra värdposten för den tillagda IP-adressen. Om dessa DNS-servrar inte har uppdaterats kan du överväga att tvinga fram en DNS-zonöverföring och se till att klienterna i undernätet kan matcha båda AlwaysOn IP-adresserna, så du behöver inte vänta på automatisk DNS-replikering.

Steg 16: Konfigurera om AlwaysOn

Nu väntar du på att den sekundära noden som migrerades ska synkroniseras om helt med den lokala noden och växla till synkron replikeringsnod och göra den till AFP.

Steg 17: Migrera andra noden

$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

Steg 18: Ändra inställningarna för diskcachelagring i CSV-filen och spara

För datavolymer ska cacheinställningarna anges till READONLY.

För TLOG-volymer ska cacheinställningarna anges till NONE.

Steg 19: Skapa nytt oberoende lagringskonto för sekundär nod

$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

Steg 20: Kopiera VHDS

#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

Du kan kontrollera statusen för VHD-kopiering för alla virtuella hårddiskar:

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
}

Vänta tills alla dessa har registrerats som lyckade.

Information om enskilda blobar:

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

Steg 21: Registrera OS-disk

#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

Steg 22: Lägg till lastbalanserade slutpunkter och ACL:er

#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

Steg 23: Testa omkoppling vid fel

Vänta tills den migrerade noden synkroniseras med den lokala AlwaysOn-noden. Placera den i synkront replikeringsläge och vänta tills den har synkroniserats. Sedan sker övergång från lokala system till den första noden som migrerats, vilket är AFP. När det har fungerat ändrar du den senaste migrerade noden till AFP.

Du bör testa failover mellan alla noder och genomföra kaostester för att säkerställa att failover fungerar som förväntat och på ett tidsenligt sätt.

Steg 24: Sätt tillbaka klusterkvoruminställningar/DNS TTL/Redundans-Pntrs/Synkroniseringsinställningar

Lägga till IP-adressresurs i samma undernät

Om du bara har två SQL-servrar och vill migrera dem till en ny molntjänst, men vill behålla dem i samma undernät, kan du undvika att ta lyssnaren offline för att ta bort den ursprungliga AlwaysOn-IP-adressen och lägga till den nya IP-adressen. Om du migrerar de virtuella datorerna till ett annat undernät behöver du inte göra det eftersom det finns ytterligare ett klusternätverk som refererar till undernätet.

När du har tagit upp den migrerade sekundära resursen och lagt till den nya IP-adressresursen för den nya molntjänsten innan du redundansväxlar den befintliga primära, bör du vidta följande steg i Klusterredundanshanteraren:

Information om hur du lägger till IP-adress finns i tillägget steg 14.

1. För den aktuella IP-adressresursen ändrar du den möjliga ägaren till "Befintlig primär SQL Server", i exemplet "dansqlams4":

   

2. För den nya IP-adressresursen ändrar du den möjliga ägaren till "Migrerad sekundär SQL Server", i exemplet "dansqlams5":

   

3. När detta har angetts kan du utföra en failover, och när den sista noden migreras ska Möjliga ägare redigeras så att noden läggs till som en möjlig ägare:

   

Ytterligare resurser

• Azure Premium Storage
• Virtuella datorer
• SQL Server i Azure Virtual Machines