Compartir a través de

Uso de Azure Premium Storage con SQL Server en máquinas virtuales

  • Artículo

Información general

SSD Premium de Azure es la próxima generación de almacenamiento que proporciona baja latencia y alta eficiencia en E/S. Funciona mejor para cargas de trabajo de uso intensivo de E/S clave, como SQL Server en IaaS Virtual Machines.

Importante

Azure tiene dos modelos de implementación diferentes para crear recursos y trabajar con ellos: Resource Manager y el clásico. En este artículo se aborda el uso del modelo de implementación clásico. Microsoft recomienda que las implementaciones más recientes usen el modelo de Resource Manager.

En este artículo se proporciona planeación e instrucciones para migrar una máquina virtual que ejecuta SQL Server para usar Premium Storage. Esto incluye los pasos de infraestructura de Azure (redes, almacenamiento) y máquina virtual Windows invitada. En el ejemplo del apéndice se muestra una migración completa de un extremo a otro de cómo mover máquinas virtuales más grandes para aprovechar el almacenamiento SSD local mejorado con PowerShell.

Es importante comprender el proceso integral de uso de Azure Premium Storage con SQL Server en máquinas virtuales IAAS. Esto incluye:

  • Identificación de los requisitos previos para usar Premium Storage.
  • Ejemplos de implementación de SQL Server en IaaS en Premium Storage para nuevas implementaciones.
  • Ejemplos de migración de implementaciones existentes, tanto servidores independientes como implementaciones mediante grupos de disponibilidad AlwaysOn de SQL.
  • Posibles enfoques de migración.
  • Ejemplo completo de un extremo a otro que muestra los pasos de Azure, Windows y SQL Server para la migración de una implementación de AlwaysOn existente.

Para más información sobre SQL Server en Azure Virtual Machines, consulte SQL Server en Azure Virtual Machines.

Autor: Daniel Sol Revisores Técnicos: Luis Carlos Vargas Herring, Sanjay Mishra, Pravin Mital, Juergen Thomas, Gonzalo Ruiz.

Requisitos previos para Premium Storage

Hay varios requisitos previos para usar Premium Storage.

Tamaño de la máquina

Para usar Premium Storage, debe usar máquinas virtuales (VM) de la serie DS. Si no ha usado máquinas de la serie DS en el servicio en la nube antes, debe eliminar la máquina virtual existente, mantener los discos conectados y, a continuación, crear un nuevo servicio en la nube antes de volver a crear la máquina virtual como tamaño de rol DS*. Para más información sobre los tamaños de Máquina Virtual, consulte Tamaños de Máquina Virtual y Servicios de Nube para Azure.

Servicios en la nube

Solo puede usar máquinas virtuales DS* con Premium Storage cuando se crean en un nuevo servicio en la nube. Si usa SQL Server AlwaysOn en Azure, el agente de escucha AlwaysOn hace referencia a la dirección IP de Azure Internal o External Load Balancer asociada a un servicio en la nube. En este artículo se centra en cómo migrar mientras se mantiene la disponibilidad en este escenario.

Nota:

Una serie DS* debe ser la primera máquina virtual que se implementa en el nuevo servicio en la nube.

Redes virtuales (VNETs) regionales

En el caso de las máquinas virtuales DS*, debe configurar la red virtual (VNET) que hospeda las máquinas virtuales para que sean regionales. Esta "ampliación" de la red virtual es permitir que las máquinas virtuales más grandes se aprovisionen en otros clústeres y permitan la comunicación entre ellas. En la captura de pantalla siguiente, la ubicación resaltada muestra redes virtuales regionales, mientras que el primer resultado muestra una red virtual "estrecha".

RegionalVNET

Puede generar un ticket de soporte de Microsoft para migrar a una red virtual regional. Después, Microsoft realiza un cambio. Para completar la migración a redes virtuales regionales, cambie la propiedad AffinityGroup en la configuración de red. En primer lugar, exporte la configuración de red en PowerShell y, a continuación, reemplace la propiedad AffinityGroup en el elemento VirtualNetworkSite por una propiedad Location de. Especifique Location = XXXX donde XXXX es una región de Azure. A continuación, importe la nueva configuración.

Por ejemplo, teniendo en cuenta la siguiente configuración de red virtual:

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

Para moverlo a una red virtual regional en Oeste de Europa, cambie la configuración a lo siguiente:

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

Cuentas de almacenamiento

Debe crear una cuenta de almacenamiento que esté configurada para Premium Storage. Tenga en cuenta que el uso de Premium Storage se establece en la cuenta de almacenamiento, no en discos duros virtuales individuales; sin embargo, cuando se usa una máquina virtual de la serie DS*, puede asociar VHD desde cuentas de Premium y Standard Storage. Puede considerar esto si no desea colocar el disco duro virtual del sistema operativo en la cuenta de Premium Storage.

El siguiente comando New-AzureStorageAccountPowerShell con el tipo "Premium_LRS" crea una cuenta de almacenamiento Premium:

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

Configuración de caché de discos duros virtuales

La principal diferencia entre la creación de discos que forman parte de una cuenta de Premium Storage es la configuración de caché de disco. Para los discos de volumen de datos de SQL Server, se recomienda usar "caché de lectura". En el caso de los volúmenes de registros de transacciones, la configuración de caché del disco debe fijarse en "Ninguno". Esto es diferente de las recomendaciones para las cuentas de Standard Storage.

Una vez conectados los discos duros virtuales (VHDs), no se puede modificar la configuración de caché. Tendría que desmontar y volver a montar el disco duro virtual con una configuración de caché actualizada.

Espacios de almacenamiento de Windows

Puede usar Espacios de almacenamiento de Windows como hizo con el almacenamiento estándar anterior, lo que le permite migrar una máquina virtual que ya usa espacios de almacenamiento. En el ejemplo de Apéndice (paso 9 y adelante) se muestra el código de PowerShell para extraer e importar una máquina virtual con varios VHD conectados.

Los grupos de almacenamiento se usaron con la cuenta de almacenamiento de Azure estándar para mejorar el rendimiento y reducir la latencia. Es posible que encuentre un valor en probar los grupos de almacenamiento con Premium Storage para las nuevas implementaciones, pero agregan complejidad adicional con la configuración de almacenamiento.

Cómo encontrar qué discos virtuales de Azure se corresponden con los grupos de almacenamiento

Dado que hay diferentes recomendaciones de configuración de caché para discos duros virtuales adjuntos, es posible que decida copiar los discos duros virtuales en una cuenta de Premium Storage. Sin embargo, al volver a adjuntarlos a la nueva máquina virtual de la serie DS, es posible que tenga que modificar la configuración de caché. Es más sencillo aplicar la configuración de caché recomendada de Premium Storage cuando tiene discos duros virtuales independientes para los archivos de datos SQL y los archivos de registro (en lugar de un solo disco duro virtual que contenga ambos).

Nota:

Si tiene archivos de registro y datos de SQL Server en el mismo volumen, la opción de almacenamiento en caché que elija depende de los patrones de acceso de E/S para las cargas de trabajo de base de datos. Solo las pruebas pueden demostrar qué opción de almacenamiento en caché es la mejor para este escenario.

Sin embargo, si usa Espacios de almacenamiento de Windows que están formados por varios VHD, debe examinar los scripts originales para identificar a qué grupo específico pertenece cada VHD conectado, de modo que pueda establecer la configuración de caché en consecuencia para cada disco.

Si no tiene el script original disponible para mostrar qué VHD se asigna al grupo de almacenamiento, puede usar los siguientes pasos para determinar la asignación de disco/grupo de almacenamiento.

Para cada disco, siga estos pasos:

  1. Obtenga la lista de discos conectados a la máquina virtual utilizando el comando Get-AzureVM:
Get-AzureVM -ServiceName <servicename> -Name <vmname> | Get-AzureDataDisk

  1. Anote DiskName y LUN.

    NombreDelDiscoYLUN

  2. Escritorio remoto en la máquina virtual. A continuación, vaya a Administración de equipos | Administrador de dispositivos | unidades de disco. Examine las propiedades de cada uno de los discos virtuales de Microsoft.

    VirtualDiskProperties

  3. El número de LUN aquí se refiere al número de LUN que especificas al conectar el disco duro virtual a la máquina virtual.

  4. En el caso del 'disco virtual de Microsoft', vaya a la pestaña Detalles y, a continuación, en la lista de Propiedades, vaya a Clave de Controlador. En el Valor , tenga en cuenta el Offset , que es 0002 en la captura de pantalla siguiente. El 0002 denota el elemento PhysicalDisk2 al que hace referencia el grupo de almacenamiento.

    DetallesDePropiedadDeDiscoVirtual

  5. Para cada grupo de almacenamiento, muestra los discos asociados.

Get-StoragePool -FriendlyName AMS1pooldata | Get-PhysicalDisk

GetStoragePool

Ahora puede usar esta información para asociar los VHD adjuntos a discos físicos en grupos de almacenamiento.

Una vez que haya asignado discos duros virtuales a discos físicos en grupos de almacenamiento, puede desasociarlos y copiarlos en una cuenta de Premium Storage y, a continuación, asociarlos con la configuración de caché correcta. Vea el ejemplo del apéndice , pasos del 8 al 12. Estos pasos muestran cómo extraer la configuración del disco VHD conectado a una máquina virtual en un archivo CSV, copiar los discos duros virtuales, modificar la configuración de caché del disco y, por último, volver a implementar la máquina virtual como una máquina virtual de la serie DS con todos los discos conectados.

Ancho de banda de almacenamiento de máquina virtual y rendimiento de almacenamiento de VHD

El rendimiento del almacenamiento depende del tamaño de máquina virtual DS* especificado y de los tamaños de VHD. Las máquinas virtuales tienen diferentes asignaciones para la cantidad de VHD que pueden conectarse y el ancho de banda máximo que admiten (MB/s). Para conocer los números específicos de ancho de banda, consulte Tamaños de Máquina Virtual y Servicio en la Nube para Azure.

El aumento de IOPS se logra con tamaños de disco mayores. Debe tener en cuenta esto cuando piense en la ruta de migración. Para obtener más información, consulte la tabla de IOPS y Tipos de disco.

Por último, tenga en cuenta que las máquinas virtuales tienen anchos de banda de disco máximo diferentes que admiten para todos los discos conectados. Bajo una carga alta, podría saturar el ancho de banda de disco máximo disponible para ese tamaño de rol de máquina virtual. Por ejemplo, un Standard_DS14 admite hasta 512 MB/s; por lo tanto, con tres discos P30 podría saturar el ancho de banda de disco de la máquina virtual. Pero en este ejemplo, se podría superar el límite de capacidad de procesamiento en función de la combinación de E/S de lectura y escritura.

Nuevas implementaciones

En las dos secciones siguientes se muestra cómo puede implementar máquinas virtuales de SQL Server en Premium Storage. Como se mencionó antes, no es necesario colocar el disco del sistema operativo en Premium Storage. Puede optar por hacerlo si piensa colocar cargas de trabajo de E/S intensivas en el disco duro virtual del sistema operativo.

En el primer ejemplo se muestra el uso de imágenes existentes de la Galería de Azure. En el segundo ejemplo se muestra cómo usar una imagen de máquina virtual personalizada que tiene en una cuenta de almacenamiento estándar existente.

Nota:

En estos ejemplos se supone que ya ha creado una red virtual regional.

En el ejemplo siguiente se muestra cómo colocar el VHD del sistema operativo en almacenamiento premium y conectar VHDs de almacenamiento premium. Sin embargo, también puede colocar el disco del sistema operativo en una cuenta de Almacenamiento estándar y, a continuación, adjuntar discos duros virtuales que residen en una cuenta de Premium Storage. Se muestran ambos escenarios.

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

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

Paso 1: Crear una cuenta de Premium Storage

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

Paso 2: Crear un nuevo servicio en la nube

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

Paso 3: Reservar una VIP de servicio en la nube (opcional)

#check exisitng reserved VIP
Get-AzureReservedIP

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

Paso 4: Creación de un contenedor de máquinas virtuales

#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

Paso 5: Colocación del VHD del sistema operativo en Standard o Premium Storage

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

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

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

Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount  $standardstorageaccountname

Paso 6: Creación de una máquina virtual

#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

Creación de una nueva máquina virtual para usar Premium Storage con una imagen personalizada

En este escenario se muestra dónde se encuentran las imágenes personalizadas existentes que residen en una cuenta de Standard Storage. Como se mencionó, si desea colocar el disco duro virtual del sistema operativo en Premium Storage, debe copiar la imagen que existe en la cuenta de la Standard Storage y transferirla a la Premium Storage antes de poder usarla. Si tiene una imagen local, también puede usar este método para copiarlo directamente en la cuenta de Premium Storage.

Paso 1: Crear cuenta de almacenamiento

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

Paso 2: Creación de un servicio en la nube

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

Paso 3: Usar la imagen existente

Puede usar una imagen existente. O bien, puede tomar una imagen de una máquina existente. Tenga en cuenta que la máquina que imagen no tiene que ser máquina DS*. Una vez que tenga la imagen, los pasos siguientes muestran cómo copiarla en la cuenta de Premium Storage con el Start-AzureStorageBlobCopy commandlet de 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

Paso 4: Copiar Blob entre cuentas de almacenamiento

#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

Paso 5: Comprobar periódicamente el estado de copia:

$blob | Get-AzureStorageBlobCopyState

Paso 6: Adición de un disco de imagen al repositorio de discos de Azure en la suscripción

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

Add-AzureVMImage -ImageName $newimageName -MediaLocation $imageMediaLocation

Nota:

Es posible que descubra que, aunque el estado indique éxito, aún podría recibir un error de leasing de disco. En este caso, espere unos 10 minutos.

Paso 7: Compilación de la máquina virtual

Aquí está creando la máquina virtual a partir de su imagen y adjuntando dos discos duros virtuales de Premium Storage.

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

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

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

#create new Availability Set
$availabilitySet = "cloudmigAVAMS3"

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


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

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



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

Implementaciones existentes que no usan grupos de disponibilidad AlwaysOn

Nota:

Para las implementaciones existentes, consulte primero la sección Requisitos previos de este artículo.

Hay diferentes consideraciones para las implementaciones de SQL Server que no usan grupos de disponibilidad AlwaysOn y los que sí lo hacen. Si no usa AlwaysOn y tiene un servidor SQL Server independiente existente, puede actualizar a Premium Storage mediante un nuevo servicio en la nube y una cuenta de almacenamiento. Considere las opciones siguientes:

  • Crear una nueva máquina virtual con SQL Server. Puede crear una nueva máquina virtual con SQL Server que use una cuenta de Premium Storage, como se documenta en Nuevas implementaciones. A continuación, realice una copia de seguridad y restaure la configuración de SQL Server y las bases de datos de usuario. La aplicación debe actualizarse para hacer referencia a la nueva instancia de SQL Server si se accede a ella interna o externamente. Tendría que copiar todos los objetos "fuera de base de datos" como si estuviera realizando una migración de SQL Server en paralelo (SxS). Esto incluye objetos como inicios de sesión, certificados y servidores vinculados.
  • Migrar una máquina virtual de SQL Server existente. Esto requiere poner fuera de línea la máquina virtual de SQL Server y, a continuación, transferirla a un nuevo servicio en la nube, lo que incluye copiar todos sus discos duros virtuales adjuntos a la cuenta de Premium Storage. Cuando la máquina virtual está en línea, la aplicación hace referencia al nombre de host del servidor como antes. Tenga en cuenta que el tamaño del disco existente afecta a las características de rendimiento. Por ejemplo, un disco de 400 GB se redondea hasta un P20. Si sabe que no necesita ese rendimiento de disco, podría volver a crear la máquina virtual como una máquina virtual de la serie DS y conectar discos duros virtuales de Premium Storage de la especificación de tamaño y rendimiento que necesita. A continuación, puede desasociar y volver a adjuntar los archivos de base de datos SQL.

Nota:

Al copiar los discos VHD, debe tener en cuenta el tamaño, ya que este determina en qué tipo de Disco de Almacenamiento Premium se clasificarán, lo cual a su vez define la especificación de rendimiento del disco. Azure redondea hasta el tamaño de disco más cercano, por lo que si tiene un disco de 400 GB, se redondea hasta un P20. En función de los requisitos de E/S existentes del disco duro virtual del sistema operativo, es posible que no tenga que migrarlo a una cuenta de Premium Storage.

Si se accede a SQL Server desde el exterior, la dirección VIP del servicio en la nube cambia. También tiene que actualizar los puntos de conexión, las ACL y la configuración de DNS.

Implementaciones existentes que usan grupos de disponibilidad AlwaysOn

Nota:

Para las implementaciones existentes, consulte primero la sección Requisitos Previos de este artículo.

Inicialmente en esta sección veremos cómo Interactúa AlwaysOn con las redes de Azure. A continuación, desglosamos las migraciones en dos escenarios: migraciones en las que se pueden tolerar algunos tiempos de inactividad y migraciones en las que debe lograr un tiempo de inactividad mínimo.

Los grupos de disponibilidad AlwaysOn de SQL Server local usan un agente de escucha local que registra un nombre DNS virtual junto con una dirección IP compartida entre uno o varios servidores SQL Server. Cuando los clientes se conectan, se enrutan a través de la dirección IP del agente de escucha al servidor SQL Server principal. Este es el servidor que posee el recurso de IP Always On en ese momento.

UsarImplementacionesSiempre Activado

En Microsoft Azure, solo puede tener una dirección IP asignada a una NIC en la máquina virtual, por lo que para lograr la misma capa de abstracción que el entorno local, Azure utiliza la dirección IP asignada a los equilibradores de carga internos o externos (ILB/ELB). El recurso IP que se comparte entre los servidores se establece en la misma dirección IP que el ILB/ELB. Esto se publica en el DNS y el tráfico de cliente se pasa a través del ILB/ELB a la réplica principal de SQL Server. El ILB/ELB sabe cuál es el SQL Server principal, ya que utiliza sondeos para examinar el recurso AlwaysOn IP. En el ejemplo anterior, sondea cada nodo que tiene un punto de conexión al que hace referencia el ELB/ILB; cualquiera que responda es el servidor SQL principal.

Nota:

Tanto el ILB como el ELB se asignan a un servicio en la nube de Azure determinado, por lo que cualquier migración a la nube en Azure probablemente significa que la dirección IP del equilibrador de carga cambia.

Migración de implementaciones de AlwaysOn que pueden permitir un tiempo de inactividad

Hay dos estrategias para migrar implementaciones de AlwaysOn que permiten un tiempo de inactividad:

  1. Agregar más réplicas secundarias a un clúster AlwaysOn existente
  2. Migrar a un nuevo clúster Always On

1. Agregar más réplicas secundarias a un clúster AlwaysOn existente

Una estrategia consiste en agregar más secundarias al grupo de disponibilidad AlwaysOn. Debe añadirlos a un nuevo servicio en la nube y actualizar el listener con la nueva IP del equilibrador de carga.

Puntos de inactividad:
  • Validación del clúster.
  • Prueba de conmutación por error Always On para los nuevos secundarios.

Si usa grupos de almacenamiento de Windows dentro de la máquina virtual para un mayor rendimiento de E/S, estos se desconectan durante una validación completa del clúster. La prueba de validación es necesaria cuando se agregan nodos al clúster. El tiempo necesario para ejecutar la prueba puede variar, por lo que debe probarlo en el entorno de prueba representativo para obtener un tiempo aproximado del tiempo que tarda.

Debe dedicar tiempo para poder realizar la conmutación por error manual y las pruebas de caos en los nodos recién agregados, asegurándose de que las funciones de alta disponibilidad Always On funcionan como se espera.

DeploymentUseAlways On2

Nota:

Debe detener todas las instancias de SQL Server en las que se usan los grupos de almacenamiento antes de que se ejecute la validación.

Pasos generales

  1. Cree dos servidores SQL Server en un nuevo servicio en la nube con Premium Storage conectado.

  2. Copie las copias de seguridad completas y restaure con NORECOVERY.

  3. Copie los objetos dependientes "fuera de la base de datos del usuario", como los inicios de sesión, etc.

  4. Cree un nuevo equilibrador de carga interno (ILB) o use un equilibrador de carga externo (ELB) y, a continuación, configure puntos de conexión con equilibrio de carga en ambos nodos nuevos.

    Nota:

    Compruebe que todos los nodos tienen la configuración de punto de conexión correcta antes de continuar.

  5. Detenga el acceso de usuario o aplicación a SQL Server (si usa grupos de almacenamiento).

  6. Detenga los servicios del motor de SQL Server en todos los nodos (si usa grupos de almacenamiento).

  7. Agregue nuevos nodos al clúster y ejecute la validación completa.

  8. Una vez que la validación se realiza correctamente, inicie todos los servicios de SQL Server.

  9. Copia de seguridad de registros de transacciones y restauración de bases de datos de usuario.

  10. Agregue nuevos nodos al Grupo de Disponibilidad Always On y coloque la replicación en sincrónica .

  11. Agregue el recurso de dirección IP del nuevo ILB/ELB del servicio en la nube a través de PowerShell para Always On en función del ejemplo de Multisitio en el Apéndice . En la agrupación en clústeres de Windows, establezca el Posibles propietarios del recurso dirección IP en los nuevos nodos antiguos. Consulte la sección "Agregar recurso de dirección IP en la misma subred" del apéndice .

  12. Conmutación por error a uno de los nuevos nodos.

  13. Haga que los nuevos nodos sean socios de conmutación por error automática y pruebe las conmutaciones por error.

  14. Quite los nodos originales del grupo de disponibilidad.

Ventajas
  • Los nuevos servidores SQL Server se pueden probar (SQL Server y Aplicación) antes de que se agreguen a AlwaysOn.
  • Puede cambiar el tamaño de la máquina virtual y personalizar el almacenamiento a sus requisitos exactos. Sin embargo, sería beneficioso mantener todas las rutas de acceso del archivo SQL iguales.
  • Puede controlar cuándo se inicia la transferencia de las copias de seguridad de la base de datos a las réplicas secundarias. Esto difiere del uso de Azure Start-AzureStorageBlobCopy commandlet para copiar discos duros virtuales, ya que es una copia asincrónica.
Desventajas
  • Al usar grupos de almacenamiento de Windows, hay tiempo de inactividad del clúster durante la validación completa del clúster para los nuevos nodos adicionales.
  • Según la versión de SQL Server y el número existente de réplicas secundarias, es posible que no pueda agregar más réplicas secundarias sin quitar los secundarios existentes.
  • Puede haber un tiempo de transferencia de datos SQL largo al configurar las secundarias.
  • Hay un costo adicional durante la migración mientras tiene máquinas nuevas que se ejecutan en paralelo.

2. Migración a un nuevo clúster AlwaysOn

Otra estrategia consiste en crear un nuevo clúster AlwaysOn con nuevos nodos en el nuevo servicio en la nube y, a continuación, redirigir a los clientes para que lo usen.

Puntos de inactividad

Hay tiempo de inactividad al transferir aplicaciones y usuarios al nuevo agente de escucha AlwaysOn. El tiempo de inactividad depende de:

  • El tiempo necesario para restaurar las copias de seguridad finales del registro de transacciones en bases de datos en servidores nuevos.
  • El tiempo necesario para actualizar las aplicaciones cliente para usar el nuevo Always On listener.
Ventajas
  • Puede probar el entorno de producción real, SQL Server y los cambios de compilación del sistema operativo.
  • Tiene la opción de personalizar el almacenamiento y reducir potencialmente el tamaño de la máquina virtual. Esto podría dar lugar a una reducción de costos.
  • Puede actualizar la versión o compilación de SQL Server durante este proceso. También puede actualizar el sistema operativo.
  • El clúster Always On anterior puede actuar como destino de reversión sólido.
Desventajas
  • Debe cambiar el nombre DNS del agente de escucha si desea que ambos clústeres AlwaysOn se ejecuten simultáneamente. Esto añade una sobrecarga administrativa durante la migración, ya que las cadenas de la aplicación cliente deben reflejar el nuevo nombre del Listener.
  • Debe implementar un mecanismo de sincronización entre los dos entornos para mantenerlos lo más cerca posible para minimizar los requisitos de sincronización finales antes de la migración.
  • Hay un costo adicional durante la migración mientras se ejecuta el nuevo entorno.

Migración de implementaciones de AlwaysOn para un tiempo de inactividad mínimo

Hay dos estrategias para migrar implementaciones de AlwaysOn para un tiempo de inactividad mínimo:

  1. Utilizar una base de datos secundaria existente: de sitio único
  2. usar réplicas secundarias existentes: de varios sitios

1. Utilizar un secundario existente: Single-Site

Una estrategia para un tiempo de inactividad mínimo es tomar una base de datos secundaria en la nube existente y quitarla del servicio en la nube actual. A continuación, copie los discos duros virtuales a la nueva cuenta de almacenamiento premium y cree la máquina virtual en el nuevo servicio en la nube. A continuación, actualice el agente de escucha en el clúster y la configuración de conmutación por error.

Puntos de inactividad
  • Hay tiempo de inactividad al actualizar el nodo final con el punto de conexión de Load Balanced.
  • Es posible que la reconexión del cliente se retrase en función de la configuración del cliente o DNS.
  • Hay tiempo de inactividad adicional si decide desconectar el grupo de clústeres AlwaysOn para intercambiar las direcciones IP. Puede evitar esto usando una dependencia "OR" y Propietarios Posibles para el recurso de dirección IP agregado. Consulte la sección "Agregar recurso de dirección IP en la misma subred" del apéndice .

Nota:

Cuando desee que el nodo agregado participe como asociado de conmutación por error AlwaysOn, debe agregar un punto de conexión de Azure con una referencia al conjunto de carga equilibrada. Al ejecutar el comando Add-AzureEndpoint para ello, las conexiones actuales permanecen abiertas, pero las nuevas conexiones al agente de escucha no se pueden establecer hasta que el equilibrador de carga se haya actualizado. Durante las pruebas, se vio que esto duraba entre 90 y 120 segundos, esto debería probarse.

Ventajas
  • No se incurre en ningún costo adicional durante la migración.
  • Una migración uno a uno.
  • Complejidad reducida.
  • Permite aumentar las IOPS de las SKU de Premium Storage. Cuando los discos se desasocian de la máquina virtual y se copian en el nuevo servicio en la nube, se puede usar una herramienta de terceros para aumentar el tamaño del disco duro virtual, lo que proporciona un mayor rendimiento. Para aumentar los tamaños de VHD, consulte esta discusión del foro .
Desventajas
  • Hay una pérdida temporal de HA y DR durante la migración.
  • Como se trata de una migración 1:1, debe usar un tamaño mínimo de máquina virtual que soporte su número de VHDs, por lo que puede que no pueda reducir el tamaño de sus máquinas virtuales.
  • En este escenario se usaría el cmdlet Start-AzureStorageBlobCopy, que es asincrónico. No hay ningún Acuerdo de Nivel de Servicio al finalizar la copia. El tiempo de las copias varía, mientras que esto depende de la espera en cola, también depende de la cantidad de datos que se van a transferir. El tiempo de copia aumenta si la transferencia va a otro centro de datos de Azure que admita Premium Storage en otra región. Si solo tiene 2 nodos, considere la posibilidad de una posible mitigación en caso de que la copia tarde más tiempo que en las pruebas. Esto podría incluir las siguientes ideas.
    • Agregue un nodo temporal de SQL Server para alta disponibilidad antes de la migración con tiempo de inactividad acordado.
    • Ejecute la migración fuera del mantenimiento programado de Azure.
    • Asegúrese de que ha configurado el cuórum del clúster correctamente.
Pasos generales

Este documento no muestra un ejemplo completo de un extremo a otro, pero el apéndice proporciona detalles que se pueden aprovechar para realizar esto.

TiempoDeInactividadMínimo

  • Recopile la configuración del disco y quite el nodo (no elimine los discos duros virtuales conectados).
  • Crea una cuenta de Almacenamiento Premium y copia discos duros virtuales desde la cuenta de Almacenamiento Estándar
  • Cree un nuevo servicio en la nube y vuelva a implementar la máquina virtual de SQL2 en ese servicio en la nube. Cree la máquina virtual utilizando el VHD copiado del sistema operativo original y adjuntando los VHD copiados.
  • Configure ILB/ELB y agregue puntos de conexión.
  • Actualice el Listener mediante:
    • Desconectar el grupo AlwaysOn y actualizar el agente de escucha AlwaysOn con la nueva dirección IP de ILB/ELB.
    • O bien, agregue el recurso de dirección IP del nuevo servicio en la nube ILB/ELB mediante PowerShell en clústeres de Windows. A continuación, establezca los posibles propietarios del recurso de dirección IP en el nodo migrado, SQL2 y establézcalo como dependencia OR en el nombre de red. Consulte la sección "Agregar recurso de dirección IP en la misma subred" del apéndice .
  • Compruebe la configuración o propagación de DNS a los clientes.
  • Migre la máquina virtual de SQL1 y siga los pasos 2 a 4.
  • Si usa los pasos 5ii, agregue SQL1 como posible propietario para el recurso de dirección IP agregado.
  • Pruebe conmutaciones por error.

2. Usar réplicas secundarias existentes: Multisitio

Si tiene nodos en más de un centro de datos de Azure (DC) o si tiene un entorno híbrido, puede usar una configuración AlwaysOn en este entorno para minimizar el tiempo de inactividad.

El enfoque consiste en cambiar la sincronización de Always On a Sincrónica para el centro de datos local o el secundario de Azure y, a continuación, realizar/hacer un failover a ese SQL Server. A continuación, copie los VHDs en una cuenta de almacenamiento premium y reimplemente la máquina en un nuevo servicio en la nube. Actualice la escucha y, a continuación, realice una recuperación.

Puntos de inactividad

El tiempo de inactividad consiste en el tiempo de conmutación al centro de datos alternativo y de regreso. También depende de la configuración de tu cliente y DNS, y la reconexión del cliente puede retrasarse. Considere el ejemplo siguiente de una configuración híbrida de AlwaysOn:

Multisitio1

Ventajas
  • Puede usar la infraestructura existente.
  • Tiene la opción de preparar para la actualización el almacenamiento de Azure primero en el centro de datos de recuperación ante desastres de Azure.
  • El almacenamiento de Azure DC de recuperación ante desastres se puede volver a configurar.
  • Hay un mínimo de dos conmutaciones por error durante la migración, excluyendo las conmutaciones por error de prueba.
  • No es necesario mover datos de SQL Server con copia de seguridad y restauración.
Desventajas
  • En función del acceso de cliente a SQL Server, puede haber una mayor latencia cuando SQL Server se ejecuta en un controlador de dominio alternativo a la aplicación.
  • El tiempo de copia de los discos duros virtuales en Premium Storage podría ser largo. Esto puede afectar a la decisión sobre si se debe mantener el nodo en el grupo de disponibilidad. Tenga en cuenta esto para cuando se ejecutan cargas de trabajo intensivas de registro durante la migración, ya que el nodo principal tiene que mantener las transacciones no replicadas en su registro de transacciones. Por lo tanto, esto podría crecer significativamente.
  • En este escenario se usaría el commandlet Start-AzureStorageBlobCopy Start-AzureStorageBlobCopy, que es asincrónico. No hay ningún Acuerdo de Nivel de Servicio respecto a la finalización. El tiempo de las copias varía, mientras que esto depende de la espera en cola, también depende de la cantidad de datos que se van a transferir. Por lo tanto, tiene solo un nodo en su segundo centro de datos. Debe tomar medidas de mitigación en caso de que la copia demore más que en las pruebas. Estos pasos de mitigación incluyen las siguientes ideas:
    • Agregue un segundo nodo SQL temporal para HA antes de la migración con el tiempo de inactividad acordado.
    • Ejecute la migración fuera del mantenimiento programado de Azure.
    • Asegúrese de que ha configurado el cuórum del clúster correctamente.

En este escenario se supone que ha documentado la instalación y sabe cómo se asigna el almacenamiento para realizar cambios en la configuración óptima de caché de disco.

Pasos de alto nivel

Multisite2

  • Convierta el centro de datos local o alternativo en Azure en el SQL Server principal y configure el otro como el socio de conmutación por error automático (AFP).
  • Recopile información de configuración de disco de SQL2 y quite el nodo (no elimine discos duros virtuales conectados).
  • Cree una cuenta de Almacenamiento Premium y copie VHDs desde la cuenta de Almacenamiento Estándar.
  • Cree un nuevo servicio en la nube y cree la máquina virtual de SQL2 con sus discos de Premium Storage conectados.
  • Configure ILB/ELB y agregue puntos de conexión.
  • Actualice el Always On Listener con la nueva dirección IP de ILB/ELB y pruebe la conmutación por error.
  • Compruebe la configuración de DNS.
  • Cambiar la AFP a SQL2 y luego migrar SQL1 y seguir los pasos del 2 al 5.
  • Pruebe las conmutaciones por error.
  • Vuelva a cambiar la AFP a SQL1 y SQL2.

Apéndice: Migración de un clúster AlwaysOn multisitio a Premium Storage

En el resto de este artículo se proporciona un ejemplo detallado de la conversión de un clúster AlwaysOn de varios sitios a Premium Storage. También convierte el agente de escucha de utilizar un equilibrador de carga externo (ELB) a uno interno (ILB).

Medio ambiente

  • Windows 2k12/SQL 2k12
  • 1 archivo de base de datos en SP
  • 2 x grupos de almacenamiento por nodo

apéndice1

VM:

En este ejemplo, vamos a demostrar cómo pasar de un ELB a un ILB. ELB estaba disponible antes del ILB, por lo que se muestra cómo cambiar a ILB durante la migración.

Apéndice 2

Pasos previos: Conexión a la suscripción

Add-AzureAccount

#Set up subscription
Get-AzureSubscription

Paso 1: Crear una cuenta de almacenamiento y un servicio en la nube

$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

Paso 2: Aumentar los errores permitidos en los recursos <opcional>

En determinados recursos que pertenecen al grupo de disponibilidad AlwaysOn hay límites en cuanto a cuántos errores pueden producirse en un período, donde el servicio de clúster intenta reiniciar el grupo de recursos. Se recomienda aumentar esto mientras recorre este procedimiento, ya que si no realiza la conmutación por error manual y desencadena las conmutaciones por error al apagar las máquinas, puede acercarse a este límite.

Sería prudente duplicar la asignación de errores; para hacerlo, en el Administrador de Clústeres de Conmutación por Error, vaya a las propiedades del grupo de recursos Always On:

apéndice3

Cambiar el número máximo de fallos a 6.

Paso 3: Adición del recurso de dirección IP para el grupo de clústeres <> opcional

Si solo tiene una dirección IP para el grupo de clústeres y se alinea con la subred en la nube, tenga en cuenta que, si se desconecta accidentalmente todos los nodos de clúster de la nube en esa red, el recurso IP del clúster y el nombre de red del clúster no podrán conectarse. En esta situación, evita las actualizaciones de otros recursos del clúster.

Paso 4: Configuración de DNS

La implementación de una transición sin problemas depende de cómo se use y actualice DNS. Cuando se instala AlwaysOn, crea un grupo de recursos de clúster de Windows, si abre el Administrador de clústeres de conmutación por error, verá que, como mínimo, tiene tres recursos, los dos a los que hace referencia el documento son:

  • Nombre de red virtual (VNN): el nombre DNS al que se conectan los clientes al querer conectarse a servidores SQL Server a través de AlwaysOn.
  • Recurso de dirección IP: la dirección IP que está asociada con el VNN; puede tener más de una dirección IP, y en una configuración multisitio, tiene una dirección IP por cada sitio o subred.

Al conectarse a SQL Server, el controlador cliente de SQL Server recupera los registros DNS asociados al agente de escucha e intenta conectarse a cada dirección IP asociada alwaysOn. A continuación, analizamos algunos factores que pueden influir en esto.

El número de registros DNS simultáneos asociados al nombre de listener no solo depende del número de direcciones IP asociadas, sino del ajuste de "RegisterAllIpProviders" en los clústeres de conmutación por error para el recurso VNN de Always ON.

Al implementar AlwaysOn en Azure hay diferentes pasos para crear el agente de escucha y las direcciones IP, tiene que configurar manualmente "RegisterAllIpProviders" en 1, esto es diferente a una implementación de AlwaysOn local en la que ya está establecida en 1.

Si "RegisterAllIpProviders" es 0, solo verá un registro DNS en DNS asociado con el Listener.

Apéndice 4

Si "RegisterAllIpProviders" es 1:

apéndice5

El código siguiente volca la configuración de VNN y la establece automáticamente. Para que el cambio surta efecto, debe desconectar el VNN y volver a activarlo en línea. Esto hace que el agente de escucha esté sin conexión, lo que provoca una interrupción de la conectividad del cliente.

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

En un paso de migración posterior, debe actualizar el agente de escucha AlwaysOn con una dirección IP actualizada que haga referencia a un equilibrador de carga, lo que implica la eliminación y adición de recursos de dirección IP. Después de la actualización de IP, debe asegurarse de que la nueva dirección IP se ha actualizado en la zona DNS y de que los clientes actualizan su caché DNS local.

Si los clientes residen en un segmento de red diferente y hacen referencia a un servidor DNS diferente, debe tener en cuenta lo que sucede con la transferencia de zona DNS durante la migración, ya que el tiempo de reconexión de la aplicación está restringido por al menos la hora de transferencia de zona de cualquier nueva dirección IP para el agente de escucha. Si tiene limitaciones de tiempo, debe discutir y probar cómo forzar una transferencia incremental de zona con los equipos de Windows, y también establecer el registro de host DNS en un tiempo de vida (TTL) más corto, para que los clientes se actualicen. Para obtener más información, vea Transferencias de Zona Incrementales y Start-DnsServerZoneTransfer.

De forma predeterminada, el TTL para el registro DNS asociado al agente de escucha en AlwaysOn en Azure es de 1200 segundos. Es posible que desee reducir el tiempo necesario si está bajo restricción de tiempo durante su migración para asegurarse de que los clientes actualicen su DNS con la dirección IP actualizada para el escucha. Puede ver y modificar la configuración al exportar la configuración de VNN.

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

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

Nota:

Cuanto menor sea "HostRecordTTL", se produce una mayor cantidad de tráfico DNS.

Configuración de la aplicación cliente

Si la aplicación cliente SQL admite .NET 4.5 SQLClient, puede usar la palabra clave "MULTISUBNETFAILOVER=TRUE". Esta palabra clave debe aplicarse, ya que permite una conexión más rápida al grupo de disponibilidad SQL Always On durante la conmutación por error. Enumera todas las direcciones IP asociadas al agente de escucha AlwaysOn en paralelo y realiza una velocidad de reintento de conexión TCP más agresiva durante una conmutación por error.

Para obtener más información sobre la configuración anterior, consulte Palabra clave MultiSubnetFailover y Características asociadas. Consulte también compatibilidad con SqlClient para alta disponibilidad, recuperación ante desastres.

Paso 5: Configuración del cuórum de clúster

A medida que va a desactivar al menos un servidor SQL Server a la vez, debe modificar la configuración del cuórum del clúster. Si utiliza el Testigo de Recursos Compartidos (FSW) con dos nodos, debe establecer el cuórum para permitir la mayoría de los nodos y utilizar la votación dinámica, lo que permite que un único nodo permanezca operativo.

Set-ClusterQuorum -NodeMajority

Para obtener más información sobre cómo administrar y configurar el cuórum de clúster, consulte Configurar y administrar el cuórum en un clúster de conmutación por error de Windows Server 2012.

Paso 6: Extracción de puntos de conexión y ACL existentes

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

Guarde este texto en un archivo.

Paso 7: Cambiar los asociados de conmutación por error y los modos de replicación

Si tiene más de dos servidores SQL Server, debería cambiar la conmutación por error de otro servidor secundario en otro centro de datos o en las instalaciones a 'Sincrónica' y convertirlo en un socio de conmutación automática por error (AFP), para así mantener la alta disponibilidad mientras realiza los cambios. Puede hacerlo mediante TSQL de modificación a través de SSMS:

apéndice6

Paso 8: Eliminación de una máquina virtual secundaria del servicio en la nube

Primero debe planear la migración de un nodo secundario en la nube. Si este nodo es actualmente primario, debería iniciar una conmutación por error manual.

$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

Paso 9: Cambiar la configuración de almacenamiento en caché de disco en el archivo CSV y guardar

En el caso de los volúmenes de datos, estos deben establecerse en READONLY.

En el caso de los volúmenes de TLOG, estos deben establecerse en NONE.

apéndice7

Paso 10: Copiar discos duros virtuales

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

Puede comprobar el estado de copia de los VHDs en la cuenta de almacenamiento 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
}

Apéndice8

Espere hasta que todos estos se registren como exitosos.

Para obtener información sobre blobs individuales:

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

Paso 11: Registro del disco del sistema operativo

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

Paso 12: Importación de una base de datos secundaria en un nuevo servicio en la nube

El código siguiente también utiliza la opción añadida aquí en la que puede importar la máquina y usar la VIP retenible.

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

Paso 13: Crear un ILB en un nuevo servicio en la nube, agregar puntos de conexión con equilibrio de carga y 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

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

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

Paso 14: Actualizar AlwaysOn

#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

apéndice9

Ahora quite la dirección IP del servicio en la nube anterior.

Apéndice10

Paso 15: Comprobación de actualización de DNS

Ahora debe comprobar los servidores DNS en las redes cliente de SQL Server y asegurarse de que la agrupación en clústeres ha agregado el registro de host adicional para la dirección IP agregada. Si esos servidores DNS no se han actualizado, considere forzar una transferencia de zona DNS y asegúrese de que los clientes en su subred puedan resolverse en ambas direcciones IP de Always On, de manera que no tenga que esperar a la replicación automática de DNS.

Paso 16: Volver a configurar AlwaysOn

En este momento, espere a que ese nodo secundario que fue migrado se vuelva a sincronizar completamente con el nodo local y cambie su estado a nodo de replicación sincrónica y se designe como el AFP.

Paso 17: Migración del segundo nodo

$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

Paso 18: Cambiar la configuración de almacenamiento en caché de disco en el archivo CSV y guardar

En el caso de los volúmenes de datos, la configuración de caché debe establecerse en READONLY.

En el caso de los volúmenes de TLOG, la configuración de caché debe establecerse en NONE.

apéndice11

Paso 19: Crear una nueva cuenta de almacenamiento independiente para el nodo secundario

$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

Paso 20: Copiar 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

Puede comprobar el estado de copia del disco duro virtual para todos los discos duros virtuales:

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
}

Apéndice12

Espere hasta que todos estos se registren como exitosos.

Para obtener información sobre blobs individuales:

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

Paso 21: Registro del disco del sistema operativo

#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

Paso 22: Agregar puntos de conexión y ACL con equilibrio de carga

#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

Paso 23: Prueba de conmutación por error

Espere a que el nodo migrado se sincronice con el nodo AlwaysOn local. Colóquelo en modo de replicación sincrónica y espere hasta que se sincronice. A continuación, realiza una conmutación por error del entorno local al primer nodo migrado, que es la AFP. Una vez que haya funcionado, cambie el último nodo migrado a la AFP.

Debe probar las conmutaciones por error entre todos los nodos y ejecutar pruebas de caos para asegurarse de que las conmutaciones por error funcionan según lo previsto y de manera oportuna.

Paso 24: Volver a colocar la configuración del cuórum del clúster / TTL de DNS / Punteros de conmutación por error / Configuración de sincronización

Adición de un recurso de dirección IP en la misma subred

Si solo tiene dos servidores SQL Server y quiere migrarlos a un nuevo servicio en la nube, pero desea mantenerlos en la misma subred, puede evitar desconectar el agente de escucha para eliminar la dirección IP de AlwaysOn original y agregar la nueva dirección IP. Si va a migrar las máquinas virtuales a otra subred, no es necesario hacerlo, ya que hay una red de clúster adicional que hace referencia a esa subred.

Una vez que haya presentado la base de datos secundaria migrada y agregado en el nuevo recurso de dirección IP para el nuevo servicio en la nube antes de conmutar por error el principal existente, debe seguir estos pasos en el Administrador de conmutación por error de clúster:

Para agregar la dirección IP, consulte el Apéndice, paso 14.

  1. Para el recurso de dirección IP actual, cambie el posible propietario a "Existing Primary SQL Server", en el ejemplo, "dansqlams4":

    Apéndice13

  2. Para el nuevo recurso de dirección IP, cambie el posible propietario a "Migrated secondary SQL Server", en el ejemplo, "dansqlams5":

    Apéndice 14

  3. Una vez establecido, puedes iniciar el proceso de conmutación por error y, cuando se migre el último nodo, se deben editar los Posibles Propietarios para que el nodo se agregue como un Posible Propietario.

    Apéndice15

Recursos adicionales