Compartir a través de

Traslado de recursos a una nueva región: Azure SQL Managed Instance

  • Artículo

Se aplica a: Azure SQL Managed Instance

En este artículo se enseña un flujo de trabajo genérico sobre cómo mover Azure SQL Managed Instance a otra región.

Nota:

Este artículo se aplica a las migraciones dentro de la nube pública de Azure o dentro de la misma nube soberana.

Información general

Hay varios escenarios en los que puede desear mover la instancia administrada existentes de una región a otra. Por ejemplo, va a ampliar su negocio a una nueva región y desear optimizarla para la nueva base de clientes. O bien, debe migrar las operaciones a una otra región por motivos de cumplimiento. O también que Azure ha lanzado una nueva región que proporciona una mejor proximidad y mejora la experiencia del cliente.

El flujo de trabajo general para mover recursos a otra región consta de los pasos siguientes:

  1. Comprobar los requisitos previos para el traslado.
  2. Preparar el traslado de los recursos en el ámbito.
  3. Supervisar el proceso de preparación.
  4. Probar el proceso de traslado.
  5. Iniciar el traslado real.
  6. Eliminar los recursos de la región de origen.

Verificar los requisitos previos

  1. Para cada instancia administrada de origen, cree una instancia del mismo tamaño en la región de destino.
  2. Configure la red para la instancia administrada. Para más información, consulte Configuración de la red.
  3. Configure la base de datos master de destino con los inicios de sesión correctos. Si no es el administrador de la suscripción ni de la Instancia administrada de SQL, solicite al administrador que le asigne los permisos que necesita.
  4. Si las bases de datos están cifradas con cifrado de datos transparente (TDE) y usan su propia clave de cifrado (BYOK o clave administrada por el cliente) en Azure Key Vault, asegúrese de que se aprovisiona el material de cifrado correcto en las regiones de destino.
    • La manera más sencilla de hacerlo es agregar la clave de cifrado del almacén de claves existente (que se usa como protector de TDE en el servidor de origen) al servidor de destino y, a continuación, establecer la clave como protector de TDE en el servidor de destino ya que ahora una instancia de una región puede conectarse a un almacén de claves de cualquier otra región..
    • Como procedimiento recomendado para asegurarse de que la instancia de destino tiene acceso a claves de cifrado anteriores (necesarias para restaurar copias de seguridad de base de datos), ejecute el cmdlet Get-AzSqlServerKeyVaultKey en la instancia de origen o el cmdlet Get-AzSqlInstanceKeyVaultKey en la instancia administrada de origen para devolver la lista de claves disponibles y agregar esas claves a la instancia de destino.
    • Para más información y procedimientos recomendados sobre la configuración del TDE administrado por el cliente en la instancia de destino, vea Cifrado de datos transparente de Azure SQL con una clave administrada por el cliente en Azure Key Vault.
  5. Si está habilitada la auditoría para la instancia administrada, asegúrese de que:
    • El contenedor de almacenamiento o el centro de eventos con los registros existentes migran a la región de destino.
    • La auditoría se configura en la instancia de destino. Para más información, consulte Auditoría con Azure SQL Managed Instance.
  6. Si la instancia tiene una directiva de retención a largo plazo (LTR), las copias de seguridad de LTR existentes permanecerán asociadas a la instancia actual. Dado que la instancia de destino es diferente, podrá tener acceso a las copias de seguridad de LTR anteriores de la región de origen mediante la instancia de origen, aunque se elimine la instancia.

Nota:

No se admite la migración de instancias con copias de seguridad de LTR existentes entre regiones soberanas y públicas, ya que esto requiere mover copias de seguridad de LTR a la instancia de destino, lo que no es posible actualmente.

Preparación de recursos

Cree un grupo de conmutación por error entre cada instancia administrada de origen y la instancia de destino correspondiente de SQL Managed Instance.

La replicación de todas las bases de datos en cada instancia se iniciará automáticamente. Para más información, consulta Grupos de conmutación por error.

Supervisión del proceso de preparación

Puede llamar periódicamente a Get-AzSqlDatabaseInstanceFailoverGroup para supervisar la replicación de las bases de datos desde el origen a la instancia de destino. El objeto de salida de Get-AzSqlDatabaseInstanceFailoverGroup incluye una propiedad para Get-AzSqlDatabaseInstanceFailoverGroup:

  • ReplicationState = CATCH_UP indica que la base de datos está sincronizada y se puede conmutar por error de forma segura.
  • ReplicationState = SEEDING indica que la base de datos aún no se ha inicializado y se producirá un error en un intento de conmutación por error.

Prueba de la sincronización

Una vez que ReplicationState es CATCH_UP, conéctese a cna base de datos geográfica secundaria que use el punto de conexión secundario <fog-name>.secondary.<zone_id>.database.windows.net y realice cualquier consulta en las bases de datos para asegurarse de la conectividad, la configuración de seguridad adecuada y la replicación de datos.

Inicio de la migración

  1. Conéctese a la Instancia administrada de destino mediante el punto de conexión secundario <fog-name>.secondary.<zone_id>.database.windows.net.
  2. Use Switch-AzSqlDatabaseInstanceFailoverGroup para cambiar la instancia administrada secundaria para que sea la principal con sincronización completa. Esta operación se realiza correctamente o revierte.
  3. Compruebe que el comando se ha completado correctamente mediante nslook up <fog-name>.secondary.<zone_id>.database.windows.net para determinar que la entrada CNAME de DNS apunta a la dirección IP de la región de destino. Si se produce un error en el comando switch, no se actualiza CNAME.

Eliminación de las instancias administradas de origen

Una vez completado el traslado, elimine los recursos de la región de origen para evitar cargos innecesarios.

  1. Elimine el grupo de conmutación por error mediante Remove-AzSqlDatabaseInstanceFailoverGroup. Esto quita la configuración del grupo de conmutación por error y finalizará los vínculos de replicación geográfica entre las dos instancias.
  2. Elimine la instancia administrada de origen mediante Remove-AzSqlInstance.
  3. Quite cualquier recurso adicional en el grupo de recursos, como la red y el grupo de seguridad.

Contenido relacionado