Traslado de una instancia de Azure SQL Managed Instance entre subredes

Se aplica a:Azure SQL Managed Instance

En este artículo se explica cómo mover Azure SQL Managed Instance de una subred a otra en la misma red virtual o una diferente. La operación es similar al escalado de núcleos virtuales o al cambiar el nivel de servicio de instancia. Durante el traslado, SQL Managed Instance permanece disponible, excepto durante un breve tiempo de inactividad cuando se produce la conmutación por error, que suele durar hasta 10 segundos, incluso si se interrumpen las transacciones de larga duración.

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

• El clúster virtual se compila o cambia 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.

Requisitos y limitaciones

Azure SQL Managed Instance debe implementarse dentro de una subred dedicada de una virtual network de Azure. El número de instancias administradas de SQL que se pueden implementar dentro de la subred depende del tamaño de la subred (intervalo de subred). Para implementar una instancia administrada de SQL o moverla a otra subred, la subred de destino debe tener determinados requisitos de red.

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.

Preparación de la subred

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

En la interfaz de usuario de red virtual de Azure Portal, las redes virtuales que cumplen los requisitos previos de una instancia administrada de SQL se clasifican como Listas para instancia administrada. Las redes virtuales que tienen subredes con instancias administradas de SQL ya implementadas en ellas muestran un icono de Instancia administrada de SQL antes del nombre de la red virtual. Las subredes vacías que están listas para una instancia administrada de SQL 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 situado a la derecha del nombre de la subred para saber por qué la subred no está lista y si la subred puede cumplir los requisitos de red. Estos requisitos incluyen:

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

En caso de que la subred forme parte de alguna 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 No listo a la categoría Ready for Managed Instance (Listo para instancia administrada ) y se puede usar para una instancia administrada de SQL.

Las subredes que ya están en uso (las subredes que se usan para implementaciones de instancias no pueden contener otros recursos) o subredes que tienen una zona DNS diferente (una limitación de movimiento de instancia entre subredes), siempre forman parte de la categoría No listo .

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 de SQL 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

^{1 Las} reglas personalizadas agregadas a la configuración de subred de origen no se copian en 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 de 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 pasar a una subred no vacía.

  • Puede preparar especialmente la subred de destino para conservar la zona DNS de la instancia administrada de SQL que se va a mover. La preparación se puede realizar creando una nueva instancia administrada de SQL en una subred vacía y proporcionando el dnsZonePartner parámetro en la solicitud de creación. Este parámetro como valor acepta el identificador de INSTANCIA administrada de SQL y, en este caso, puede usar la instancia que más adelante se movería a la nueva subred¹.

Nota

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

Si desea migrar una instancia administrada de SQL con un grupo de conmutación por error, se aplican los siguientes requisitos previos:

• 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 (NSG) para las conexiones de la otra subred de instancia administrada de SQL (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 más información sobre cómo configurar la red para grupos de conmutación por error, consulte Habilitación de la replicación geográfica entre instancias administradas de SQL.

Pasos de la operación

Mover una instancia de una subred a otra implica muchos pasos y, en función de cómo esté configurada la instancia administrada de SQL, podría tardar entre 30 minutos y 6 horas.

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 propagan o se vuelven 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, que normalmente es inferior a 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 operación en 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. Las API de actualización de instancias existentes, Azure PowerShell y los comandos de la CLI de Azure se mejoran con una propiedad de identificador 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 otro panel que contenga información sobre el paso actual, los pasos totales 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 instancias y mueven la instancia administrada de SQL.

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 preparation 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 de SQL a otra subred especificando el identificador 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 de SQL a otra subred especificando el nombre de la 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

Contenido relacionado

• Inicio rápido: Creación de Una instancia administrada de Azure SQL
• Comparación de características: Azure SQL Database e Instancia administrada de Azure SQL
• Arquitectura de conectividad para Azure SQL Managed Instance
• Migración de SQL Managed Instance mediante Database Migration Service