Utilizzare Archiviazione Premium di Azure con SQL Server in macchine virtualiUse Azure Premium Storage with SQL Server on Virtual Machines

OverviewOverview

Archiviazione Premium di Azure è la risorsa di archiviazione di nuova generazione che fornisce bassa latenza e I/O ad alta velocità.Azure Premium Storage is the next generation of storage that provides low latency and high throughput IO. Funziona al meglio per i carichi di lavoro con numerose operazioni di I/O, ad esempio SQL Server in macchine virtualiIaaS.It works best for key IO intensive workloads, such as SQL Server on IaaS Virtual Machines.

Importante

Azure offre due diversi modelli di distribuzione per creare e usare le risorse: Gestione risorse e la distribuzione classica.Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. Questo articolo illustra l'uso del modello di distribuzione classica.This article covers using the Classic deployment model. Microsoft consiglia di usare il modello di Gestione risorse per le distribuzioni più recenti.Microsoft recommends that most new deployments use the Resource Manager model.

In questo articolo sono fornite indicazioni per la migrazione di una macchina virtuale che esegue SQL Server per l’uso di Archiviazione Premium.This article provides planning and guidance for migrating a Virtual Machine running SQL Server to use Premium Storage. Sono inclusi i passaggi relativi all'infrastruttura di Azure (rete, archiviazione) e alle macchine virtuali guest di Windows.This includes Azure infrastructure (networking, storage) and guest Windows VM steps. Nell'esempio incluso nell' Appendice viene mostrata una migrazione end-to-end completa in cui le VM più grandi vengono spostate per sfruttare i vantaggi dell'archiviazione SSD locale migliorata con PowerShell.The example in the Appendix shows a full comprehensive end to end migration of how to move larger VMs to take advantage of improved local SSD storage with PowerShell.

È importante comprendere il processo end-to-end di utilizzo di Archiviazione Premium di Azure con SQL Server in macchine virtuali IAAS.It is important to understand the end-to-end process of utilizing Azure Premium Storage with SQL Server on IAAS VMs. Sono inclusi:This includes:

  • Identificazione dei prerequisiti per l'utilizzo di Archiviazione Premium.Identification of the prerequisites to use Premium Storage.
  • Esempi di distribuzione di SQL Server su IaaS in Archiviazione Premium per nuove distribuzioniExamples of deploying SQL Server on IaaS to Premium Storage for new deployments.
  • Esempi di migrazione delle distribuzioni esistenti, sia di server autonomi che distribuzioni tramite gruppi di disponibilità di SQL AlwaysOn.Examples of migrating existing deployments, both stand-alone servers and deployments using SQL Always On Availability Groups.
  • Approcci di migrazione possibili.Possible migration approaches.
  • Esempio end-to-end completo che mostra i passaggi di Azure, Windows e SQL Server per la migrazione di un'implementazione di AlwaysOn esistente.Full end-to-end example showing Azure, Windows, and SQL Server steps for the migration of an existing Always On implementation.

Per ottenere le informazioni più esaustive sull'uso di SQL Server in Macchine virtuali di Azure, vedere SQL Server in Macchine virtuali di Azure.For more background information on SQL Server in Azure Virtual Machines, see SQL Server in Azure Virtual Machines.

Autore: Daniel Sol Revisori tecnici: Luis Carlos Vargas Herring, Sanjay Mishra, Pravin Mital, Juergen Thomas, Gonzalo Ruiz.Author: Daniel Sol Technical Reviewers: Luis Carlos Vargas Herring, Sanjay Mishra, Pravin Mital, Juergen Thomas, Gonzalo Ruiz.

Prerequisiti per Archiviazione PremiumPrerequisites for Premium Storage

Esistono diversi prerequisiti per l'utilizzo di Archiviazione Premium.There are several prerequisites for using Premium Storage.

Dimensioni della macchinaMachine size

Per utilizzare Archiviazione Premium occorre usare macchine virtuali (VM) serie DS.For using Premium Storage you will need to use DS series Virtual Machines (VM). Se in precedenza non sono state utilizzate macchine serie DS nel servizio cloud, è necessario eliminare la macchina virtuale esistente, mantenere i dischi collegati e creare quindi un nuovo servizio cloud prima di ricreare la macchina virtuale con dimensioni del ruolo DS.If you have not used DS Series machines in your cloud service before, you must delete the existing VM, keep the attached disks, and then create a new cloud service before recreating the VM as DS role size. Per ulteriori informazioni sulle dimensioni della macchine virtuali, vedere Dimensioni delle macchine virtuali e dei servizi cloud per Azure.For more information on Virtual Machine sizes, see Virtual Machine and Cloud Service Sizes for Azure.

Servizi cloudCloud services

È possibile utilizzare le macchine virtuali DS* con Archiviazione Premium solo quando vengono create in un nuovo servizio cloud.You can only use DS* VMs with Premium Storage when they are created in a new cloud service. Se si usa SQL Server AlwaysOn in Azure, il listener AlwaysOn farà riferimento all'indirizzo IP del servizio di bilanciamento del carico interno o esterno di Azure associato a un servizio cloud.If you are using SQL Server Always On in Azure, the Always On Listener will refer to the Azure Internal or External Load Balancer IP address that is associated with a cloud service. In questo articolo viene illustrato come eseguire la migrazione mantenendo la disponibilità in questo scenario.This article focuses on how to migrate while maintaining availability in this scenario.

Nota

Una macchina virtuale serie DS* deve essere la prima macchina virtuale distribuita nel nuovo servizio cloud.A DS* Series must be the first VM that is deployed to the new Cloud Service.

Reti virtuali regionaliRegional VNETS

Per le macchine virtuali DS* è necessario configurare la rete virtuale (VNET) che ospita le macchine virtuali regionali.For DS* VMs you must configure the Virtual Network (VNET) hosting your VMs to be regional. In tal modo si "amplia" la rete virtuale per consentire il provisioning delle macchine virtuali più grandi in altri cluster e permettere la comunicazione.This “widens” the VNET is to allow the larger VMs to be provisioned in other clusters and allow communication between them. Nella schermata seguente, la posizione evidenziata mostra le VNET regionali, mentre il primo risultato mostra una rete virtuale limitata.In the following screenshot, the highlighted Location shows regional VNETs, whereas the first result shows a “narrow” VNET.

RegionalVNET

È possibile generare un ticket di supporto Microsoft per eseguire la migrazione a una rete virtuale regionale. Microsoft apporterà una modifica, quindi per completare la migrazione alle reti virtuali regionali sarà necessario modificare la proprietà AffinityGroup nella configurazione di rete.You can raise a Microsoft support ticket to migrate to a regional VNET, Microsoft will make a change, then to complete the migration to regional VNETs, change the property AffinityGroup in the network configuration. Esportare innanzitutto la configurazione di rete in PowerShell, quindi sostituire la proprietà AffinityGroup nell’elemento VirtualNetworkSite con una proprietà Location.First export the Network Configuration in PowerShell, and then replace the AffinityGroup property in the VirtualNetworkSite element with a Location property. Specificare Location = XXXX dove XXXX è un'area di Azure.Specify Location = XXXX where XXXX is an Azure region. Importare quindi la nuova configurazione.Then import the new configuration.

Ad esempio, prendere in considerazione la seguente configurazione di rete virtuale:For example, considering the following VNET configuration:

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

Per spostarla in una rete virtuale regionale in Europa occidentale, modificare la configurazione come segue:To move this to a regional VNET in West Europe, change the configuration to the following:

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

Account di archiviazioneStorage accounts

Occorre creare un nuovo account di archiviazione configurato per Archiviazione Premium.You will need to create a new storage account that is configured for Premium Storage. Si noti che l'utilizzo di Archiviazione Premium è impostato sull’account di archiviazione, non sui singoli dischi rigidi virtuali. Tuttavia, quando si utilizza una macchina virtuale serie DS* è possibile collegare i dischi rigidi virtuali dagli account di archiviazione Standard e Premium.Note that the use of Premium Storage is set at the storage account, not on individual VHDs, however when using a DS* Series VM you can attach VHD’s from Premium and Standard Storage accounts. Se non si desidera collocare il disco rigido virtuale del sistema operativo sull'account di Archiviazione Premium, è possibile valutare questa possibilità.You may consider this if you do not want to place the OS VHD on to the Premium Storage account.

Il seguente comando New-AzureStorageAccountPowerShell con Type "Premium_LRS" consente di creare un account di Archiviazione Premium:The following New-AzureStorageAccountPowerShell command with the "Premium_LRS" Type creates a Premium Storage Account:

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

Impostazioni della cache di dischi rigidi virtualiVHDs Cache Settings

La differenza principale con la creazione di dischi che fanno parte di un account di Archiviazione Premium è l'impostazione della cache su disco.The main difference between creating disks that are part of a Premium Storage account is the disk cache setting. Per i dischi del volume di dati di SQL Server, è consigliabile usare "Read Caching".For SQL Server Data volume disks it is recommended that you use ‘Read Caching’. Per i volumi del log delle transazioni, l'impostazione della cache su disco deve essere "None".For Transaction log volumes, the disk cache setting should be set to ‘None’. Questa impostazione differisce da quelle consigliate per gli account di archiviazione Standard.This is different from the recommendations for Standard Storage accounts.

Dopo aver collegato i dischi rigidi virtuali, l'impostazione della cache non può essere modificata.Once the VHDs have been attached, the cache setting cannot be altered. È necessario scollegare e ricollegare il disco rigido virtuale con un'impostazione di cache aggiornata.You would need to detach and reattach the VHD with an updated cache setting.

Spazi di archiviazione di WindowsWindows storage spaces

È possibile utilizzare Spazi di archiviazione Windows come è avvenuto con la precedente Archiviazione Standard; questo consentirà di eseguire la migrazione di una macchina virtuale che già utilizza Spazi di archiviazione.You can use Windows Storage Spaces as you did with previous Standard Storage, this will allow you to migrate a VM that is already utilizing Storage Spaces. Nell'esempio riportato in Appendice (passaggio 9 e successivi) viene illustrato il codice di Powershell per estrarre e importare una macchina virtuale con più dischi rigidi virtuali collegati.The example in Appendix (step 9 and forward) demonstrates the Powershell code to extract and import a VM with multiple attached VHDs.

Sono stati utilizzati pool di archiviazione con account di archiviazione Azure Standard per migliorare la velocità effettiva e ridurre la latenza.Storage Pools were used with Standard Azure storage account to enhance throughput and reduce latency. Può essere utile testare i pool di archiviazione con Archiviazione Premium per le nuove distribuzioni, ma l’impostazione dell’archiviazione aggiunge ulteriore complessità.You might find value in testing Storage Pools with Premium Storage for new deployments, but they do add additional complexity with storage setup.

Come individuare quali dischi virtuali di Azure sono mappati ai pool di archiviazioneHow to find which Azure Virtual Disks map to storage pools

Poiché esistono diverse indicazioni di impostazione della cache per i dischi rigidi virtuali collegati, è possibile copiare i dischi rigidi virtuali in un account di Archiviazione Premium.As there are different cache setting recommendations for attached VHDs, you might decide to copy the VHDs to a Premium Storage account. Tuttavia, quando vengono ricollegati alla nuova macchina virtuale serie DS, è necessario modificare le impostazioni della cache.However, when you reattach them to the new DS series VM, you might need to alter the cache settings. È più semplice applicare le impostazioni della cache di Archiviazione Premium consigliate quando si dispone di dischi rigidi virtuali separati per i file di dati SQL e file di log (anziché di un singolo disco rigido virtuale che contiene entrambi).It is simpler to apply the Premium Storage recommended cache settings when you have separate VHDs for the SQL Data files and log files (rather than a single VHD that contains both).

Nota

Se si dispone di file di log e dati di SQL Server nello stesso volume, l'opzione di memorizzazione nella cache da scegliere dipende dai modelli di accesso I/O per i carichi di lavoro del database.If you have SQL Server data and log files on the same volume, the caching option you choose depends on the IO access patterns for your database workloads. Solo i test possono dimostrare quale opzione di memorizzazione nella cache è più adatta a questo scenario.Only testing can demonstrate which caching option is best for this scenario.

Tuttavia, se si usano spazi di archiviazione di Windows costituiti da più VHD, è necessario esaminare gli script originali per identificare quali VHD collegati si trovano in un pool specifico in modo da poter impostare adeguatamente la cache per ogni disco.However, if you are using Windows Storage Spaces which are made up of multiple VHDs you will need to look at your original scripts to identify which attached VHDs are in what specific pool, so you can then set the cache settings accordingly for each disk.

Se non è disponibile lo script originale che mostra quali dischi rigidi virtuali sono mappati al pool di archiviazione, è possibile utilizzare la procedura seguente per determinare il mapping tra disco e pool di archiviazione.If you do not have original script available to show you which VHDs map to the storage pool, you can use the following steps to determine the disk/storage pool mapping.

Per ogni disco, attenersi alla procedura seguente:For each disk, use the following steps:

  1. Ottenere l’elenco di dischi collegati alla macchina virtuale con il comando Get-AzureVM :Get list of disks attached to VM with the Get-AzureVM command:

    Get-AzureVM -ServiceName -Name | Get-AzureDataDiskGet-AzureVM -ServiceName -Name | Get-AzureDataDisk

  2. Prendere nota del nome del disco e del LUN.Note the Diskname and LUN.

    DisknameAndLUN

  3. Desktop remoto nella macchina virtuale.Remote desktop into the VM. Passare quindi a Gestione computer | Gestione dispositivi | Unità disco.Then go to Computer Management | Device Manager | Disk Drives. Esaminare le proprietà di ciascun ’Disco virtuale Microsoft’Look at the properties of each of the ‘Microsoft Virtual Disks’

    VirtualDiskProperties

  4. Il numero LUN è un riferimento al numero LUN specificato al momento del collegamento del disco rigido virtuale alla macchina virtuale.The LUN number here is a reference to the LUN number you specify when attaching the VHD to the VM.
  5. Per il "Disco virtuale Microsoft" andare alla scheda Dettagli, quindi nell’elenco Proprietà andare a Chiave driver.For the ‘Microsoft Virtual Disk’ go to the Details tab, then in the Property list, go to Driver Key. In Valore, notare l'Offset, ovvero 0002 nella schermata seguente.In the Value, note the Offset, which is 0002 in the following screenshot. Il valore 0002 denota PhysicalDisk2 a cui fa riferimento il pool di archiviazione.The 0002 denotes the PhysicalDisk2 that the storage pool references.

    VirtualDiskPropertyDetails

  6. Per ogni del pool di archiviazione eseguire il dump dei dischi associati:For each storage pool, dump out the associated disks:

    Get-StoragePool -FriendlyName AMS1pooldata | Get-PhysicalDiskGet-StoragePool -FriendlyName AMS1pooldata | Get-PhysicalDisk

    GetStoragePool

Ora è possibile utilizzare queste informazioni per collegare i dischi rigidi virtuali collegati ai dischi fisici nei pool di archiviazione.Now you can use this information to associate attached VHDs to Physical Disks in Storage Pools.

Una volta eseguito il mapping dei dischi rigidi virtuali ai dischi fisici nei pool di archiviazione è possibile scollegarli e copiarli su un account di Archiviazione Premium e quindi collegarli con l'impostazione corretta della cache.Once you have mapped VHDs to Physical Disks in Storage Pools you can then detach and copy them over to a Premium Storage account, then attach them with the correct cache setting. Vedere l'esempio fornito in Appendice, passaggi da 8 a 12.Please see the example in the Appendix, steps 8 through 12. Questi passaggi illustrano come estrarre una configurazione di disco rigido virtuale collegato alla macchina virtuale in un file CSV, copiare i dischi rigidi virtuali, modificare le impostazioni della cache di configurazione disco e infine ridistribuire la macchina virtuale come macchina virtuale serie DS con tutti i dischi collegati.These steps show how to extract a VM-attached VHD disk configuration to a CSV file, copy the VHDs, alter the disk configuration cache settings, and finally redeploy the VM as a DS series VM with all the attached disks.

Larghezza di banda di archiviazione della VM e velocità effettiva di archiviazione del VHDVM storage bandwidth and VHD storage throughput

Le prestazioni dell’archiviazione dipendono dalle dimensioni della macchina virtuale DS* specificate e della dimensioni del disco rigido virtuale.The amount of storage performance depends on the DS* VM size specified and the VHD sizes. Le macchine virtuali hanno quote diverse per il numero di dischi rigidi virtuali che possono essere collegati e la larghezza di banda massima che supporteranno (MB/s).The VMs have different allowances for the number of VHDs that can be attached and the maximum bandwidth they will support (MB/s). Per i numeri di larghezza di banda specifici, vedere Dimensioni delle macchine virtuali e dei servizi cloud per Azure.For the specific bandwidth numbers, see Virtual Machine and Cloud Service Sizes for Azure.

Input/output al secondo maggiori si ottengono con dimensioni del disco maggiori.Increased IOPS are achieved with larger disk sizes. Tenere conto di questa considerazione quando si decide il percorso di migrazione.You should consider this when you think about your migration path. Per i dettagliate vedere la tabella per i tipi di disco e input/output al secondo.For details, see the table for IOPS and Disk Types.

Infine, tenere presente che le macchine virtuali supporteranno larghezza di banda massime diverse per tutti i dischi collegati.Finally, consider that VMs have different maximum disk bandwidths they will support for all disks attached. Con un carico elevato si potrebbe saturare la larghezza di banda su disco massima disponibile per le dimensioni del ruolo di macchina virtuale.Under high load, you could saturate the maximum disk bandwidth available for that VM role size. Ad esempio, Standard_DS14 supporterà fino a 512 MB/s. Pertanto, con tre dischi P30 si potrebbe saturare la larghezza di banda del disco della macchina virtuale.For example a Standard_DS14 will support up to 512MB/s; therefore, with three P30 disks you could saturate the disk bandwidth of the VM. In questo esempio, tuttavia, il limite di velocità effettiva potrebbe essere superato a seconda della combinazione di I/O di lettura e scrittura.But in this example, the throughput limit could be exceeded depending on the mix of read and write IOs.

Nuove distribuzioniNew deployments

Nelle due sezioni successive viene illustrato come distribuire le macchine virtuali di SQL Server in Archiviazione Premium.The next two sections demonstrate how you can deploy SQL Server VMs to Premium Storage. Come affermato in precedenza, non occorre necessariamente collocare il disco del sistema operativo su Archiviazione Premium.As mentioned before, you do not necessarily need to place the OS disk onto Premium storage. È possibile eseguire questa operazione se si intende posizionare i carichi di lavoro con numerose operazioni di I/O sul disco rigido virtuale del sistema operativo.You might choose to do this if you are intending to place any intensive IO workloads on the OS VHD.

Nel primo esempio viene illustrato l'utilizzo di immagini della raccolta Azure esistente.The first example demonstrates utilizing existing Azure Gallery Images. Nel secondo esempio viene illustrato come utilizzare un'immagine di macchina virtuale personalizzata disponibile in un account di archiviazione Standard esistente.The second example shows how to use a custom VM image that you have in an existing Standard storage account.

Nota

Questi esempi presuppongono che sia già stata creata una rete virtuale regionale.These examples assume that you have already created a Regional VNET.

Nell'esempio seguente viene illustrato come collocare il disco rigido virtuale di sistema operativo su Archiviazione Premium e collegare dischi rigidi virtuali di Archiviazione Premium.The example below shows how to place the OS VHD onto premium storage and attach Premium Storage VHDs. Tuttavia, è anche possibile collocare il disco del sistema operativo in un account di archiviazione Standard e quindi collegare dischi rigidi virtuali che risiedono in un account di Archiviazione Premium.However, you can also place the OS disk in a Standard Storage account and then attach VHDs that reside in a Premium Storage account. Vengono illustrati entrambi gli scenari.Both scenarios are demonstrated.

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

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

Passaggio 1: Creare un account di Archiviazione PremiumStep 1: Create a Premium Storage Account

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

Passaggio 2: Creare un nuovo servizio cloudStep 2: Create a New Cloud Service

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

Passaggio 3: Riservare un VIP di servizio cloud (facoltativo)Step 3: Reserve a Cloud Service VIP (Optional)

#check exisitng reserved VIP
Get-AzureReservedIP

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

Passaggio 4: Creare un contenitore di macchine virtualiStep 4: Create a 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

Passaggio 5: Collocazione del disco rigido virtuale su Archiviazione Standard o Premium Step 5: Placing OS VHD on Standard or Premium Storage

#NOTE: Set up subscription and default storage account which will be 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

Passaggio 6: Creare la macchina virtualeStep 6: Create VM

#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 Avaiability 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 will attach 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

Creare una nuova VM per usare Archiviazione Premium con un'immagine personalizzataCreate a new VM to use Premium Storage with a custom image

Questo scenario mostra la posizione delle immagini personalizzate esistenti che risiedono in un account di Archiviazione Standard.This scenario demonstrates where you have existing customized images that reside in a Standard Storage account. Come accennato, se si desidera collocare il disco rigido virtuale del sistema operativo su Archiviazione Premium, è necessario copiare l'immagine esistente nell'account di Archiviazione Standard e trasferirlo a una Archiviazione Premium prima che possa essere utilizzato.As mentioned if you want to place the OS VHD on Premium Storage you will need to copy the image that exists in the Standard Storage account and transfer them to a Premium Storage before it can be used. Se si dispone di un'immagine locale, è possibile usare questo metodo per copiarla direttamente nell'account di archiviazione Premium.If you have an image on-premises, you can also use this method to copy that directly to the Premium Storage account.

Passaggio 1: Creare l’account di archiviazioneStep 1: Create Storage Account

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

Passaggio 2: Creare il servizio cloudStep 2 Create Cloud Service

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

Passaggio 3: Usare l'immagine esistenteStep 3: Use existing image

È possibile utilizzare un'immagine esistente.You can use an existing image. In alternativa è possibile acquisire un'immagine di una macchina esistente.Or, you can take an image of an existing machine. Si noti che la macchina non deve essere DS*.Note the machine you image does not have to be DS* machine. Dopo aver creato l'immagine, la procedura seguente illustra come copiarla nell'account di archiviazione Premium con il cmdlet Start-AzureStorageBlobCopy di PowerShell.Once you have the image, the following steps show how to copy it to the Premium Storage account with the Start-AzureStorageBlobCopy PowerShell commandlet.

#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  

Passaggio 4: Copiare BLOB tra account di archiviazioneStep 4: Copy Blob between Storage Accounts

#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  

Passaggio 5: Verificare regolarmente lo stato della copia:Step 5: Regularly check copy status:

$blob | Get-AzureStorageBlobCopyState

Passaggio 6: Aggiungere il disco immagine al repository dischi di Azure in SottoscrizioneStep 6: Add Image disk to Azure disk Repository in Subscription

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

Add-AzureVMImage -ImageName $newimageName -MediaLocation $imageMediaLocation

Nota

È possibile che si verifichino errori di lease del disco anche se i report di stato indicano un esisto positivo.You may find that even though the status reports as success, you could still get a disk lease error. In questo caso, attendere circa 10 minuti.In this case, wait about 10 minutes.

Passaggio 7: Compilare la macchina virtualeStep 7: Build the VM

Si compila la macchina virtuale da un'immagine e si collegano due dischi rigidi virtuali di Archiviazione Premium:Here you are building the VM from your image and attaching two Premium Storage VHDs:

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

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

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

#create new Avaiability 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

Distribuzioni esistenti che non usano i gruppi di disponibilità AlwaysOnExisting deployments that do not use Always On Availability Groups

Nota

Per le distribuzioni esistenti, vedere prima la sezione Prerequisiti di questo argomento.For existing deployments, first see the Prerequisites section of this topic.

Esistono diverse considerazioni per le distribuzioni di SQL Server che non usano i gruppi di disponibilità AlwaysOn e per quelle che li usano.There are different considerations for SQL Server deployments that do not use Always On Availability Groups and those that do. Se non si usa AlwaysOn ed è disponibile un SQL Server autonomo esistente, si può eseguire l'aggiornamento ad Archiviazione Premium con un nuovo servizio cloud e un account di archiviazione.If you are not using Always On and have an existing standalone SQL Server, you can upgrade to Premium Storage by using a new cloud service and storage account. Valutare le opzioni seguenti:Consider the following options:

  • Creare una nuova macchina virtuale di SQL Server.Create a new SQL Server VM. È possibile creare una nuova macchina virtuale di SQL Server che utilizza un account di Archiviazione Premium, come documentato in Nuove distribuzioni.You can create a new SQL Server VM that uses a Premium Storage account, as documented in New Deployments. Eseguire quindi il backup e ripristino della configurazione di SQL Server e dei database utente.Then backup and restore your SQL Server configuration and user databases. L'applicazione dovrà essere aggiornata per fare riferimento al nuovo SQL Server se si accede internamente o esternamente.The application will need to be updated to reference the new SQL Server if it is being accessed internally or externally. È necessario copiare tutti gli oggetti esterni al db, come se si eseguisse una migrazione di SQL Server SxS (Side by Side).You would need to copy all ‘out of db’ objects as if you were doing a Side by Side (SxS) SQL Server migration. Sono inclusi oggetti come account di accesso, certificati e server collegati.This includes objects such as logins, certificates, and linked servers.
  • Eseguire la migrazione di una macchina virtuale di Server SQL esistente.Migrate an existing SQL Server VM. Sarà necessario disconnettere la macchina virtuale di SQL Server e trasferirla in un nuovo servizio cloud, operazione che implica la copia di tutti i relativi dischi rigidi virtuali collegati all'account di Archiviazione Premium.This will require taking the SQL Server VM offline, then transferring it to a new cloud service, which includes copying all of its attached VHDs to the Premium Storage account. Quando la macchina virtuale torna online, l'applicazione farà riferimento al nome host del server come prima.When the VM comes online, the application will reference the server host name as before. Tenere presente che le dimensioni del disco esistente influiranno sulle prestazioni.Be aware that the size of the existing disk will affect the performance characteristics. Ad esempio, un disco di 400 GB viene arrotondato per eccesso a un P20.For example, a 400 GB disk gets rounded up to a P20. Se si sa che tali prestazioni del disco non sono necessarie, è possibile ricreare la macchina virtuale come macchina virtuale serie DS e collegare dischi rigidi di archiviazione virtuale di Archiviazione Premium con le prestazioni/dimensioni desiderate.If you know that you do not require that disk performance, then you could recreate the VM as a DS Series VM, and attach Premium Storage VHDs of the size/performance specification you require. È quindi possibile scollegare e ricollegare i file di database SQL.Then you could detach and reattach the SQL DB files.

Nota

Quando si copiano i dischi rigidi virtuali è necessario fare attenzione alle dimensioni in quanto indicano in quale tipo di disco di archiviazione Premium rientrano, determinando la specifica delle prestazioni del disco.When copying the VHD disks you should be aware of the size, depending on the size will mean what Premium Storage Disk type they fall into, this determines disk performance specification. Azure arrotonderà alla dimensione del disco più vicina, per cui se si dispone di un disco di 400 GB, questo verrà arrotondato a un P20.Azure will round up to the nearest disk size, so if you have a 400GB disk, this will be rounded up to a P20. A seconda dei requisiti di I/O esistenti del disco rigido virtuale del sistema operativo, potrebbe essere necessario eseguirne la migrazione a un account di Archiviazione Premium.Depending on your existing IO requirements of the OS VHD, you might not need to migrate this to a Premium Storage account.

Se si accede esternamente a SQL Server, verrà modificato il VIP del servizio cloud.If your SQL Server is accessed externally, then the cloud service VIP will change. Sarà necessario, inoltre, aggiornare le impostazioni di endpoint, ACL e DNS.You will also have to update end points, ACLs, and DNS settings.

Distribuzioni esistenti che usano i gruppi di disponibilità AlwaysOnExisting deployments that use Always On Availability Groups

Nota

Per le distribuzioni esistenti, vedere prima la sezione Prerequisiti di questo argomento.For existing deployments, first see the Prerequisites section of this topic.

In questa sezione si osserverà prima di tutto in che modo AlwaysOn interagisce con una rete di Azure.Initially in this section we will look at how Always On interacts with Azure Networking. Verranno quindi descritte le migrazioni in due scenari: migrazioni in cui viene considerato tollerabile un certo tempo di inattività e migrazioni in cui è necessario che i tempi di inattività siano minimi.We will then break down migrations in to two scenarios: migrations where some downtime can be tolerated and migrations where you must achieve minimal downtime.

I gruppi di disponibilità di SQL Server AlwaysOn locali usano un listener locale che registra un nome DNS virtuale con un indirizzo IP condiviso tra uno o più server SQL.On-premises SQL Server Always On Availability Groups use a Listener on-premises that registers a virtual DNS name along with an IP address that is shared between one or more SQL Servers. Quando si connettono i client vengono indirizzati attraverso l’IP del listener a SQL Server primario.When clients connect they are routed through the listener IP to the Primary SQL Server. Si tratta del server a cui appartiene la risorsa IP AlwaysOn in quel momento.This is the server that owns the Always On IP resource at that time.

DeploymentsUseAlways On

In Microsoft Azure è consentito un solo indirizzo IP assegnato a una scheda di rete nella macchina virtuale, pertanto per conseguire lo stesso livello di astrazione possibile in locale, Azure utilizza l'indirizzo IP assegnato ai servizi di bilanciamento del carico interno ed esterno (ILB/ELB).In Microsoft Azure you can have only one IP address assigned to a NIC on the VM, so in order to achieve the same layer of abstraction as on-premises, Azure utilizes the IP address that is assigned to the Internal/External Load Balancers (ILB/ELB). La risorsa IP condivisa tra i server viene impostata sullo stesso IP del servizio ILB/ELB, che viene pubblicato nel DNS, e il traffico del client viene passato attraverso il servizio ILB/ELB alla replica di SQL Server primario.The IP resource that is shared between the servers is set to the same IP as the ILB/ELB. Il servizio ILB/ELB riconosce l'istanza di SQL Server primaria, perché usa i probe per verificare la presenza della risorsa IP AlwaysOn.This is published in the DNS, and client traffic is passed through the ILB/ELB to the Primary SQL Server replica. Nell'esempio precedente, verifica ogni nodo che dispone di un endpoint a cui fa riferimento il servizio ELB/ILB.The ILB/ELB knows which SQL Server is primary since it uses probes to probe the Always On IP resource. Quello che risponde è il Server SQL primario.In the previous example, it probes each node that has an endpoint referenced by the ELB/ILB, whichever responds is the Primary SQL Server.

Nota

Il servizio ILB e il servizio ELB vengono assegnati a un servizio cloud di Azure specifico, pertanto qualsiasi migrazione cloud in Azure comporterà probabilmente la modifica dell'IP del servizio di bilanciamento del carico.The ILB and ELB are both assigned to a particular Azure cloud service, therefore any cloud migration in Azure will most likely mean that the Load Balancer IP will change.

Migrazione delle distribuzioni di AlwaysOn che tollerano tempi di inattivitàMigrating Always On deployments that can allow some downtime

Sono disponibili due strategie per eseguire la migrazione delle distribuzioni di AlwaysOn che consentono periodi di inattività:There are two strategies to migrate Always On deployments that allow for some downtime:

  1. Aggiungere più repliche secondarie a un cluster AlwaysOn esistenteAdd more secondary replicas to an existing Always On Cluster
  2. Eseguire la migrazione a un nuovo cluster AlwaysOnMigrate to a new Always On Cluster

1. Aggiungere più repliche secondarie a un cluster AlwaysOn esistente1. Add more Secondary Replicas to an Existing Always On Cluster

Una strategia consiste nell'aggiungere più repliche secondarie al gruppo di disponibilità AlwaysOn.One strategy is to add more secondaries to the Always On Availability Group. È necessario aggiungere questi elementi in un nuovo servizio cloud e aggiornare il listener con il nuovo IP del servizio di bilanciamento carico.You need to add these into a new cloud service and update the listener with the new load balancer IP.

Punti dei tempi di inattività:Points of downtime:
  • Convalida del cluster.Cluster Validation.
  • Test di failover AlwaysOn per nuovi database secondari.Testing Always On failovers for New Secondaries.

Se si utilizzano pool di archiviazione di Windows nella macchina virtuale per una velocità effettiva I/O superiore, questi saranno portati offline durante una convalida completa del cluster.If you are using Windows Storage Pools within the VM for higher IO throughput, then these will be taken offline during a Full Cluster Validation. Il test di convalida è necessario quando si aggiungono nodi al cluster.The validation test is required when you add nodes to the cluster. Il tempo necessario per eseguire il test può variare, pertanto verificarlo nell'ambiente di test rappresentativo per ottenere una stima approssimativa della durata.The time it takes to run the test can vary, so you should test this in your representative test environment to get an approximate time of how long this will take.

È necessario prevedere tempo per eseguire il failover manuale e test CHAOS sui nodi appena aggiunti per assicurarsi che la disponibilità elevata AlwaysOn funzioni come previsto.You should provision time where you can perform manual failover and chaos testing on the newly added nodes to ensure Always On High Availability functions as expected.

DeploymentUseAlways On2

Nota

Prima che venga eseguita la convalida è necessario arrestare tutte le istanze di SQL Server in cui vengono usati i pool di archiviazione.You should stop all instances of SQL Server where the Storage Pools are used before the Validation runs.

Procedure generaliHigh-level steps
  1. Creare due nuovi server SQL Server nel nuovo servizio cloud con Archiviazione Premium collegata.Create two new SQL Servers in new cloud service with attached Premium Storage.
  2. Copiare i backup completi e ripristinare con NORECOVERY.Copy over FULL backups and restore with NORECOVERY.
  3. Copiare gli oggetti dipendenti esterni al database utente, ad esempio nomi di accesso e così via.Copy over ‘out of user DB’ dependent objects, such as logins etc.
  4. Crea un nuovo servizio di carico bilanciamento interno (ILB) oppure utilizzare un servizio di bilanciamento del carico esterno (ELB) e quindi impostare gli endpoint con bilanciamento del carico in entrambi i nodi nuovi.Create new a new Internal Load Balancer (ILB) or use an External Load Balancer (ELB), and then set up Load Balanced Endpoints on both new nodes.

    Nota

    Prima di continuare, verificare che tutti i nodi abbiano la configurazione dell'endpoint correttaCheck all Nodes have the correct Endpoint configuration before you continue

  5. Impedire all'utente/applicazione l’accesso a SQL Server (se si utilizzano pool di archiviazione).Stop User/Application Access to the SQL Server (if using Storage Pools).
  6. Arrestare i servizi motore di SQL Server in tutti i nodi (se si utilizzano il pool di archiviazione).Stop SQL Server Engine Services on All Nodes (if using Storage Pools).
  7. Aggiungere nuovi nodi al cluster ed eseguire la convalida completa.Add new Nodes to cluster and run full validation.
  8. Quando la convalida ha esito positivo, avviare tutti i servizi di SQL Server.Once Validation is successful, start all SQL Server Services.
  9. Eseguire il backup dei log delle transazioni e ripristinare i database utente.Backup Transaction logs, and restore user databases.
  10. Aggiungere nuovi nodi nel gruppo di disponibilità AlwaysOn e impostare la replica come sincrona.Add new nodes into the Always On Availability Group and place replication into Synchronous.
  11. Aggiungere la risorsa indirizzo IP del nuovo ILB/ELB del servizio cloud tramite PowerShell per AlwaysOn in base all'esempio multisito riportato nell' Appendice.Add the IP address resource of the new Cloud Service ILB/ELB through PowerShell for Always On based on the Multi-site example in the Appendix. Nel clustering di Windows impostare i Proprietari possibili della risorsa Indirizzo IP sui nuovi nodi.In Windows clustering, set the Possible owners of the IP Address resource to the new nodes old. Vedere la sezione 'Aggiunta della risorsa indirizzo IP nella stessa subnet' in Appendice.See the ‘Adding IP Address Resource on Same Subnet’ section of the Appendix.
  12. Failover su uno dei nuovi nodi.Failover to one of the new nodes.
  13. Impostare i nuovi nodi come Partner di failover automatico e testare i failover.Make the new nodes Auto Failover Partners and test failovers.
  14. Rimuovere i nodi originali dal gruppo di disponibilità.Remove original nodes from Availability Group.
VantaggiAdvantages
  • Nuovi SQL Server possono essere testati (SQL Server e applicazione) prima di essere aggiunti a AlwaysOn.New SQL Servers can be tested (SQL Server and Application) before they are added to Always On.
  • È possibile modificare le dimensioni della macchina virtuale e personalizzare la risorsa di archiviazione per i requisiti specifici.You can change the VM size and customize the storage to your exact requirements. Tuttavia, sarebbe opportuno mantenere tutti i percorsi di file SQL inalterati.However, it would be beneficial to keep all the SQL file paths the same.
  • È possibile controllare quando viene avviato il trasferimento dei backup del database per le repliche secondarie.You can control when the transfer of the DB backups to the Secondary Replicas are started. Questo comportamento è diverso dal quello del commandlet di Azure Start-AzureStorageBlobCopy per copiare i dischi rigidi virtuali perché in quest’ultimo caso la copia è asincrona.This differs from using Azure Start-AzureStorageBlobCopy commandlet to copy VHDs, because that is an asynchronous copy.
Svantaggi:Disadvantages
  • Quando si utilizzano pool di archiviazione di Windows, durante la convalida del cluster completo si verifica un tempo di inattività del cluster per i nuovi nodi aggiuntivi.When using Windows Storage Pools, there is Cluster downtime during the Full Cluster Validation for the new additional nodes.
  • A seconda della versione di SQL Server e del numero di repliche secondarie esistenti, potrebbe non essere possibile aggiungere ulteriori repliche secondarie senza rimuovere i le repliche secondarie esistenti.Depending on the SQL Server Version and the existing number of secondary replicas, you might not be able to add more secondary replicas without removing existing secondaries.
  • Il tempo di trasferimento dei dati SQL potrebbe essere molto lungo durante la configurazione di repliche secondarie.There could be long SQL data transfer time while setting up the secondaries.
  • Esiste un costo aggiuntivo durante la migrazione mentre le nuove macchine vengono eseguite in parallelo.There is additional cost during migration while you have new machines running in parallel.

2. Eseguire la migrazione a un nuovo cluster AlwaysOn2. Migrate to a new Always On Cluster

Un'altra strategia consiste nel creare un nuovo cluster AlwaysOn con nuovi nodi nel nuovo servizio cloud e quindi reindirizzare i client in modo che lo usino.Another strategy is to create a brand new Always On Cluster with brand new nodes in new cloud service and then redirect the clients to use it.

Punti dei tempi di inattivitàPoints of downtime

Quando si trasferiscono utenti e applicazioni al nuovo listener AlwaysOn, si verifica un tempo di inattività.There is downtime when you transfer applications and users to the new Always On listener. Il tempo di inattività dipende da:The downtime depends on:

  • Il tempo necessario per ripristinare i backup dei log delle transazioni finali nei database in nuovi server.The time taken to restore final transaction log backups to databases on new servers.
  • Il tempo impiegato per aggiornare le applicazioni client in modo che usino il nuovo listener AlwaysOn.The time taken to update client applications to use new Always On listener.
VantaggiAdvantages
  • È possibile testare l'ambiente di produzione reale, SQL Server e le modifiche del build del sistema operativo.You can test the actual production environment, SQL Server, and OS build changes.
  • È possibile personalizzare l'archiviazione e ridurre le dimensioni della macchina virtuale.You have the option to customize the storage and to potentially reduce size of VM. Ciò potrebbe causare determinare una riduzione dei costi.This could result in cost reduction.
  • Durante questo processo, è possibile aggiornare il build o la versione di SQL Server.You can update your SQL Server build or version during this process. È inoltre possibile aggiornare il sistema operativo.You can also upgrade the Operating System.
  • Il cluster AlwaysOn precedente può fungere da destinazione di rollback.The previous Always On Cluster can act as a solid rollback target.
Svantaggi:Disadvantages
  • È necessario modificare il nome DNS del listener, se si vuole che entrambi i cluster AlwaysOn vengano eseguiti contemporaneamente.You need to change the DNS name of the listener if you want both Always On clusters running simultaneously. Ciò comporta un sovraccarico di amministrazione durante la migrazione perché le stringhe dell’applicazione client devono riflettere il nuovo nome del listener.This adds administration overhead during the migration as client application strings must reflect the new Listener name.
  • È necessario implementare un meccanismo di sincronizzazione tra i due ambienti per mantenerli quanto più vicini è possibile al fine di ridurre al minimo i requisiti di sincronizzazione finale prima della migrazione.You must implement a synchronization mechanism between the two environments to keep them as close as possible to minimize the final synchronization requirements before migration.
  • Esiste un costo aggiunto durante la migrazione mentre il nuovo ambiente è in esecuzione.There is added cost during migration while you have the new environment running.

Migrazione delle distribuzioni AlwaysOn per un tempo di inattività minimoMigrating Always On Deployments for minimal downtime

Sono disponibili due strategie per la migrazione delle distribuzioni di AlwaysOn per un tempo di inattività minimo:There are two strategies for migrating Always On deployments for minimal downtime:

  1. Utilizzare una replica secondaria esistente: singolo sitoUtilize an Existing Secondary: Single-Site
  2. Utilizzare repliche secondarie esistenti: multisitoUtilize Existing Secondary Replica(s): Multi-Site

1. Usare una replica secondaria esistente: sito singolo1. Utilize an existing secondary: Single-Site

Una strategia per il tempo di inattività minimo consiste nel rimuovere una replica secondaria del cloud esistente dal servizio cloud corrente.One strategy for minimal downtime is to take an existing cloud secondary and remove it from the current cloud service. Successivamente si copiano i dischi rigidi virtuali nel nuovo account di Archiviazione Premium e si crea la macchina virtuale nel nuovo servizio cloud.Then copy the VHDs to the new Premium Storage account, and create the VM in the new cloud service. A questo punto, si aggiorna il listener in clustering e failover.Then update the listener in clustering and failover.

Punti dei tempi di inattivitàPoints of downtime
  • Quando si aggiorna il nodo finale con l'endpoint di bilanciamento del carico, si verifica un tempo di inattività.There is downtime when you update the final node with the Load Balanced endpoint.
  • La riconnessione del client potrebbe essere rimandata a seconda della configurazione client/DNS.Your client reconnection might be delayed depending on your client/DNS configuration.
  • Un tempo di inattività aggiuntivo si verifica se si sceglie di portare offline il gruppo di cluster AlwaysOn per sostituire gli indirizzi IP.There is additional downtime if you choose to take the Always On Cluster group offline to swap out the IP addresses. È possibile evitare questa situazione usando una dipendenza OR e possibili proprietari per la risorsa indirizzo IP aggiunto.You can avoid this by using an OR dependency and Possible Owners for the added IP Address resource. Vedere la sezione 'Aggiunta della risorsa indirizzo IP nella stessa subnet' in Appendice.See the ‘Adding IP Address Resource on Same Subnet’ section of the Appendix.

Nota

Quando si vuole che il nodo aggiunto partecipi come partner di failover AlwaysOn, è necessario aggiungere un endpoint di Azure con un riferimento al set con carico bilanciato.When you want the added node to partake in as an Always On Failover Partner, you need to add an Azure Endpoint with a reference to the Load Balanced Set. Quando si esegue il comando Add-AzureEndpoint per eseguire questa operazione, le connessioni correnti restano aperte, ma non sarà possibile stabilire nuove connessioni fino a quando non viene aggiornato il servizio di bilanciamento del carico.When you run the Add-AzureEndpoint command to do this, current connections to remain open, but new connections to the listener will not be able to be established until the load balancer has updated. Nel test questo processo è durato 90-120 secondi; è opportuno verificare questa durata.In testing this was seen to last 90-120seconds, this should be tested.

VantaggiAdvantages
  • Nessun costo aggiuntivo durante la migrazione.No extra cost incurred during migration.
  • Una migrazione uno a uno.A one-to-one migration.
  • Minore complessità.Reduced complexity.
  • Consente un maggiore IOPS dalle SKU di Archiviazione Premium.Allows for increased IOPS from Premium Storage SKUs. Quando i dischi sono disconnessi dalla macchina virtuale e copiati nel nuovo servizio cloud, è possibile utilizzare uno strumento di terze parti per aumentare le dimensioni del disco rigido virtuale, fornendo una maggiore velocità effettiva.When the disks are detached from the VM and copied to the new cloud service, a 3rd party tool can be used to increase the VHD size, which provides higher throughputs. Per aumentare le dimensioni del disco rigido virtuale, vedere questo forum di discussione.For increasing VHD sizes, see this forum discussion.
Svantaggi:Disadvantages
  • Perdita temporanea di disponibilità elevata e ripristino di emergenza durante la migrazione.There is a temporary loss of HA and DR during migration.
  • Poiché si tratta di una migrazione 1:1, è necessario utilizzare una dimensione minima di macchina virtuale che supporti il numero di dischi rigidi virtuali presenti, pertanto potrebbe non essere possibile ridurre le dimensioni delle macchine virtuali.As this is a 1:1 migration, you will have to use a minimum VM size that will support your number of VHDs, so you might not be able to downsize your VMs.
  • Questo scenario prevede l’uso del commandlet Start-AzureStorageBlobCopy di Azure, che è asincrono.This scenario would use the Azure Start-AzureStorageBlobCopy commandlet, which is asynchronous. Non esiste alcun contratto di servizio al completamento della copia.There is no SLA on copy completion. Il tempo delle copie varia perché dipende dal tempo di attesa in coda e dalla quantità di dati da trasferire.The time of the copies varies, while this depends on wait in queue it will also depend on the amount of data to transfer. Il tempo di copia aumenta se la destinazione del trasferimento è un altro centro dati di Azure che supporta Archiviazione Premium in un'altra area.The copy time increases if the transfer is going to another Azure data center that supports Premium Storage in another region. Se si dispone solo di due nodi, valutare la possibilità di un’attenuazione per l’eventualità che la copia richieda più tempo durante i test.If you just have 2 nodes, consider a possible mitigation in case the copy takes longer than in testing. Valutare, ad esempio, le possibilità seguenti.This could include the following ideas.
    • Aggiungere un terzo nodo di SQL Server temporaneo per la disponibilità elevata prima della migrazione con tempi di inattività concordati.Add a temporary 3rd SQL Server node for HA before the migration with agreed downtime.
    • Eseguire la migrazione all'esterno della manutenzione pianificata di Azure.Run the migration outside of Azure scheduled maintenance.
    • Assicurarsi di che avere configurato correttamente il quorum del cluster.Ensure you have configured your cluster quorum correctly.
Procedure generaliHigh-level steps

In questo documento non viene illustrato un esempio end-to-end completo. Nella sezione Appendice, tuttavia, sono forniti dettagli che possono essere usati per eseguire questo tipo di migrazione.This document does not demonstrate a complete end to end example, however the Appendix provides details that can be leveraged to perform this.

MinimalDowntime

  • Raccogliere la configurazione del disco e rimuovere il nodo (non eliminare i dischi rigidi virtuali collegati).Gather disk configuration, and remove the node (do not delete attached VHDs).
  • Creare un account di Archiviazione Premium e copiare i dischi rigidi virtuali dall'account di Archiviazione StandardCreate a Premium Storage account and copy VHDs from the Standard Storage account
  • Creare il nuovo servizio cloud e ridistribuire la macchina virtuale SQL2 in tale servizio cloud.Create new cloud service and redeploy the SQL2 VM in that cloud service. Creare la macchina virtuale utilizzando la copia del disco rigido virtuale del sistema operativo originale e collegare i dischi rigidi virtuali copiati.Create the VM using the copied original OS VHD and attaching the copied VHDs.
  • Configurare ILB/ELB e aggiungere gli endpoint.Configure ILB / ELB and add Endpoints.
  • Aggiornare il listener in uno dei modi seguenti:Update Listener by either:
    • Portare offline il gruppo AlwaysOn e aggiornare il listener di AlwaysOn con il nuovo indirizzo IP ILB/ELB.Taking the Always On Group offline and updating the Always On Listener with new ILB / ELB IP address.
    • Aggiungere la risorsa indirizzo IP del servizio ILB/ELB del nuovo servizio cloud tramite PowerShell nel clustering di Windows.Or adding the IP address resource of new Cloud Service ILB/ELB through PowerShell into Windows clustering. Quindi impostare i possibili proprietari della risorsa indirizzo IP sul nodo migrato, SQL2, e impostare tale nodo come dipendenza OR nel nome di rete.Then set the Possible owners of the IP Address resource to the migrated node, SQL2, and set this as OR dependency in the Network Name. Vedere la sezione 'Aggiunta della risorsa indirizzo IP nella stessa subnet' in Appendice.See the ‘Adding IP Address Resource on Same Subnet’ section of the Appendix.
  • Controllare la configurazione DNS/propagazione ai client.Check DNS configuration/propogation to the clients.
  • Eseguire la migrazione della macchina virtuale SQL1 ed effettuare i passaggi da 2 a 4.Migrate SQL1 VM, and go through steps 2 – 4.
  • Se si utilizzano i passaggi 5ii, aggiungere SQL1 come possibile proprietario per la risorsa indirizzo IP aggiuntoIf using steps 5ii, then add SQL1 as a Possible Owner for the added IP Address Resource
  • Testare i failover.Test failovers.

2. Usare una o più repliche secondarie esistenti: multisito2. Utilize existing secondary replica(s): Multi-Site

Se sono disponibili nodi in più data center di Azure o se è disponibile un ambiente ibrido, si può usare una configurazione AlwaysOn in questo ambiente per ridurre al minimo i tempi di inattività.If you have nodes in more than one Azure datacenter (DC) or if you have a hybrid environment, then you can use an Always On configuration in this environment to minimize downtime.

L'approccio consiste nel cambiare in sincrona la sincronizzazione di AlwaysOn per il data center di Azure locale o secondario e quindi eseguire il failover in tale SQL Server.The approach is to change the Always On synchronization to Synchronous for the on-premises or secondary Azure DC, and then failover over to that SQL Server. Copiare quindi i dischi rigidi virtuali in un account di Archiviazione Premium e ridistribuire la macchina in un nuovo servizio cloud.Then copy the VHDs to a Premium Storage account, and redeploy the machine into a new cloud service. Aggiornare il listener ed eseguire il failback.Update the listener, and then fail back.

Punti dei tempi di inattivitàPoints of downtime

Il tempo di inattività corrisponde al tempo necessario per il failover al centro dati alternativo e ritorno.The downtime consists of the time to failover to the alternative DC and back. Dipende anche dalla configurazione del client/DNS e potrebbe determinare un ritardo della riconnessione del client.It also depends on your client/DNS configuration and your client reconnection may be delayed. Si consideri l'esempio seguente di una configurazione di AlwaysOn ibrida:Consider the following example of a hybrid Always On configuration:

MultiSite1

VantaggiAdvantages
  • È possibile utilizzare l'infrastruttura esistente.You can utilize existing infrastructure.
  • È possibile pre-aggiornare Archiviazione di Azure nel centro dati di Azure di ripristino di emergenza.You have the option to pre-upgrade the Azure storage on the DR Azure DC first.
  • È possibile riconfigurare l'archiviazione del centro dati di Azure di ripristino di emergenza.The DR Azure DC storage can be reconfigured.
  • Esiste un minimo di due failover durante la migrazione, esclusi i failover di test.There is a minimum of two failovers during migration, excluding test failovers.
  • Non è necessario spostare i dati di SQL Server con backup e ripristino.You do not need to move SQL Server data with backup and restore.
Svantaggi:Disadvantages
  • A seconda dell’accesso client a SQL Server, potrebbe esserci un aumento della latenza durante l'esecuzione di SQL Server in un centro dati alternativo per l'applicazione.Depending on client access to SQL Server, there might be increased latency when SQL Server is running in an alternative DC to the application.
  • Il tempo di copia dei dischi rigidi virtuali in Archiviazione Premium potrebbe essere lungo.The copy time of VHDs to Premium storage could be long. Ciò potrebbe influire sulla decisione relativa al mantenimento del nodo nel gruppo di disponibilità.This might affect your decision on whether to keep the node in the Availability Group. Considerare questo aspetto quando carichi di lavoro a uso intensivo di log vengono eseguiti durante le migrazioni richieste dal momento che il nodo primario dovrà mantenere le transazioni non replicate nel proprio log delle transazioni,Consider this for when log intensive work loads are running during the migration is required, since the Primary node will have to keep the unreplicated transactions in its transaction log. aumentando così in modo significativo.Therefore this could grow significantly.
  • Questo scenario prevede l’uso del commandlet Start-AzureStorageBlobCopy di Azure, che è asincrono.This scenario would use the Azure Start-AzureStorageBlobCopy commandlet, which is asynchronous. Non esiste alcun contratto di servizio al completamento.There is no SLA on completion. Il tempo delle copie varia perché dipende dal tempo di attesa in coda e dalla quantità di dati da trasferire.The time of the copies varies, while this depends on wait in queue, it will also depend on the amount of data to transfer. Di conseguenza, dal momento che si dispone di un solo nodo nel secondo centro dati, è opportuno prevedere operazioni di attenuazione per l’eventualità che la copia richieda più tempo durante i test.Therefore you just have one node in your 2nd data center, you should take mitigation steps in case the copy takes longer than in testing. Valutare, ad esempio, le possibilità seguenti.This could include the following ideas.
    • Aggiungere un secondo nodo di SQL Server temporaneo per la disponibilità elevata prima della migrazione con tempi di inattività concordati.Add a temporary 2nd SQL node for HA before the migration with agreed downtime.
    • Eseguire la migrazione all'esterno della manutenzione pianificata di Azure.Run the migration outside of Azure scheduled maintenance.
    • Assicurarsi di che avere configurato correttamente il quorum del cluster.Ensure you have configured your cluster quorum correctly.

Questo scenario presuppone di aver documentato l'installazione e che si sappia come viene eseguito il mapping dell’archiviazione in modo da poter apportare le modifiche necessarie a definire impostazioni della cache su disco ottimali.This scenario assumes that you have documented your install and know how the storage is mapped in order to make changes for optimal disk cache settings.

Procedure generaliHigh-level steps

MultiSite2

  • Rendere il centro dati di Azure locale/alternativo l'SQL Server primario e l’altro partner di failover automatico.Make the on-premises / alternate Azure DC the SQL Server Primary, and make it the other Auto Failover Partner (AFP).
  • Raccogliere la configurazione del disco da SQL2 e rimuovere il nodo (non eliminare i dischi rigidi virtuali collegati).Gather disk configuration information from SQL2, and remove the node (do not delete attached VHDs).
  • Creare un account di Archiviazione Premium e copiare i dischi rigidi virtuali dall'account di Archiviazione Standard.Create a Premium Storage account and copy VHDs from the Standard Storage account.
  • Creare un nuovo servizio cloud e la macchina virtuale SQL2 con relativi dischi di archiviazione Premium collegati.Create a new cloud service and create the SQL2 VM with its Premiums Storage disks attached.
  • Configurare ILB/ELB e aggiungere gli endpoint.Configure ILB / ELB and add Endpoints.
  • Aggiornare il listener di AlwaysOn con nuovo il indirizzo IP ILB/ELB e testare il failover.Update the Always On Listener with new ILB / ELB IP address and test failover.
  • Controllare la configurazione DNS.Check the DNS configuration.
  • Modificare l'AFP in SQL2, quindi eseguire la migrazione di SQL1 ed eseguire i passaggi da 2 a 5.Change the AFP to SQL2, and then migrate SQL1 and go through steps 2 – 5.
  • Testare i failover.Test failovers.
  • Riportare l'AFP a SQL1 e SQL2Switch the AFP back to SQL1 and SQL2

Appendice: Migrazione di un cluster AlwaysOn multisito all'Archiviazione PremiumAppendix: Migrating a Multisite Always On Cluster to Premium Storage

La parte restante di questo argomento fornisce un esempio dettagliato della conversione di un cluster AlwaysOn multisito all'archiviazione Premium.The remainder of this topic provides a detailed example of converting a multi-site Always On cluster to Premium storage. Il listener, inoltre, viene passato dall’uso di un servizio di bilanciamento del carico esterno (ELB) all’uso di un servizio di bilanciamento del carico interno (ILB).It also converts the Listener from using an external load balancer (ELB) to an internal load balancer (ILB).

EnvironmentEnvironment

  • Windows 2K12 /SQL 2K12Windows 2k12 / SQL 2k12
  • 1 File DB su SP1 DB Files on SP
  • 2 pool di archiviazione per ogni nodo2 x Storage Pools per Node

Appendix1

VM:VM:

In questo esempio sarà illustrato lo spostamento da un ELB a un ILB.In this example we are going to demonstrate moving from an ELB to ILB. ELB era disponibile prima di ILB, pertanto viene illustrato come eseguire questo passaggio durante la migrazione.ELB was available before ILB, so this shows how to switch to this during the migration.

Appendix2

Passaggi precedenti: Connettersi alla sottoscrizionePre Steps: Connect to Subscription

Add-AzureAccount

#Set up subscription
Get-AzureSubscription

Passaggio 1: Creare un nuovo account di archiviazione e servizio cloudStep 1: Create New Storage Account and Cloud Service

$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

Passaggio 2: Aumentare il numero di errori consentiti nelle risorse Step 2: Increase the permitted failures on resources

In alcune risorse che appartengono al gruppo di disponibilità AlwaysOn sono previsti limiti al numero di errori che possono verificarsi in un intervallo di tempo durante il quale il servizio cluster prova a riavviare il gruppo di risorse.On certain resources that belong to your Always On Availability Group there are limits on how many failures that can occur in a period, where the cluster service will attempt to restart the resource group. Si consiglia di aumentare questo numero durante l’esecuzione di questa procedura poiché se non si esegue il failover manuale e non si attivano i failover arrestando le macchine si potrebbe raggiungere il limite.It is recommended you increase this whilst you are walking through this procedure, since if you don’t manually failover and trigger failovers by shutting down machines you can get close to this limit.

Sarebbe prudente raddoppiare la quantità di errori consentita. A questo scopo, in Gestione cluster di failover passare alle proprietà del gruppo di risorse AlwaysOn:It would be prudent to double the failure allowance, to do this in Failover Cluster Manager, go to the Properties of the Always On resource group:

Appendix3

Modificare il numero massimo di errori in 6.Change the Maximum Failures to 6.

Passaggio 3: Aggiungere la risorsa indirizzo IP per il gruppo di cluster Step 3: Addition IP Address resource for Cluster Group

Se si dispone di un solo indirizzo IP per il gruppo cluster e questo viene allineato alla subnet cloud, tenere presente che se di portano accidentalmente offline tutti i nodi del cluster nel cloud nella rete, la risorsa IP del cluster e il nome di rete del cluster non potranno essere portati online.If you have only one IP address for the Cluster Group and this is aligned to the cloud subnet, beware, if you accidentally take offline all cluster nodes in the cloud on that network then the Cluster IP resource and Cluster Network Name will not be able to come online. In tal caso, gli aggiornamenti per altre risorse cluster non saranno consentiti.In the event of this it will prevent updates to other cluster resources.

Passaggio 4: Eseguire la configurazione di DNSStep 4: DNS configuration

L'implementazione di una transizione senza intoppi dipende dalla modalità di uso e aggiornamento del DNS.To implement a smooth transition depends on how DNS is being utilized and updated. Quando viene installato AlwaysOn, crea un gruppo di risorse cluster di Windows. Se si apre Gestione cluster di failover, si noterà la presenza di almeno tre risorse. Le due a cui fa riferimento il documento sono:When Always On is installed, it creates a Windows Cluster Resource group, if you open Failover Cluster Manager, you will see that at a minimum it will have three resources, the two that the document refers to are:

  • Nome di rete virtuale (VNN): questo è il nome DNS a cui si connette il client quando si sceglie di stabilire la connessione a SQL Server tramite AlwaysOn.Virtual Network Name (VNN) – This is the DNS name that client connect to when wanting to connect to SQL Servers via Always On.
  • Risorsa indirizzo IP: questo è l'indirizzo IP associato al nome di rete virtuale; possono essere più di uno e in una configurazione multisito sarà presente un indirizzo IP per sito/subnet.IP Address Resource – This is the IP address that associated with the VNN, you can have more than one, and in a multisite configuration you will have an IP address per site/subnet.

Quando ci si connette a SQL Sevrer, il driver del client SQL Server recupera i record DNS associati al listener e prova a connettersi a ogni indirizzo IP associato a AlwaysOn. Di seguito sono illustrati alcuni fattori che possono influenzare questa situazione.When connecting to SQL Server, the SQL Server Client driver will retrieve the DNS records associated with the listener and try to connect to each Always On associated IP address, below we discuss some factors that can influence this.

Il numero di record DNS simultanei associati al nome del listener dipende non solo dal numero di indirizzi IP associati, ma anche dall'impostazione 'RegisterAllIpProviders' in Clustering di failover per la risorsa nome di rete virtuale di AlwaysOn.The number of concurrent DNS records that are associated with the listener name depends not only on the number of IP addresses associated, but the ‘RegisterAllIpProviders’setting in Failover Clustering for the Always ON VNN resource.

Quando si distribuisce AlwaysOn in Azure, sono disponibili diversi passaggi per creare il listener e gli indirizzi IP. È necessario configurare manualmente su 1 l'impostazione "RegisterAllIpProviders", diversamente dalla distribuzione di AlwaysOn locale, dove è già impostata su 1.When you deploy Always On in Azure there are different steps to create the Listener and IP Addresses, you have to manually configure the ‘RegisterAllIpProviders’ to 1, this is different to an on-premises Always On deployment where it is already set to 1.

Se 'RegisterAllIpProviders' è 0, verrà visualizzato solo un record DNS nel DNS associato il listener:If ‘RegisterAllIpProviders’ is 0, then you will only see one DNS record in DNS associated with the Listener:

Appendix4

Se 'RegisterAllIpProviders' è 1:If ‘RegisterAllIpProviders’ is 1:

Appendix5

Il codice riportato di seguito esegue dump delle impostazioni del nome di rete virtuale e lo imposta automaticamente. Tenere presente che per rendere effettiva la modifica è necessario portare il nome di rete virtuale offline e poi di nuovo online, operazione che causa l'interruzione della connettività client.The code below will dump out the VNN settings and set it for you, please note, for the change to take effect you will need to take the VNN offline and turn it back online, this taking the Listener offline causing client connectivity disruption.

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

In un passaggio di migrazione successivo si dovrà aggiornare il listener AlwaysOn con un indirizzo IP aggiornato che farà riferimento a un servizio di bilanciamento del carico. Ciò comporterà la rimozione e l'aggiunta di una risorsa indirizzo IP.In a later migration step you will need to update the Always On listener with an updated IP address that will reference a load balancer, this will involve an IP Address resource removal and addition. Dopo l’aggiornamento IP, è necessario assicurarsi che il nuovo indirizzo IP sia stato aggiornato nella zona DNS e che i client aggiornino la relativa cache DNS locale.After the IP update, you need to ensure the new IP address has been updated in DNS Zone and that the clients are updating their local DNS cache.

Se i client si trovano in segmenti di rete diversi e fanno riferimento a un server DNS diverso, è necessario considerare ciò che accade sul trasferimento di zona DNS durante la migrazione dal momento che il tempo di riconnessione dell'applicazione sarà limitato almeno del tempo di trasferimento di zona di ogni nuovo indirizzo IP per il listener.If your clients reside in a different network segment and reference a different DNS server, you need to consider what happens about DNS Zone Transfer during the migration, as the application reconnect time will be constrained by at least the Zone Transfer Time of any new IP addresses for the listener. In caso di vincolo di tempo, è necessario discutere e verificare imponendo un trasferimento di zona incrementale con i team di Windows e, inoltre, impostare il record host DNS su una durata (TTL) inferiore, così i client si aggiornano.If you are under time constraint here, you should discuss and test forcing an incremental zone transfer with your Windows teams, and also put the DNS host record to a lower Time To Live (TTL), so the clients update. Per ulteriori informazioni, vedere Trasferimenti di zona incrementali e Start-DnsServerZoneTransfer.For more information, see Incremental Zone Transfers and Start-DnsServerZoneTransfer.

Per impostazione predefinita, il valore TTL per il Record DNS associato al Listener in AlwaysOn in Azure è 1200 secondi.By default the TTL for DNS Record that is associated with the Listener in Always On in Azure is 1200 seconds. È possibile ridurre questo valore in caso di vincolo di tempo durante la migrazione per assicurarsi che i client aggiornino il proprio DNS con l'indirizzo IP aggiornato per il listener.You may wish to reduce this if you are under time constraint during your migration to ensure the clients update their DNS with the updated IP address for the listener. È possibile visualizzare e modificare la configurazione eseguendo il dump della configurazione del nome di rete virtuale:You can see and modify the configuration by dumping out the configuration of the VNN:

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

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

Si noti che più basso è 'HostRecordTTL' più alto sarà il traffico DNS.Please note, the lower the ‘HostRecordTTL’, a higher amount of DNS traffic will occur.

Impostazioni applicazione clientClient application settings

Se l'applicazione client SQL supporta .Net 4.5 SQLClient, è possibile usare la parola chiave "MULTISUBNETFAILOVER=TRUE", che è consigliabile applicare perché consente una connessione più veloce al gruppo di disponibilità SQL AlwaysOn durante il failover.If your SQL client application supports the .Net 4.5 SQLClient, then you can use ‘MULTISUBNETFAILOVER=TRUE’ keyword, this is recommended to be applied as it allows for faster connection to SQL Always On Availability Group during failover. Enumera tutti gli indirizzi IP associati al listener AlwaysOn in parallelo e consente una velocità di tentativi di connessione TCP maggiore durante un failover.It enumerates through all IP addresses associated with the Always On listener in parallel, and performs a more aggressive TCP connection retry speed during a failover.

Per ulteriori informazioni riguardanti le impostazioni precedenti, vedere Parola chiave MultiSubnetFailover e funzionalità associate.For more information regarding the settings above, please see MultiSubnetFailover Keyword and Associated Features. Vedere anche Supporto SqlClient per disponibilità elevata, ripristino di emergenza.Also see SqlClient Support for High Availability, Disaster Recovery.

Passaggio 5: Impostare il quorum del clusterStep 5: Cluster quorum settings

Poiché sarà portato offline almeno un SQL Server alla volta, è necessario modificare l'impostazione del quorum cluster, se si usa FSW (File Share Witness) con due nodi. Il quorum deve essere impostato in modo da consentire la maggioranza del nodo e usare la votazione dinamica al fine di permettere a un singolo nodo di rimanere permanente.As you are going to be taking out at least one SQL Server down at a time, you should modify the cluster quorum setting, if using File Share Witness (FSW) with 2 nodes, you should set the quorum to allow node majority and utilize dynamic voting, and this is to allow for a single node to remain standing.

Set-ClusterQuorum -NodeMajority  

Per ulteriori informazioni sulla gestione e configurazione del quorum del cluster, vedere Configurare e gestire il quorum in un cluster di failover di Windows Server 2012.For more information on managing and configuring the cluster quorum, please see Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster.

Passaggio 6: Estrarre endpoint e ACL esistentiStep 6: Extract Existing Endpoints and ACLs

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

Salvarli in un file di testo.Save these to a text file.

Passaggio 7: Modificare i partner di failover e le modalità di replicaStep 7: Change Failover Partners and Replication Modes

Se si dispone di più di 2 SQL Server, è necessario impostare su "Sincrono" il failover di un'altra replica secondaria in un altro centro dati o locale e renderlo Partner di failover automatico (AFP) in modo da mantenere la disponibilità elevata mentre si apportano modifiche.If you have more than 2 SQL Servers, you should change the failover of another secondary in another DC or on-premises to ‘Synchronous’ and make it an Automatic Failover Partner (AFP), this is so you maintain HA whilst you are making changes. A tale scopo, è possibile utilizzare TSQL o SSMS:You can do this through TSQL of modify though SSMS:

Appendix6

Passaggio 8: Rimuovere la VM secondaria dal servizio cloudStep 8: Remove Secondary VM from cloud service

È consigliabile pianificare prima la migrazione di un nodo secondario del cloud, se è attualmente primario, è necessario avviare un failover manuale.You should be planning to migrate a cloud secondary node first, if this is currently primary, you should initiate a manual failover.

$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

Passaggio 9: Modificare le impostazioni di caching del disco nel file CSV e salvareStep 9: Change disk caching settings in CSV file and save

Per i volumi di dati, devono essere impostate su READONLY.For data volumes these should be set to READONLY.

Per i volumi di TLOG, devono essere impostate su NONE.For TLOG volumes these should be set to NONE.

Appendix7

Passaggio 10: Copiare i dischi rigidi virtualiStep 10: Copy 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
   }

È possibile controllare lo stato della copia dei dischi rigidi virtuali per l'account di Archiviazione Premium:You can check the copy status of the VHDs to the Premium Storage account:

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

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

Appendix8

Attendere che tutto venga registrato come esito positivo.Wait until all these are recorded as success.

Per informazioni per i singoli BLOB:For information for individual blobs:

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

Passaggio 11: Registrare un disco del sistema operativoStep 11: Register 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"

Passaggio 12: Importare la replica secondaria nel nuovo servizio cloudStep 12: Import secondary into new cloud service

Il codice riportato di seguito utilizza anche l'opzione aggiunta qui, è possibile importare la macchina e utilizzare l'indirizzo VIP da conservare.The code below also uses the added option here you can import the machine and use the retainable VIP.

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

#Create new Avaiability 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)

Passaggio 13: Creare il servizio ILB sul nuovo Svc cloud, aggiungere endpoint a carico bilanciato e ACLStep 13: Create ILB on New Cloud Svc, Add Load Balanced Endpoints and ACLs

#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

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

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

Passaggio 14: Aggiornare AlwaysOnStep 14: Update Always On

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

Appendix9

Ora, rimuovere l’indirizzo IP del servizio cloud precedente.Now remove the old cloud service IP Address.

Appendix10

Passaggio 15: Eseguire il controllo dell'aggiornamento DNSStep 15: DNS update check

È ora necessario controllare i server DNS nelle reti client SQL Server e assicurarsi che il servizio cluster abbia aggiunto il record host aggiuntivo per l'indirizzo IP aggiunto.You should now check DNS Servers on your SQL Server client networks and make sure that clustering has added the extra host record for the added IP address. Se tali server DNS non sono stati aggiornati, forzare un trasferimento di zona DNS e assicurarsi che i client presenti nella subnet riescano a risolversi in entrambi gli indirizzi IP di AlwaysOn, in modo che non sia necessario attendere la replica DNS automatica.If those DNS servers have not updated, consider forcing a DNS Zone transfer and ensure that the clients in there subnet are able to resolve to both Always On IP Addresses, this is so you do not need to wait for automatic DNS replication.

Passaggio 16: Riconfigurare Always OnStep 16: Reconfigure Always On

A questo punto è necessario attendere che il database secondario su cui è stato migrato il nodo venga risincronizzato completamente e passare al nodo di replica sincrona e renderlo AFP.At this point you wait for the secondary that node that was migrated to fully resynchronize with the on-premises node and switch to synchronous replication node and make it the AFP.

Passaggio 17: Eseguire la migrazione del secondo nodoStep 17: Migrate second node

$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

Passaggio 18: Modificare le impostazioni di caching del disco nel file CSV e salvareStep 18: Change disk caching settings in CSV file and save

Per i volumi di dati, devono essere impostate su READONLY.For data volumes these should be set to READONLY.

Per i volumi di TLOG, devono essere impostate su NONE.For TLOG volumes these should be set to NONE.

Appendix11

Passaggio 19: Creare nuovi account di archiviazione indipendente per il nodo secondarioStep 19: Create New Independent Storage Account for Secondary Node

$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

Passaggio 20: Copiare i dischi rigidi virtualiStep 20: Copy 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 induvidual blob status
Get-AzureStorageBlobCopyState -Blob "danRegSvcAms-dansqlams1-2014-07-03.vhd" -Container $containerName -Context $xioContext

È possibile controllare lo stato di copia del disco rigido virtuale per tutti i dischi rigidi virtuali: ForEach ($disk in $diskobjects) {$lun = $disk. LUN $vhdname = $disk.vhdname $cacheoption = $disk. HostCaching $disklabel = $disk. EtichettaDisco $diskName = $disk.DiskNameYou can check the VHD copy status for all VHDs: 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
   }

Appendix12

Attendere che tutto venga registrato come esito positivo.Wait until all these are recorded as success.

Per informazioni per i singoli BLOB:For information for individual blobs:

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

Passaggio 21: Registrare il disco del sistema operativoStep 21: Register 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 Avaiability 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

Passaggio 22: Aggiungere endpoint con carico bilanciato e ACLStep 22: Add Load Balanced Endpoints and ACLs

#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

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

Passaggio 23: Eseguire il failover di testStep 23: Test failover

A questo punto, è consigliabile consentire al nodo migrato di sincronizzarsi con il nodo AlwaysOn locale, impostarlo in modalità di replica sincrona e attendere che sia sincronizzato.You should now let the migrated node synchronize with the on-premises Always On node, place it in to synchronous replication mode and wait until it is synchronized. Quindi eseguire il failover da locale sul primo nodo migrato, ossia AFP.Then failover from on-prem to the first node migrated, which is the AFP. Successivamente, modificare l’ultimo nodo migrato in AFP.Once that has worked, change the last migrated node to the AFP.

È consigliabile testare i failover tra tutti i nodi ed eseguire i caos test per assicurarsi che i failover funzionino nel modo previsto e nei tempi indicati.You should test failovers between all nodes and run though chaos tests to ensure failovers work as expected and in a timely manor.

Passaggio 24: Ripristinare le impostazioni quorum del cluster / TTL DNS / Failover Pntrs / impostazioni di sincronizzazioneStep 24: Put back cluster quorum settings / DNS TTL / Failover Pntrs / Sync Settings

Aggiunta della risorsa indirizzo IP nella stessa SubnetAdding IP Address Resource on Same Subnet

Se sono presenti solo due server SQL e si vuole eseguirne la migrazione a un nuovo servizio cloud ma mantenerli nella stessa subnet, è possibile evitare di portare offline il listener per eliminare l'indirizzo IP di AlwaysOn originale e aggiungere il nuovo indirizzo IP.If you have only 2 SQL Servers and want to migrate them to a new cloud service, but want to keep them on the same subnet, you can avoid taking the listener offline to delete the original Always On IP Address and add the New IP Address. Se si esegue la migrazione delle macchine virtuali in un'altra subnet non sarà necessario eseguire questa operazione perché una rete di cluster aggiuntiva farà riferimento a tale subnet.If you are migrating the VMs to another subnet you will not need to do this as there will be an additional cluster network that will reference that subnet.

Dopo aver attivato la replica secondaria migrata e aggiunto la nuova risorsa indirizzo IP per il nuovo servizio cloud prima del failover della replica primaria esistente, è necessario eseguire questi passaggi in Gestione failover cluster:Once you have brought up the migrated secondary and added in the new IP Address resource for the new cloud service before failover the existing Primary, you should take these steps within the Cluster Failover Manager:

Per aggiungere l'indirizzo IP, vedere l’ Appendice, passaggio 14.To add in IP Address, see the Appendix, step 14.

  1. Per la risorsa indirizzo IP corrente, modificare il proprietario possibile in 'SQL Server primario esistente', nell'esempio seguente 'dansqlams4':For the current IP Address resource, change the possible owner to ‘Existing Primary SQL Server’, in the example below, ‘dansqlams4’:

    Appendix13

  2. Per la nuova risorsa indirizzo IP, modificare il proprietario possibile in 'SQL Server secondario migrato', nell'esempio seguente 'dansqlams5':For the new IP Address resource, change the possible owner to ‘Migrated secondary SQL Server’, in the example below, ‘dansqlams5’:

    Appendix14

  3. Dopo queste impostazioni, è possibile eseguire il failover e quando l'ultimo viene migrato, i possibili proprietari devono essere modificati in modo che tale nodo venga aggiunto come possibile proprietario:Once this is set you can failover, and when the last node is migrated the Possible Owners should be edited so that node is added as a Possible Owner:

    Appendix15

Risorse aggiuntiveAdditional resources