Traslado de una instancia de Azure SQL Managed Instance entre subredes

Se aplica a:Azure SQL Managed Instance

La instancia de Azure SQL Managed Instance debe implementarse dentro de una subred dedicada de una red virtual de Azure. El número de instancias administradas que se puede implementar en la subred depende del tamaño de la subred (intervalo de subred).

En este artículo se explica cómo mover la instancia administrada de una subred a otra (en la misma red virtual u otra distinta), de forma similar al escalado de núcleos virtuales o al cambio del nivel de servicio de la instancia. La instancia de SQL Managed Instance está disponible durante el traslado, excepto durante un breve tiempo de inactividad causado por una conmutación por error al final de la actualización, que normalmente dura hasta 10 segundos, incluso si se interrumpen las transacciones de larga ejecución.

Mover la instancia a otra subred desencadena las siguientes operaciones de clúster virtual:

• El clúster virtual compilará o cambiará el tamaño de la infraestructura subyacente en la subred de destino.
• El clúster virtual se quita o desfragmenta en la subred de origen.

Antes de mover la instancia a otra subred, considere la posibilidad de familiarizarse con los siguientes conceptos:

• Determine el tamaño e intervalo de subred necesarios para Azure SQL Managed Instance.
• Elija entre mover la instancia a una subred nueva o usar una subred existente.
• Use las operaciones de administración para implementar automáticamente nuevas instancias administradas, actualizar las propiedades de una instancia o eliminar instancias. Es posible supervisar estas operaciones de administración.

Limitaciones y requisitos

Para implementar una instancia administrada o moverla a otra subred, la subred de destino debe cumplir determinados requisitos de red.

Preparación de la subred

Antes de mover la instancia administrada, confirme que la subred está marcada como Listo para Instancia administrada.

En la interfaz de usuario de red virtual de Azure Portal, las redes virtuales que cumplen los requisitos previos para una instancia administrada se clasifican como Listo para Instancia administrada. Las redes virtuales que tienen subredes con instancias administradas ya implementadas en ellas muestran un icono SQL Managed Instance antes del nombre de la red virtual. Las subredes vacías que están listas para una instancia administrada muestran un icono de subred de red virtual.

Las subredes marcadas como Sin preparar no cumplen todos los requisitos de implementación de SQL Managed Instance. Use el icono de información que aparece a la derecha del nombre de la subred para averiguar por qué no está lista la subred y si esta puede cumplir los requisitos de red. Estos requisitos incluyen:

• delegar al proveedor de recursos Microsoft.Sql/managedInstances
• adjuntar una tabla de rutas
• adjuntar un grupo de seguridad de red

En el caso de que la subred forme parte de otra red virtual, los requisitos adicionales son

• el emparejamiento bidireccional entre la red virtual actual y la de destino.
• Las subredes actuales y de destino usan tablas de enrutamiento independientes y grupos de seguridad de red.

Una vez que se cumplen todos los requisitos, la subred pasa de la categoría Sin preparar a la categoría A punto para Managed Instance y se puede usar para una instancia administrada.

Una subred que ya está en uso (las subredes usadas para las implementaciones de instancias no pueden contener otros recursos) o una subred que tiene una zona DNS distinta (una limitación de movimiento de instancias entre subredes) siempre forma parte de la categoría Sin preparar.

Según el estado y la designación de la subred, se pueden realizar los siguientes ajustes en la subred de destino:

• Listo para Instancia administrada (contiene la instancia de SQL Managed Instance existente): no se realiza ningún ajuste. Estas subredes ya contienen instancias administradas, y realizar cualquier cambio en la subred podría afectar a las instancias existentes.
• Listo para Instancia administrada (vacío): el flujo de trabajo valida todas las reglas necesarias en el grupo de seguridad de red y la tabla de rutas, y agrega las reglas necesarias pero que faltan. ¹

Nota

¹ Las reglas personalizadas agregadas a la configuración de la subred de origen no se copian a la subred de destino. Cualquier personalización de la configuración de la subred de origen se debe replicar manualmente en la subred de destino. Una manera de lograrlo es usar la misma tabla de rutas y el mismo grupo de seguridad de red para las subredes de origen y de destino.

Limitaciones de la subred de destino

Tenga en cuenta las siguientes limitaciones al elegir una subred de destino para una instancia existente:

• SQL Managed Instance se puede mover a la subred que esté:

  • En la misma red virtual que la utilizada actualmente.
  • En una red virtual emparejada, si se cambia a una subred de otra red virtual.

• La zona DNS de las instancias en la subred de destino debe coincidir con la zona DNS de la instancia que se va a mover. Esta limitación se aplica si tiene previsto cambiar a una subred que no esté vacía.

  • Puede preparar la subred de destino de forma especial para conservar la zona DNS de SQL Managed Instance que se va a mover. Para prepararla, cree nuevas instancias de SQL Managed Instance en una subred vacía y proporcione el parámetro dnsZonePartner en la solicitud de creación. Este parámetro como valor acepta el identificador de SQL Managed Instance y, en este caso, puede usar la instancia que se pasaría más adelante a la nueva subred¹.

Nota

¹ Aparte de este enfoque, no hay ninguna otra forma de dictar la zona DNS de SQL Managed Instance, ya que se genera de forma aleatoria. Además, a partir de ahora no existe una forma de actualizar la zona DNS de una instancia de SQL Managed Instance existente.

• Si deseas migrar una instancia de SQL Managed Instance con un grupo de conmutación por error, los siguientes requisitos previos son de aplicación:
  • La subred de destino debe tener las mismas reglas de seguridad necesarias para la replicación del grupo de conmutación por error que la subred de origen: abra los puertos entrantes y salientes 5022 y el intervalo 11000~11999 en el grupo de seguridad de red para las conexiones de la otra subred de instancia administrada (la que contiene la réplica del grupo de conmutación por error) para permitir el tráfico de replicación entre las dos instancias.
  • La subred de destino no puede tener un intervalo de direcciones que se superponga con la subred que contiene la réplica de instancia secundaria del grupo de conmutación por error. Por ejemplo, si MI1 está en la subred S1, la instancia secundaria del grupo de conmutación por error es MI2 en la subred S2. Queremos cambiar MI1 a la subred S3. La subred S3 no puede tener un intervalo de direcciones que se superponga con la subred S2.

Para obtener más información sobre cómo configurar la red para grupos de conmutación por error, consulta Habilitación de la replicación geográfica entre las redes virtuales de MI.

Pasos de la operación

En la tabla siguiente se detallan los pasos de la operación que se producen durante la operación de traslado de la instancia:

Nombre del paso	Descripción del paso
Validación de solicitudes	Valida los parámetros enviados. Si se detecta un error de configuración, se produce un error en la operación.
Cambio de tamaño o creación de un clúster virtual	Según el estado de la subred de destino, el clúster virtual se crea o cambia de tamaño.
Inicio de la nueva instancia	El proceso de SQL se inicia en el clúster virtual implementado en la subred de destino.
Inicializar o asociar archivos de base de datos	Según el nivel de servicio, se inicializa la base de datos o se adjuntan los archivos de base de datos.
Preparación de la conmutación por error y conmutación por error	Una vez que los datos se han inicializado o se han vuelto a adjuntar los archivos de base de datos, el sistema se prepara para la conmutación por error. Cuando todo está listo, el sistema realiza una conmutación por error con un breve tiempo de inactividad, normalmente de menos de 10 segundos.
Limpieza de instancias de SQL antiguas	Quita el proceso de SQL anterior del clúster virtual de origen.
Eliminación de un clúster virtual	Si es la última instancia dentro de la subred de origen, el paso final elimina el clúster virtual de forma sincrónica. De lo contrario, el clúster virtual se desfragmenta de forma asincrónica.

Puede encontrar una explicación detallada de los pasos de la operación en la introducción a las operaciones de administración de Azure SQL Managed Instance.

Traslado de la instancia

El traslado de la instancia entre subredes forma parte de la operación de actualización de la instancia. La API de actualización de instancias existente, Azure PowerShell y los comandos de la CLI de Azure se han mejorado con una propiedad de id. de subred.

En Azure Portal, use el campo de subred del panel Redes para mover la instancia a la subred de destino. Si usa Azure PowerShell o la CLI de Azure, proporcione un id. de subred diferente en el comando de actualización para mover la instancia de una subred existente a la subred de destino.

Para obtener una referencia completa de los comandos de administración de instancias, consulte Referencia de la API de administración Para Azure SQL Managed Instance.

Portal

La opción para elegir la subred de la instancia se encuentra en el panel Redes de Azure Portal. La operación de traslado de la instancia se inicia al seleccionar una subred y guardar los cambios.

El primer paso de la operación de traslado es preparar la subred de destino para la implementación, lo que puede tardar varios minutos. Una vez que la subred está lista, la operación de administración de traslado de instancias se inicia y se vuelve visible en Azure Portal.

Supervise las operaciones de traslado de instancias desde el panel Información general de Azure Portal. Seleccione la notificación para abrir un panel adicional con información sobre el paso actual, el total de pasos y un botón para cancelar la operación.

PowerShell

Use el comando Set-AzSqlInstance de Azure PowerShell para mover una instancia después de crear la subred en la misma red virtual que la subred de destino. Si quiere usar una subred existente, proporcione ese nombre de subred en el comando de PowerShell.

Los comandos de PowerShell de ejemplo de esta sección preparan la subred de destino para la implementación de la instancia y mueven la instancia administrada.

Use el siguiente comando de PowerShell para especificar los parámetros:

### PART 1 - DEFINE PARAMETERS

#Generating basic parameters
$currentSubscriptionID = 'subscription-id'
$sqlMIResourceGroupName = 'resource-group-name-of-sql-mi'
$sqlMIName = 'sql-mi-name'
$sqlMIResourceVnetName = 'vnet-name-of-sql-mi'
$destinationSubnetName = 'name-of-the-destination-subnet-for-sql-mi'

Omita este comando si la subred ya tiene instancias implementadas. Si usa una subred nueva, utilice el comando siguiente de Azure PowerShell para prepararla:

### PART 2 - PREPARE DESTINATION SUBNET

#Loading the url of script used for preparing the subnet for SQL MI deployment
$scriptUrlBase = 'https://raw.githubusercontent.com/Microsoft/sql-server-samples/master/samples/manage/azure-sql-db-managed-instance/delegate-subnet'

#Generating destination subnet parameters
$parameters = @{
    subscriptionId = $currentSubscriptionID
    resourceGroupName = $sqlMIResourceGroupName
    virtualNetworkName = $sqlMIResourceVnetName
    subnetName = $destinationSubnetName
}

#Initiating subnet prepartion script
Invoke-Command -ScriptBlock ([Scriptblock]::Create((iwr ($scriptUrlBase+'/delegateSubnet.ps1?t='+ [DateTime]::Now.Ticks)).Content)) -ArgumentList $parameters

Nota

Para obtener más información sobre el script que prepara la subred, consulte Configuración de una red virtual existente para Azure SQL Managed Instance.

El comando de Azure PowerShell siguiente mueve la instancia a la subred de origen:

### PART 3 - MOVE INSTANCE TO THE NEW SUBNET

Set-AzSqlInstance -Name $sqlMIName -ResourceGroupName $sqlMIResourceGroupName `
-SubnetId "/subscriptions/$currentSubscriptionID/resourceGroups/$sqlMIResourceGroupName/providers/Microsoft.Network/virtualNetworks/$sqlMIResourceVnetName/subnets/$destinationSubnetName"

El siguiente comando de Azure PowerShell mueve la instancia y, además, proporciona una manera de supervisar el progreso:

###PART 3 EXTENDED - MOVE INSTANCE AND MONITOR PROGRESS

# Extend the Set-AzSqlInstance command with -AsJob -Force parameters to be able to monitor the progress or proceed with script execution as moving the instance to another subnet is long running operation 
Set-AzSqlInstance -Name $sqlMIName -ResourceGroupName $sqlMIResourceGroupName `
-SubnetId "/subscriptions/$currentSubscriptionID/resourceGroups/$sqlMIResourceGroupName/providers/Microsoft.Network/virtualNetworks/$sqlMIResourceVnetName/subnets/$destinationSubnetName" -AsJob -Force

$operationProgress = Get-AzSqlInstanceOperation -ManagedInstanceName $sqlMIName -ResourceGroupName $sqlMIResourceGroupName
#checking the operation step status
Write-Host "Checking the ongoing step" -ForegroundColor Yellow
$operationProgress.OperationSteps.StepsList

CLI de Azure

Use el comando az sql mi update de la CLI de Azure para mover la instancia a otra subred.

Proporcione el destino especificando el id. de subred como la propiedad --subnet o especificando el nombre de red virtual como la propiedad --vnet-name, y el nombre de subred como la propiedad --subnet.

En el ejemplo siguiente se mueve la instancia administrada a otra subred especificando el id. de subred:

az sql mi update -g myResourceGroup -n mySqlManagedInstance --subnet /subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetworkName/subnets/destinationSubnetName

En el ejemplo siguiente se mueve la instancia administrada a otra subred especificando el nombre de red virtual y el nombre de subred:

az sql mi update -g myResourceGroup -n mySqlManagedInstance --vnet-name myVirtualNetworkName --subnet destinationSubnetName

Use el siguiente comando para supervisar el progreso de la operación de administración:

az sql mi op list -g myResourceGroup --mi mySqlManagedInstance

Pasos siguientes

• Para más información sobre cómo crear su primera instancia administrada, vea la Guía de inicio rápido.
• Para obtener una lista de características y una comparación, consulte Características comunes de SQL.
• Para obtener más información sobre la configuración de redes virtuales, vea Configuración de una red virtual de Instancia administrada de SQL.
• Para ver un inicio rápido en el que se crea una instancia administrada y se restaura una base de datos desde un archivo de copia de seguridad, consulte Creación de una instancia administrada.
• Para consultar un tutorial sobre el uso de Azure Database Migration Service para la migración, consulte Migración de Instancia administrada de SQL mediante Database Migration Service.