Configuración de una réplica en espera sin licencia para Azure SQL Managed Instance
Se aplica a:
Azure SQL Managed Instance
En este artículo se describe cómo puede ahorrar en costes de licencias designando su instancia administrada secundaria como instancia en espera cuando utilice Azure SQL Managed Instance.
Nota:
La ventaja de conmutación por error solo es aplicable cuando se configura una instancia secundaria como en espera dentro de un grupo de conmutación por error. En el caso de entornos híbridos entre SQL Server y SQL Managed Instance, use la ventaja de conmutación por error híbrida en su lugar.
Información general
Si usa una implementación de Azure SQL Managed Instance secundaria como modo de espera para la recuperación ante desastres y la instancia secundaria no tiene ninguna carga de trabajo de lectura o aplicaciones conectadas a ella, puede ahorrar en costos de licencias mediante la designación de la réplica como una instancia en espera.
Cuando una instancia secundaria se designa para la espera, Microsoft le proporciona la cantidad de núcleos virtuales con licencia para la instancia principal sin cargo adicional en virtud de las ventajas de derechos de conmutación por error de los términos de licencia del producto. Se le seguirá facturando por el proceso y el almacenamiento que usa la instancia secundaria.
Los grupos de conmutación por error para la implementación de SQL Managed Instance solo admiten una réplica. La réplica debe ser una réplica legible o designada como una réplica en espera.
Ventaja del costo
Cuando designa una réplica de instancia administrada como en espera, Microsoft no le cobra los costes de licencia de SQL Server por los núcleos virtuales utilizados por la réplica en espera. Sin embargo, dado que la instancia se factura por la hora completa, es posible que se le sigan cobrando costos de licencia por toda la hora si el cambio de estado se realiza a mitad de la hora.
La ventaja se traduce de forma diferente entre los clientes que usan el modelo de pago por uso y los clientes que usan el modelo Ventaja híbrida de Azure. Para un cliente de pago por uso, los núcleos virtuales se descuentan de su factura. Para un cliente que usa la Ventaja híbrida de Azure para la réplica en espera, el número de núcleos virtuales que la réplica secundaria usa se devuelve a su grupo de licencias.
Por ejemplo, como cliente de pago por uso, si tiene 16 núcleos virtuales asignados a la instancia secundaria, aparece un descuento por 16 núcleos virtuales en la factura si designa la instancia secundaria como solo en espera.
En otro ejemplo, si tiene 16 licencias de Ventaja híbrida de Azure e implementa dos instancias administradas con 8 núcleos virtuales cada una en un grupo de conmutación por error, después de designar la instancia secundaria como en espera, se devuelven 8 núcleos virtuales al grupo de licencias para que lo use con otras implementaciones de Azure SQL.
Funcionalidades funcionales
En la tabla siguiente se describen las funcionalidades funcionales de una instancia administrada secundaria en espera:
| Funcionalidad | Descripción |
|---|---|
| Cargas de trabajo de lectura limitadas | Después de designar la instancia como en espera, solo puede ejecutar un número limitado de cargas de trabajo de lectura en la instancia secundaria, como vistas de administración dinámica (DMV), copias de seguridad y consultas de comandos de consola de base de datos (DBCC). |
| Conmutación por error planeada | Todos los escenarios de conmutación por error planeados, incluidos los simulacros de recuperación, la reasignación de bases de datos a diferentes regiones y la devolución de bases de datos a la réplica principal, son compatibles con la réplica en espera. Cuando la secundaria cambia a la principal, puede atender consultas de lectura y escritura. La nueva réplica secundaria (la principal original) se convierte en la réplica en espera y no debe usarse para cargas de trabajo de lectura. |
| Conmutación por error no planeada | Durante una conmutación por error no planeada, una vez que la réplica secundaria cambia al rol principal, puede atender consultas de lectura y escritura. Una vez mitigada la interrupción y la réplica antigua principal se vuelva a conectar, se convierte en la nueva réplica en espera secundaria y no se debe usar para las cargas de trabajo de lectura. |
| Copia de seguridad y restauración | El comportamiento de copia de seguridad y restauración entre una réplica en espera y una instancia administrada de réplica secundaria legible es el mismo. |
| Supervisión | Todas las operaciones de supervisión compatibles con una réplica secundaria legible son compatibles con la réplica en espera. |
| RTO y RPO | La réplica en espera proporciona el mismo objeto de punto de recuperación (RPO) y objetivo de tiempo de recuperación (RTO) como una réplica secundaria legible. |
| Eliminación de un grupo de conmutación por error | Si el grupo de conmutación por error se quita a través de un método como el uso del cmdlet Remove-AzSqlDatabaseInstanceFailoverGroup, la réplica en espera se convierte en una instancia independiente de lectura y escritura. El modelo de licencias vuelve a lo que era antes de que se designara como en espera (ya sea Ventaja híbrida de Azure o pago por uso). |
La instancia en espera debe utilizarse únicamente para la recuperación de desastres. No se pueden conectar aplicaciones de producción a la réplica. A continuación se muestran las únicas actividades que se permiten en la réplica en espera:
- Ejecución de copias de seguridad
- Realización de operaciones de mantenimiento, como checkDB
- Conexión de aplicaciones de supervisión
- Ejecutar simulacros de recuperación ante desastres
Configurar una réplica en espera
Tiene dos opciones para designar la instancia administrada secundaria como en espera:
- Designarla como en espera al crear el grupo de conmutación por error.
- Actualizar la configuración de un grupo de conmutación por error existente.
Nuevo grupo de conmutación por error
Puede designar la instancia secundaria como una réplica en espera al crear un nuevo grupo de conmutación por error mediante Azure Portal, Azure PowerShell y la CLI de Azure.
Al crear un nuevo grupo de conmutación por error en Azure Portal, en Derechos de conmutación por error, seleccione Activado. Active la casilla junto a Confirmo que usaré la instancia secundaria como réplica en espera. Seleccione Crear para crear el grupo de conmutación por error.
Para más información, consulta Configurar un grupo de conmutación por error.
Grupo de conmutación por error existente
Puede actualizar los derechos de conmutación por error de un grupo de conmutación por error existente mediante Azure Portal, Azure PowerShell y la CLI de Azure.
Para actualizar los derechos de conmutación por error de un grupo de conmutación por error existente mediante Azure Portal, siga estos pasos:
En Azure Portal, vaya a al recurso secundario de SQL Managed Instance.
En el menú de la izquierda, en Administración de datos, seleccione Grupos de conmutación por error.
En la barra de comandos, seleccione Editar configuraciones.
En Editar configuraciones para el grupo de conmutación por error, en Derechos de conmutación por error, seleccione Activado. Active la casilla Confirmo que usaré la instancia secundaria como réplica en espera.
Seleccione Aplicar para guardar la nueva configuración y cerrar el panel de configuración.
Como alternativa, puede habilitar los derechos de conmutación por error en Proceso y almacenamiento de la instancia administrada secundaria. Para más información, revise Visualización de derechos de licencia.
Importante
Si ve Derechos de conmutación por error híbrida y no Derechos de conmutación por error, es probable que esté en la instancia administrada principal. Vaya a la instancia administrada secundaria para activar correctamente los Derechos de conmutación por error. La activación de Derechos de conmutación por error híbrida en la instancia principal no te ahorra costes de licencia para la instancia secundaria cuando se usa con grupos de conmutación por error.
Visualización de derechos de licencia
Puede comprobar los derechos de licencia de un grupo de conmutación por error existente mediante Azure Portal, Azure PowerShell o la CLI de Azure.
En Azure Portal, puede comprobar la licencia de la instancia administrada secundaria en dos lugares:
- Grupos de conmutación por error para la instancia administrada principal.
- Proceso y almacenamiento para la instancia administrada secundaria.
En Grupos de conmutación por error, asegúrese de que Estado de los derechos de conmutación por error esté establecido en ACTIVADO y que el modelo de licencia de la instancia secundaria sea Derechos de conmutación por error actualmente activados.
El modelo de licencia predeterminado indica el modelo de licencias al que se devuelve la instancia si el grupo de conmutación por error conmuta por error y la instancia secundaria actual se convierte en la nueva instancia principal. Podría incurrir en cargos por error, según el modelo de licencia predeterminado.
En Proceso y almacenamiento para la instancia administrada secundaria, confirme que la licencia Derechos de conmutación por error está activada. En Resumen del costo, vea el descuento de conmutación por error que recibe actualmente para esa instancia.
Si los derechos de conmutación por error no están activados y cumple los requisitos para la ventaja, también ve la siguiente recomendación en la sección de Información general de cualquier instancia. Para activar la ventaja, seleccione la recomendación para ir a Editar configuraciones.
Pasos siguientes
- Para obtener una guía, consulta Adición de SQL Managed Instance a un grupo de conmutación por error.
- Si deseas un script de ejemplo, consulta: Uso de PowerShell para crear un grupo de conmutación por error en SQL Managed Instance.
- Para obtener información general y escenarios de continuidad empresarial, consulte Introducción a la continuidad empresarial con Azure SQL Database y Azure SQL Managed Instance.
- Si desea información sobre las copias de seguridad automatizadas, consulte Copias de seguridad automatizadas de SQL Database.
- Si quiere saber cómo utilizar las copias de seguridad automatizadas para procesos de recuperación, consulte Restauración de una base de datos desde una copia de seguridad en Azure SQL Database.
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de