Utiliser le Stockage Premium Azure avec SQL Server sur des Machines Virtuelles

Aperçu

Azure Premium SSD est la nouvelle génération de stockage qui fournit une faible latence et des E/S à débit élevé. Il fonctionne mieux pour les charges de travail importantes d’E/S, telles que SQL Server sur des machines virtuelles IaaS.

Cet article fournit des conseils et une planification pour la migration d’une machine virtuelle exécutant SQL Server pour utiliser le stockage Premium. Cela inclut l’infrastructure Azure (mise en réseau, stockage) et les étapes de machine virtuelle Windows invitée. L’exemple de l’annexe montre une migration complète complète de bout en bout de la façon de déplacer des machines virtuelles plus volumineuses pour tirer parti d’un stockage SSD local amélioré avec PowerShell.

Il est important de comprendre le processus de bout en bout d’utilisation d’Azure Premium Storage avec SQL Server sur des machines virtuelles IAAS. Cela inclut les éléments suivants :

• Identification des conditions préalables à l’utilisation du stockage Premium.
• Exemples de déploiement de SQL Server sur IaaS vers le stockage Premium pour les nouveaux déploiements.
• Exemples de migration de déploiements existants, à la fois des serveurs autonomes et des déploiements à l’aide de groupes de disponibilité SQL Always On.
• Approches de migration possibles.
• Exemple complet de bout en bout montrant les étapes d’Azure, Windows et SQL Server pour la migration d’une implémentation Always On existante.

Pour plus d’informations sur SQL Server dans les machines virtuelles Azure, consultez SQL Server dans machines virtuelles Azure.

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

Conditions préalables pour le stockage Premium

Il existe plusieurs conditions préalables à l’utilisation du stockage Premium.

Taille de la machine

Pour utiliser le stockage Premium, vous devez utiliser des machines virtuelles de série DS. Si vous n’avez pas déjà utilisé de machines de série DS dans votre service cloud, vous devez supprimer la machine virtuelle existante, conserver les disques attachés, puis créer un service cloud avant de recréer la machine virtuelle en tant que taille de rôle DS*. Pour plus d’informations sur les tailles de machine virtuelle, consultez Virtual Machine and Cloud Service Sizes for Azure.

Services de cloud

Vous pouvez uniquement utiliser des machines virtuelles DS* avec stockage Premium lorsqu’elles sont créées dans un nouveau service cloud. Si vous utilisez SQL Server Always On dans Azure, l’écouteur Always On fait référence à l'adresse IP du Load Balancer Interne ou Externe d'Azure associée à un service de cloud. Cet article se concentre sur la migration tout en conservant la disponibilité dans ce scénario.

Réseaux virtuels régionaux

Pour les machines virtuelles DS*, vous devez configurer le réseau virtuel (VNET) hébergeant vos machines virtuelles comme régionales. Ce « widens » du réseau virtuel consiste à permettre aux machines virtuelles plus volumineuses d’être approvisionnées dans d’autres clusters et d’autoriser la communication entre eux. Dans la capture d’écran suivante, l’emplacement mis en surbrillance affiche les réseaux virtuels régionaux, tandis que le premier résultat montre un réseau virtuel « étroit ».

Vous pouvez déclencher un ticket de support Microsoft pour migrer vers un réseau virtuel régional. Microsoft apporte ensuite une modification. Pour effectuer la migration vers des réseaux virtuels régionaux, modifiez la propriété AffinityGroup dans la configuration réseau. Tout d’abord, exportez la configuration réseau dans PowerShell, puis remplacez la propriété AffinityGroup dans l’élément VirtualNetworkSite par une propriété Location . Spécifiez Location = XXXX quand XXXX est une région Azure. Ensuite, importez la nouvelle configuration.

Par exemple, en tenant compte de la configuration de réseau virtuel suivante :

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

Pour passer à un réseau virtuel régional en Europe Ouest, remplacez la configuration par ce qui suit :

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

Comptes de stockage

Vous devez créer un compte de stockage configuré pour le stockage Premium. Notez que l’utilisation du stockage Premium est définie sur le compte de stockage, et non sur des disques durs virtuels individuels. Toutefois, lors de l’utilisation d’une machine virtuelle de série DS*, vous pouvez attacher les disques durs virtuels à partir de comptes de stockage Premium et Standard. Vous pouvez envisager cela si vous ne souhaitez pas placer le disque dur virtuel du système d’exploitation sur le compte de stockage Premium.

La commande New-AzureStorageAccountPowerShell suivante avec le type « Premium_LRS » crée un compte de stockage Premium :

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

Paramètres du cache des disques durs virtuels

La principale différence entre la création de disques qui font partie d’un compte de stockage Premium est le paramètre de cache de disque. Pour les disques de volume de données SQL Server, il est recommandé d’utiliser « mise en cache en lecture ». Pour les volumes du journal des transactions, le paramètre de cache de disque doit être défini sur « Aucun ». Cela diffère des recommandations pour les comptes de stockage Standard.

Une fois que les disques durs virtuels ont été attachés, le paramètre de cache ne peut pas être modifié. Vous devez détacher et rattacher le disque dur virtuel avec un paramètre de cache mis à jour.

Espaces de stockage Windows

Vous pouvez utiliser des espaces de stockage Windows comme vous l’avez fait avec le stockage Standard précédent, ce qui vous permet de migrer une machine virtuelle qui utilise déjà des espaces de stockage. L’exemple de l’annexe (étape 9 et suivantes) illustre le code PowerShell pour extraire et importer une machine virtuelle avec plusieurs disques durs virtuels attachés.

Les pools de stockage ont été utilisés avec le compte de stockage Azure Standard pour améliorer le débit et réduire la latence. Vous pouvez trouver une valeur dans le test des pools de stockage avec stockage Premium pour les nouveaux déploiements, mais ils ajoutent une complexité supplémentaire à la configuration du stockage.

Comment trouver les disques virtuels Azure associés aux pools de stockage

Comme il existe différentes recommandations de paramètre de cache pour les disques durs virtuels attachés, vous pouvez décider de copier les disques durs virtuels dans un compte de stockage Premium. Toutefois, lorsque vous les rattachez à la nouvelle machine virtuelle de la série DS, vous devrez peut-être modifier les paramètres du cache. Il est plus simple d’appliquer les paramètres de cache recommandés pour le stockage Premium lorsque vous avez des disques durs virtuels distincts pour les fichiers de données SQL et les fichiers journaux (plutôt qu’un seul disque dur virtuel qui contient les deux).

Toutefois, si vous utilisez des espaces de stockage Windows constitués de plusieurs disques durs virtuels, vous devez examiner vos scripts d’origine pour identifier les disques durs virtuels attachés qui se trouvent dans le pool spécifique. Vous pouvez donc définir les paramètres de cache en conséquence pour chaque disque.

Si vous n’avez pas de script d’origine disponible pour afficher les disques durs virtuels mappés au pool de stockage, vous pouvez utiliser les étapes suivantes pour déterminer le mappage de disque/pool de stockage.

Pour chaque disque, procédez comme suit :

1. Obtenez la liste des disques attachés à la machine virtuelle avec la commande Get-AzureVM :

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

1. Notez le nom de disque et le numéro d’unité logique.

   

2. Bureau à distance dans la machine virtuelle. Accédez ensuite à Gestion de l'ordinateur | Gestionnaire de périphériques | Lecteurs de disque. Examinez les propriétés de chacun des « disques virtuels Microsoft »

   

3. Le numéro d’unité logique ici est une référence au numéro d’unité logique que vous spécifiez lors de l’attachement du disque dur virtuel à la machine virtuelle.

4. Pour « Disque virtuel Microsoft », accédez à l’onglet Détails , puis, dans la liste des propriétés , accédez à Clé de pilote. Dans la valeur, notez le décalage, qui est 0002 dans la capture d’écran suivante. Le 0002 désigne physicalDisk2 référencé par le pool de stockage.

   

5. Pour chaque pool de stockage, listez les disques associés :

Get-StoragePool -FriendlyName AMS1pooldata | Get-PhysicalDisk

Vous pouvez maintenant utiliser ces informations pour associer des VHDs attachés à des disques physiques dans des pools de stockage.

Une fois que vous avez mappé des disques durs virtuels à des disques physiques dans des pools de stockage, vous pouvez ensuite les détacher et les copier sur un compte de stockage Premium, puis les attacher avec le paramètre de cache approprié. Consultez l’exemple de l’annexe, étapes 8 à 12. Ces étapes montrent comment extraire une configuration de disque dur virtuel attaché à une machine virtuelle dans un fichier CSV, copier les disques durs virtuels, modifier les paramètres du cache de configuration du disque et enfin redéployer la machine virtuelle en tant que machine virtuelle de série DS avec tous les disques attachés.

Bande passante de stockage des machines virtuelles et débit de stockage de disque dur virtuel

La quantité de performances de stockage dépend de la taille de machine virtuelle DS* spécifiée et des tailles de disque dur virtuel. Les machines virtuelles ont des allocations différentes pour le nombre de disques durs virtuels qui peuvent être attachés et la bande passante maximale qu’elles prennent en charge (Mo/s). Pour connaître les numéros de bande passante spécifiques, consultez Machines virtuelles et tailles de service cloud pour Azure.

L'augmentation des IOPS est obtenue avec des tailles de disque plus grandes. Vous devez tenir compte de cela lorsque vous réfléchissez à votre chemin de migration. Pour plus d’informations, consultez le tableau des E/S par seconde et des types de disques.

Enfin, considérez que les machines virtuelles ont des bande passantes de disque maximales différentes qu’elles prennent en charge pour tous les disques attachés. Sous une charge élevée, vous pouvez saturer la bande passante maximale de disque disponible pour cette taille de rôle de machine virtuelle. Par exemple, un Standard_DS14 prend en charge jusqu’à 512 Mo/s ; par conséquent, avec trois disques P30, vous pouvez saturer la bande passante du disque de la machine virtuelle. Toutefois, dans cet exemple, la limite de débit peut être dépassée en fonction de la combinaison d’E/S de lecture et d’écriture.

Nouveaux déploiements

Les deux sections suivantes montrent comment déployer des machines virtuelles SQL Server dans le stockage Premium. Comme mentionné précédemment, vous n’avez pas nécessairement besoin de placer le disque du système d’exploitation sur le stockage Premium. Vous pouvez choisir de le faire si vous envisagez de placer des charges de travail d’E/S intensives sur le disque dur virtuel du système d’exploitation.

Le premier exemple illustre l’utilisation d’images de galerie Azure existantes. Le deuxième exemple montre comment utiliser une image de machine virtuelle personnalisée que vous avez dans un compte de stockage Standard existant.

Créer une nouvelle machine virtuelle avec stockage Premium et image de la galerie

L’exemple ci-dessous montre comment placer le disque dur virtuel du système d’exploitation sur un stockage Premium et attacher des disques durs virtuels de stockage Premium. Toutefois, vous pouvez également placer le disque du système d’exploitation dans un compte de stockage Standard, puis attacher des disques durs virtuels qui résident dans un compte de stockage Premium. Les deux scénarios sont illustrés.

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

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

Étape 1 : Créer un compte de stockage Premium

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

Étape 2 : Créer un service cloud

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

Étape 3 : Réserver un VIP pour un service Cloud (facultatif)

#check exisitng reserved VIP
Get-AzureReservedIP

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

Étape 4 : Créer un conteneur de machines virtuelles

#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

Étape 5 : Placer le VHD du système d’exploitation sur le stockage Standard ou Premium

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

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

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

Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount  $standardstorageaccountname

Étape 6 : Créer une machine virtuelle

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

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

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

#create new Availability Set
$availabilitySet = "cloudmigAVAMS"

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

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

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

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

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

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

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

Créer une machine virtuelle pour utiliser le stockage Premium avec une image personnalisée

Ce scénario montre où vous disposez d’images personnalisées existantes qui résident dans un compte de stockage Standard. Comme mentionné, si vous souhaitez placer le disque dur virtuel du système d'exploitation sur le stockage Premium, vous devez copier l'image qui existe dans le compte de stockage Standard et la transférer vers un stockage Premium avant de pouvoir l'utiliser. Si vous disposez d’une image sur site, vous pouvez également utiliser cette méthode pour copier celle-ci directement dans le compte de stockage Premium.

Étape 1 : Créer un compte de stockage

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

Étape 2 : Créer un service cloud

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

Étape 3 : Utiliser une image existante

Vous pouvez utiliser une image existante. Vous pouvez également prendre une image d’une machine existante. Notez que la machine que vous imaginez n'a pas besoin d'être une machine DS*. Une fois que vous avez l’image, les étapes suivantes montrent comment la copier dans le compte de stockage Premium avec la commande Start-AzureStorageBlobCopy PowerShell.

#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  

Étape 4 : Copier un blob entre des comptes de stockage

#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  

Étape 5 : Vérifiez régulièrement l’état de copie :

$blob | Get-AzureStorageBlobCopyState

Étape 6 : Ajouter un disque image au référentiel de disques Azure dans l’abonnement

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

Add-AzureVMImage -ImageName $newimageName -MediaLocation $imageMediaLocation

Étape 7 : Générer la machine virtuelle

Ici, vous créez la machine virtuelle à partir de votre image et attachez deux disques durs virtuels de stockage Premium :

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

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

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

#create new Availability Set
$availabilitySet = "cloudmigAVAMS3"

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


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

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



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

Déploiements existants qui n’utilisent pas de groupes de disponibilité Always On

Il existe différentes considérations relatives aux déploiements SQL Server qui n’utilisent pas les groupes de disponibilité Always On et ceux qui le font. Si vous n’utilisez pas Always On et que vous disposez d’un serveur SQL Server autonome existant, vous pouvez effectuer une mise à niveau vers le stockage Premium à l’aide d’un nouveau service cloud et d’un nouveau compte de stockage. Considérez les options suivantes :

• Créez une machine virtuelle SQL Server. Vous pouvez créer une machine virtuelle SQL Server qui utilise un compte de stockage Premium, comme documenté dans les nouveaux déploiements. Sauvegardez et restaurez ensuite vos bases de données utilisateur et de configuration SQL Server. L’application doit être mise à jour pour référencer le nouveau serveur SQL Server s’il est accessible en interne ou en externe. Vous devez copier tous les objets « hors base de données » comme si vous faisiez une migration côte à côte (SxS) SQL Server. Cela inclut des objets tels que les connexions, les certificats et les serveurs liés.
• Migrez une machine virtuelle SQL Server existante. Cela nécessite de mettre la machine virtuelle SQL Server hors connexion, puis de la transférer vers un nouveau service cloud, ce qui inclut la copie de tous ses disques durs virtuels attachés vers le compte de stockage Premium. Lorsque la machine virtuelle est en ligne, l’application fait référence au nom d’hôte du serveur comme avant. N’oubliez pas que la taille du disque existant affecte les caractéristiques de performances. Par exemple, un disque de 400 Go est arrondi à un P20. Si vous savez que vous n’avez pas besoin de ces performances de disque, vous pouvez recréer la machine virtuelle en tant que machine virtuelle de série DS et attacher des disques durs virtuels de stockage Premium de la taille/des performances dont vous avez besoin. Vous pouvez ensuite détacher et réattacher les fichiers de base de données SQL.

Si votre serveur SQL Server est accessible en externe, l’adresse IP virtuelle du service cloud change. Vous devez également mettre à jour les points de terminaison, les listes de contrôle d’accès et les paramètres DNS.

Déploiements existants utilisant les groupes de disponibilité Always On

Initialement dans cette section, nous examinons comment Always On interagit avec La mise en réseau Azure. Nous allons ensuite décomposer les migrations dans deux scénarios : les migrations où certains temps d’arrêt peuvent être tolérés et les migrations où vous devez obtenir un temps d’arrêt minimal.

Les groupes de disponibilité Always On SQL Server locaux utilisent un écouteur local qui inscrit un nom DNS virtuel avec une adresse IP partagée entre un ou plusieurs serveurs SQL Server. Lorsque les clients se connectent, ils sont routés via l’adresse IP de l’écouteur vers le serveur SQL Server principal. Il s’agit du serveur propriétaire de la ressource IP Always On à ce moment-là.

Dans Microsoft Azure, vous ne pouvez avoir qu’une seule adresse IP affectée à une carte réseau sur la machine virtuelle. Par conséquent, pour obtenir la même couche d’abstraction que locale, Azure utilise l’adresse IP affectée aux équilibreurs de charge internes/externes (ILB/ELB). La ressource IP partagée entre les serveurs est définie sur la même adresse IP que l’ILB/ELB. Ceci est publié dans le DNS et le trafic client est transmis via l’ILB/ELB vers le réplica SQL Server principal. L’ILB/ELB sait quel SQL Server est principal, car il utilise des sondes pour sonder la ressource IP Always On. Dans l’exemple précédent, il sonde chaque nœud ayant un point de terminaison référencé par l’ELB/ILB, et le nœud qui répond est identifié comme le serveur SQL Server principal.

Migration de déploiements Always On qui peuvent permettre un temps d’arrêt

Il existe deux stratégies pour migrer des déploiements Always On qui permettent un temps d’arrêt :

1. Ajouter d’autres réplicas secondaires à un cluster Always On existant
2. Migrer vers un nouveau cluster Always On

1. Ajouter d’autres réplicas secondaires à un cluster Always On existant

Une stratégie consiste à ajouter d’autres secondaires au groupe de disponibilité Always On. Vous devez les ajouter à un nouveau service cloud et mettre à jour l’écouteur avec la nouvelle adresse IP de l’équilibreur de charge.

Points de temps d’arrêt :

• Validation du cluster.
• Test des basculements Always On pour les nouveaux Secondaires.

Si vous utilisez des pools de stockage Windows au sein de la machine virtuelle pour un débit d’E/S plus élevé, ceux-ci sont mis hors connexion pendant une validation complète du cluster. Le test de validation est requis lorsque vous ajoutez des nœuds au cluster. Le temps nécessaire à l’exécution du test peut varier. Vous devez donc le tester dans votre environnement de test représentatif pour obtenir un délai approximatif de la durée nécessaire.

Vous devez prévoir du temps pour pouvoir effectuer des tests manuels de basculement et de chaos sur les nœuds qui viennent d’être ajoutés afin de garantir que les fonctions haute disponibilité Always On fonctionnent comme prévu.

1. Créez deux serveurs SQL Server dans un nouveau service cloud avec stockage Premium attaché.

2. Copiez les sauvegardes complètes et restaurez-les avec NORECOVERY.

3. Copiez les objets dépendants à partir de la base de données utilisateur, tels que les identifiants, etc.

4. Créez un équilibreur de charge interne (ILB) ou utilisez un équilibreur de charge externe (ELB), puis configurez des points de terminaison d’équilibrage de charge sur les deux nouveaux nœuds.

   Remarque

   Vérifiez que toutes les nœuds ont la configuration de point de terminaison correcte avant de continuer

5. Arrêtez l’accès utilisateur/application à SQL Server (si vous utilisez des pools de stockage).

6. Arrêtez sql Server Engine Services sur tous les nœuds (si vous utilisez des pools de stockage).

7. Ajoutez de nouveaux nœuds au cluster et exécutez la validation complète.

8. Une fois la validation réussie, démarrez tous les services SQL Server.

9. Sauvegardez les journaux des transactions et restaurez les bases de données utilisateur.

10. Ajoutez de nouveaux nœuds au groupe de disponibilité Always On et placez la réplication dans Synchrone.

11. Ajoutez la ressource d'adresse IP du nouvel équilibreur de charge interne (ILB) ou externe (ELB) du service cloud via PowerShell pour Always On basé sur l'exemple multi-site de l'annexe. Dans le clustering Windows, définissez les propriétaires possibles de la ressource d’adresse IP sur les nouveaux nœuds anciens. Consultez la section « Ajout d’une ressource d’adresse IP sur le même sous-réseau » de l’annexe.

12. Basculement vers l’un des nouveaux nœuds.

13. Transformez les nouveaux nœuds en partenaires de basculement automatique et testez les basculements.

14. Supprimez les nœuds originaux du groupe de disponibilité.

Avantages

• Les nouveaux serveurs SQL peuvent être testés (SQL Server et Application) avant d’être ajoutés à Always On.
• Vous pouvez modifier la taille de la machine virtuelle et personnaliser le stockage en fonction de vos besoins exacts. Toutefois, il serait utile de conserver tous les chemins d’accès de fichier SQL identiques.
• Vous pouvez contrôler quand le transfert des sauvegardes de base de données vers les réplicas secondaires est démarré. Cela diffère de l’utilisation de l’applet de commande Azure Start-AzureStorageBlobCopy pour copier des disques durs virtuels, car il s’agit d’une copie asynchrone.

Inconvénients

• Lorsque vous utilisez des pools de stockage Windows, il existe un temps d’arrêt du cluster pendant la validation complète du cluster pour les nouveaux nœuds supplémentaires.
• En fonction de la version de SQL Server et du nombre existant de réplicas secondaires, il se peut que vous ne puissiez pas ajouter d’autres réplicas secondaires sans supprimer des réplicas secondaires existants.
• Il peut y avoir un temps de transfert de données SQL long lors de la configuration des fichiers secondaires.
• Il existe des coûts supplémentaires pendant la migration pendant que vous avez de nouvelles machines en cours d’exécution en parallèle.

2. Migrer vers un nouveau cluster Always On

Une autre stratégie consiste à créer un cluster Always On avec de nouveaux nœuds dans le nouveau service cloud, puis à rediriger les clients pour l’utiliser.

Points de temps d’arrêt

Il y a un temps d’arrêt lorsque vous transférez des applications et des utilisateurs vers le nouvel écouteur Always On. Le temps d’arrêt dépend des éléments suivants :

• Temps nécessaire pour restaurer les sauvegardes finales du journal des transactions sur les bases de données sur de nouveaux serveurs.
• Temps nécessaire pour mettre à jour les applications clientes afin d’utiliser un nouvel écouteur Always On.

Avantages

• Vous pouvez tester l’environnement de production réel, SQL Server et les modifications de build du système d’exploitation.
• Vous avez la possibilité de personnaliser le stockage et de réduire potentiellement la taille de la machine virtuelle. Cela pourrait entraîner une réduction des coûts.
• Vous pouvez mettre à jour votre build ou version SQL Server pendant ce processus. Vous pouvez également mettre à niveau le système d’exploitation.
• Le cluster Always On précédent peut agir comme un point de restauration fiable.

Inconvénients

• Vous devez modifier le nom DNS de l’écouteur si vous souhaitez que les deux clusters Always On s’exécutent simultanément. Cela ajoute une surcharge d’administration pendant la migration car les chaînes de l'application cliente doivent refléter le nouveau nom du Listener.
• Vous devez implémenter un mécanisme de synchronisation entre les deux environnements pour les garder aussi proches que possible pour réduire les exigences de synchronisation finales avant la migration.
• Un coût supplémentaire est ajouté pendant la migration lorsque vous avez le nouvel environnement en fonctionnement.

Migration de déploiements "Always On" pour un temps d'indisponibilité minimal

Il existe deux stratégies de migration des déploiements Always On pour un temps d’arrêt minimal :

1. Utiliser un site secondaire existant : site unique
2. Utiliser un ou plusieurs réplicas secondaires existants : multi-site

1. Utiliser un secondaire existant : Single-Site

Une stratégie pour un temps d’arrêt minimal consiste à prendre une base de données secondaire cloud existante et à la supprimer du service cloud actuel. Copiez ensuite les disques durs virtuels dans le nouveau compte de stockage Premium et créez la machine virtuelle dans le nouveau service cloud. Mettez ensuite à jour l'écouteur dans le clustering et le basculement.

Points de temps d’arrêt

• Il y a une interruption de service lorsque vous mettez à jour le nœud final avec le point de terminaison d'équilibrage de charge.
• La reconnexion de votre client peut être retardée en fonction de votre configuration client/DNS.
• Il y a un temps d’arrêt supplémentaire si vous choisissez de mettre hors connexion le groupe de cluster Always On pour échanger les adresses IP. Vous pouvez éviter cela en utilisant une dépendance OU et des propriétaires potentiels pour la ressource d'adresse IP ajoutée. Consultez la section « Ajout d’une ressource d’adresse IP sur le même sous-réseau » de l’annexe.

Avantages

• Aucun coût supplémentaire encouru lors de la migration.
• Migration un-à-un.
• Complexité réduite.
• Permet d’augmenter les E/S par seconde à partir des références SKU de stockage Premium. Lorsque les disques sont détachés de la machine virtuelle et copiés vers le nouveau service cloud, un outil tiers peut être utilisé pour augmenter la taille du disque dur virtuel, ce qui offre des débits plus élevés. Pour augmenter les tailles de disque dur virtuel, consultez cette discussion sur le forum.

Inconvénients

• Il y a une perte temporaire de haute disponibilité et de reprise après sinistre pendant la migration.
• Comme il s’agit d’une migration de 1:1, vous devez utiliser une taille minimale de machine virtuelle qui prend en charge votre nombre de disques durs virtuels, de sorte que vous ne pourrez peut-être pas réduire vos machines virtuelles.
• Ce scénario utilise l’applet de commande Azure Start-AzureStorageBlobCopy , qui est asynchrone. Il n’existe aucun accord de niveau de service pour l’achèvement de la copie. Le temps des copies varie, tandis que cela dépend de l’attente en file d’attente, il dépend également de la quantité de données à transférer. Le temps de copie augmente si le transfert va vers un autre centre de données Azure qui prend en charge le stockage Premium dans une autre région. Si vous n’avez que 2 nœuds, envisagez une mesure d'atténuation possible au cas où la copie prendrait plus de temps que lors des tests. Cela peut inclure les idées suivantes.
  • Ajoutez un troisième nœud SQL Server temporaire pour la haute disponibilité avant la migration avec le temps d'arrêt convenu.
  • Exécutez la migration en dehors de la maintenance planifiée Azure.
  • Vérifiez que vous avez correctement configuré votre quorum de cluster.

Étapes de haut niveau

Ce document ne montre pas un exemple complet de bout en bout, mais l’annexe fournit des détails qui peuvent être utilisés pour effectuer cette opération.

• Collectez la configuration du disque et supprimez le nœud (ne supprimez pas les disques durs virtuels attachés).
• Créer un compte de stockage Premium et copier des disques durs virtuels à partir du compte de stockage Standard
• Créez un service cloud et redéployez la machine virtuelle SQL2 dans ce service cloud. Créez la machine virtuelle en utilisant le disque dur virtuel copié du système d'exploitation d'origine et en attachant les disques durs virtuels copiés.
• Configurez ILB / ELB et ajoutez des points de terminaison.
• Mettez à jour l’écouteur en effectuant les opérations suivantes :
  • Mettre le groupe Always On hors connexion et mettre à jour l’écouteur Always On avec une nouvelle adresse IP ILB/ELB.
  • Vous pouvez également ajouter la ressource d’adresse IP du nouveau cloud Service ILB/ELB via PowerShell dans le clustering Windows. Définissez ensuite les propriétaires possibles de la ressource d’adresse IP sur le nœud migré, SQL2 et définissez-le comme dépendance OR dans le nom du réseau. Consultez la section « Ajout d’une ressource d’adresse IP sur le même sous-réseau » de l’annexe.
• Vérifiez la configuration/propagation DNS vers les clients.
• Migrez une machine virtuelle SQL1 et effectuez les étapes 2 à 4.
• Si vous utilisez les étapes 5ii, ajoutez SQL1 comme propriétaire possible pour la ressource d’adresse IP ajoutée.
• Testez les basculements.

2. Utiliser les répliques secondaires existantes : Sites multiples

Si vous avez des nœuds dans plusieurs centres de données Azure (DC) ou si vous avez un environnement hybride, vous pouvez utiliser une configuration Always On dans cet environnement pour réduire les temps d’arrêt.

L’approche consiste à modifier la synchronisation Always On en synchrone pour le contrôleur de domaine Azure local ou secondaire, puis à basculer vers ce serveur SQL Server. Copiez ensuite les disques durs virtuels dans un compte de stockage Premium et redéployez la machine dans un nouveau service cloud. Mettez à jour l'écouteur, puis effectuez une restauration.

Points de temps d’arrêt

Le temps d’arrêt se compose du temps de basculement vers l’autre centre de données et de retour. Cela dépend également de votre configuration client/DNS et de la reconnexion de votre client peut être retardée. Prenons l’exemple suivant d’une configuration Always On hybride :

Avantages

• Vous pouvez utiliser l’infrastructure existante.
• Vous avez la possibilité de mettre à niveau à l'avance le stockage Azure sur le centre de données Azure de récupération d'urgence.
• Le stockage DE contrôleur de domaine Azure de récupération d’urgence peut être reconfiguré.
• Il y a au moins deux basculements pendant la migration, à l’exception des basculements de test.
• Vous n’avez pas besoin de déplacer des données SQL Server avec sauvegarde et restauration.

Inconvénients

• En fonction de l’accès client à SQL Server, il peut y avoir une latence accrue lorsque SQL Server s’exécute dans un autre contrôleur de domaine de l’application.
• Le temps de copie des VHD vers le stockage Premium peut prendre du temps. Cela peut affecter votre décision de conserver le nœud dans le groupe de disponibilité. Considérez ceci lorsque le chargement intensif de journaux est nécessaire pendant la migration, car le nœud principal doit conserver les transactions non répliquées dans son journal des transactions. Par conséquent, cela pourrait augmenter considérablement.
• Ce scénario utilise l’applet de commande Azure Start-AzureStorageBlobCopy , qui est asynchrone. Il n’y a pas de SLA concernant l’achèvement. Le temps des copies varie, tandis que cela dépend d’une attente en file d’attente, il dépend également de la quantité de données à transférer. Par conséquent, vous n’avez qu’un seul nœud dans votre 2e centre de données, vous devez prendre des mesures d’atténuation si la copie prend plus de temps que dans les tests. Ces étapes d’atténuation incluent les idées suivantes :
  • Ajoutez un 2e nœud SQL temporaire pour la haute disponibilité (HA) avant le temps d’arrêt convenu de la migration.
  • Exécutez la migration en dehors de la maintenance planifiée Azure.
  • Vérifiez que vous avez correctement configuré votre quorum de cluster.

Ce scénario suppose que vous avez documenté votre installation et que vous savez comment le stockage est mappé afin d’apporter des modifications pour optimiser les paramètres de cache de disque.

Étapes générales

• Faites de l'instance locale ou alternative de DC Azure le principal de SQL Server, puis faites-en l'autre partenaire de basculement automatique (AFP).
• Rassemblez les informations de configuration de disque de SQL2 et supprimez le nœud (ne supprimez pas les disques durs virtuels attachés).
• Créez un compte de stockage Premium et copiez les VHDs (disques durs virtuels) à partir du compte de stockage Standard.
• Créez un service cloud et créez la machine virtuelle SQL2 avec ses disques de stockage Premium attachés.
• Configurez ILB / ELB et ajoutez des points de terminaison.
• Mettez à jour l’écouteur Always On avec une nouvelle adresse IP ILB/ELB et testez le basculement.
• Vérifiez la configuration DNS.
• Remplacez l’AFP par SQL2, puis migrez SQL1 et passez aux étapes 2 à 5.
• Testez les basculements.
• Remettre l'AFP sur SQL1 et SQL2

Annexe : Migration d’un cluster Always On multisite vers un stockage Premium

Le reste de cet article fournit un exemple détaillé de conversion d’un cluster Always On multise site en stockage Premium. Il convertit également le récepteur d'un équilibreur de charge externe (ELB) à un équilibreur de charge interne (ILB).

Environnement

• Windows 2k12 / SQL 2k12
• 1 fichier de base de données sur SP
• 2 x pools de stockage par nœud

VM:

Dans cet exemple, nous allons illustrer le passage d’un ELB à l’ILB. ELB était disponible avant l'équilibrage de charge interne (ILB), ce qui montre comment basculer vers ILB pendant la migration.

Étapes préalables : Se connecter à l’abonnement

Add-AzureAccount

#Set up subscription
Get-AzureSubscription

Étape 1 : Créer un compte de stockage et un service cloud

$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

Étape 2 : Augmenter les échecs autorisés sur les ressources <facultatives>

Sur certaines ressources appartenant à votre groupe de disponibilité Always On, il existe des limites sur le nombre d’échecs qui peuvent se produire pendant une période, où le service de cluster tente de redémarrer le groupe de ressources. Nous vous recommandons d’augmenter cela pendant que vous parcourez cette procédure, car si vous ne basculez pas manuellement et déclenchez des basculements en arrêtant des machines, vous pouvez vous rapprocher de cette limite.

Il serait prudent de doubler la tolérance d'échec. Pour ce faire, dans le Gestionnaire de cluster de basculement, accédez aux propriétés du groupe de ressources Always On.

Remplacez le nombre maximal d’échecs par 6.

Étape 3 : Ajout de la ressource adresse IP pour le groupe de clusters <facultatif>

Si vous n'avez qu'une seule adresse IP pour le groupe de clusters et qu'elle est alignée sur le sous-réseau cloud, prenez garde : si vous mettez accidentellement hors ligne tous les nœuds de cluster dans le cloud sur ce réseau, la ressource IP du cluster et le nom du réseau de cluster ne pourront pas être remis en ligne. Dans ce cas, elle empêche les mises à jour d’autres ressources de cluster.

Étape 4 : Configuration DNS

L’implémentation d’une transition fluide dépend de la façon dont DNS est utilisé et mis à jour. Quand Always On est installé, il crée un groupe de ressources de cluster Windows, si vous ouvrez le Gestionnaire du cluster de basculement, vous voyez qu’au minimum il a trois ressources, les deux auxquelles le document fait référence sont :

• Nom de réseau virtuel (VNN) : nom DNS auquel les clients se connectent lorsque vous souhaitez vous connecter à DES serveurs SQL via Always On.
• Ressource d’adresse IP : adresse IP associée au réseau virtuel, vous pouvez en avoir plusieurs et, dans une configuration multisite, vous disposez d’une adresse IP par site/sous-réseau.

Lors de la connexion à SQL Server, le pilote client SQL Server récupère les enregistrements DNS associés à l’écouteur et tente de se connecter à chaque adresse IP associée à Always On. Ensuite, nous abordons certains facteurs qui peuvent influencer cela.

Le nombre d’enregistrements DNS simultanés associés au nom du récepteur dépend non seulement du nombre d’adresses IP associées, mais du paramètre « RegisterAllIpProviders » dans le clustering de basculement pour la ressource VNN Always ON.

Lorsque vous déployez Always On dans Azure, il existe différentes étapes pour créer l’écouteur et les adresses IP, vous devez configurer manuellement « RegisterAllIpProviders » sur 1, ce qui est différent d’un déploiement Always On local où il est déjà défini sur 1.

Si « RegisterAllIpProviders » est 0, vous ne voyez qu’un seul enregistrement DNS dans DNS associé à l’écouteur :

Si « RegisterAllIpProviders » est 1 :

Le code ci-dessous extrait les paramètres VNN et les définit pour vous. Pour que la modification prenne effet, vous devez mettre le VNN hors connexion et le réactiver en ligne. Cela met l’écouteur hors connexion à l’origine d’une interruption de connectivité du client.

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

Dans une étape de migration ultérieure, vous devez mettre à jour l’écouteur Always On avec une adresse IP mise à jour qui fait référence à un équilibreur de charge, cela implique une suppression et un ajout de ressources d’adresse IP. Après la mise à jour IP, vous devez vous assurer que la nouvelle adresse IP a été mise à jour dans la zone DNS et que les clients mettent à jour leur cache DNS local.

Si vos clients résident dans un segment réseau différent et référencent un autre serveur DNS, vous devez prendre en compte ce qui se passe au sujet du transfert de zone DNS pendant la migration, car l’heure de reconnexion de l’application est limitée par au moins l’heure de transfert de zone de toutes les nouvelles adresses IP pour l’écouteur. Si vous êtes sous contrainte de temps ici, vous devez discuter et tester forcer un transfert de zone incrémentielle avec vos équipes Windows, et également placer l’enregistrement hôte DNS à une durée de vie plus faible (TTL), pour que les clients puissent mettre à jour. Pour plus d’informations, consultez Transferts de zone incrémentiels et Start-DnsServerZoneTransfer.

Par défaut, la durée de vie de l’enregistrement DNS associé à l’écouteur dans Always On dans Azure est de 1200 secondes. Vous pouvez le réduire si vous êtes sous contrainte de temps pendant votre migration pour vous assurer que les clients mettent à jour leur DNS avec l’adresse IP mise à jour pour l’écouteur. Vous pouvez voir et modifier la configuration en exportant la configuration du VNN.

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

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

Paramètres de l’application cliente

Si votre application cliente SQL prend en charge .NET 4.5 SQLClient, vous pouvez utiliser le mot clé « MULTISUBNETFAILOVER=TRUE ». Ce mot clé doit être appliqué, car il permet une connexion plus rapide au groupe de disponibilité SQL Always On pendant le basculement. Il énumère toutes les adresses IP associées à l’écouteur Always On en parallèle et effectue une vitesse de nouvelle tentative de connexion TCP plus agressive pendant un basculement.

Pour plus d’informations sur les paramètres précédents, consultez Le mot clé MultiSubnetFailover et les fonctionnalités associées. Consultez également la prise en charge de SqlClient pour la haute disponibilité et la reprise après sinistre.

Étape 5 : Paramètres de quorum du cluster

Comme vous allez retirer au moins un serveur SQL Server à la fois, vous devez modifier le paramètre de quorum du cluster, si vous utilisez le témoin de partage de fichiers (FSW) avec deux nœuds, vous devez définir le quorum pour autoriser la majorité des nœuds et utiliser le vote dynamique, ce qui permet à un seul nœud de rester debout.

Set-ClusterQuorum -NodeMajority  

Pour plus d’informations sur la gestion et la configuration du quorum de cluster, consultez Configurer et gérer le quorum dans un cluster de basculement Windows Server 2012.

Étape 6 : Extraire les points de terminaison et les listes de contrôle d'accès existants

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

Enregistrez ce texte dans un fichier.

Étape 7 : Modifier les partenaires de basculement et les modes de réplication

Si vous avez plus de deux serveurs SQL, vous devez changer le basculement d’un autre serveur secondaire dans un autre contrôleur de domaine ou local en « synchrone » et le rendre un partenaire de basculement automatique (AFP), c’est pourquoi vous conservez la haute disponibilité pendant que vous apportez des modifications. Pour ce faire, vous pouvez utiliser TSQL ou modifier via SSMS.

Étape 8 : Supprimer la machine virtuelle secondaire du service cloud

Vous devez d’abord planifier la migration d’un nœud secondaire cloud. Si ce nœud est actuellement principal, il est conseillé de procéder à un basculement manuel.

$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

Étape 9 : Modifier les paramètres de mise en cache du disque dans le fichier CSV et enregistrer

Pour les volumes de données, ceux-ci doivent être définis sur READONLY.

Pour les volumes TLOG, ceux-ci doivent être définis sur NONE.

Étape 10 : Copier 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
}

Vous pouvez vérifier l’état de copie des disques durs virtuels vers le compte de stockage Premium :

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
}

Attendez que l'enregistrement de tous ces éléments soit effectué avec succès.

Pour des informations sur les blobs individuels :

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

Étape 11 : Inscrire le disque du système d’exploitation

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

Étape 12 : Importer secondaire dans un nouveau service cloud

Le code ci-dessous utilise également l'option ajoutée vous permettant d'importer la machine et d'utiliser l'adresse IP virtuelle (VIP) réservable.

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

#Create new Availability Set
$availabilitySet = "cloudmigAVAMS"

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

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

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

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

}

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

Étape 13 : Créer un équilibreur de charge interne sur un nouveau service cloud, ajouter des points de terminaison à charge équilibrée et des listes de contrôle d’accès

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

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

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

#SET Azure ACLs or Network Security Groups & Windows FWs

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

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

Étape 14 : Mettre à jour 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 dependency and NETBIOS, then remove old IP address

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

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

#Make sure no static records in DNS

Supprimez maintenant l’ancienne adresse IP du service cloud.

Étape 15 : Vérification de la mise à jour DNS

Vous devez maintenant vérifier les serveurs DNS sur vos réseaux clients SQL Server et vous assurer que le clustering a ajouté l’enregistrement hôte supplémentaire pour l’adresse IP ajoutée. Si ces serveurs DNS n’ont pas été mis à jour, envisagez de forcer un transfert de zone DNS et de vous assurer que les clients dans ce sous-réseau sont en mesure de résoudre les deux adresses IP Always On, c’est pourquoi vous n’avez pas besoin d’attendre la réplication DNS automatique.

Étape 16 : Reconfigurer Always On

À ce stade, vous attendez que le nœud secondaire migré se resynchronise entièrement avec le nœud sur site, bascule vers le nœud de réplication synchrone, et le désigner comme AFP.

Étape 17 : Migrer le deuxième nœud

$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

Étape 18 : Modifier les paramètres de mise en cache de disque dans le fichier CSV et enregistrer

Pour les volumes de données, les paramètres de cache doivent être définis sur READONLY.

Pour les volumes TLOG, les paramètres de cache doivent être définis sur NONE.

Étape 19 : Créer un compte de stockage indépendant pour le nœud secondaire

$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

Étape 20 : Copier VHDS

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

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

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

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

#Check for copy progress

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

Vous pouvez vérifier l’état de copie du disque dur virtuel pour tous les disques durs virtuels :

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
}

Attendez que tous ces éléments soient enregistrés comme étant réussis.

Pour plus d’informations sur les objets blob individuels :

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

Étape 21 : Inscrire le disque du système d’exploitation

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

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

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

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

#Join to existing Availability Set

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

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

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

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

}

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

Étape 22 : Ajouter des points de terminaison équilibrés en charge et des listes de contrôle d’accès.

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


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

#SET ACLs or Azure Network Security Groups & Windows FWs

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

Étape 23 : Tester le basculement

Attendez que le nœud migré se synchronise avec le nœud Always On local. Placez-le en mode de réplication synchrone et attendez qu’il soit synchronisé. Ensuite, basculez d’un emplacement local vers le premier nœud migré, qui est l’AFP. Une fois que cela a fonctionné, modifiez le dernier nœud migré vers l’AFP.

Vous devez tester les basculements entre tous les nœuds et effectuer des tests de chaos pour garantir que les basculements fonctionnent comme prévu et dans un délai raisonnable.

Étape 24 : Remettre les paramètres de quorum du cluster / TTL DNS / Pointeurs de basculement / Paramètres de synchronisation

Ajout d’une ressource d’adresse IP sur le même sous-réseau

Si vous avez seulement deux serveurs SQL et que vous souhaitez les migrer vers un nouveau service cloud, mais que vous souhaitez les conserver sur le même sous-réseau, vous pouvez éviter de mettre l’écouteur hors connexion pour supprimer l’adresse IP Always On d’origine et ajouter la nouvelle adresse IP. Si vous migrez les machines virtuelles vers un autre sous-réseau, vous n’avez pas besoin de le faire, car il existe un réseau de cluster supplémentaire qui fait référence à ce sous-réseau.

Une fois que vous avez mis en place le serveur secondaire migré et ajouté la nouvelle ressource d'adresse IP pour le nouveau service cloud, avant de basculer le serveur principal existant, vous devez effectuer ces étapes dans le Gestionnaire de basculement du cluster :

Pour ajouter une adresse IP, consultez l’annexe, étape 14.

1. Pour la ressource d’adresse IP actuelle, remplacez le propriétaire possible par « SQL Server principal existant », dans l’exemple « dansqlams4 » :

   

2. Pour la nouvelle ressource d’adresse IP, remplacez le propriétaire possible par « Sql Server secondaire migré », dans l’exemple « dansqlams5 » :

   

3. Une fois ce paramètre défini, vous pouvez basculer et lorsque le dernier nœud est migré, les propriétaires possibles doivent être modifiés afin que le nœud soit ajouté en tant que propriétaire possible :

   

Ressources supplémentaires

• Azure Stockage Premium
• machines virtuelles
• SQL Server dans des machines virtuelles Azure