Compartir a través de

Confiabilidad en Azure SQL Managed Instance

Azure SQL Managed Instance es un motor de base de datos de plataforma como servicio (PaaS) totalmente administrado. Proporciona casi 100% compatibilidad de características con SQL Server. Azure SQL Managed Instance controla la mayoría de las funciones de administración de bases de datos, como la actualización, la aplicación de revisiones, las copias de seguridad y la supervisión sin intervención del usuario. Se ejecuta en la versión estable más reciente del motor de base de datos de SQL Server y un sistema operativo revisado con alta disponibilidad integrada.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Azure SQL Managed Instance sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones de regiones. También se describe cómo puede usar copias de seguridad para recuperarse de otros tipos de problemas, cómo controlar el mantenimiento del servicio y resaltar cierta información clave sobre el contrato de nivel de servicio (SLA) de Azure SQL Managed Instance.

Recomendaciones de implementación de producción para la confiabilidad

Para la mayoría de las implementaciones de producción de SQL Managed Instance, tenga en cuenta las siguientes recomendaciones:

Introducción a la arquitectura de confiabilidad

Las instancias administradas de SQL de uso general se ejecutan en un único nodo que administra Azure Service Fabric . Cada vez que se actualiza el motor de base de datos o el sistema operativo, o se detecta un error, SQL Managed Instance funciona con Service Fabric para mover el proceso del motor de base de datos sin estado a otro nodo de proceso sin estado que tenga suficiente capacidad libre. Los archivos de base de datos se almacenan en Azure Blob Storage, que tiene características de redundancia integradas. Los archivos de datos y registro se desasocian del nodo de proceso original y se adjuntan al proceso del motor de base de datos recién inicializado.

Las instancias administradas de SQL críticas para la empresa usan varias réplicas en un clúster. El clúster incluye dos tipos de réplicas:

  • Una única réplica principal a la que se puede acceder para cargas de trabajo de cliente de lectura y escritura

  • Hasta cinco réplicas secundarias (proceso y almacenamiento) que contienen copias de datos

La réplica principal inserta continua y secuencialmente los cambios en las réplicas secundarias, lo que garantiza que los datos se conserven en un número suficiente de réplicas secundarias antes de confirmar cada transacción. Este proceso garantiza que si la réplica principal o una réplica secundaria legible deja de estar disponible, siempre hay una réplica totalmente sincronizada al que conmutar por error.

SQL Managed Instance y Service Fabric inician la conmutación por error entre réplicas. Después de que una réplica secundaria se convierta en la nueva réplica principal, se crea otra réplica secundaria para asegurarse de que el clúster tiene un número suficiente de réplicas para mantener el cuórum. Una vez completada la conmutación por error, las conexiones de Azure SQL se redirigen automáticamente a la nueva réplica principal o a la réplica secundaria legible en función de la cadena de conexión.

Redundancia

De forma predeterminada, SQL Managed Instance logra redundancia mediante la propagación de nodos de proceso y datos a lo largo de un único centro de datos de la región primaria. Este enfoque protege los datos durante los siguientes tiempos de inactividad esperados e inesperados:

  • Operaciones de administración iniciadas por el cliente que dan lugar a un breve tiempo de inactividad

  • Operaciones de mantenimiento de servicio

  • Errores de red o energía a pequeña escala

  • Problemas y interrupciones del centro de datos que implican los siguientes componentes:

    • El bastidor en el que se ejecutan las máquinas que impulsan el servicio

    • La máquina física que hospeda la máquina virtual (VM) que ejecuta el motor de base de datos SQL.

    • Máquina virtual que ejecuta el motor de base de datos de SQL

  • Problemas con el motor de base de datos sql

  • Posibles interrupciones localizadas no planeadas

Para obtener más información sobre cómo SQL Managed Instance proporciona redundancia, consulte Disponibilidad a través de redundancia de zona y local.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Sql Managed Instance controla automáticamente las tareas de mantenimiento críticas, como la aplicación de revisiones, las copias de seguridad y las actualizaciones del motor de base de datos de SQL y Windows. También controla eventos no planeados, como errores de red, software o hardware subyacentes. Sql Managed Instance puede recuperarse rápidamente incluso en las circunstancias más críticas, lo que garantiza que los datos estén siempre disponibles. La mayoría de los usuarios no observan que las actualizaciones se realizan continuamente.

Por lo general, cuando aplique revisiones a una instancia o cuando la conmute por error, el tiempo de inactividad tiene un efecto mínimo si usa la lógica de reintento en la aplicación. Puede probar la resistencia de la aplicación a errores transitorios.

Resistencia a errores de zona de disponibilidad

Nota:

La redundancia de zona no está disponible actualmente para el nivel de servicio de próxima generación de uso general.

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Al habilitar una configuración con redundancia de zona, puede asegurarse de que la instancia administrada de SQL sea resistente a un gran conjunto de errores, incluidas interrupciones catastróficas del centro de datos, sin cambios en la lógica de la aplicación.

SQL Managed Instance logra la redundancia de zona al colocar nodos de cómputo sin estado en diferentes zonas de disponibilidad. Se basa en ZRS con estado que está asociado al nodo que actualmente contiene el proceso activo del motor de base de datos SQL. Si se produce una interrupción, el proceso del motor de base de datos SQL se activa en uno de los nodos de cómputo sin estado, que luego accede a los datos en el almacenamiento con estado.

Sql Managed Instance logra la redundancia de zona colocando réplicas de la instancia administrada de SQL en varias zonas de disponibilidad. Para eliminar un punto de error único, también se duplica el anillo de control en varias zonas. El tráfico del plano de control se enruta a un equilibrador de carga que también se implementa en zonas de disponibilidad. Azure Traffic Manager controla el enrutamiento del tráfico desde el plano de control al equilibrador de carga.

Requisitos

  • Compatibilidad con regiones: La redundancia de zona para SQL Managed Instance se admite en regiones seleccionadas. Para obtener más información, consulte Regiones admitidas.

  • Redundancia de almacenamiento de copia de seguridad: Para habilitar la redundancia de zona para la instancia administrada de SQL, establezca la redundancia del almacenamiento de copia de seguridad en ZRS o almacenamiento con redundancia de zona geográfica (GZRS).

Cost

Al habilitar la redundancia de zona, hay un costo adicional para la instancia administrada de SQL y para las copias de seguridad con redundancia de zona. Para obtener más información, consulte el apartado Precios.

Puede ahorrar dinero confirmando el uso de recursos de proceso a una tarifa con descuento durante un período de tiempo, que incluye instancias con redundancia de zona en el nivel de servicio Crítico para la empresa. Para obtener más información, consulte Reservas para SQL Managed Instance.

Configurar soporte de zonas de disponibilidad

En esta sección se explica cómo configurar la compatibilidad con zonas de disponibilidad para las instancias administradas de SQL:

  • Habilite la redundancia de zona: Para obtener información sobre cómo configurar la redundancia de zona en instancias nuevas y existentes, consulte Configuración de la redundancia de zona.

    Todas las operaciones de escalado de SQL Managed Instance, incluida la habilitación de la redundancia de zona, son operaciones en línea y requieren un tiempo de inactividad mínimo o nulo. Para obtener más información, consulte Duración de las operaciones de administración.

  • Deshabilitar la redundancia de zona: puede deshabilitar la redundancia de zona siguiendo los mismos pasos para habilitar la redundancia de zona. Este proceso es una operación en línea similar a una actualización normal del objetivo de nivel de servicio. Al final del proceso, la instancia se migra de la infraestructura con redundancia de zona a la infraestructura de una sola zona.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando la instancia administrada de SQL está configurada para que sea redundante de zona y todas las zonas de disponibilidad estén operativas:

  • Enrutamiento de tráfico entre zonas: Durante las operaciones normales, las solicitudes se enrutan al nodo que ejecuta la capa de proceso de SQL Managed Instance.

  • Replicación de datos entre zonas: Los archivos de base de datos se almacenan en Azure Storage mediante ZRS, que se adjunta al nodo que contiene actualmente el proceso activo del motor de base de datos de SQL.

    Las operaciones de escritura son sincrónicas y no se consideran completadas hasta que los datos se replican correctamente en todas las zonas de disponibilidad. Esta replicación sincrónica garantiza una fuerte coherencia y cero pérdida de datos durante los errores de zona. Sin embargo, podría dar lugar a una latencia de escritura ligeramente mayor en comparación con el almacenamiento con redundancia local.

  • Enrutamiento de tráfico entre zonas: durante las operaciones normales, las solicitudes se enrutan a la réplica principal de la instancia administrada de SQL.

  • Replicación de datos entre zonas: la réplica principal inserta continua y secuencialmente los cambios en las réplicas secundarias en diferentes zonas de disponibilidad. Este proceso garantiza que los datos se conserven en un número suficiente de réplicas secundarias antes de confirmar cada transacción. Esas réplicas se encuentran en diferentes zonas de disponibilidad. Este proceso garantiza que si la réplica principal o una réplica secundaria legible deja de estar disponible por alguna razón, siempre hay una réplica totalmente sincronizada al que conmutar por error.

    Dado que las instancias con redundancia de zona tienen réplicas en diferentes centros de datos con cierta distancia entre ellos, el aumento de la latencia de red podría aumentar el tiempo de confirmación de la transacción. Este aumento puede afectar al rendimiento de algunas cargas de trabajo de procesamiento de transacciones en línea (OLTP). La mayoría de las aplicaciones no son sensibles a esta latencia adicional.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando la instancia administrada de SQL está configurada para que sea redundante de zona y una o varias zonas de disponibilidad no están disponibles:

  • Detección y respuesta: Instancia administrada de SQL es responsable de detectar y responder a un error en una zona de disponibilidad. No es necesario hacer nada para iniciar una conmutación por error de la zona.
  • Solicitudes activas: Cuando una zona de disponibilidad no está disponible, las solicitudes que se procesan en la zona de disponibilidad defectuosa se finalizan y se deben reintentar. Para que las aplicaciones sean resistentes a estos tipos de problemas, consulte Guía sobre resistencia a errores transitorios .

  • Reenrutamiento del tráfico: Sql Managed Instance funciona con Service Fabric para mover el motor de base de datos a un nodo de proceso sin estado adecuado que se encuentra en una zona de disponibilidad diferente y tiene suficiente capacidad libre. Una vez completada la conmutación por error, las nuevas conexiones se redirigen automáticamente al nuevo nodo de proceso principal.

    Una carga de trabajo pesada podría experimentar cierta degradación del rendimiento durante la transición de un nodo de proceso al otro porque el nuevo proceso del motor de base de datos comienza con una caché inactiva.

  • Reenrutamiento del tráfico: Instancia administrada de SQL funciona con Service Fabric para seleccionar una réplica adecuada en otra zona de disponibilidad para convertirse en la réplica principal. Después de que una réplica secundaria se convierta en la nueva réplica principal, se crea otra réplica secundaria para asegurarse de que el clúster tiene un número suficiente de réplicas para mantener el cuórum. Una vez completada la conmutación por error, las nuevas conexiones se redirigen automáticamente a la nueva réplica principal o a la réplica secundaria legible en función de la cadena de conexión.

  • Tiempo de inactividad esperado: puede haber una pequeña cantidad de tiempo de inactividad durante una conmutación por error de zona de disponibilidad. El tiempo de inactividad suele ser inferior a 30 segundos, que la aplicación debe tolerar si sigue las instrucciones de resistencia a errores transitorios .

  • Pérdida de datos esperada: no se espera ninguna pérdida de datos para las transacciones confirmadas durante una conmutación por error de zona de disponibilidad. Es necesario reintentar las transacciones en curso.

Recuperación de zona

Cuando se recupera la zona de disponibilidad, SQL Managed Instance funciona con Service Fabric para restaurar operaciones en la zona recuperada. No se requiere intervención del cliente.

Prueba de fallos de zona

La plataforma de SQL Managed Instance administra el enrutamiento del tráfico, la conmutación por error y la conmutación por recuperación para planes de instancias con redundancia de zona. Dado que esta característica está totalmente administrada, no es necesario iniciar ni validar los procesos de error de zona de disponibilidad. Sin embargo, puede validar la gestión de fallos de su aplicación.

Resistencia a errores en toda la región

Una instancia administrada de SQL individual se implementa dentro de una sola región. Sin embargo, puede implementar una instancia administrada de SQL secundaria en una región de Azure independiente y configurar un grupo de conmutación por error.

Grupos de conmutación por error

Los grupos de conmutación por error replican automáticamente de forma geográfica sus datos y pueden conmutar por error automáticamente o manualmente si se produce un error regional, en función de la directiva de conmutación por error.

En esta sección se resume la información clave sobre los grupos de conmutación por error, pero es importante revisar la introducción a los grupos de conmutación por error y los procedimientos recomendados para obtener más información sobre cómo funcionan y cómo configurarlos.

Directivas de conmutación por error

Al crear un grupo de conmutación por error, seleccione la directiva de conmutación por error, que especifica quién es responsable de detectar una interrupción y realizar una conmutación por error. Puede configurar dos tipos de directivas de conmutación por error:

  • Conmutación por error administrada por el cliente (recomendada): Cuando se usa una directiva de conmutación por error administrada por el cliente, puede decidir si se debe realizar una conmutación por error, que no incurre en pérdida de datos o una conmutación por error forzada, lo que podría suponer una pérdida de datos. La conmutación por error forzada se utiliza como método de recuperación durante las interrupciones del servicio cuando no se puede acceder a la instancia principal.

  • Conmutación por error administrada por Microsoft: La conmutación por error administrada por Microsoft solo se usa en situaciones excepcionales para desencadenar una conmutación por error forzada.

Importante

Utilice las opciones de conmutación por error administradas por el cliente para desarrollar, probar e implementar tus planes de recuperación ante desastres. No confíe en la conmutación por error administrada por Microsoft, que solo se puede utilizar en circunstancias extremas. Es probable que se haya iniciado una conmutación por error administrada por Microsoft para toda una región. No se puede iniciar para grupos de conmutación por error individuales, instancias administradas de SQL, suscripciones o clientes. La conmutación por error puede producirse en momentos diferentes para distintos servicios de Azure. Recomendamos que utilice la conmutación por error administrada por el cliente.

Soporte para regiones

Puede seleccionar cualquier región de Azure para las instancias administradas de SQL en el grupo de conmutación por error. Debido a la alta latencia de las redes de área extensa, la replicación geográfica usa un mecanismo de replicación asincrónico. Para reducir los retrasos de red, seleccione regiones que tengan conexiones de baja latencia. Para más información sobre la latencia entre regiones de Azure, consulte Estadísticas de latencia de ida y vuelta de red de Azure.

Cost

Al crear varias instancias administradas de SQL en regiones diferentes, se le factura cada instancia administrada de SQL.

Sin embargo, si la instancia secundaria no tiene ninguna carga de trabajo de lectura o aplicaciones conectadas a ella, puede ahorrar en costes de licencias mediante la designación de la réplica como una instancia en espera. Para más información, consulte Configuración de una réplica en espera sin licencia para SQL Managed Instance.

Para más información sobre los precios de SQL Managed Instance, consulte Información de precios del servicio.

Configuración de la compatibilidad con varias regiones

Para obtener información sobre cómo configurar un grupo de conmutación por error, consulte Configuración de un grupo de conmutación por error para SQL Managed Instance.

Planeamiento y administración de capacidad

Durante una conmutación por error, el tráfico se redirige a una instancia administrada de SQL secundaria. Es importante que la instancia administrada de SQL secundaria esté lista para recibir tráfico. Cree una instancia administrada de SQL secundaria con el mismo nivel de servicio, generación de hardware y tamaño de proceso que la instancia principal.

Para más información sobre el escalado de instancias administradas de SQL en un grupo de conmutación por error, consulte Escalado de instancias.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar cuando las instancias administradas de SQL están configuradas para usar grupos de conmutación por error de varias regiones y todas las regiones están operativas:

  • Enrutamiento del tráfico entre regiones: durante las operaciones normales, las solicitudes de lectura y escritura van a la instancia principal única de la región primaria.

    Los grupos de conmutación por error también proporcionan un punto de conexión de agente de escucha de solo lectura independiente. Durante las operaciones normales, este punto de conexión se conecta a la instancia secundaria para enrutar el tráfico de solo lectura especificado en la cadena de conexión.

    Para obtener más información sobre cómo los grupos de conmutación por error envían tráfico a cada instancia y cómo puede dirigir el tráfico a un punto de conexión del oyente de solo lectura, consulte Introducción a los grupos de conmutación por error y procedimientos recomendados.

  • Replicación de datos entre regiones: de manera predeterminada, los datos se replican de forma asincrónica desde la instancia principal a la instancia administrada de SQL secundaria.

    Dado que la replicación geográfica es asincrónica, si realiza una conmutación por error forzada, es posible experimentar la pérdida de datos. Puede supervisar el retraso de replicación para comprender la posible pérdida de datos durante una conmutación por error forzada. Para más información, consulte lista de comprobación de recuperación ante desastres.

    Si necesita eliminar la pérdida de datos de la replicación asincrónica durante las conmutaciones por error, configure la aplicación para bloquear el subproceso de llamada hasta que confirme que la última transacción confirmada se ha transmitido y protegido en el registro de transacciones de la base de datos secundaria. Este enfoque requiere desarrollo personalizado y reduce el rendimiento de la aplicación. Para obtener más información, consulte Evitar la pérdida de datos críticos.

Comportamiento durante una falla de región

En esta sección se describe qué esperar cuando las instancias administradas de SQL están configuradas para usar grupos de conmutación por error de varias regiones y hay una interrupción en la región primaria:

  • Detección y respuesta: la responsabilidad de la detección y respuesta depende de la directiva de conmutación por error utilizada por el grupo de conmutación por error.

    • Directiva de conmutación por error administrada por el cliente: es responsable de detectar el error en una región y desencadenar una conmutación por error o una conmutación por error forzada a la instancia secundaria del grupo de conmutación por error.

      Si realiza una conmutación por error, SQL Managed Instance espera a que los datos se sincronicen con la instancia secundaria antes de realizar el procedimiento de conmutación por error.

      Si realiza una conmutación por error forzada, SQL Managed Instance cambia inmediatamente la instancia secundaria al rol principal sin esperar a que los cambios recientes se propaguen desde la principal. Este tipo de conmutación por error puede incurrir en pérdida de datos.

    • Directiva de conmutación por error administrada por Microsoft: las conmutaciones por error administradas por Microsoft se realizan en circunstancias excepcionales. Cuando Microsoft desencadena una conmutación por error, el grupo de conmutación por error realiza automáticamente una conmutación por error forzada a la instancia secundaria del grupo de conmutación por error. Sin embargo, se recomienda usar una directiva de conmutación por error administrada por el cliente para cargas de trabajo de producción para que pueda controlar cuándo se produce la conmutación por error.

  • Solicitudes activas: Cuando se produce una conmutación por error, se finalizan las solicitudes que se están procesando y se deben reintentar. Para que las aplicaciones sean resistentes a estos tipos de problemas, consulte Resistencia a errores transitorios.

  • Pérdida de datos esperada: La cantidad de pérdida de datos depende de cómo configure la aplicación. Para más información, consulte Introducción a los grupos de conmutación por error y procedimientos recomendados.

  • Tiempo de inactividad esperado: puede haber una pequeña cantidad de tiempo de inactividad durante una conmutación por error de un grupo de conmutación por error. El tiempo de inactividad suele ser inferior a 60 segundos.

  • Reenrutamiento del tráfico: Una vez que el grupo de conmutación por error completa el proceso de conmutación por error, el tráfico de lectura y escritura se enruta automáticamente a la nueva instancia principal. Si las aplicaciones usan los puntos de conexión del grupo de conmutación por error en sus cadenas de conexión, no necesitan modificar sus cadenas de conexión después de la conmutación por error.

Recuperación de regiones

Los grupos de conmutación por error no conmutan automáticamente por recuperación a la región primaria cuando se restauran y, por tanto, es su responsabilidad iniciar una conmutación por recuperación.

Prueba de fallos de región

Puede probar la conmutación por error de un grupo de conmutación por error.

Probar un grupo de conmutación por error es solo una parte de la realización de un simulacro de recuperación ante desastres. Para más información, consulte Realización de simulacros de DR.

Copias de seguridad y restauración

Realice copias de seguridad de las bases de datos para protegerse frente a diversos riesgos, incluida la pérdida de datos. Las copias de seguridad se pueden restaurar para recuperarse de pérdida accidental de datos, daños u otros problemas. Las copias de seguridad no son lo mismo que la replicación geográfica, y tienen diferentes propósitos y mitigan distintos riesgos.

Instancia administrada de SQL realiza automáticamente copias de seguridad completas, diferenciales y del registro de transacciones de las bases de datos. Para obtener más información sobre los tipos de copias de seguridad, su frecuencia, funcionalidades de restauración, costos de almacenamiento y cifrado de copia de seguridad, consulte Copias de seguridad automatizadas en SQL Managed Instance.

SQL Managed Instance proporciona copias de seguridad automatizadas integradas y también admite copias de seguridad de solo copia iniciadas por el usuario para bases de datos de usuario. Para más información, consulte Copias de seguridad de solo copia.

Replicación de copia de seguridad

Al configurar copias de seguridad automatizadas para la instancia administrada de SQL, puede especificar cómo se deben replicar las copias de seguridad. Las copias de seguridad configuradas para almacenarse en ZRS tienen un mayor nivel de resistencia. Se recomienda configurar las copias de seguridad para que usen uno de los siguientes tipos de almacenamiento:

  • ZRS para la resistencia dentro de la región, si la región tiene zonas de disponibilidad

  • GZRS para mejorar la resistencia de las copias de seguridad entre regiones si la región tiene zonas de disponibilidad y está emparejada con otra región

  • GRS si la región no admite zonas de disponibilidad, pero tiene una región emparejada

Para más información sobre los distintos tipos de almacenamiento y sus funcionalidades, consulte Redundancia de almacenamiento de respaldo.

Restauración geográfica

La funcionalidad de restauración geográfica es una solución básica de recuperación ante desastres que permite restaurar copias de seguridad en otra región de Azure. La copia de seguridad geográfica normalmente requiere una cantidad significativa de tiempo de inactividad y pérdida de datos. Para lograr niveles más altos de capacidad de recuperación si se produce una interrupción regional, debe configurar grupos de conmutación por error.

Si usa la restauración geográfica, debe tener en cuenta cómo hacer que las copias de seguridad estén disponibles en la región secundaria:

  • Si la región primaria está emparejada, use el almacenamiento de copia de seguridad de GZRS o GRS para admitir la restauración geográfica en la región emparejada.

  • Si la región primaria no está emparejada, puede crear una solución personalizada para replicar las copias de seguridad en otra región. Considere la posibilidad de usar copias de seguridad de solo copia iniciadas por el usuario y almacenarlas en una cuenta de almacenamiento que use la replicación de objetos de blob para replicar en una cuenta de almacenamiento de otra región.

Resistencia al mantenimiento del servicio

Cuando SQL Managed Instance realiza el mantenimiento en la instancia, la instancia administrada de SQL permanece totalmente disponible, pero puede estar sujeta a reconfiguraciones breves. Las aplicaciones cliente pueden observar breves interrupciones de conectividad cuando se produce un evento de mantenimiento. Las aplicaciones cliente deben seguir las instrucciones de resistencia a errores transitorios para minimizar los efectos.

Instancia administrada de SQL permite especificar una ventana de mantenimiento que se usa generalmente para las actualizaciones del servicio y otras operaciones de mantenimiento. La configuración de una ventana de mantenimiento puede ayudarle a minimizar los efectos secundarios, como las conmutaciones automáticas por error, durante el horario comercial. También puede recibir notificaciones anticipadas del mantenimiento planeado.

Para obtener más información, consulte Ventana de mantenimiento en SQL Managed Instance.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Para SQL Managed Instance, el Acuerdo de Nivel de Servicio de disponibilidad solo se aplica cuando la red virtual de Azure está configurada correctamente para que no impida el tráfico de administración. Esta configuración incluye el tamaño de subred, los grupos de seguridad de red (NSG), las rutas definidas por el usuario (UDR), la configuración de DNS y otros recursos que afectan a la administración y el uso de recursos de red. Para obtener más información sobre la configuración de red necesaria para SQL Managed Instance, consulte Requisitos de red.

Contenido relacionado

  • Last updated on