Compartir a través de


Instancias de clúster de conmutación por error en SQL Server en Máquinas Virtuales de Azure

Applies to:SQL Server en Máquina Virtual de Azure

En este artículo se presentan las diferencias de características al trabajar con instancias de clúster de conmutación por error (FCI) para SQL Server en máquinas virtuales de Azure.

Para empezar, prepare la máquina virtual.

Información general

SQL Server en máquinas virtuales de Azure usa la funcionalidad de Windows Server clústeres de conmutación por error (WSFC) para proporcionar alta disponibilidad local a través de redundancia a nivel de instancia de servidor: una instancia de conmutación por error de clúster. Una FCI es una sola instancia de SQL Server que se instala en los nodos WSFC (o simplemente en el clúster) y, posiblemente, en varias subredes. En la red, una FCI parece ser una sola instancia de SQL Server que se ejecuta en un único equipo. Pero la FCI proporciona conmutación por error de un nodo WSFC a otro si el nodo actual deja de estar disponible.

El resto de este artículo se centra en las diferencias de las instancias de clúster de conmutación por error cuando se usan con SQL Server en máquinas virtuales de Azure. Para obtener más información sobre la tecnología de clústeres de conmutación por error, consulte:

Nota:

Ahora es posible realizar la migración mediante lift-and-shift de la solución de instancia del clúster de conmutación por error a SQL Server en máquinas virtuales de Azure mediante Azure Migrate. Para obtener más información, consulte Migración de una instancia de clúster de conmutación por error.

quórum

Las instancias de clúster de conmutación por error con SQL Server en Máquinas Virtuales de Azure admiten el uso de un testigo de disco, un testigo en la nube o un testigo de compartición de archivos para el quórum del clúster.

Para más información, consulte procedimientos recomendados de Quorum con máquinas virtuales de SQL Server en Azure.

Almacenamiento

En entornos en clúster locales tradicionales, un clúster de conmutación por error de Windows usa una red de área de almacenamiento (SAN) accesible para todos los nodos como almacenamiento compartido. SQL Server archivos se hospedan en el almacenamiento compartido y solo el nodo activo puede acceder a los archivos de una vez.

SQL Server en máquinas virtuales de Azure ofrece varias opciones como solución de almacenamiento compartido para una implementación de instancias de clúster de conmutación por error de SQL Server:

Azure discos compartidos Comparticiones de archivos Premium Storage Spaces Direct (S2D) Azure Elastic SAN
Versión mínima de sistema operativo Todos Windows Server 2012 Windows Server 2016 Windows Server 2022
Versión mínima de SQL Server Todos SQL Server 2012 SQL Server 2016 SQL Server 2022
Disponibilidad admitida de VM Premium SSD LRS: conjuntos de disponibilidad con o sin grupo de ubicación por proximidad
Premium SSD ZRS: Zonas de disponibilidad
Discos Ultra: misma zona de disponibilidad
Conjuntos y zonas de disponibilidad Conjuntos de disponibilidad Zonas de disponibilidad
Admite FileStream No No
Admite MSDTC No No No

En el resto de esta sección se enumeran las ventajas y limitaciones de cada opción de almacenamiento disponible para SQL Server en máquinas virtuales de Azure.

Azure discos compartidos

Azure shared disks son una característica de Azure Managed Disks. Los clústeres de conmutación por error de Windows Server admiten el uso de discos compartidos de Azure en un entorno de clúster de conmutación por error.

Sistema operativo compatible: All
Versión de SQL compatible: All

Ventajas

  • Resulta útil para las aplicaciones que buscan migrar a Azure a la vez que mantiene su arquitectura de alta disponibilidad y recuperación ante desastres (HADR) tal cual.
  • Puede migrar aplicaciones en clúster a Azure tal cual debido a la compatibilidad con reservas persistentes SCSI (PR SCSI).
  • Admite almacenamiento compartido de Azure SSD Premium, Azure SSD Premium v2 y Azure Ultra Disk.
  • Puede usar un único disco compartido o seccionar varios para crear un grupo de almacenamiento compartido.
  • Admite FILESTREAM.
  • Las SSD Premium admiten conjuntos de disponibilidad.
  • El almacenamiento con redundancia de zona de los discos SSD prémium (ZRS) admite las zonas de disponibilidad. Las máquinas virtuales que forman parte de FCI se pueden colocar en distintas zonas de disponibilidad.
  • Admite el Coordinador de transacciones distribuidas de Microsoft (MSDTC) a partir de Windows Server 2019.

Nota:

Aunque los discos compartidos de Azure también admiten Tamaños SSD estándar, no se recomienda usar SSD estándar para cargas de trabajo de SQL Server debido a las limitaciones de rendimiento.

Limitaciones:

  • No se admite el almacenamiento en caché de SSD prémium.
  • Los discos Ultra no admiten conjuntos de disponibilidad ni almacenamiento con redundancia de zona (ZRS).
  • Las zonas de disponibilidad son compatibles con Ultra Disks, pero las máquinas virtuales deben estar en la misma zona de disponibilidad, lo que reduce la disponibilidad de la máquina virtual al 99,9 %.

Para comenzar, consulte configurar la instancia de clúster de conmutación por error con discos compartidos de Azure.

Storage Spaces Direct

Storage Spaces Direct es una característica de Windows Server compatible con la agrupación en clústeres de conmutación por error en Azure Virtual Machines. Proporciona una SAN virtual basada en software.

Sistemas Operativos Compatibles: Windows Server 2016 y versiones posteriores
Versión de SQL compatible: SQL Server 2016 y versiones posteriores

Ventajas:

  • El ancho de banda de red suficiente permite una solución de almacenamiento compartido sólida y de alto rendimiento.
  • Admite la caché de blobs de Azure, permitiendo que las lecturas se sirvan localmente desde la memoria caché. (Las actualizaciones se replican simultáneamente en ambos nodos).
  • Admite la funcionalidad FileStream.

Limitaciones:

  • Solo está disponible para Windows Server 2016 y versiones posteriores.
  • No se admiten zonas de disponibilidad.
  • Requiere la misma capacidad de disco conectado a ambas máquinas virtuales.
  • Se requiere un ancho de banda de red alto para lograr un gran rendimiento debido a la replicación de disco en curso.
  • Necesita un tamaño de máquina virtual mayor y un doble pago por almacenamiento, ya que el almacenamiento está conectado a cada máquina virtual.
  • No se admite Microsoft DTC (Coordinador de transacciones distribuidas).

Para empezar, consulte Configurar la instancia de clúster de conmutación por error con Storage Spaces Direct.

Compartición de archivos premium

Comparticiones de archivos premium son una característica de Azure Files. Los recursos compartidos de archivos Premium están respaldados por SSD y tienen una latencia baja constante. Se admiten por completo para su uso con instancias de clúster de conmutación para SQL Server 2012 o posterior en Windows Server 2012 o posterior. Los recursos compartidos de archivos Premium ofrecen mayor flexibilidad, lo que le permite cambiar el tamaño y escalar un recurso compartido de archivos sin tiempo de inactividad.

Sistemas operativos compatibles: Windows Server 2012 y versiones posteriores
Versiones de SQL compatibles: SQL Server 2012 y versiones posteriores

Ventajas:

  • Solución de almacenamiento compartido para máquinas virtuales distribuidas en varias zonas de disponibilidad.
  • Sistema de archivos totalmente administrado con latencias de un solo dígito y rendimiento de E/S escalable.
  • No se admiten todas las características de SQL Server, como instantáneas de base de datos, secuencia de archivos y CHECKDB sin TABLOCK. Consulte Limitaciones para obtener más información.

Limitaciones:

  • Solo está disponible para Windows Server 2012 y versiones posteriores.
  • No se admite FileStream.
  • No se admite Microsoft DTC (Coordinador de transacciones distribuidas).

Para empezar, consulte Configuración de una instancia de clúster de conmutación por error con el recurso compartido de archivos Premium.

Azure Elastic SAN

Azure Elastic SAN es una oferta de almacenamiento conectado a la red que proporciona a los clientes una solución flexible y escalable con el potencial de reducir el costo mediante la consolidación del almacenamiento. Azure Elastic SAN ofrece una solución de almacenamiento en bloques rentable, eficaz y confiable que se conecta a una variedad de Azure servicios de proceso a través del protocolo iSCSI. Elastic SAN permite una transición sin problemas de un patrimonio de almacenamiento SAN existente a la nube sin tener que refactorizar la arquitectura de la aplicación.

Sistemas Operativos Compatibles: Windows Server 2019 y versiones posteriores
Versión de SQL compatible: SQL Server 2022 y versiones posteriores

Ventajas:

  • Elastic SAN no está limitado por los límites de rendimiento del disco de máquina virtual, lo que significa que puede ahorrar costos al lograr un rendimiento deseado con máquinas virtuales más pequeñas.
  • Consolidación del almacenamiento y uso compartido dinámico del rendimiento: es posible ahorrar costos mediante la consolidación de cargas de trabajo de bajo a nivel medio con cargas de trabajo de rendimiento SQL Server, ya que el grupo de almacenamiento se aprovisiona en el nivel de SAN y el rendimiento se comparte entre cargas de trabajo.
  • Admite reservas persistentes SCSI (PR SCSI), lo que significa que puede migrar aplicaciones en clúster a Azure tal cual.
  • Puede usar un único volumen compartido o seccionar varios para crear un grupo de almacenamiento compartido.
  • El almacenamiento con redundancia de zona de Elastic SAN admite las zonas de disponibilidad. Las máquinas virtuales que son parte de una instancia de clúster de conmutación por error pueden ubicarse en diferentes zonas de disponibilidad.

Limitaciones:

  • El testigo en la nube no se admite actualmente.
  • No admite cargas de trabajo de latencia de submillisegundos.
  • Filestream no está soportado.
  • No se admite Microsoft DTC (Coordinador de transacciones distribuidas).

Asociado

Hay soluciones de agrupación en clústeres de asociados con almacenamiento compatible.

Sistema operativo compatible: All
Versión de SQL compatible: All

En un ejemplo se usa SIOS DataKeeper como almacenamiento. Para obtener más información, consulte la publicación del blog Clúster de conmutación por error y SIOS DataKeeper.

iSCSI y ExpressRoute

También puede exponer un almacenamiento en bloque compartido de destino iSCSI a través de Azure ExpressRoute.

Sistema operativo compatible: All
Versión de SQL compatible: All

Por ejemplo, NetApp Private Storage (NPS) expone un objetivo iSCSI a través de ExpressRoute con Equinix para máquinas virtuales de Azure.

Para las soluciones de almacenamiento compartido y de replicación de datos de asociados de Microsoft, debe ponerse en contacto con el proveedor en caso de que surjan problemas relacionados con el acceso de datos durante la conmutación por error.

Conectividad

Para igualar la experiencia local al conectarse a la instancia de clúster de conmutación por error, implemente sus máquinas virtuales de SQL Server en múltiples subredes dentro de la misma red virtual. Tener varias subredes elimina la necesidad de una dependencia adicional en un Azure Load Balancer o un nombre de red distribuido (DNN) para enrutar el tráfico a la FCI.

Si implementa las máquinas virtuales de SQL Server en una sola subred, puede configurar un nombre de red virtual (VNN) y un Azure Load Balancer, o un nombre de red distribuido (DNN) para enrutar el tráfico a la instancia del clúster de conmutación por error. Revise las diferencias entre los dos y, a continuación, implemente un nombre de red distribuida o un nombre de red virtual para la instancia de clúster de conmutación por error.

Se recomienda el nombre de red distribuido, si es posible, ya que la conmutación por error es más rápida, y se eliminan el costo y la sobrecarga de administrar el balanceador de carga.

La mayoría de las características de SQL Server funcionan de forma transparente con FCI al usar el DNN, pero hay ciertas características que pueden requerir una consideración especial. Para más información, consulte Interoperabilidad de FCI y DNN.

Nota:

Si tiene varios grupos de disponibilidad o FCI en el mismo clúster y usa un agente de escucha de DNN o VNN, cada grupo de disponibilidad o FCI necesita su propio punto de conexión independiente.

Limitaciones

Compatibilidad de extensión limitada

En este momento, las instancias de clúster de conmutación por error de SQL Server en máquinas virtuales de Azure registradas con la extensión SQL IaaS Agent solo admiten un número limitado de características disponibles a través del registro básico, pero no aquellas que requieren del agente, como la copia de seguridad automatizada, la aplicación de revisiones, la autenticación de Microsoft Entra y la administración avanzada del portal. Para obtener más información, vea la tabla de ventajas.

Si la máquina virtual de SQL Server ya se ha registrado con la extensión del Agente de IaaS de SQL y ha habilitado las características que requieren el agente, debe eliminar la extensión de la máquina virtual de SQL Server mediante la eliminación del recurso de máquina virtual SQL para las máquinas virtuales correspondientes, y luego registrarlo nuevamente con la extensión del Agente de IaaS de SQL. Al eliminar la máquina virtual SQL mediante el portal de Azure, desactive la casilla situada junto a la máquina virtual correcta para evitar eliminar la máquina virtual.

MSDTC

Azure Virtual Machines admite el Coordinador de transacciones distribuidas de Microsoft (MSDTC) en Windows Server 2019 con almacenamiento en volúmenes compartidos agrupados (CSV) y Azure Standard Load Balancer o en máquinas virtuales de SQL Server que usan Azure discos compartidos.

En Azure Virtual Machines, MSDTC no se admite para Windows Server 2016 ni versiones anteriores con volúmenes compartidos agrupados porque:

  • El recurso MSDTC en clúster no puede configurarse para usar almacenamiento compartido. En Windows Server 2016, si crea un recurso MSDTC, no muestra ningún almacenamiento compartido disponible para su uso, incluso si el almacenamiento está disponible. Este problema se ha corregido en Windows Server 2019.