Grupo de disponibilidad Always On de Microsoft SQL Server en Google Cloud

Last reviewed 2026-08-12 UTC

En este documento, se proporciona una arquitectura de referencia para implementar bases de datos de Microsoft SQL Server con alta disponibilidad (HA) en Google Cloud con un grupo de disponibilidad Always On. El documento también incluye consideraciones de diseño para la alta disponibilidad (HA) y la recuperación ante desastres (DR), opciones de implementación, recomendaciones de automatización y orientación para las operaciones de Backup and DR. Este documento está dirigido a profesionales técnicos que evalúan Google Cloud como una plataforma para ejecutar bases de datos de SQL Server. Se supone que tienes conocimientos básicos de Compute Engine y SQL Server.

Google Cloud proporciona soluciones rentables, confiables, seguras y de alto rendimiento para ejecutar bases de datos de SQL Server. Para obtener una descripción general de las soluciones de SQL Server compatibles en Google Cloud, consulta SQL Server en Google Cloud.

Para operar una implementación que no sea de desarrollo de SQL Server en Google Cloud, usa una de las siguientes opciones de licencias:

  • Licencias adquiridas por el usuario (BYOL): Trae tus licencias existentes de Microsoft SQL Server a Google Cloud. Debes usar nodos de usuario único o Software Assurance con movilidad de licencias.

  • Usa licencias a pedido: Usa imágenes prediseñadas de SQL Server en Google Cloud y paga una tarifa que incluye el costo de procesamiento y el costo de la licencia de Microsoft. Google se encarga de los acuerdos de licencias y la facturación de Microsoft.

En la sección Implementación de este documento, se proporcionan recursos para ayudarte a implementar esta arquitectura de referencia.

Arquitectura

En el siguiente diagrama, se muestra una arquitectura de referencia para una implementación de SQL Server configurada para HA en Google Cloud:

Una arquitectura que muestra una implementación de SQL Server con un grupo de disponibilidad Always On que abarca VMs de Compute Engine en diferentes zonas y regiones.

La arquitectura anterior muestra un grupo de disponibilidad Always On con tres nodos en un clúster de conmutación por error de Windows Server (WSFC). Cada nodo es una VM de Compute Engine que ejecuta SQL Server.

Un grupo de disponibilidad Always On es un patrón de implementación estándar de la industria para alcanzar los objetivos de confiabilidad de las bases de datos de SQL Server críticas para la misión. Los grupos de disponibilidad Always On proporcionan alta disponibilidad local (conmutación por error dentro de una región) y conmutación por error entre regiones para la DR. Este patrón de implementación es una alternativa de nivel empresarial a la duplicación de bases de datos. Un grupo de disponibilidad Always On proporciona los siguientes beneficios:

  • No se necesitan componentes de infraestructura especializados: SQL Server administra la replicación en todas las réplicas de bases de datos configuradas.
  • Configuración de ANS más alta para SQL Server: Objetivo de tiempo de recuperación (RTO) de menos de un minuto y objetivo de punto de recuperación (RPO) cercano a cero.
  • Capacidad de descargar cargas de trabajo de solo lectura en réplicas secundarias: Amplía de manera eficiente tu implementación para el análisis y otros casos de uso comunes.
  • Nodos en regiones adicionales para la recuperación ante desastres: Implementa una réplica principal y hasta ocho réplicas secundarias.
  • Implementable en Windows y Linux: Puedes usar una herramienta de terceros, como Pacemaker, como administrador de clústeres para implementaciones en Linux.

En la arquitectura anterior, los nodos principal y secundario de SQL Server se encuentran en zonas separadas dentro de una región. El nodo de DR se encuentra en una región geográficamente remota. Los datos del nodo principal se replican de forma síncrona en el nodo secundario y de forma asíncrona en el nodo de DR.

Para distribuir el tráfico desde la capa de aplicación a los nodos de bases de datos principal y secundario dentro de una región, puedes usar uno de los siguientes enfoques:

Productos usados

La arquitectura usa los siguientes productos y componentes de Google Cloud y Microsoft.

Google Cloud productos

  • Compute Engine: Un servicio de procesamiento seguro y personalizable que te permite crear y ejecutar VMs en la infraestructura de Google.
  • Google Cloud Hyperdisk: Es un servicio de almacenamiento de red que puedes usar para aprovisionar y escalar de forma dinámica volúmenes de almacenamiento en bloque con un rendimiento configurable y predecible.
  • Nube privada virtual (VPC): Es un sistema virtual que proporciona funcionalidad de red global y escalable para tus cargas de trabajo de Google Cloud . La VPC incluye el intercambio de tráfico entre redes de VPC, Private Service Connect, el acceso privado a servicios y la VPC compartida.
  • Cloud Load Balancing: Una cartera de balanceadores de cargas escalables, globales y regionales de alto rendimiento.

Productos y componentes de Microsoft

Los siguientes componentes se incluyen o habilitan en los nodos de SQL Server:

  • Windows Server (versión 2019 o posterior)
  • WSFC: Es un grupo de instancias de SQL Server que se instalan en varios nodos de clúster de Windows Server o en varias subredes.
  • Grupo de disponibilidad siempre activado: Es una alternativa de alta disponibilidad y DR de nivel empresarial a la duplicación de bases de datos.
  • Listener del grupo de disponibilidad: Es un nombre de red virtual (VNN) que los clientes pueden usar para acceder a una base de datos en una réplica principal o secundaria de un grupo de disponibilidad Always On. Los clientes no necesitan conocer el nombre de la instancia física de las réplicas. Debido a que el objeto de escucha enruta el tráfico, no es necesario modificar la cadena de conexión del cliente después de una conmutación por error.

Se requieren los siguientes componentes adicionales para implementar esta arquitectura:

Consideraciones del diseño

En esta sección, se describen los factores de diseño, las prácticas recomendadas y las recomendaciones de diseño que debes tener en cuenta cuando usas esta arquitectura de referencia para desarrollar una topología que cumpla con tus requisitos de confiabilidad, eficiencia operativa, seguridad, costo y rendimiento.

Confiabilidad

En esta sección, se describen las consideraciones y recomendaciones de diseño para compilar y operar una infraestructura confiable para tu implementación de SQL Server enGoogle Cloud.

Elige una estrategia de HA y DR

Para implementar bases de datos de SQL Server confiables en Google Cloud, necesitas una estrategia que combine la infraestructura sólida de Google Cloud con las capacidades de HA y DR de SQL Server. Esta combinación protege tus bases de datos de fallas que van desde interrupciones zonales hasta desastres regionales.

Cuando diseñes la estrategia de HA y DR para tu implementación de SQL Server, ten en cuenta los siguientes factores:

  • RPO: ¿Cuánta pérdida de datos es aceptable en caso de falla?
  • RTO: Después de una falla, ¿con qué rapidez debe volver a estar operativa la base de datos?
    • Para lograr un RTO bajo, usa un grupo de disponibilidad Always On.
    • Si se acepta un tiempo de inactividad, restablece las bases de datos a partir de las copias de seguridad o usa el envío de registros con conmutación por error manual.
  • Presupuesto: Considera las compensaciones entre el costo y la confiabilidad.
    • Alto costo, pero confiable: Usa un grupo de disponibilidad Always On con replicación asíncrona en nodos adicionales en una región de DR. Planifica la infraestructura y las licencias redundantes.
    • Costo medio: Implementa la replicación asíncrona de discos en otra región o usa el servicio Backup and DR.
    • Bajo costo, pero alto tiempo de recuperación: Crea copias de seguridad de las bases de datos en un bucket de Cloud Storage multirregional.
  • Tipos de fallas: ¿Qué tipos de fallas debes controlar?
    • Para controlar las fallas a nivel del hardware, de la instancia y de la zona, puedes usar grupos de disponibilidad.
    • Para recuperarte de interrupciones o desastres en todo el sitio, necesitas una solución de DR dispersa geográficamente, como el envío de registros o los grupos de disponibilidad Always On con replicación asíncrona de la base de datos.
  • Importancia para la empresa: ¿Qué tan importante es la aplicación para tu empresa?
    • Las aplicaciones esenciales necesitan una estrategia que proporcione el nivel más alto de disponibilidad, la mínima pérdida de datos y una recuperación rápida.
    • En el caso de los sistemas menos críticos, considera una estrategia que suponga un tiempo de inactividad aceptable o cierta pérdida de datos.

Usa el siguiente cuestionario de flujo de decisiones para elegir una estrategia de confiabilidad óptima para tu base de datos de SQL Server. Las opciones de estrategia varían desde un grupo de disponibilidad Always On que proporciona una pérdida de datos casi nula hasta una copia de seguridad externa rentable.

  1. ¿Las copias de seguridad externas cumplen con tus objetivos de RPO y RTO?
    • Sí: Usa copias de seguridad externas o el envío de registros.
    • No: Continúa con la siguiente pregunta.
  2. ¿Tu RTO o RPO es inferior a un minuto?
    • Sí (RPO casi nulo): Usa un grupo de disponibilidad Always On de SQL Server con una réplica de base de datos de DR.
    • No: Continúa con la siguiente pregunta.
  3. ¿Cuál es tu RTO?
    • Menos de cinco minutos: Usa un grupo de disponibilidad Always On de SQL Server con una réplica de disco asíncrona.
    • Una hora o más: Continúa con la siguiente pregunta.
  4. ¿Cuál es tu RPO?
    • Menos de dos horas: Usa un grupo de disponibilidad Always On de SQL Server con el servicio Backup and DR.
    • Ocho horas o más: Usa copias de seguridad externas o el envío de registros.

Elige las opciones de copia de seguridad adecuadas

Si tu estrategia de confiabilidad incluye copias de seguridad de bases de datos, elige un método de copia de seguridad que cumpla con tus requisitos. Google Cloud ofrece las siguientes opciones flexibles y listas para la empresa para crear copias de seguridad de bases de datos de SQL Server:

  • Copia de seguridad directa en un bucket de Cloud Storage: Escribe copias de seguridad de la base de datos directamente en Cloud Storage con el comando BACKUP TO URL y el conector de S3 en SQL Server (versión 2022 o posterior). Para los entornos de producción, puedes usar una clave de acceso de código de autenticación de mensajes basado en hash (HMAC). Esta opción de copia de seguridad proporciona protección rentable para las bases de datos y los registros sin necesidad de almacenamiento local intermedio.
  • Instantáneas instantáneas de Compute Engine: Captura instantáneas simultáneas en varios discos (por ejemplo, en discos Hyperdisk Balanced) en menos de un segundo con operaciones de congelación y descongelación de Transact-SQL (T-SQL) combinadas con grupos de coherencia de Compute Engine. Esta opción permite copias de seguridad de alto rendimiento a nivel de la VM para bases de datos de varios discos y tiene un requisito de inmovilización de escritura casi nulo.
  • Backup and DR: Coordina instantáneas coherentes con la aplicación usando proveedores de VSS de Microsoft y grupos de coherencia. Esta opción de copia de seguridad es adecuada cuando necesitas una recuperación de un momento determinado (PITR) granular y de varias bases de datos, y la capacidad de usar registros para restablecer bases de datos.
  • Google Cloud NetApp Volumes: Crea instantáneas y copias de seguridad asíncronas en bóvedas remotas con el motor de almacenamiento ONTAP. Recomendamos NetApp Volumes para aplicaciones empresariales sensibles a la latencia que necesitan una mitigación rápida del ransomware y clones eficientes en cuanto al espacio.

Para las implementaciones híbridas y de múltiples nubes que necesitan políticas unificadas de protección de datos, puedes elegir un producto de copia de seguridad de terceros, como Veeam, Veritas NetBackup o Cohesity.

Operaciones

Para garantizar la alta disponibilidad y el rendimiento óptimo de las bases de datos de SQL Server implementadas en las VMs de Compute Engine, configura un sistema integral de supervisión y alertas con Cloud Monitoring y Cloud Logging.

  • Realiza un seguimiento continuo de las métricas de los recursos principales, como la utilización de la CPU y la carga de memoria. Configura alertas de referencia para detectar la presión sobre los recursos antes de que las consultas comiencen a degradarse.
  • Para evitar que se detengan las escrituras en la base de datos, observa continuamente la utilización del espacio en disco. Supervisa el estado general del servicio y configura alertas para recibir notificaciones cuando las bases de datos se detengan de forma inesperada.
  • En el caso de las implementaciones de alta disponibilidad, haz un seguimiento de las conmutaciones por error no planificadas y garantiza una visibilidad completa durante los eventos automatizados de recuperación ante desastres.
  • Además de la telemetría a nivel del sistema, Google Cloud proporciona un amplio conjunto de métricas específicas de la base de datos, como los límites de conexión de usuarios activos, el retraso de replicación y las tasas de transacciones. Haz un seguimiento de estas métricas para supervisar la disponibilidad y el rendimiento de tus bases de datos de SQL Server.
  • Para capturar errores a nivel de la aplicación, como interbloqueos, corrupción de la base de datos y fallas en los trabajos del agente directamente desde los registros de errores de SQL Server, configura alertas personalizadas basadas en registros en Logging.

Seguridad

En esta sección, se describen las consideraciones y recomendaciones de diseño para diseñar una implementación de SQL Server en Google Cloud que cumpla con los requisitos de seguridad de tu carga de trabajo.

Seguridad y aislamiento de la red

  • Para evitar la exposición externa de las bases de datos, implementa las instancias de SQL Server con direcciones IP privadas dentro de una VPC. Usa el acceso privado a servicios para enrutar el tráfico de forma interna. Este enfoque ayuda a garantizar que el tráfico de tu base de datos nunca atraviese la Internet pública.
  • Restringe aún más el acceso a las bases de datos configurando reglas estrictas de firewall de VPC que permitan el tráfico solo desde subredes de aplicaciones autorizadas o bloques CIDR específicos.
  • Para proteger los datos en tránsito contra escuchas y la interceptación, implementa la conectividad encriptada aplicando TLS/SSL a todas las conexiones de la base de datos.

Encriptación y control de claves

  • De forma predeterminada, Google Cloud usa claves AES-256 administradas por Google para encriptar automáticamente todos los datos en reposo en los discos de la base de datos, los archivos temporales y las copias de seguridad. Para cumplir con los entornos de cumplimiento, puedes implementar la encriptación a nivel de la base de datos con la capacidad de encriptación de datos transparente (TDE) de SQL Server.
  • Para garantizar la soberanía de los datos, puedes usar claves de encriptación administradas por el cliente (CMEK) en Cloud Key Management Service. Las CMEK te brindan control criptográfico total. Administras los ciclos de vida de las claves, estableces programas de rotación automática y revocas instantáneamente el acceso a la base de datos y a sus copias de seguridad cuando es necesario.

Autenticación y autorización

  • Integra tu base de datos con Microsoft Active Directory o centraliza la administración de identidades en tus bases de datos de SQL Server y otros recursos deGoogle Cloud con Identity and Access Management (IAM).
  • Después de establecer las identidades, aplica el principio de privilegio mínimo para que los usuarios y las cuentas de servicio de la aplicación solo tengan los permisos necesarios para realizar sus funciones. Asigna identidades a roles detallados de bases de datos de SQL Server.

Optimización de costos

En esta sección, se proporciona orientación para optimizar el costo de configurar y operar una implementación de SQL Server que compilas a través de esta arquitectura de referencia. La optimización de costos ayuda a garantizar que la implementación cumpla con los requisitos de confiabilidad y rendimiento de tu carga de trabajo dentro de las restricciones de presupuesto.

Ten en cuenta las siguientes recomendaciones:

  • Inhabilita el multiprocesamiento simultáneo (SMT): Si inhabilitas el SMT, puedes reducir en un 50% el recuento de núcleos que se informa para fines de licencias. Si aprovisionas en exceso tus CPU en un 20% y, luego, inhabilitas el SMT, puedes lograr ahorros sustanciales en los costos de licencias sin sacrificar el rendimiento. Para obtener más información, consulta Configura una cantidad de subprocesos por núcleo.
  • Usa SQL Server Standard Edition: Según tus requisitos de HA y DR, puedes reducir el costo de licencias si usas la edición Standard de SQL Server en lugar de la edición Enterprise. Para obtener más información, consulta Ediciones y funciones compatibles de SQL Server.
  • Optimiza el almacenamiento: Hyperdisk proporciona diferentes opciones de disco que puedes elegir según las necesidades de tu implementación de SQL Server. El hiperdisco balanceado ofrece un equilibrio entre costo y rendimiento. Puedes escalar la capacidad de procesamiento y las operaciones de entrada y salida por segundo (IOPS) de forma independiente, de modo que la inversión en infraestructura coincida con precisión con las necesidades de la carga de trabajo. Para obtener más información, consulta la sección Elige un tipo de disco de almacenamiento adecuado.

Optimización del rendimiento

En esta sección, se describen las consideraciones y recomendaciones de diseño para una implementación de SQL Server que cumpla con tus requisitos de rendimiento.

Si implementas SQL Server en VMs de Compute Engine, obtendrás el control total de la base de datos y la infraestructura subyacente. El rendimiento de tu carga de trabajo depende de la infraestructura que elijas. Para equilibrar el rendimiento con el costo y la confiabilidad, debes tomar decisiones fundamentadas sobre la familia de máquinas de la VM y el tipo de disco para los nodos de la base de datos.

Elige una familia de máquinas de VM adecuada

La familia de máquinas que elijas para las VMs de Compute Engine determina la potencia de procesamiento (CPU virtual) y la memoria (RAM) que están disponibles para tus nodos de SQL Server. Estos recursos afectan el rendimiento de tus bases de datos.

Elige una familia de máquinas de VM que aborde tu principal cuello de botella de rendimiento. Por ejemplo, si tu base de datos de SQL Server tiene un uso alto de CPU constante, elige un tipo de máquina de la familia de máquinas optimizadas para procesamiento. Si tu base de datos de SQL Server muestra lecturas lentas desde el disco, elige un tipo de máquina con optimización de memoria.

En la siguiente tabla, se comparan las familias de máquinas de VM que proporciona Compute Engine, el caso de uso principal de cada familia de máquinas y el impacto en el rendimiento de las bases de datos de SQL Server:

Familia y serie de la máquina Caso de uso principal Impacto en el rendimiento de SQL Server
De uso general (serie de máquinas N4) Precio y rendimiento equilibrados Usa esta familia de máquinas como punto de partida para la mayoría de las cargas de trabajo. La serie de máquinas N4 proporciona un equilibrio óptimo de CPU y memoria para bases de datos de uso mixto, aplicaciones web y entornos de desarrollo o prueba.
Optimizadas para procesamiento (series de máquinas C3 o C4) Mayor rendimiento por núcleo Usa esta familia de máquinas para cargas de trabajo vinculadas a la CPU. Para las bases de datos que realizan consultas complejas, procesan grandes volúmenes de datos o ejecutan una gran cantidad de operaciones de procesamiento de transacciones en línea (OLTP), usa las series de máquinas C3 y C4. Los tipos de máquinas de estas series ayudan a reducir significativamente el tiempo de ejecución de las consultas.
Con optimización de memoria (serie de máquinas M3 o M4) Proporciones grandes de memoria a CPU virtual Esta familia de máquinas es ideal para aplicaciones que requieren mucha memoria. SQL Server almacena en caché los datos y los planes de ejecución en la memoria, lo que proporciona un mayor rendimiento que la lectura desde los discos. Con bases de datos o almacenes de datos muy grandes para el procesamiento analítico en línea (OLAP), las consultas suelen analizar tablas y conjuntos de datos grandes. En estos casos de uso, una mayor cantidad de memoria ayuda a mejorar el rendimiento.

Para obtener más información, consulta la guía de comparación y recurso de familias de máquinas.

Elige un tipo de disco de almacenamiento adecuado

El rendimiento del disco es un factor importante para la capacidad de respuesta de la base de datos, que es fundamental para el rendimiento de la aplicación. En el caso de los tipos de discos que ofrece Google Cloud, las capacidades de rendimiento se indican con las siguientes métricas:

  • IOPS: Es la cantidad de solicitudes de lectura y escritura que un disco puede controlar por segundo. Las IOPS son fundamentales para las cargas de trabajo de OLTP que implican muchas operaciones de lectura y escritura pequeñas y aleatorias, como la actualización de registros de clientes o el procesamiento de pedidos.
  • Capacidad de procesamiento: Es la cantidad total de datos que se pueden transferir al disco o desde él por segundo. La capacidad de procesamiento es esencial para las cargas de trabajo de OLAP que implican analizar grandes cantidades de datos, como la ejecución de informes, el almacenamiento de datos o la realización de copias de seguridad.

En la siguiente tabla, se comparan los Google Cloud tipos de discos entre los que puedes elegir:

Tipo de disco Características de rendimiento Idoneidad de la carga de trabajo
Disco persistente SSD (pd-ssd) Rendimiento de medio a alto según el tipo de máquina de la VM y el tamaño del disco Cargas de trabajo que requieren que el rendimiento se ajuste según el tamaño del disco y las CPU virtuales de la VM Para obtener más información, consulta la descripción general del rendimiento de Persistent Disk.
Hiperdisco balanceado Alto rendimiento con IOPS y capacidad de procesamiento configurables Archivos de registro y datos de SQL Server de producción Hyperdisk Balanced te permite configurar las IOPS y la capacidad de procesamiento de forma independiente del tamaño del disco y en función de las necesidades de la carga de trabajo.
Hyperdisk Extreme Rendimiento muy alto con IOPS configurables Cargas de trabajo de OLTP de alta gama y fundamentales que necesitan la mayor cantidad de IOPS y la latencia más baja, como los sistemas financieros o de comercio electrónico a gran escala
SSD local Las IOPS y la capacidad de procesamiento más altas en comparación con los otros tipos de discos Datos temporales que no necesitan la durabilidad de los discos persistentes Para los datos, como la base de datos del sistema tempdb y el archivo de paginación de Windows, los SSD locales proporcionan la latencia más baja porque están conectados físicamente a las VMs.

Haz coincidir la infraestructura con los requisitos de rendimiento

Elige los tipos de máquinas y discos de VM según los requisitos de rendimiento de tu carga de trabajo. En la siguiente tabla, se recomiendan configuraciones de infraestructura para diferentes situaciones de cargas de trabajo:

Situación Requisitos de rendimiento Configuración recomendada del tipo de máquina y el disco
Base de datos de comercio electrónico con gran cantidad de transacciones para OLTP IOPS altas para controlar miles de operaciones de lectura y escritura simultáneas pequeñas

Tipo de máquina de VM: Elige un tipo de máquina optimizado para procesamiento (por ejemplo, de la serie de máquinas C4) para el procesamiento eficiente de transacciones.

Discos de datos y registros: Usa discos Hyperdisk Balanced. Aprovisiona un nivel alto de IOPS para satisfacer la demanda transaccional. Usa discos separados para los datos y los registros.

tempdb: Usa discos SSD locales para descargar operaciones temporales y maximizar el rendimiento.
Almacén de datos de la empresa para OLAP Alta capacidad de procesamiento para analizar y agregar terabytes de datos para generar informes

Tipo de máquina de VM: Elige un tipo de máquina con optimización de memoria (por ejemplo, de la serie de máquinas M4) para que puedas almacenar en caché la mayor cantidad posible del conjunto de datos grande.

Disco de datos: Usa discos Hyperdisk Balanced. Proporciona un alto nivel de capacidad de procesamiento para acelerar los análisis de datos grandes.
Servidor de desarrollo o de etapa de pruebas Rentabilidad en lugar de rendimiento máximo

Tipo de máquina de VM: Elige un tipo de máquina de uso general con un tamaño pequeño de la serie de máquinas E2 o N4.

Discos: Usa discos persistentes balanceados (pd-balanced) para todos los archivos de la base de datos y, así, lograr un rendimiento aceptable a un bajo costo.

Implementación

Para implementar esta arquitectura de referencia, usa uno de los siguientes recursos:

¿Qué sigue?

Colaboradores

Autores:

Otro colaborador: Kumar Dhanagopal | Desarrollador de soluciones entre productos