Continuidad empresarial y recuperación ante desastres para SQL Managed Instance habilitado para Azure Arc

SQL Managed Instance habilitado para Azure Arc proporcionan funcionalidades para la continuidad empresarial y la recuperación ante desastres (BCDR) que ayudan a las empresas a recuperarse de interrupciones y a seguir funcionando con un tiempo de inactividad mínimo.

En este artículo se proporcionan consideraciones y recomendaciones de diseño clave para configurar y administrar funcionalidades de continuidad empresarial, como la restauración a un momento dado, la alta disponibilidad y la recuperación ante desastres.

Architecture

En los diagramas de arquitectura siguientes se muestran las funcionalidades de alta disponibilidad de SQL Managed Instance habilitado para Arc en el nivel de servicio Crítico para la empresa, que admite la conmutación por error con un tiempo de inactividad cercano a cero. Si se produce un error en la instancia principal, el equilibrador de carga deja de enviar tráfico a esa instancia. A continuación, una de las instancias secundarias se promociona para ser principal y la instancia recién promocionada empieza a recibir tráfico de lectura y escritura desde el equilibrador de carga. Una vez que la instancia con error vuelve a estar en línea, se agrega como una instancia secundaria.

En el siguiente diagrama de arquitectura se muestra cómo se puede implementar SQL Managed Instance habilitado para Arc en dos clústeres de Kubernetes independientes que se encuentran en dos sitios diferentes para la recuperación ante desastres.

En el siguiente diagrama de arquitectura se muestra cómo responde SQL Managed Instance habilitado para Arc cuando se inicia una conmutación por error de recuperación ante desastres.

Consideraciones de diseño

Para evaluar el efecto de SQL Managed Instance habilitado para Azure Arc en el modelo de continuidad empresarial y recuperación ante desastres general, examine las recomendaciones de continuidad empresarial y recuperación ante desastres para las zonas de aterrizaje en el artículo sobre continuidad empresarial y recuperación ante desastres. Tenga en cuenta que el artículo sobre continuidad empresarial y recuperación ante desastres se centra solo en las recomendaciones de diseño de la continuidad empresarial, pero la alta disponibilidad y resistencia de la instancia también dependen de la disponibilidad de la infraestructura de Kubernetes subyacente.

Restauración a un momento dado

• Define los objetivos tanto del objetivo de punto de recuperación (RPO) como del objetivo de tiempo de recuperación (RTO).

• Determine el tiempo durante el que desea conservar y restaurar las copias de seguridad dentro de los límites de retención admitidos.

• Tenga en cuenta las implicaciones del almacenamiento y el costo de aumentar el período de retención de las copias de seguridad. La retención predeterminada es de siete días. Con esta duración, se puede restaurar contenido con una antigüedad máxima de siete días y obtener una copia de seguridad completa, una copia de seguridad diferencial diaria y copias de seguridad de registros transaccionales aproximadamente cada cinco minutos.

• Piense en qué clase de almacenamiento se va a usar en el volumen persistente para las copias de seguridad. Para obtener instrucciones al respecto, consulte Materias de Storage para SQL Managed Instance habilitado para Azure Arc.

• Tenga en cuenta el tamaño del volumen persistente para las copias de seguridad en el contexto del tamaño de datos esperado y el período de retención configurado.

• Para conocer los procedimientos recomendados para el almacenamiento, consulte Materias de Storage para SQL Managed Instance habilitado para Azure Arc.

• Las copias de seguridad siempre se realizan en la réplica principal. Tenga en cuenta los efectos, en cuanto a rendimiento, de los procesos de copia de seguridad y restauración al identificar los recursos que se asignan a su instancia.

• Tenga en cuenta que las restauraciones a un momento dado de una base de datos no pueden sobrescribir las bases de datos existentes. Sin embargo, pueden restaurar datos a una nueva base de datos de la misma instancia.

• Tenga en cuenta los pasos adicionales necesarios para recuperar completamente una base de datos si la aplicación está en línea durante el proceso de restauración.

• Tenga en cuenta los pasos adicionales necesarios para restaurar una base de datos en una instancia de varias réplicas, como se describe en Restauración de una base de datos en una instancia de varias réplicas.

• Determine las herramientas que usan los administradores de bases de datos para configurar y restaurar las copias de seguridad. Para más información, consulte Conexión a SQL Managed Instance habilitado para Azure Arc.

Alta disponibilidad

• Examine los requisitos de disponibilidad de la carga de trabajo y decida cuál es el nivel de servicio más adecuado para la implementación de SQL Managed Instance habilitado para Arc:

  • En el nivel de servicio De uso general, hay una réplica individual disponible y la alta disponibilidad se logra a través de la orquestación de Kubernetes.
  • En el nivel de servicio Crítico para la empresa, Azure SQL Managed Instance habilitado para Azure Arc proporciona un grupo de disponibilidad contenido, además de lo que proporciona de forma nativa la orquestación de Kubernetes.

• Tenga en cuenta los posibles efectos en la empresa del tiempo de inactividad en el nivel de servicio De uso general que podría deberse a la existencia de una sola réplica.

• Tenga en cuenta cuántas réplicas (entre una y tres) se van a implementar en el nivel de servicio Crítico para la empresa.

• Al implementar una instancia en un nivel de servicio Crítico para la empresa con dos o más réplicas, puede configurar las réplicas secundarias como legibles. Decida el número de réplicas secundarias que se van a implementar en el nivel de servicio Crítico para la empresa. Para obtener información sobre cómo cambiar el número, consulte Configuración de réplicas secundarias legibles.

• Tome la decisión de priorizar la coherencia sobre la disponibilidad en el número de réplicas secundarias necesarias para confirmar una transacción en el nivel de servicio Crítico para la empresa mediante el parámetro opcional --sync-secondary-to-commit. Si hay problemas de conectividad entre las réplicas, es posible que la principal no confirme ninguna transacción:

  • En una configuración de dos réplicas, las transacciones se deben confirmar en ambas para que la principal reciba un mensaje de operación correcta.
  • En una configuración de tres réplicas, al menos dos de ellas deben confirmar una transacción para que se devuelva un mensaje de operación correcta.

• Decida si necesita designar una réplica específica como principal. Para obtener información sobre cómo especificar una réplica principal, consulte Réplica principal preferida.

• Decida qué tipo de servicio de Kubernetes va a usar, LoadBalancer o NodePort. Si usa el equilibrador de carga, las aplicaciones pueden volver a conectarse al mismo punto de conexión principal y Kubernetes redirigirá la conexión al nuevo punto de conexión principal. Si usa el puerto de nodo, las aplicaciones deben volver a conectarse a la nueva dirección IP.

Recuperación ante desastres

• Las instancias de SQL Managed Instance habilitado para Azure Arc en sitios de la base de datos geográfica principal y de la base de datos geográfica secundaria debe ser idénticas en cuanto a capacidad y proceso, y se deben desplegar en los mismos niveles de servicio.

• Decida la ubicación en la que desea almacenar los certificados de creación de reflejo al crear la configuración de la recuperación ante desastres a la que pueden acceder los dos clústeres que hospedan la instancia.

• Piense en cómo supervisar el tiempo de inactividad de la instancia principal para decidir cuándo realizar una conmutación por error a la instancia secundaria.

• Cada instancia tiene sus propios puntos de conexión. Piense en la forma en que las aplicaciones van a acceder al punto de conexión principal con una interrupción mínima en caso de conmutación por error.

Recomendaciones de diseño

En las secciones siguientes se enumeran las recomendaciones de diseño para la restauración a un momento dado, la alta disponibilidad y la recuperación ante desastres.

Restauración a un momento dado

• Cuando implemente una nueva instancia de SQL Managed Instance habilitado para Arc, defina siempre la clase de almacenamiento para las copias de seguridad, con el fin de que el valor predeterminado no sea la clase de almacenamiento de datos.

• Use una clase de almacenamiento que admita ReadWriteMany (RWX) para el volumen de las copias de seguridad. Para obtener instrucciones al respecto, consulte Materias de Storage para SQL Managed Instance habilitado para Azure Arc.

• Antes de iniciar una operación de restauración, use el parámetro opcional --dry-run para validar primero si la operación se realizaría correctamente. Para más información, consulte Creación de una base de datos a partir de un momento dado mediante az CLI.

• Cree un proceso para enviar las copias de seguridad que necesiten períodos de retención más largos tanto a Azure como a otro almacenamiento en frío local.

• Supervise el almacenamiento que consumen las copias de seguridad para determinar si puede albergar una retención más larga, si fuera necesario.

Alta disponibilidad

• Realice maniobras regulares para validar la alta disponibilidad de la instancia de SQL Managed Instance habilitada para Arc. Algunos ejemplos de maniobras incluyen la eliminación de un pod en una instancia de De uso general y un error de una réplica en una instancia de Crítico para la empresa.

• En el nivel Crítico para la empresa, implemente una instancia en una configuración de tres réplicas, en lugar de una configuración de dos réplicas para lograr una pérdida de datos casi de cero.

• Para mejorar la disponibilidad, use LoadBalancer como tipo de servicio al implementar una instancia.

• Examine las limitaciones de la alta disponibilidad de SQL Managed Instance habilitado para Azure Arc.

• Examine los modos de disponibilidad admitidos para decidir cuál usar en función de sus necesidades de alta disponibilidad.

• Si implementa una instancia de Crítico para la empresa con varias réplicas, use una de las réplicas secundarias para cargas de trabajo de lectura. La cadena de conexión de la aplicación debe especificar el punto de conexión secundario como agente de escucha del servicio para el redireccionamiento a las réplicas secundarias. Para obtener información sobre los puntos de conexión, consulte Obtención de los puntos de conexión principales y secundarios, y del estado del grupo de disponibilidad.

• Para conocer los procedimientos recomendados para supervisar la disponibilidad de las instancias, consulte Administración y supervisión de SQL Managed Instance habilitado para Azure Arc.

Recuperación ante desastres

• Asegúrese de que las instancias de SQL Managed Instance habilitado para Arc tengan nombres diferentes para los sitios primarios y secundarios, y que el valor de nombre compartido de los sitios sea idéntico.

• Realice maniobras de recuperación ante desastres normales para validar el proceso de conmutación por error.

• Cree un proceso para iniciar las conmutaciones por error manuales y forzadas.

• Para conocer tanto los procedimientos recomendados para supervisar el estado de los clústeres como cuándo se requiere una conmutación por error, consulte Administración y supervisión de SQL Managed Instance habilitado para Azure Arc.

• Defina el registro DNS del nombre compartido del grupo de disponibilidad distribuido en los servidores DNS para no tener que crear manualmente registros DNS durante la conmutación por error.

Pasos siguientes

Para más información sobre el recorrido de nube híbrida y multinube, consulte los siguientes artículos:

• ¿Qué son los servicios de datos habilitados para Azure Arc?
• Información general: continuidad empresarial de SQL Managed Instance habilitado para Azure Arc
• Validación de Kubernetes de los servicios de datos habilitados para Azure Arc
• Administración de la cartera a través de operaciones híbridas y multinube
• Servicios de datos habilitados para Azure Arc para escenarios automatizados con Azure Arc Jumpstart
• Incorporación de la innovación de Azure a entornos híbridos con Azure Arc, una ruta de aprendizaje de Microsoft Learn