Alta Disponibilidad

26
Nov
2025

SQL Server sobre VMware vSphere: Buenas prácticas

La virtualización de SQL Server ha sido durante más de una década una de las estrategias más consolidadas en entornos corporativos. VMware vSphere ha jugado un papel central en ese éxito, ofreciendo una plataforma madura, estable y altamente optimizada para ejecutar cargas de trabajo críticas como bases de datos relacionales. Sin embargo, en 2025 la situación es diferente.

Desde que Broadcom cerró la adquisición de VMware a finales de 2023, el panorama ha cambiado. La transición forzada al modelo de suscripción, la retirada de licencias perpetuas y el aumento generalizado de precios han generado un malestar evidente en muchos clientes. Algunas organizaciones han iniciado migraciones hacia Hyper-V, otras han apostado por plataformas cloud y unas pocas han optado incluso por volver al metal físico para sus cargas más exigentes.

Pero en medio de esa reconfiguración estratégica, una cosa sigue siendo cierta: vSphere sigue siendo una de las plataformas más fiables para ejecutar entornos virtualizados críticos como servidores SQL Server, siempre que se configure correctamente. Y eso, precisamente, es lo que nos ocupa en esta guía.

A continuación, abordamos en profundidad las consideraciones técnicas clave para desplegar SQL Server sobre VMware vSphere en 2025, actualizando las recomendaciones oficiales a la realidad operativa actual. Porque más allá de las decisiones de licenciamiento o la política comercial de turno, lo que importa es garantizar que nuestras bases de datos funcionen con previsibilidad, rendimiento y resiliencia.

Antes de empezar, conviene señalar que la mayoría de los fundamentos que vamos a repasar están basados en la guía oficial de VMware publicada en 2019 (Architecting Microsoft SQL Server on vSphere). No obstante, han pasado seis años desde entonces, por lo que además de recuperar los puntos más relevantes, matizaremos aquellos aspectos donde la tecnología, el hardware o las prácticas de operación han evolucionado.

Diseño correcto de la máquina virtual

Uno de los errores más comunes en despliegues SQL Server sobre vSphere es asumir que la virtualización, cómo se puede redimensionar fácilmente, elimina la necesidad de una planificación detallada. Nada más lejos de la realidad. El rendimiento y la estabilidad de SQL Server dependen en gran medida de cómo se diseñe la máquina virtual así que si, podrás cambiarlo luego pero eso no quiere decir que no lo diseñes bien de primeras.

Dimensionamiento inicial (right-sizing)

A diferencia de entornos físicos, en VMware es preferible asignar sólo los recursos que la carga realmente necesita. Asignar más CPU o RAM de la necesaria puede generar efectos negativos: contención, mayor coste de scheduling, uso ineficiente de licencias, o incluso, aunque pueda ser contraintuitivo, peor rendimiento. Una VM con más vCPU de las que necesita puede sufrir más Ready Time, más latencia y menos rendimiento.

Para dimensionar correctamente, conviene recopilar datos de uso real de CPU, memoria y disco mediante DMVs, Performance Monitor o herramientas de observabilidad (SQL Sentry, vRealize Operations). A partir de ahí, se puede asignar el número adecuado de vCPU y memoria, ajustando posteriormente según carga.

Configuración de CPU y NUMA

Núcleos por socket: impacto técnico y de licenciamiento

La edición Standard de SQL Server impone límites que no siempre se respetan al definir una VM: máximo 4 sockets o 24 núcleos. Por tanto, es frecuente encontrar configuraciones ineficientes: por ejemplo, una VM con 8 sockets y 1 core por socket, que solo permite el uso de 4 sockets con un núcleo cada uno, aunque se hayan asignado 8 núcleos.

Lo recomendable es agrupar los núcleos virtuales en menos sockets: por ejemplo, 1 socket con 8 cores, o 2 sockets con 12. Esto permite que SQL Server aproveche todos los recursos asignados sin restricciones de licenciamiento.

Consideraciones NUMA

Cuando una VM supera los recursos de un nodo NUMA físico (CPU o memoria), se producen accesos a memoria remota, lo que introduce latencia física. SQL Server es muy sensible a este comportamiento así que tenlo en cuenta.

VMware detecta la topología NUMA del host y crea configuraciones vNUMA equivalentes, pero esto solo es posible si la VM tiene más de 8 vCPU (configurable). En cualquier caso, es necesario verificar que la asignación real de nodos NUMA es coherente, tanto desde el visor de recursos del host como desde dentro de SQL Server (por ejemplo, con sys.dm_os_memory_nodes).

Asignación y gestión de memoria

Evitar el overcommit de memoria

En entornos VMware es posible sobreasignar memoria física, confiando en mecanismos como ballooning o swapping para equilibrar el uso. Pero esto es completamente desaconsejado para máquinas que ejecutan SQL Server, ya que su gestión interna de memoria (buffer pool, cache) depende de una disponibilidad constante.

La práctica recomendada es reservar memoria para la VM (memory reservation = memory size) y evitar que el host pueda utilizar parte de esa RAM para otros fines. En ESXi modernos, la opción de Transparent Page Sharing (TPS) está deshabilitada por defecto, lo que refuerza la necesidad de no sobrecomprometer recursos.

Configuración dentro de SQL Server

Dentro de la instancia, es imprescindible limitar la memoria máxima (max server memory) para evitar que el sistema operativo se quede sin recursos. Hay que tener un especial cuidado al habilitar lock pages in memory, JAMÁS se debe activar si el balloning está activado para esa VM o puede producir errores. 

Siguiendo con estas configuraciones, el uso de large pages (Trace Flag 834) puede mejorar el rendimiento en sistemas con mucha RAM, pero es muy delicado y requiere pruebas específicas. De todas formas no seré yo quien os recomiende una configuración que ni Microsoft recomienda…

Almacenamiento y controladoras

Cuando se crean discos virtuales (VMDKs) para una VM, VMware permite elegir entre discos de tamaño fijo (thick provisioned) o dinámico (thin provisioned). Aunque el aprovisionamiento dinámico puede ahorrar espacio a corto plazo, introduce fragmentación y penalizaciones de rendimiento a medida que el disco crece.

En entornos SQL Server, donde la carga de I/O es constante y predecible, el uso de discos thin puede generar latencia adicional, sobre todo en sistemas de almacenamiento que no gestionan bien el crecimiento dinámico.

La recomendación es clara, utilizar discos de tamaño preasignado (thick eager zeroed) para todos los VMDKs que manejen datos, logs o TempDB. Este tipo de disco se crea completamente al aprovisionar la VM, evitando operaciones de escritura adicionales durante el uso. Esta práctica garantiza un mejor rendimiento sostenido, especialmente en entornos con IOPS elevados, y reduce el riesgo de fragmentación interna del datastore

Separación de discos y uso de PVSCSI

Una práctica consolidada es separar los distintos tipos de archivos de SQL Server en VMDKs distintos: sistema operativo, base de datos, logs, TempDB. Esto no solo mejora el rendimiento, también facilita la gestión de snapshots, backups y análisis de uso.

En cuanto a la controladora, VMware recomienda usar PVSCSI en lugar de LSI Logic SAS para los discos de datos. PVSCSI ofrece mayor profundidad de cola (hasta 256) y menor uso de CPU. La configuración ideal combina:

  1. LSI Logic SAS solo para la unidad C:\
  2. Varias controladoras PVSCSI adicionales para datos, logs y TempDB, separadas si es posible.

Compatibilidad con NVMe

Aunque los discos NVMe han ganado presencia en datacenters en los últimos años, las recomendaciones no cambian: PVSCSI sigue siendo preferible por compatibilidad, madurez y soporte. Solo si se trabaja directamente con hardware o almacenamiento NVMe puede valorarse otra configuración, siempre tras validación en laboratorio.

Instantáneas (snapshots): limitaciones y riesgos

Los snapshots de vSphere son herramientas útiles para pruebas y cambios puntuales, pero no deben utilizarse como método de backup. En SQL Server, los discos delta que crean los snapshots generan penalizaciones de rendimiento progresivas, especialmente en entornos con alto volumen de escritura.

Es frecuente que un snapshot olvidado de semanas cause degradaciones difíciles de diagnosticar. Si hay que usarlos, deben eliminarse en horas, no días. Y siempre debe preferirse una estrategia de backup basada en herramientas nativas o soluciones de backup empresarial compatibles con SQL Server.

Red y conectividad

SQL Server puede requerir un uso intensivo de red, especialmente en escenarios con alta concurrencia, réplicas, Always On o transacciones distribuidas.

Las interfaces de red deben ser siempre VMXNET3, que ofrecen mejor rendimiento y menor latencia que E1000. Además, se recomienda activar Receive Side Scaling (RSS) tanto en el sistema operativo como en las VMware Tools, para distribuir la carga de red entre múltiples núcleos de CPU.

Si se trabaja con grandes volúmenes de datos entre nodos (como en grupos de disponibilidad o replicaciones), debe garantizarse que la infraestructura física y virtual está optimizada para latencia baja y alto throughput. 

Por ejemplo, es una buena práctica usar una VLAN e interfaz de red (física y virtual) dedicada para la comunicación entre servidores SQL, o para la conexión con los servidores de copias de seguridad.

Configuración de energía

Cuando hablamos de servidores críticos debemos primar el rendimiento a la eficiencia energética y esto implica establecer un plan High Performance en todos los niveles

El plan de energía es una de las configuraciones más olvidadas (si aun en 2025), pero con mayor impacto. Por defecto, ESXi y Windows Server pueden utilizar políticas de ahorro de energía (Balanced), que reducen la frecuencia de CPU o introducen cambios de estado (P-states) perjudiciales para cargas sensibles.

La recomendación es clara: habilitar el modo High Performance en tres capas:

  1. BIOS del host físico.
  2. Política de energía de ESXi.
  3. Plan de energía dentro del sistema operativo invitado.

Esta configuración reduce la latencia de respuesta de la CPU y evita throttling no deseado. En pruebas reales, he notado mejoras de entre el 10 y el 15% en rendimiento solo con una buena configuración de energía.

Disponibilidad y recuperación

Garantizar la disponibilidad de una instancia de SQL Server virtualizada no se limita a activar vSphere HA o a desplegar un grupo de disponibilidad. Exige entender cómo interactúan las funcionalidades de VMware con las tecnologías de alta disponibilidad del propio SQL Server, y decidir cuál debe ser el punto de recuperación (RPO) y el tiempo de recuperación objetivo (RTO) para cada tipo de fallo.

Alta disponibilidad en la capa VMware

VMware proporciona mecanismos propios de alta disponibilidad y movilidad de cargas que pueden complementar (o incluso entrar en conflicto con) las estrategias nativas de SQL Server:

  • vSphere HA permite el reinicio automático de una VM en otro host del clúster cuando se detecta un fallo físico. No ofrece continuidad de servicio inmediata, pero sí reduce el downtime sin intervención manual. Es transparente para el sistema operativo y para SQL Server.
  • vSphere FT (Fault Tolerance) proporciona replicación síncrona a nivel de VM y failover instantáneo sin pérdida de estado. No está soportado para máquinas con más de 8 vCPU (en la mayoría de versiones actuales) y no es compatible con algunos escenarios de licenciamiento de SQL Server. Es útil solo en casos muy concretos y no se recomienda como estrategia principal de HA para SQL.
  • vMotion permite migrar en caliente una VM entre hosts sin apagado, útil para mantenimiento planificado o balanceo. Sin embargo, en cargas intensivas (como operaciones de backup, reindexación o grandes transacciones), la migración puede introducir latencias temporales. Aunque no genera caída del servicio, puede afectar al rendimiento en momentos críticos.
  • DRS (Distributed Resource Scheduler) balancea dinámicamente la carga entre hosts según consumo de recursos. Esto puede provocar movimientos frecuentes de la VM si no se definen reglas adecuadas. 

En entornos con SQL Server, es necesario evaluar cuidadosamente el impacto de vMotion y DRS en instancias críticas. Mover una VM durante una operación intensiva puede degradar el rendimiento o generar latencia adicional. Se recomienda definir reglas de afinidad o exclusión para evitar migraciones no deseadas. 

Consideraciones de diseño

A la hora de planificar una solución de alta disponibilidad para SQL Server sobre VMware, es fundamental definir el tipo de fallo que se quiere cubrir:

  • Fallo físico del host: vSphere HA es suficiente si se acepta un reinicio de VM.
  • Fallo de software en el sistema operativo o SQL Server: requiere HA a nivel de SQL Server (AG, FCI).
  • Fallo del datastore: debe cubrirse mediante almacenamiento redundante (vSAN, replicación SAN/NAS).
  • Fallo completo del datacenter: implica solución de recuperación ante desastres (DR), normalmente con réplicas geográficas y procedimientos definidos de failover manual o automático.

Es importante destacar que las soluciones de VMware y SQL Server no son excluyentes, pero deben coordinarse cuidadosamente para evitar conflictos: por ejemplo, no tendría sentido proteger una FCI solo con vSphere HA, o dejar que DRS migre réplicas sincronizadas entre hosts indiscriminadamente. En casos en los que se implementan soluciones HA de SQL Server se recomienda definir reglas de afinidad y exclusión para que las máquinas implicadas en el HA no compartan host físico.

También hay que considerar el licenciamiento: algunas ediciones de SQL Server requieren licencias activas en todas las réplicas del clúster, incluso si solo una está activa (según el uso que se haga). Además, ciertos entornos requieren asegurar que las réplicas pasivas no procesan cargas activas para beneficiarse de ventajas en licencias de Software Assurance.

Vecinos ruidosos

Uno de los retos más infravalorados en la virtualización de cargas críticas como SQL Server es el efecto de otras VMs compartiendo el mismo host físico, conocidas comúnmente como “noisy neighbors” (vecinos ruidosos).

Una máquina virtual que consume picos de CPU, I/O o memoria puede afectar negativamente a otras VMs en el mismo host, especialmente si no hay control de calidad de servicio (QoS) o reservas definidas. Los síntomas suelen incluir:

  • Latencia intermitente en consultas.
  • Variabilidad en tiempos de respuesta bajo carga constante.
  • Aumento de CPU Ready Time o Co-Stop sin incremento aparente de carga en SQL Server.

Para detectar estos problemas, se requiere visibilidad más allá del sistema operativo invitado. Herramientas como vRealize Operations, SQL Sentry o VMware Aria Operations permiten identificar VMs que saturan recursos compartidos, y correlacionar ese uso con degradaciones de rendimiento en las instancias afectadas.

En este caso las recomendaciones son:

  • Establecer reservas mínimas de recursos para VMs críticas.
  • Aplicar affinity/anti-affinity rules para separar cargas pesadas o sensibles.
  • Evitar que SQL Server comparta host con VMs que realizan tareas de backup, ETL o pruebas automatizadas en horarios críticos.
  • Monitorizar periódicamente la actividad del host para detectar comportamientos anómalos.

En entornos donde se requiere máxima previsibilidad (banca, OLTP de alto rendimiento, entornos de pricing), puede incluso justificarse la dedicación exclusiva de host para una o varias VMs SQL Server.

Versiones de hardware y VMware Tools

Mantener actualizadas tanto la versión de hardware virtual como las VMware Tools es esencial para acceder a nuevas funcionalidades, mejorar el rendimiento y garantizar el soporte oficial.

En 2025, la versión mínima recomendada es hardware version 19 (ESXi 7.0), aunque lo ideal sería estar en versión 20 u 21 si se usa ESXi 8.x. Las VMware Tools deben actualizarse de forma coordinada tras cambios de versión o parches del host.

Monitorización y observabilidad

Las métricas estándar de vSphere no siempre ofrecen suficiente visibilidad sobre los cuellos de botella que afectan a SQL Server. Por ello, se recomienda utilizar herramientas especializadas que permitan analizar desde la capa de hipervisor hasta el motor de base de datos:

  • SQL Sentry (SolarWinds): ofrece no solo métricas de SQL Server sino también propias del entorno virtual.
  • vRealize Operations: para el análisis de capacidad, planificación y rendimiento.
  • Perfmon + DMVs: exclusivo para el análisis desde dentro de la VM.

Indicadores como CPU Ready Time, Co-Stop, latencia de I/O, uso de memoria o crecimiento de snapshots deben estar controlados de forma continua.

Conclusión

La virtualización de SQL Server sobre VMware sigue siendo, en 2025, una estrategia plenamente válida para cargas de misión crítica. Pero su éxito depende de un diseño cuidadoso, de un conocimiento profundo del comportamiento del motor SQL y de una integración adecuada con las funcionalidades del hipervisor.

Los errores más comunes (malas configuraciones NUMA, exceso de vCPU, uso de snapshots como backup, planes de energía inadecuados) pueden evitarse si se siguen las prácticas que hemos repasado. Esta guía pretende servir como base técnica de referencia para garantizar que cada instancia virtualizada de SQL Server funcione con la previsibilidad, rendimiento y fiabilidad que un entorno de producción exige.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Alta Disponibilidad, Rendimiento, SQL Server, 1 comentario
26
Sep
2025

Opciones de Quorum para un clúster Always On

Sí, lo sé. Esto no va de índices columnstore ni de Extended Events sacando fuegos artificiales ni nada propiamente de bases de datos. Esto va de Quorum. Ese componente del clúster de Windows que muchos DBAs miran de reojo con la misma ilusión con la que uno revisa un log de errores a las 6 de la mañana. Pero si te metes en el barro de Always On, más te vale entender cómo funciona. Porque si el Quorum no está bien configurado, tu clúster puede caerse por una tontería. Y no, no da igual poner un disco o un voto más aquí o allá. Aquí no venimos a improvisar.

Este artículo no es tanto de SQL Server como de administración de sistemas, pero es un conocimiento que cualquier DBA serio necesita tener controlado. No porque vayamos a montar los clústeres a mano (que también), sino porque cuando empiecen los problemas, nadie va a buscar al sysadmin de guardia. Primero te van a buscar a ti.

El Quorum no es una opinión

Primero, vamos al grano: ¿qué demonios es el Quorum y por qué nos debería importar?

El Quorum es un mecanismo que usan la mayoría de los clúster, incluido el de Windows Server (WSFC, Windows Server Failover Cluster), para decidir si puede seguir funcionando. No estamos hablando de algo estético. Si el clúster pierde el Quorum, se apaga. Así de simple. O, peor aún, se divide y entra en split-brain, ese estado esquizofrénico donde dos nodos piensan que son los jefes, pero en realidad nadie manda. Un poco como algunas reuniones entre directores de distintos departamentos.

Así que no, el Quorum no es un «detalle más». Es un componente crítico del diseño. Y en el caso de Always On Availability Groups, que se basan en WSFC, ignorarlo es como montar un Ferrari y pasar de los frenos.

Tipos de Quorum en WSFC

Windows Server ofrece varias configuraciones de Quorum. Cada una con sus ventajas, sus pegas y sus peligros ocultos. No son intercambiables ni da igual cuál elijas. Vamos a repasarlas, una a una.

Node Majority (Mayoría de nodos)

Es el más sencillo, cada nodo tiene un voto, y si más de la mitad están activos y comunicados, el clúster sigue funcionando. Normalmente se usa en entornos con número impar de nodos (3, 5…). Es el ideal cuando todos los nodos están en el mismo datacenter o con conexiones fiables.

Su principal ventaja es su simplicidad de configuración, no necesita recursos compartidos adicionales y mantiene la alta disponibilidad mientras haya mayoría.

El inconveniente es que en un clúster con número par de nodos, el riesgo de perder Quorum por una simple caída es real. Además no escala bien para entornos geográficamente distribuidos.

Si montas un clúster de 2 nodos con esta configuración, estás invitando a que se caiga con solo un reboot. Lo llaman “configuración de alto riesgo”.

Node and Disk Majority (Mayoría de nodos y disco testigo)

Aquí añadimos a los nodos un testigo en forma de disco compartido (usualmente un LUN en un SAN), que también vota. Es perfecto para evitar empates en clústeres con número par de nodos. Se usa mayoritariamente cuando tiene clústeres con número par de nodos en el mismo datacenter.

Sigue siendo fácil de configurar si tienes un SAN compartido y evita el split-brain. 

El problema es que el disco es un punto de fallo más. Si falla el disco y un nodo, te vas al suelo. Y si hablamos de Always On con réplicas distribuidas en varios sitios, esta opción no aplica.

¿Un único punto de fallo en una configuración de alta disponibilidad? Brillante.

Node and File Share Majority (Mayoría de nodos y recurso compartido)

En este caso sustituimos el disco testigo por un File Share Witness (FSW), alojado en un servidor accesible por red. No necesita almacenamiento compartido, solo conectividad SMB. Su uso está extendido entre clusters distribuidos o donde no hay almacenamiento compartido disponible.

Es flexible y fácil de montar y, cómo no dependes de un SAN, es ideal para Always On entre sitios.E inconveniente es que el recurso compartido debe estar SIEMPRE disponible y accesible desde todos los nodos. Si cae la conectividad, puede hacer más daño del que parece.

Sí, ese FSW que “nadie sabe muy bien dónde lo pusimos” puede ser lo que decida si tu clúster sobrevive o se apaga. Más vale que esté monitorizado.

No Majority: Disk Only (Solo disco)

Aquí no hay mayoría. El disco decide. Y si el disco falla, adivina qué más falla.

¿Cuándo se usa? La respuesta correcta es NUNCA. O, como mucho, en entornos de laboratorio. No hay excusa para usar esta configuración en producción.

Como ventajas de este tipo de Quorum podríamos destacar NINGUNA y como inconvenientes TODOS: Alta fragilidad, nula tolerancia a fallos. No compatible con Always On.

Si ves esto en un entorno real, haz un RDP al nodo, abre un bloc de notas y escribe tu carta de despido preventivo.

Votos, pesos y cómo romper el clúster sin querer

No basta con elegir el tipo de Quorum. También hay que entender cómo se distribuyen los votos. Cada nodo, por defecto, tiene un voto. Pero puedes ajustar manualmente qué nodos votan. Y también puedes decirle al testigo (FSW o disco) si vota o no.

Esto es útil, pero también peligroso. Quitar votos a la ligera puede provocar que el Quorum se pierda con menos fallos de los que imaginas. Y confiar ciegamente en que “Windows lo ajusta solo” es un camino directo al caos. WSFC puede hacer ajustes automáticos, sí, pero no es infalible. El clúster no tiene bola de cristal.

¿Un ejemplo real? Un clúster de 4 nodos con dos en cada datacenter y un FSW mal ubicado. Si cae la conectividad entre sitios y el testigo queda del lado equivocado, puedes perder todo. Porque, como en las películas malas, gana el lado que tenga más votos. Aunque no tenga la base de datos principal.

Always On y el testigo olvidado

En los grupos de disponibilidad de Always On, mucha gente se obsesiona con los réplicas, los listeners, las rutas de red… y se olvidan del Quorum. Error.

Una réplica en modo síncrono con failover automático NO te sirve de nada si el Quorum no se mantiene en caso de caída. La réplica puede estar perfecta, lista para levantar el grupo, pero si el clúster ha perdido el Quorum, no se produce el failover. Porque el WSFC está abajo. Fin.

Por eso, en entornos con réplicas distribuidas geográficamente, el testigo (FSW) debe estar ubicado estratégicamente. Idealmente, en un tercer sitio con conectividad simétrica. Si no puedes, al menos asegúrate de que el Quorum esté configurado con cabeza.

Y no, no pongas el FSW en uno de los nodos del clúster. No es que vaya a fallar, pero síes una muy mala idea. Es como guardar las llaves de la caja fuerte… dentro de la misma caja.

Casos típicos y cómo configurarlos bien

A modo de ejemplo vamos a repasar las configuraciones más recomendadas en los escenarios más comunes.

  • Clúster de 2 nodos en el mismo datacenter: Node and File Share Majority. FSW en un servidor externo y altamente disponible. Nada de ponerlo en uno de los nodos.
  • Clúster de 3 nodos: Node Majority. Número impar, no hace falta testigo, salvo que tengas paranoia (bien justificada). Si los tres nodos están en ubicaciones distintas, replantéate la estrategia.
  • Clúster con réplicas entre datacenters: Node and File Share Majority. FSW en una tercera ubicación. Y no, “la nube” no es una tercera ubicación si no tienes garantizada la conectividad.

Conclusión

Como muchas cosas en administración de sistemas, el Quorum es esa parte invisible que solo duele cuando falla. Pero cuando falla, duele de verdad. Si gestionas entornos con Always On y no entiendes bien cómo se comporta el Quorum, estás conduciendo a ciegas. Y algún día, te vas a estrellar.

No hace falta que seas un experto en WSFC, pero necesitas saber cómo se configura el Quorum, cómo afecta a la disponibilidad real de tu clúster y, sobre todo, cómo evitar caer en las trampas típicas. Porque no, Always On no lo gestiona “todo solo”. Tú sigues siendo responsable de que el clúster se mantenga vivo. Y para eso, el Quorum es tu piedra angular.

Así que la próxima vez que montes un clúster, o revises uno existente, pregúntate: ¿está el Quorum bien diseñado o estoy viviendo con una bomba de relojería? Porque en producción, el Quorum no perdona.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios
22
Sep
2025

El libro de SQL Server que estabas esperando

Después de más de una década trabajando con SQL Server y ahora compartiendo contenido en SoyDBA, estoy escribiendo un libro pensado para profesionales que quieren ir más allá de la documentación oficial. Un libro técnico y muy didáctico.

Más de 40 capítulos en 7 partes, desde los fundamentos del modelo relacional hasta las herramientas de diagnóstico más avanzadas. Un recorrido completo, pensado para DBAs, analistas y desarrolladores que quieren entender cómo funciona SQL Server de verdad.

Portada Libro

El prólogo lo firma Fernando G. Guerrero, pionero y referente en nuestra comunidad. La contraportada, Juanjo Luna, MVP de Access y más apasionado de SQL de lo que quiere reconocer. Os dejo aquí el texto de la contraportada:

No os voy a engañar; comercialmente, este libro va a ser un fracaso. Escribir más de 200 hojas hablando de un tema que no es de uso práctico, es algo que nadie quiere hoy en día.

Su propia portada ya lo indica: La no guía práctica …

En medio de una sociedad en la que lo que vende es el producto rápido de consumo inmediato, con soluciones mágicas; pretender sacar un producto de este tipo significa ser un… Déjame que busque la palabra… ah sí: MVP

Leyendo el libro, me venía a la cabeza que tenía entre manos el test de la ITV de los DBAs. Si no dominas lo que pone en el libro y gestionas servidores y/o bases de datos, tienes un problema.

¿Por qué deberías leer este libro?

Si eres un neófito del tema, que tan solo consume servicios de datos, sin saber lo que hace, este libro es un itinerario fantástico para saber cómo adentrarte en el mundo de los DBAs.

Para el ya iniciado es el test perfecto para descubrir todo lo que le falta por saber. Cuánto habría dado hace años por tener algo así para poder elegir como progresar, de manera independiente en la gestión de mis servidores de datos.

Si por el contrario, eres realmente un experto, el mero hecho de compartir conocimientos con Roberto Carrancio, es un disfrute que solo los grandes entendidos pueden comprender.

Seas el tipo que seas, el libro que tienes entre manos, no te hará experto en nada; pero te abrirá las puertas para que puedas llegar a serlo.

Escribir este libro justo ahora en el que todo el mundo busca cómo utilizar la IA para que haga las cosas sin necesidad de entenderlas es un error absoluto….

O TAL VEZ NO.

Si quieres conseguirlo corre a Amazón.

El libro está disponible en Amazon en formato papel y Kindle en todo el mundo.

Consigue el libro aquí

Mantente al día de las novedades con mi newsletter gratuita

Logo SoyDBA

Únete a la newsletter de SoyDBA

Regístrate gratis para no perderte ninguna novedad. Te avisaré de noticias y eventos importantes

¡No hacemos spam! Lee nuestra política de privacidad para obtener más información.

Publicado por Roberto Carrancio en Alta Disponibilidad, Cloud, Índices, Rendimiento, SQL Server, 0 comentarios
19
Sep
2025

Backups en SQL Server Always On y novedades en SQL Server 2025

Llevamos años con Always On sobre la mesa, vendiéndolo como la solución de alta disponibilidad y recuperación ante desastres por excelencia en entornos SQL Server. Cuando alguien monta un Availability Group por primera vez, suele pensar que ya tiene resuelta la alta disponibilidad, la recuperación ante desastres, los backups, el estrés y la hipoteca. Y no es mentira, pero tampoco es magia. Quienes lo gestionamos sabemos que montar un AG (Availability Group) es fácil en demos, pero bastante más delicado en producción. Always On resuelve cosas, sí, pero también introduce otras que hay que entender, especialmente cuando hablamos de estrategias de backup.

Y es que, hasta ahora, hacer backups en réplicas secundarias era poco más que un “parche”. Con SQL Server 2025, Microsoft ha introducido una mejora que, aunque llega tarde, se agradece: la posibilidad de hacer backups completos, diferenciales y de logs directamente sobre una réplica secundaria. Vamos a ver qué cambia exactamente y cómo podemos (por fin) diseñar estrategias de backup decentes en entornos Always On.

¿Dónde se hacen los backups en un Availability Group?

Empecemos con lo básico, que no es tan obvio como parece. En un AG, todas las réplicas tienen una copia de la base de datos, pero no todas son iguales ni sirven para todo. A la hora de hacer backups, SQL Server nos permite controlar el comportamiento a través de dos configuraciones clave:

AUTOMATED_BACKUP_PREFERENCE: una propiedad del Availability Group que indica en qué réplica se deben lanzar los backups automáticos (es decir, los lanzados mediante SQL Server Agent, Maintenance Plans, etc.). Esta propiedad puede tomar los valores:

  • PRIMARY: sólo se hacen backups en la réplica primaria.
  • SECONDARY_ONLY: sólo se hacen en las réplicas secundarias.
  • SECONDARY: se prefiere una secundaria, pero se usa la primaria si no hay otra disponible.
  • NONE: no hay preferencia definida, el agente decide.

BACKUP_PRIORITY: una propiedad individual de cada réplica que define su peso relativo a la hora de ser elegida para realizar los backups, si hay varias candidatas disponibles según la preferencia anterior.

Con estas dos configuraciones combinadas, SQL Server decide en qué réplica ejecutar los backups cuando se utilizan herramientas automatizadas. Pero ojo: si ejecutas el backup manualmente (T-SQL, PowerShell, etc.), se lanza en la réplica donde estés conectado. Lo de la preferencia solo aplica en los automatismos.

Logo SoyDBA

Únete a la newsletter de SoyDBA

Regístrate gratis para no perderte ninguna novedad. Te avisaré de noticias y eventos importantes

¡No hacemos spam! Lee nuestra política de privacidad para obtener más información.

Tipos de backups permitidos hasta SQL Server 2022

Ahora bien, no todos los tipos de backup están permitidos en todas las réplicas. Hasta SQL Server 2022 (incluido), las reglas eran bastante limitantes.

Los backups completos (FULL) sólo están permitidos en la réplica primaria, salvo que sean COPY_ONLY, en cuyo caso sí se pueden hacer en réplicas secundarias. Los backups diferenciales (DIFFERENTIAL) tienen el mismo “problema”, únicamente se pueden hacer en la primaria. Por el contrario, los backups de log (TRANSACTION LOG) si se pueden hacer en cualquier réplica (primaria o secundaria), siempre que esté en estado sincronizado o aceptable. Y son válidos como parte de la cadena de recuperación.

En resumen, solo los logs son realmente “migrables” a réplicas secundarias de forma productiva. El resto, si no es COPY_ONLY, requiere pasar por la primaria. Y como ya sabemos, los COPY_ONLY no afectan a la cadena de backups, por lo que no sirven como parte del plan de recuperación principal.

Este escenario genera el clásico problema, la carga de los backups importantes (full y diff) sigue recayendo en la réplica primaria, justo la que está ejecutando cargas de producción críticas. Y claro, luego vienen los lloros por I/O, CPU y ventanas de mantenimiento.

¿Qué cambiará en los backups de AG con SQL Server 2025?

Aquí llega la buena noticia. A partir de SQL Server 2025 (en preview), Microsoft amplía por fin el soporte de backups en réplicas secundarias. Y esta vez de verdad: Ya se podrán hacer backups FULL, DIFFERENTIAL y LOG en réplicas secundarias. Y no en modo COPY_ONLY, sino como parte activa de la cadena de recuperación.

Esto significa que podremos rediseñar completamente nuestra estrategia de backups en entornos Always On. Por ejemplo, podremos mover el backup completo diario a una secundaria, programar los diferenciales en otra y dejar los logs en una tercera. Todo sin tocar la primaria.

Y lo mejor es que no habrá que cambiar nada en la configuración actual del AG. Si ya tenemos configurado AUTOMATED_BACKUP_PREFERENCE = SECONDARY_ONLY y hemos definido prioridades con BACKUP_PRIORITY, esas mismas reglas se aplicarán también a full y diferenciales. Lo único que cambia es lo que SQL Server permitirá hacer técnicamente en cada réplica.

Cómo configurarlo (y cómo comprobarlo)

La configuración es la misma de siempre, para ver el valor actual de la preferencia de backups del AG podemos usar:

SELECT automated_backup_preference_desc FROM sys.availability_groups;

Para ver la prioridad de backup por réplica:

SELECT replica_server_name, backup_priority FROM sys.availability_replicas;

Y, si necesitas modificar la preferencia:

ALTER AVAILABILITY GROUP [NombreDelAG]
SET (AUTOMATED_BACKUP_PREFERENCE = SECONDARY_ONLY);

Y podrás seguir usando la vista sys.dm_hadr_backup_is_preferred_replica para determinar en tiempo real cuál es la réplica preferida según la configuración actual. Ideal para integrarlo en scripts de backup personalizados.

Consideraciones importantes y limitaciones

Como todo cambio de este tipo, hay que tener claro qué implica antes de correr a modificar tus scripts. La réplica secundaria debe estar sincronizada y en estado ONLINE. No sirve una réplica desactualizada o en SUSPENDED. Por supuesto, el backup de log seguirá necesitando una cadena coherente. Como hasta ahora, puedes hacer logs desde réplicas secundarias, pero asegúrate de que tu estrategia de restauración tiene en cuenta su procedencia.

El restaurado no cambiará, si haces un FULL en una secundaria, un DIFF en otra y LOGs en una tercera, tendrás que restaurarlos todos en orden, desde sus respectivas ubicaciones. Esto requiere un buen control del sistema de almacenamiento y del catálogo de backups.

Por último, el rendimiento de las réplicas secundarias importa. No pienses que es buena idea mandar todos los backups a una secundaria con discos lentos y CPU de museo. Es posible, sí. Recomendable, no.

¿Cómo adaptar tu estrategia de backups?

Con esta mejora, por fin podremos plantear una estrategia de backups moderna para Always On, que de verdad aproveche la arquitectura del AG. Algunas ideas:

  • Mueve los FULL y DIFF a réplicas secundarias bien dimensionadas.
  • Mantén los LOGs distribuidos según disponibilidad, pero con control estricto del histórico.
  • Diseña tus planes de mantenimiento con tolerancia a failover: si una réplica cae, otra puede asumir su rol.

Eso sí, no pierdas de vista que toda esta flexibilidad requiere más disciplina. El seguimiento de los backups, la monitorización y la política de retención deben estar muy claros. Porque ahora no hay excusas: puedes repartir la carga, pero también puedes complicarte la vida si no lo haces bien.

Conclusión

SQL Server 2025 traerá una mejora largamente esperada. Por fin podremos hacer backups completos y diferenciales en réplicas secundarias, de forma nativa y como parte del plan de recuperación. No es un parche ni una opción limitada, es un cambio real en cómo el motor entiende las responsabilidades de cada réplica.

Y si aún haces todos los backups desde la primaria, empieza a preguntarte por qué. Porque a partir de ahora, no es que se vaya a poder evitar: es que deberías.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios
14
Jul
2025

Azure MI Failover Group vs SQL Server Always On

Hablar de alta disponibilidad en entornos SQL Server es como entrar en un congreso de arquitectos y preguntar por el hormigón armado: todo el mundo tiene una opinión, pero no todos entienden lo que hace que no se les caiga el edificio. Desde que apareció Azure SQL Managed Instance, muchos han querido comparar su Failover Group con el clásico y reputado Always On Availability Groups (AO AG) de SQL Server. Spoiler: no son lo mismo. Ni en arquitectura, ni en control, ni en flexibilidad. Y por mucho que Microsoft los presente como soluciones “equivalentes” en diferentes contextos, la verdad está en los detalles. Ahí donde el marketing calla y el diagrama de red grita.

¿Qué es un Failover Group en Azure SQL Managed Instance?

El Failover Group (FOG, para los amigos) en Managed Instance es un servicio de Azure PaaS que nos permite tener una réplica automática en otra región, con conmutación por error (failover) automática o manual. No hay que gestionar clústeres, ni certificados, ni configurar endpoints: todo se cocina dentro de la infraestructura de Azure. ¿Ventajas? Sencillez. ¿Limitaciones? También las hay, pero menos de lo que algunos creen.

El Failover Group actúa a nivel de instancia. Replica automáticamente todas las bases de datos del grupo seleccionado, manteniendo sincronización asincrónica entre regiones. Y aunque históricamente tenía fama de ser unidireccional y sin opciones de lectura secundaria, eso ya no es cierto: podemos habilitar acceso de solo lectura a la réplica secundaria a través del listener. Eso sí, solo una réplica, y nada de topologías a medida. Pero para muchos escenarios de DR, es más que suficiente.

¿Y qué hace SQL Server con su Always On Availability Groups?

Aquí volvemos al SQL Server clásico, el de verdad, el que instalamos en máquinas (físicas o virtuales), con clústeres de Windows, certificados, endpoints, y todo lo que da gusto configurar a las tres de la mañana cuando algo falla. El AO AG es un modelo de alta disponibilidad y recuperación ante desastres (HA/DR) basado en grupos de disponibilidad, con réplicas sincronizadas (para HA) y asincrónicas (para DR). Admite múltiples réplicas, balanceo de lectura, conmutación automática o manual, y una flexibilidad que muchos aún no saben que están mal usando.

¿Requiere trabajo? Mucho. ¿Te da control absoluto? También. Y eso, en infraestructuras exigentes, marca la diferencia entre diseñar alta disponibilidad y simplemente esperar que Azure haga lo suyo.

Diferencias técnicas clave

Aquí es donde empieza lo interesante. El Failover Group en MI está limitado por diseño: solo una réplica secundaria, sincronización asincrónica entre regiones y sin opción a topologías complejas. Pero lo compensa con gestión simplificada, y sí, un listener que permite direccionar tráfico de lectura y escritura de forma bastante transparente. El parámetro ApplicationIntent=ReadOnly funciona como esperamos, siempre que tengamos configurado el grupo correctamente.

AO AG, por su parte, permite hasta ocho réplicas, elegir sincronización o asincronía según la necesidad, distribuir la carga de lectura, gestionar failover policies con precisión quirúrgica y hasta usar clusterless AGs para entornos que no necesitan HA pero sí replicación. También nos permite ajustar los parámetros internos de cada réplica, implementar scripts personalizados ante fallos y mantener una visibilidad completa del estado del clúster.

La diferencia crítica sigue siendo el acceso al entorno. En SQL Server AO AG tienes control del sistema operativo, del almacenamiento, de la red y del motor de base de datos en sí. En Managed Instance estás dentro de una caja cerrada: puedes administrar lo que te dejan, y cuando algo se rompe, dependes completamente del soporte de Azure. Que sí, son majos. Pero a veces el SLA no consuela cuando tienes al CTO respirando en la nuca.

Ventajas y limitaciones prácticas

El Failover Group de Azure Managed Instance es ideal para quienes quieren alta disponibilidad sin complicaciones, sin pelearse con Windows Server Failover Clustering, sin pensar en discos compartidos ni quorum. Y con la posibilidad de lectura secundaria, gana puntos en escenarios de DR que también exigen analítica o reporting en caliente.

AO AG, por su parte, permite arquitecturas híbridas, complejas y a medida. Pero requiere un nivel de experiencia y de mantenimiento que no todos los equipos pueden asumir. No es para todos, pero en manos expertas es una bestia formidable. Eso sí, como toda bestia, necesita cuidado constante y algo de cariño (o miedo). Cuidado con meterte en esta solución tan compleja si tu equipo no está preparado o tendrás el caldo de cultivo perfecto para un problema grave.

¿Qué debemos elegir para nuestro entorno?

La decisión real no es entre Failover Group y Always On, sino entre PaaS y IaaS (o on-premises). Si tu equipo no puede o no quiere gestionar infraestructura, el Failover Group en Azure MI es una solución más que decente. Pero si necesitas múltiples réplicas, balanceo de lectura avanzado, configuración personalizada o integración con entornos complejos… entonces AO AG sigue siendo la referencia.

También hay que mirar la criticidad del sistema. ¿Puedes tolerar unos minutos de pérdida de servicio mientras Azure detecta y conmuta? ¿O necesitas failover inmediato y con cero pérdida de datos? El RPO y RTO no son iguales, y en algunos casos eso marca la diferencia entre continuidad del negocio y justificación al comité de crisis.

Los precios de ambas soluciones también son decisivos, en Azure Managed Instance tienes que pagar todos los meses depende del tamaño de tu servidor y eso a la larga puede salir caro. Always On, por su parte, no se queda corto ya que vas a necesitar licencias SQL Server Enterprise y, eso no es barato precisamente.

Casos reales y decisiones que duelen

Recientemente, en un proyecto de consultoría, el cliente tenía que mover un entorno crítico de Always On a Azure MI. Las restricciones del Failover Group se hicieron evidentes al tercer día, cuando se dieron cuenta de que no podían controlar la latencia ni ajustar parámetros finos de sincronización. ¿Solución? Replantear parte de la arquitectura y asumir limitaciones. ¿Resultado? Un entorno funcional, sí, pero menos flexible. Y con la sensación de haber pasado de un Fórmula 1 a un coche automático: cómodo, sí. Pero que no te deja cambiar de marcha cuando más lo necesitas.

Conclusión

Failover Group en Azure MI no es el sucesor espiritual de Always On. Es una solución distinta, pensada para escenarios distintos. Si necesitas control, flexibilidad y múltiples réplicas, Always On sigue siendo el rey. Si priorizas simplicidad y mantenimiento mínimo, Failover Group cumple su papel. Y ahora, con acceso de lectura en la réplica secundaria, es más potente de lo que muchos creen.

Pero no confundamos comodidad con equivalencia. Porque cuando llegue el fallo, lo que importa no es la tecnología, sino cómo responde. Y en ese momento, más vale haber elegido bien. ¿Quieres alta disponibilidad sin sustos? Elige con cabeza, no con prisas. Porque lo único peor que una base de datos caída… es una mal diseñada que no sabe caer.

Publicado por Roberto Carrancio en Alta Disponibilidad, Cloud, SQL Server, 0 comentarios
19
May
2025

Versiones de SQL Server en Amazon AWS

Cuando hablamos de SQL Server en AWS, lo primero que debemos hacer es dejar atrás esa idea ingenua de que “en la nube todo es más fácil”. No, no lo es. Solo es diferente, y en muchos casos, más complejo. Porque cuando mezclamos la gestión de SQL Server con la selva de servicios de AWS, las posibilidades se multiplican… junto con los puntos de fallo. Así que vamos a desgranar, con precisión quirúrgica y sin evangelismos nublados por el marketing, qué opciones reales tenemos cuando queremos desplegar SQL Server en Amazon Web Services.

SQL Server en AWS: más allá del “lift and shift”

Hay dos grandes formas de ejecutar SQL Server en AWS: usar máquinas virtuales (EC2) o servicios gestionados (principalmente RDS). Y sí, hay matices, capas y excepciones, pero si no entendemos esta dicotomía básica, mejor volvemos a estudiar para el examen de certificación.

En esencia, EC2 nos da el control total (y la responsabilidad completa). RDS nos quita dolores de cabeza, pero también libertad. ¿Queremos hacer magia negra con xp_cmdshell, afinar a mano el maxdop, o aplicar un Service Pack que aún no ha salido oficialmente? Entonces EC2. ¿Preferimos que AWS se encargue de los backups, los parches y la alta disponibilidad con solo marcar unas casillas? RDS es nuestro nuevo amigo.

Amazon AWS EC2 con SQL Server: libertad para vivir al límite

Al desplegar SQL Server en instancias EC2, estamos hablando de IaaS de libro. Tú eliges el sistema operativo (Windows, claro, porque hablamos de SQL Server), tú instalas SQL Server, tú configuras todo. También tú lo rompes y lo arreglas.

La ventaja evidente es que puedes usar cualquier edición de SQL Server: Express, Web, Standard o Enterprise. Puedes traer tu propia licencia (BYOL, Bring Your Own License) o usar las licencias incluidas en la AMI (Amazon Machine Image) oficial con licencia de pago por uso.

Esta opción brilla en entornos que necesitan configuraciones exóticas o donde el cumplimiento normativo exige control absoluto sobre el sistema. También en arquitecturas donde SQL Server no está solo, sino embebido en un sistema complejo que se despliega como un todo.

¿El coste? Altísimo si no controlamos los recursos. Sí, puedes tener una r6i.16xlarge para presumir, pero luego no te quejes cuando el informe mensual de AWS te haga llorar más que un RAISERROR con severidad 25.

Amazon AWS RDS para SQL Server: el camino del zen (limitado)

RDS (Relational Database Service) ofrece SQL Server como servicio gestionado. Lo eliges desde la consola, eliges la edición, el tamaño, las opciones de almacenamiento, y listo: tienes una instancia SQL Server “as a service”.

Aquí puedes elegir entre las ediciones Web, Standard y Enterprise. Express solo está disponible en RDS para desarrollo y pruebas muy básicas. Las versiones van desde SQL Server 2012 hasta 2022, aunque las más antiguas ya huelen a rancio y deberían estar fuera de toda conversación seria.

AWS se encarga del parcheo, los backups automáticos, la monitorización con CloudWatch, la alta disponibilidad con Multi-AZ, y hasta de restaurarte una base de datos si te la cargas (dentro del periodo de retención). Muy cómodo, sí. Pero el precio de esa comodidad es la limitación.

Por ejemplo, no puedes usar funciones como FILESTREAM, SQL Server Agent personalizado, CLR Unsafe, xp_cmdshell, ni muchos otros elementos avanzados. Tampoco puedes instalar software adicional en el sistema operativo ni afinar el motor a nivel de sistema. ¿Es suficiente para la mayoría de los casos de uso? Sí. ¿Es frustrante cuando necesitas hacer algo fuera del guión? También.

¿Qué ediciones están disponibles en AWS y cuándo usarlas?

Aquí es donde las diferencias entre EC2 y RDS se hacen más evidentes. En EC2 puedes instalar lo que quieras, como si estuvieras en tu CPD de toda la vida. RDS, en cambio, restringe la elección a ediciones licenciadas por AWS.

  • SQL Server Express: limitada hasta el absurdo. Solo útil en pruebas o en ese ERP vintage que aún cabe en 10 GB. Está disponible en EC2 y en RDS.
  • SQL Server Web Edition: solo para aplicaciones web y bajo ciertas condiciones. Más barata que Standard, pero con muchas limitaciones. Solo disponible en RDS si tu contrato lo permite.
  • SQL Server Standard: el caballo de batalla. Lo suficientemente potente para la mayoría de workloads OLTP, con soporte de hasta 128 GB de RAM y sin las florituras de Enterprise. Disponible tanto en EC2 como en RDS.
  • SQL Server Enterprise: para cuando ya no hablamos de bases de datos, sino de feudos de datos. Requiere justificar su coste, pero habilita funciones como Always On, compresión de datos, particionamiento, y el Query Store decente (no el recortado de Standard). También disponible en ambas opciones.

Versiones disponibles en AWS: sí, también hay letra pequeña

En RDS, las versiones disponibles van desde SQL Server 2012 hasta 2022 (según la región y el tipo de instancia). Pero no siempre están todas. Hay regiones donde 2022 aún no está disponible o donde ciertas ediciones se ofrecen solo en ciertas clases de instancias. Y no esperes instalar CUs al día siguiente de su publicación: AWS sigue su propio calendario de validación, lo cual está bien si valoramos la estabilidad… y menos bien si necesitamos esa CU concreta para resolver un bug que nos está friendo en producción.

En EC2, como tú te lo guisas, tú decides qué versión instalar. Pero no te olvides de los ciclos de soporte. Instalar SQL Server 2016 en 2025 es como llevar un Nokia 3310 a una reunión de arquitectura cloud: nostálgico, pero absurdo.

Y si hablamos de costes… prepara la cartera

Ni EC2 ni RDS son baratos si no se diseñan con cabeza. RDS tiene costes predecibles, pero no siempre bajos. EC2 puede salir caro si dejamos las instancias encendidas todo el mes sin monitorizar nada. Y el coste de las licencias es otra historia. SQL Server no es barato, y Amazon lo sabe.

En RDS pagamos licencia por hora. En EC2 podemos traer nuestras licencias con Software Assurance, lo cual puede ahorrar bastante en escenarios Enterprise. Pero si lo haces mal, puedes terminar pagando el doble por rendimiento inferior. La arquitectura importa, y mucho.

¿Y qué pasa con la alta disponibilidad en AWS?

En EC2, la alta disponibilidad te la montas tú: con Always On Availability Groups, con failover clustering, o con lo que prefieras… y se te ocurra mantener. En RDS, basta con activar la opción Multi-AZ y dejar que AWS haga el trabajo sucio. Pero no confundamos Multi-AZ con Always On: RDS usa su propio sistema de replicación bajo el capó, que no es transparente ni configurable.

Si necesitas un AG real con réplicas legibles, bienvenido a EC2. Y prepárate para montar la infraestructura necesaria: subredes, listeners, quórum, test de failover, etc. ¿Merece la pena? Depende de lo que estés dispuesto a sacrificar por la comodidad.

Te recomiendo ver la sesión de Francisco Amat sobre este tema para llevar tu alta disponibilidad al siguiente nivel.

Conclusión

No hay una única respuesta correcta a la pregunta “¿cómo desplegamos SQL Server en AWS?”. Hay decisiones técnicas, estratégicas y económicas que tomar. EC2 es más flexible, pero también más arriesgado. RDS es más cómodo, pero impone más restricciones.

La elección depende del tipo de carga, del nivel de control que necesitamos, de los costes que estamos dispuestos a asumir y, por supuesto, de cuántos fuegos queremos apagar a las tres de la madrugada.

Así que no, no es cuestión de levantar una base de datos “en la nube” y seguir con nuestra vida. Es cuestión de entender cada opción, sus límites y sus consecuencias. Porque en AWS, igual que en la vida, cada elección tiene su precio. Y a veces, ese precio se mide en IOPS… o en dignidad.

¿Quieres rendimiento extremo, fine-tuning y llorar en modo sysadmin? EC2. ¿Prefieres comodidad, escalabilidad rápida y vivir con algunas restricciones? RDS. Tú decides. Pero decide con conocimiento, no con fe ciega en el marketing cloud.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Alta Disponibilidad, Cloud, SQL Server, 0 comentarios
07
May
2025

10 cosas que debe tener tu DRP de SQL Server

Un buen Plan de Recuperación ante Desastres (DRP) en SQL Server no se improvisa con prisas ni se resuelve con un backup semanal en una carpeta compartida. Quien piense lo contrario probablemente también crea que los backups verificados se restauran solos por arte de magia. Aquí venimos a poner orden. Vamos a repasar diez elementos que deben estar presentes en cualquier DRP decente, serio y pensado por alguien que sabe lo que significa tener producción caída más de 15 minutos.

DRP Check 1: Inventario de instancias y bases de datos críticas

Antes de correr a hacer backups como si el mundo se acabara, hace falta saber qué estamos protegiendo. Un DRP sin inventario es como un GPS sin destino. Documentar todas las instancias SQL Server, su versión, configuración, bases de datos alojadas, y cuál de ellas es crítica es el primer paso. Sin eso, el resto del plan será un ejercicio de fe.

Esto incluye nombres, versiones, configuración regional, nivel de compatibilidad, y por supuesto, si estamos hablando de SQL Server On-Prem, en Azure, en máquinas virtuales o en una mezcla caótica digna de una pesadilla DevOps.

DRP Check 2. Estrategia de copias de seguridad (real y testada)

Esto no va de tener un script que haga BACKUP DATABASE, sino de tener un plan de backups bien definido, ajustado al SLA del negocio y validado con restauraciones periódicas. Porque sí, hacer backups sin probar restores es como llenar el depósito del coche sin saber si tienes motor.

Y recuerda debes incluir backups completos, diferenciales y de logs si la base está en FULL.

DRP Check 3. Plan de restauración documentado (y probado, otra vez)

Vale, ya tenemos backups. ¿Y ahora qué? Un DRP sin un procedimiento claro de restauración es solo un acto de fe. Hay que documentar cómo restaurar cada tipo de backup, en qué orden, en qué entorno, y cuánto tiempo se estima que llevará. No valen suposiciones.

¿Se han probado esas restauraciones en un entorno aislado? ¿Se ha medido el tiempo real? ¿Se ha verificado que la aplicación vuelve a levantar sin errores? Si la respuesta es no, el DRP es papel mojado.

DRP Check 4. Topología de alta disponibilidad y replicación

La disponibilidad no es solo cosa del DRP, pero forma parte de él. Un clúster de Always On, una replicación transaccional o un Log Shipping bien montado pueden ser la diferencia entre una caída de horas y una recuperación en minutos.

Aquí hay que documentar cómo están montadas esas soluciones, cómo se comportan ante fallos y, lo más importante, cómo se revierte o se conmutan sin pérdida de datos. Porque el botón “Failover” no es magia, y conviene saber qué pasa antes de pulsarlo.

DRP Check 5. Matriz de responsabilidad (quién hace qué y cuándo)

En medio del caos no hay tiempo para preguntar «¿quién se encarga de esto?». Un DRP debe tener definidos claramente los roles: quién inicia el protocolo, quién comunica a negocio, quién ejecuta los scripts, quién valida y quién da el OK final.

Y no, no vale con poner “El DBA” para todo. Porque el DBA también duerme (al menos en teoría) y puede que no esté disponible a las 3:00 de la mañana un festivo. Así que planifica relevos, turnos y contactos de emergencia. Y por supuesto, guarda esa información fuera del entorno afectado.

DRP Check 6. Procedimiento para activar el DRP

No todo fallo es un desastre. Un plan serio define umbrales: ¿cuándo se considera que hay que activar el DRP? ¿Cuánto tiempo puede estar caída una instancia sin que salten las alarmas? ¿Hay una ventana para intentos de recuperación antes de iniciar failover?

Este punto es crítico. Muchos planes fallan porque nadie sabe cuándo hay que usarlos. Y cuando se deciden, ya es tarde y el daño está hecho. Un buen DRP se activa con decisión, no con debates.

DRP Check 7. Infraestructura de recuperación (y entorno preconfigurado)

Recuperar una base de datos en un entorno que no existe es una broma de mal gusto. El DRP debe incluir un entorno de recuperación configurado con antelación: máquinas, redes, almacenamiento, seguridad… todo listo para levantar una instancia funcional.

Si estás en Azure o AWS, tener imágenes de máquinas o plantillas ARM listas para desplegar reduce el tiempo de recuperación drásticamente. Si estás en On-Prem, tener máquinas físicas o virtuales reservadas para contingencias no es un lujo, es prevención.

DRP Check 8. Automatismos y scripts listos para ejecutar

En medio del desastre, lo último que queremos es escribir scripts a mano o copiar/pegar desde un correo de 2017. El DRP debe contener los scripts ya preparados para tareas como restaurar backups, reconfigurar logins, recrear jobs, reiniciar endpoints y comprobar integridad.

Cuanto más automático esté todo, menos errores y más rapidez. Pero cuidado: automatizar sin entender es un atajo al desastre. Automatización sí, pero documentada, validada y revisada.

DRP Check 9. Validación post-recuperación

El DR no termina cuando el servidor levanta. Termina cuando la aplicación vuelve a funcionar, los usuarios acceden y nadie grita por Teams. El plan debe incluir validaciones técnicas (integridad, acceso, jobs funcionando, monitoreo operativo) y funcionales (consultas clave, flujos de negocio).

Aquí es donde muchos se relajan demasiado pronto. Recuperar una base sin comprobar que los índices no están corruptos o que el SQL Agent arranca, es como arreglar un coche y no probar que arranca. Todo debe quedar verificado y documentado.

DRP Check 10. Revisión y simulacros regulares

Por último, un DRP no es un PDF que se guarda en una carpeta y se olvida. Es un documento vivo que hay que revisar y probar. Idealmente, al menos una vez al año (y si el entorno cambia, con cada cambio relevante).

Los simulacros revelan errores, tiempos reales, dependencias ocultas y, sobre todo, preparan al equipo. No hay vergüenza en fallar en un simulacro. La vergüenza viene cuando el desastre es real y nadie sabe ni por dónde empezar. Y sí, si nunca has hecho un simulacro y crees que todo va a salir bien, te deseo la mejor de las suertes. La vas a necesitar.

Conclusión

Un DRP de SQL Server no es un archivo bonito con diagramas de PowerPoint. Es una estrategia detallada, técnica y validada que te permite dormir un poco más tranquilo (solo un poco). Tiene que estar alineado con el negocio, ejecutado por profesionales y probado con rigor.

Dejarlo para otro día es como ignorar un CHECKDB con errores porque “no ha fallado nada todavía”. Lo sabes tú, lo sabemos todos: el desastre no avisa. Pero sí se entrena. Así que más vale tener el plan listo y no necesitarlo, que necesitarlo y tener que improvisar.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

 

Publicado por Roberto Carrancio en Alta Disponibilidad, Cloud, SQL Server, 0 comentarios