Dela via

Använd Azure Premium Storage med SQL Server på Virtual Machines

  • Artikel

Ö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å IaaS-Virtual Machines.

Viktigt

Azure har två olika distributionsmodeller för att skapa och arbeta med resurser: Resource Manager och klassisk. Den här artikeln beskriver hur du använder den klassiska distributionsmodellen. Microsoft rekommenderar att de flesta nya distributioner använder Resource Manager-modellen.

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 inkluderar 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. Det här 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 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.

Förutsättningar 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 DS-serien Virtual Machines (VM). Om du inte har använt DS Series-datorer 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 AlwaysOn i Azure refererar AlwaysOn-lyssnaren till den interna eller externa Azure-Load Balancer IP-adress 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.

Anteckning

En DS*-serie måste vara den första virtuella datorn som distribueras till den nya molntjänsten.

Regionala virtuella nätverk

För virtuella DS*-datorer måste du konfigurera Virtual Network (VNET) som är värd för dina virtuella datorer så att de är regionala. Detta "breddar" det virtuella nätverket är att tillåta att de större virtuella datorerna etableras i andra kluster och tillåter 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.

RegionalVNET

Du kan skapa ett Microsoft-supportärende för migrering 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 virtualnetworkSite-elementet med en location-egenskap . 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>

Om du vill flytta detta till ett regionalt virtuellt nätverk i Europa, västra ä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 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 datavolymdiskar 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 kopplats kan cacheinställningen inte ändras. Du skulle behöva koppla från och återansluta den virtuella hårddisken med en uppdaterad cacheinställning.

Windows-lagringsutrymmen

Du kan använda Windows Lagringsutrymmen som du gjorde med tidigare Standard Storage, vilket gör att du kan 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 ett värde 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 Virtuella Azure-diskar som mappar till 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 Premium Storage rekommenderade cacheinställningarna 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).

Anteckning

Om du har SQL Server data och loggfiler på samma volym beror cachelagringsalternativet som du väljer på I/O-åtkomstmönstren för dina databasarbetsbelastningar. Endast testning kan visa vilket cachelagringsalternativ som är bäst för det här scenariot.

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 därefter för varje disk.

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

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.

    DisknameAndLUN

  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"

    VirtualDiskEgenskaper

  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 Drivrutinsnyckel i listan Egenskap. I Värdet noterar du förskjutningen, som är 0002 på följande skärmbild. 0002 anger den PhysicalDisk2 som lagringspoolen refererar till.

    VirtualDiskPropertyDetails

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

Get-StoragePool -FriendlyName AMS1pooldata | Get-PhysicalDisk

GetStoragePool

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 virtuella hårddiskar till fysiska diskar i lagringspooler kan du sedan koppla från och kopiera dem till ett Premium Storage konto och sedan koppla dem med rätt cacheinställning. Se exemplet i bilagan, 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 DS*-datorn och VHD-storlekarna. De virtuella datorerna har olika ersättningar för antalet 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 maximal diskbandbredd 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

Följande två avsnitt visar hur du kan distribuera SQL Server virtuella 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 tänker 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.

Anteckning

De här exemplen förutsätter att du redan har skapat ett regionalt virtuellt nätverk.

Exemplet nedan visar hur du placerar den virtuella hårddisken för operativsystemet på Premium Storage och ansluter Premium Storage virtuella hårddiskar. Men du kan också placera OS-disken i 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 MOLNTJÄNST-VIP (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 VHD 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 operativsystem på Premium Storage måste du kopiera avbildningen som finns i Standard Storage-kontot och överföra dem till en 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 datorn som du avbildningen inte behöver vara DS*-dator. När du har bilden visar följande steg hur du kopierar den till Premium Storage-kontot med PowerShell-kommandot 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 regelbundet kopieringsstatus:

$blob | Get-AzureStorageBlobCopyState

Steg 6: Lägg till avbildningsdisk till Azure-disklagringsplats i prenumeration

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

Add-AzureVMImage -ImageName $newimageName -MediaLocation $imageMediaLocation

Anteckning

Du kanske upptäcker att även om statusrapporterna lyckas kan du fortfarande få ett disklånefel. I det här fallet väntar du cirka 10 minuter.

Steg 7: Skapa den virtuella datorn

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

$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

Anteckning

För befintliga distributioner, se först avsnittet Krav i den här artikeln.

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 SQL Server virtuell dator. Du kan skapa en ny SQL Server virtuell dator som använder ett Premium Storage konto, enligt beskrivningen i Nya distributioner. Säkerhetskopiera och återställ sedan din SQL Server konfiguration och 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 gjorde en SxS-migrering (Sida vid sida) SQL Server migrering. Detta inkluderar objekt som inloggningar, certifikat och länkade servrar.
  • Migrera en befintlig SQL Server virtuell dator. Detta kräver att du tar den SQL Server virtuella datorn offline och sedan överför den till en ny molntjänst, vilket inkluderar 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 disk på 400 GB upp till en P20. Om du vet att du inte behöver diskprestanda kan du återskapa den virtuella datorn som en virtuell dator i DS-serien och ansluta Premium Storage virtuella hårddiskar med den storlek/prestandaspecifikation som du behöver. Sedan kan du koppla från och koppla om SQL DB-filerna.

Anteckning

När du kopierar VHD-diskarna bör du vara medveten om storleken, beroende på storleken innebär vilken Premium Storage disktyp de hamnar i, vilket avgör diskprestandaspecifikationen. Azure avrundar upp till närmaste diskstorlek, så om du har en disk på 400 GB avrundas den upp till en P20. Beroende på dina befintliga I/O-krav för den virtuella hårddisken i operativsystemet kanske du inte behöver migrera detta till ett Premium Storage konto.

Om din SQL Server nås 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

Anteckning

För befintliga distributioner, se först avsnittet Krav i den här artikeln.

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 Server. Det här är servern som äger AlwaysOn IP-resursen vid den tidpunkten.

DistributionerUseAlways På

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 abstraktionsnivå som lokalt använder Azure den IP-adress som är tilldelad till interna/externa lastbalanserare (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 är primär eftersom den använder avsökningar för att avsöka AlwaysOn IP-resursen. I föregående exempel avsöker den varje nod som har en slutpunkt som refereras av ELB/ILB, beroende på vilket som svarar är den primära SQL Server.

Anteckning

Både ILB och ELB tilldelas till en viss Azure-molntjänst, och därför innebär all molnmigrering i Azure troligen att Load Balancer IP-ändringar.

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:
  • Klustervalidering.
  • Testa AlwaysOn-redundans för nya sekundärfiler.

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 klustervalidering. Valideringstestet 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 etablera tid där du kan utföra manuell redundans- och kaostestning på de nyligen tillagda noderna för att säkerställa always on-hög tillgänglighet som förväntat.

DeploymentUseAlways On2

Anteckning

Du bör stoppa alla instanser av SQL Server där lagringspoolerna används innan valideringen körs.

Övergripande steg

  1. Skapa två nya SQL-servrar i en ny molntjänst med anslutna 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 Load Balancer (ILB) eller använd en extern Load Balancer (ELB) och konfigurera sedan lastbalanserade slutpunkter på båda de nya noderna.

    Anteckning

    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 Services.

  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 platser i bilagan. I Windows-klustring anger du De möjliga ägarna av IP-adressresursen till de nya noderna gamla. Se avsnittet "Lägga till IP-adressresurs i samma undernät" i bilagan.

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

  13. Gör de nya noderna till automatiska redundanspartner och testa redundansväxlingar.

  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 bra att behålla alla SQL-filsökvägar på samma sätt.
  • Du kan styra när överföringen av databassäkerhetskopiorna till de sekundära replikerna 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 klusteravbrott under den fullständiga klusterverifieringen för de nya ytterligare noderna.
  • Beroende på SQL Server version 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 kostar extra 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 AlwaysOn-kluster med helt nya noder i den nya molntjänsten och sedan omdirigera klienterna till att använda det.

Stilleståndstider

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

  • Tiden det tar att återställa slutgiltiga säkerhetskopior 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 potentiellt minska storleken på den virtuella datorn. Detta kan leda till kostnadsminskning.
  • Du kan uppdatera din SQL Server version eller version 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 administrationskostnader under migreringen eftersom klientprogramsträngar 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ända en befintlig sekundär: enskild plats
  2. Använda befintliga sekundära repliker: Flera platser

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 i klustring och redundans.

Stilleståndstider
  • Det uppstår stilleståndstid när du uppdaterar den sista noden med lastbalanserad slutpunkt.
  • Återanslutningen av klienten kan fördröjas beroende på klientens/DNS-konfigurationen.
  • Det finns ytterligare stilleståndstid om du väljer att koppla från alwayson-klustergruppen 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 bilagan.

Anteckning

När du vill att den tillagda noden ska delta som en AlwaysOn-redundanspartner måste du lägga till en Azure-slutpunkt med en referens till den lastbalanserade uppsättningen. När du kör kommandot Add-AzureEndpoint för att göra detta kan aktuella anslutningar förbli öppna, men nya anslutningar till lyssnaren kan inte upprättas förrän lastbalanseraren har uppdaterats. Vid testningen av detta sågs de senaste 90–120 sekunderna, detta bör testas.

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 storleken på virtuella hårddiskar 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.
  • I det här scenariot används Azure Start-AzureStorageBlobCopy-kommandoleten , som är asynkron. Det finns inget serviceavtal för kopiering. 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 2 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 schemalagt underhåll i Azure.
    • Kontrollera att du har konfigurerat klusterkvorumet korrekt.
Övergripande steg

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.

MinimalDowntime

  • 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 med den kopierade ursprungliga virtuella hårddisken för operativsystem och koppla de kopierade virtuella hårddiskarna.
  • Konfigurera ILB/ELB och lägg till slutpunkter.
  • Uppdatera lyssnaren med antingen:
    • Koppla från AlwaysOn-gruppen och uppdatera AlwaysOn-lyssnaren med den nya IP-adressen 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 bilagan.
  • 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 redundans.

2. Använd befintliga sekundära repliker: Flera platser

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 den lokala eller sekundära Azure DC och sedan redundansväxla 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 för redundansväxling till den alternativa domänkontrollanten och tillbaka. Det beror också på din klient/DNS-konfiguration och din klientåteranslutning kan fördröjas. Tänk dig följande exempel på en AlwaysOn-hybridkonfiguration:

MultiSite1

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å redundansväxlingar under migreringen, exklusive redundanstest.
  • 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 vara lång. 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 opublicerade transaktionerna i transaktionsloggen. Därför kan detta växa avsevärt.
  • I det här scenariot används Azure Start-AzureStorageBlobCopy-kommandoleten , 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. De här åtgärdsstegen 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 schemalagt underhåll i Azure.
    • 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.

Övergripande steg

Multisite2

  • Gör den lokala/alternativa Azure DC till den SQL Server primära och gör den till den andra automatiska redundanspartnern (AFP).
  • Samla in diskkonfigurationsinformation 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 dess Premiums Storage-diskar anslutna.
  • Konfigurera ILB/ELB och lägg till slutpunkter.
  • Uppdatera Always On Listener med ny IP-adress för ILB/ELB och testa redundans.
  • 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 AlwaysOn-kluster med 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

Bilaga 1

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.

Bilaga 2

Försteg: Ansluta till prenumeration

Add-AzureAccount

#Set up subscription
Get-AzureSubscription

Steg 1: Skapa ett 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 redundans genom att stänga av datorer kan du komma nära den här gränsen.

Det skulle vara klokt att fördubbla ersättningen för fel. Om du vill göra detta i Klusterhanteraren för växling vid fel går du till Egenskaperna för resursgruppen AlwaysOn:

Bilaga 3

Ä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 bör du vara uppmärksam på att 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 AlwaysOn har installerats skapar den en Windows-klusterresursgrupp. Om du öppnar Klusterhanteraren för växling vid fel ser du att den minst har tre resurser, de två som dokumentet refererar till är:

  • Virtual Network Name (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 fler ä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 samtidiga DNS-poster som är associerade med lyssnarnamnet beror inte bara på antalet ASSOCIERADE IP-adresser, utan även inställningen RegisterAllIpProviders i redundansklustring för VNN-resursen Always ON.

När du distribuerar AlwaysOn i Azure finns det olika steg för att skapa lyssnaren och IP-adresser. 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:

Bilaga 4

Om "RegisterAllIpProviders" är 1:

Bilaga 5

Koden nedan dumpar VNN-inställningarna och anger den å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 borttagning och tillägg av en IP-adressresurs. 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 nya IP-adresser för lyssnaren. Om du är under tidsbegränsning här bör du diskutera och testa att tvinga fram en inkrementell zonöverföring med dina Windows-team och även placera DNS-värdposten till en lägre TTL (Time To Live), så att klienterna uppdateras. Mer information finns i Inkrementella zonöverföringar och Start-DnsServerZoneTransfer.

Som standard är TTL för DNS-post som är associerad med lyssnaren i AlwaysOn i Azure 1200 sekunder. Du kanske vill minska detta om du har 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 dumpa konfigurationen av det virtuella nätverket:

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

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

Anteckning

Ju lägre 'HostRecordTTL', en högre mängd DNS-trafik inträffar.

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 räknar upp alla IP-adresser som är associerade med AlwaysOn-lyssnaren parallellt och utför en mer aggressiv återförsökshastighet för TCP-anslutningen under en redundansväxling.

Mer information om de tidigare inställningarna finns i MultiSubnetFailover Keyword and Associated Features (MultiSubnetFailover-nyckelord och associerade 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 inställningen klusterkvorum. Om du använder Filresursvittne (FSW) med två noder bör du ange kvorumet för att tillåta nodmajoritet och använda dynamisk röstning, så att en enskild 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 redundansväxlingen för en annan sekundär i en annan domänkontrollant eller lokalt till "Synkron" och göra den till en automatisk redundanspartner (AFP), så att du behåller ha medan du gör ändringar. Du kan göra detta via TSQL för ändring via SSMS:

Bilaga 6

Steg 8: Ta bort den sekundära virtuella datorn 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ällningarna för diskcachelagring i CSV-filen och spara

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

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

Bilaga 7

Steg 10: Kopiera virtuella hårddiskar

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

Bilaga 8

Vänta tills alla dessa har registrerats som lyckade.

För 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 här som du kan importera datorn och använda kvarhållningsbar VIP.

#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, Add Load Balanced Endpoints 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

Bilaga 9

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

Bilaga 10

Steg 15: DNS-uppdateringskontroll

Nu bör du kontrollera DNS-servrar i dina SQL Server klientnätverk och se till att klustring 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.

Bilaga 11

Steg 19: Skapa ett nytt oberoende lagringskonto för den sekundära noden

$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 virtuella hårddiskar

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

Bilaga 12

Vänta tills alla dessa har registrerats som lyckade.

För 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 redundans

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. Redundansväxling från lokal plats till den första noden som migreras, vilket är AFP. När det har fungerat ändrar du den senaste migrerade noden till AFP.

Du bör testa redundans mellan alla noder och köra genom kaostester för att säkerställa att redundans fungerar som förväntat och i en aktuell herrgård.

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 detta 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 före redundansväxlingen av 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":

    Bilaga 13

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

    Bilaga 14

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

    Bilaga 15

Ytterligare resurser