Compartir a través de

Introducción a las operaciones de administración en Azure SQL Managed Instance

Se aplica a:Azure SQL Managed Instance

En este artículo se proporciona información general sobre las distintas operaciones que se producen al administrar Azure SQL Managed Instance. Las operaciones de administración son operaciones que se realizan en el back-end al crear, actualizar o eliminar una instancia.

Para obtener una descripción detallada de los pasos y la duración estimada de cada operación de administración, revise Duración de las operaciones de administración.

¿Qué son las operaciones de administración?

La administración de Azure SQL Managed Instance implica las siguientes operaciones:

  • Crear: las operaciones que se producen al crear por primera vez una nueva instancia administrada de SQL. Esto incluye la creación del grupo de máquinas virtuales subyacentes e implementación del proceso del motor de base de datos de SQL.
  • Actualización: las operaciones que se producen al cambiar las propiedades de una instancia administrada de SQL existente, como escalar el proceso o el almacenamiento, cambiar el nivel de servicio o actualizar la configuración de la instancia. La realización de actualizaciones suele implicar cambiar el tamaño del grupo de máquinas virtuales, así como la propagación de datos y, a continuación, conmutar por error a un nuevo proceso del motor de base de datos de SQL.
  • Delete: Operaciones que se producen al eliminar una instancia administrada de SQL existente, incluida la limpieza de recursos, como el grupo de máquinas virtuales asociado a la instancia.

Para obtener una descripción detallada de los pasos y la duración estimada de cada operación de administración, revise Duración de las operaciones de administración.

Las operaciones de administración de SQL Managed Instance se realizan a través de los siguientes procesos subyacentes:

  • Operaciones de grupo de máquina virtual (VM): operaciones que implican la creación y administración del grupo de máquinas virtuales subyacente que hospedan la instancia administrada de SQL. Esto incluye cambiar el tamaño del grupo de máquinas virtuales, crear nuevos grupos de máquinas virtuales y administrar las máquinas virtuales dentro de esos grupos.
  • Propagación: inicialización y sincronización de datos entre procesos del motor de base de datos de SQL, normalmente para prepararse para una conmutación por error.
  • Conmutación por error: las operaciones implicadas en la conmutación por error del tráfico a otro proceso del motor de base de datos de SQL, ya sea en el mismo o en un nuevo grupo de máquinas virtuales.

Operaciones de grupo de máquinas virtuales

Para admitir las implementaciones dentro de máquinas virtuales de Azure y proporcionar aislamiento y seguridad para los clientes, SQL Managed Instance depende de los clústeres virtuales. El clúster virtual representa un conjunto dedicado de máquinas virtuales aisladas implementadas dentro de la subred de la red virtual y organizadas dentro de los grupos de máquinas virtuales. Básicamente, cada instancia administrada de SQL implementada en una subred vacía da como resultado un nuevo clúster virtual que compila el primer grupo de máquinas virtuales.

Las operaciones de administración posteriores en instancias administradas de SQL pueden afectar a los grupos de máquinas virtuales subyacentes. Los cambios que afectan a los grupos de máquinas virtuales subyacentes pueden afectar a la duración de las operaciones de administración, ya que la implementación de más máquinas virtuales en el clúster virtual conlleva una sobrecarga que debe tener en cuenta al planear nuevas implementaciones o actualizaciones en instancias existentes.

Para obtener información detallada sobre la arquitectura del clúster virtual, consulte Arquitectura de clúster virtual.

Inicialización

La propagación desempeña un papel fundamental en el funcionamiento de Azure SQL Managed Instance, especialmente durante la instalación y replicación de bases de datos. La propagación es el proceso que inicializa y sincroniza los datos entre los procesos del motor de base de datos DE SQL, que es una parte fundamental de la administración de instancias. Aunque a menudo el paso más lento en operaciones largas pero correctas, la propagación sirve como piedra angular para establecer un entorno de instancia administrada de SQL correcto y funcional.

Para obtener una duración estimada de las operaciones de propagación, consulte Duración de las operaciones de administración.

El proceso de propagación normalmente implica las siguientes fases, independientemente del nivel de servicio:

  • Inicialización: el sistema identifica la base de datos de origen y destino e inicia varias tareas que preparan los procesos del motor de base de datos SQL para la transferencia de datos.
  • Transferencia de datos: los paquetes de datos reales se transfieren del origen al proceso del motor de base de datos SQL de destino, que incluye una copia completa o parcial de la base de datos, en función del escenario.
  • Sincronización: una vez completada la transferencia de datos inicial, el sistema sincroniza las actualizaciones o cambios posteriores a través de la replicación de bloques de registro de transacciones para garantizar la integridad de los datos.
  • Validación y finalización: el proceso se finaliza y el proceso de motor de base de datos SQL de destino se valida para confirmar la replicación y propagación correctas. La conmutación por error se produce para que el tráfico se enrute al nuevo proceso del motor de base de datos de SQL.

No hay propagación de datos en el nivel de servicio De uso general , excepto cuando se cambia el nivel de servicio al nivel de servicio Crítico para la empresa . Las operaciones de administración en el nivel de servicio De uso general implican desasociar el almacenamiento remoto del antiguo proceso del motor de base de datos de SQL y adjuntarlo al nuevo proceso del motor de base de datos de SQL.

Por el contrario, el nivel de servicio Crítico para la empresa , diseñado para cargas de trabajo de alto rendimiento, requiere almacenamiento local y la dependencia de las capas de proceso y almacenamiento. Por lo tanto, casi todas las operaciones y escenarios de este nivel de servicio requieren propagación para garantizar la disponibilidad y la coherencia de los datos.

Si se desencadena o no la propagación depende del escenario y el nivel de servicio concretos, como:

  • Niveles de servicio de uso general y de uso general de próxima generación :
    • Cambio al nivel de servicio Crítico para la empresa : los datos se deben transferir desde el almacenamiento remoto al almacenamiento local que se usa en el nivel de servicio De uso general.
    • Habilitación o deshabilitación de la redundancia de zona : los datos se deben copiar en o desde las regiones con redundancia de zona.
  • Nivel de servicio Crítico para la empresa:
    • Escalado de almacenamiento: dado que el almacenamiento está conectado físicamente al equipo local, cada cambio de almacenamiento requiere la creación de un nuevo grupo de máquinas virtuales, por lo que los datos deben transferirse de la máquina antigua a la nueva (en las 4 réplicas).
    • Escalado de núcleos virtuales: cada operación de escalado de proceso requiere la creación de un nuevo grupo de máquinas virtuales, por lo que los datos deben copiarse de la máquina antigua a la nueva (en las 4 réplicas).
    • Cambio de la ventana de hardware o mantenimiento: si ya existe un grupo de máquinas virtuales dentro de la subred con una configuración coincidente, se cambia el tamaño del grupo de máquinas virtuales. Si se trata de una nueva configuración, se crea un nuevo grupo de máquinas virtuales. Los datos se deben copiar del grupo de máquinas virtuales antiguo al nuevo grupo de máquinas virtuales (en las 4 réplicas).
    • Cambio del nivel de servicio: los datos se deben copiar del almacenamiento local al almacenamiento remoto que se usa en el nivel de servicio De uso general.
    • Habilitación o deshabilitación de la redundancia de zona : los datos se deben copiar en o desde las regiones con redundancia de zona.

Velocidades de propagación

Los siguientes factores afectan a la duración del proceso de propagación:

  • Tamaño de la base de datos: las bases de datos más grandes requieren más tiempo para transferir datos y sincronizarse en los procesos del motor de base de datos de SQL.
  • Dependencias de red: el ancho de banda de red y la latencia pueden influir significativamente en las velocidades de propagación.
  • Operaciones de copia de seguridad y restauración: las operaciones de copia de seguridad en curso en el proceso del motor de base de datos SQL de origen pueden influir en la preparación de los datos para enviarlos a otro proceso del motor de base de datos de SQL.
  • Carga de trabajo de instancia: la carga de trabajo de instancia durante la propagación puede provocar la limitación y prolongar gravemente el proceso.

Aunque la mayoría de estos factores están fuera del control, puede administrar el tráfico de instancias para optimizar significativamente las velocidades de propagación. La propagación usa los mismos recursos informáticos de instancia que administran el tráfico de instancia. El tráfico pesado durante la propagación puede reducir la disponibilidad de núcleos virtuales, lo que provoca una capacidad insuficiente para el proceso de propagación, lo que provoca una limitación.

El tráfico elevado durante la propagación puede afectar a la sincronización, ya que la propagación está diseñada para empaquetar y transferir todos los datos almacenados actualmente en una sola operación. Los cambios de datos posteriores en el proceso anterior del motor de base de datos de SQL que llegan después de iniciarse la propagación deben sincronizarse con el nuevo proceso del motor de base de datos sql incrementalmente a través de la replicación del bloque de registro de transacciones antes de que se pueda producir la conmutación por error. Si la instancia está bajo mucha carga, la propagación podría tener dificultades para mantenerse al día con los datos entrantes, lo que provoca retrasos y posibles errores en la fase de sincronización. El tráfico elevado continuo en el antiguo proceso del motor de base de datos de SQL después de iniciar la propagación puede provocar una situación en la que la fase de sincronización nunca se completa, ya que los nuevos datos siguen llegando y deben transferirse. Esto puede dar lugar a un ciclo perpetuo de transferencia de datos que impide la conmutación por error al nuevo proceso del motor de base de datos de SQL.

Para obtener una duración estimada de las operaciones de propagación, consulte Duración de las operaciones de administración.

Infraestructura y avisos de Azure

La propagación es un proceso que no se puede cuantificar o predecir estrictamente, ya que se basa en los servicios compartidos de Azure. Las operaciones de transferencia y propagación de datos dependen de varios servicios e infraestructuras internos de Azure, que se comparten en todo el ecosistema de Azure. Muchos otros servicios no relacionados de Azure usan estos servicios. Todos los servicios del ecosistema de Azure compiten por los recursos disponibles, lo que conduce a fluctuaciones en la disponibilidad momentánea influenciada por varios factores. Aunque Microsoft puede proporcionar un rango en el que funciona la capacidad de infraestructura, realizar predicciones precisas es difícil.

Conmutación por error

La conmutación por error de instancia es el momento en que el tráfico se enruta desde un proceso antiguo del motor de base de datos de SQL a un nuevo proceso del motor de base de datos de SQL dentro del grupo de nodos de un grupo de máquinas virtuales que abarca la instancia administrada de SQL. La conmutación por error es una parte fundamental de la mayoría de las operaciones de administración, especialmente al actualizar una instancia. El breve momento de las conexiones interrumpidas mientras se redirige el tráfico al nuevo proceso del motor de base de datos de SQL se conoce como conmutación por error.

La instancia solo no está disponible durante la conmutación por error, cuando el tráfico se vuelve a enrutar al nuevo proceso del motor de base de datos de SQL. En el nivel de servicio Crítico para la empresa , la instancia no está disponible durante hasta 20 segundos, mientras que en el nivel de servicio De uso general , la instancia puede no estar disponible durante hasta 2 minutos. Las operaciones de back-end que se producen para prepararse para la conmutación por error debido a una operación de administración, como la resegado de bases de datos en el nivel de servicio Crítico para la empresa , se producen en segundo plano y no afectan a la disponibilidad de la instancia.

Las diferencias arquitectónicas entre los niveles de servicio se explican en profundidad en la disponibilidad.

Impacto de las operaciones de administración

Las operaciones de administración en una instancia administrada de SQL pueden afectar a las operaciones de administración de otras instancias colocadas dentro de la misma subred:

  • Las operaciones de restauración de larga duración en un clúster virtual ponen otras operaciones en el mismo clúster virtual en espera, como las operaciones de creación o escalado.

    Ejemplo: Si hay una operación de restauración de larga duración y también una solicitud de escalado que reduce el grupo de máquinas virtuales, la solicitud de reducción tarda más tiempo en completarse, ya que espera a que finalice la operación de restauración antes de poder continuar.

  • Una operación de creación o escalado de instancias posteriores se mantiene en espera mediante una creación de instancia iniciada previamente o una escala de instancia que inició un cambio de tamaño del grupo de máquinas virtuales.

    Ejemplo: Si hay varias solicitudes de creación o escala en la misma subred en el mismo grupo de máquinas virtuales y una de ellas inicia un cambio de tamaño de grupo de máquinas virtuales, todas las solicitudes enviadas 5+ minutos después de que la solicitud de operación inicial dure más de lo esperado, ya que estas solicitudes deben esperar a que se complete el cambio de tamaño antes de reanudarse.

  • Las operaciones de creación y escalado enviadas en una ventana de 1 minuto se procesan por lotes y se ejecutan en paralelo.

    Ejemplo: Solo se realiza un cambio de tamaño de clúster virtual para todas las operaciones enviadas en un período de 1 minuto (medido desde el momento en que se envía la primera solicitud de operación). Si se envía otra solicitud más de 1 minuto después de enviar la primera, espera a que se complete el cambio de tamaño del clúster virtual antes de que se inicie la ejecución.

Importante

Las operaciones de administración que se mantienen en espera debido a otra operación en curso se reanudan automáticamente una vez que se cumplen las condiciones para continuar. No se necesita ninguna acción del usuario para reanudar las operaciones de administración temporalmente en pausa.

Supervisión de las operaciones de administración

Para obtener información sobre cómo supervisar el estado y el progreso de la operación de administración, consulte Supervisión de las operaciones de administración de Azure SQL Managed Instance.

Cancelación de las operaciones de administración

Para obtener información sobre cómo cancelar la operación de administración, consulte Cancelación de operaciones de administración de Azure SQL Managed Instance.

Contenido relacionado