Dado que el tema de Alta disponibilidad me apasiona bastante, y ya que alguno de vosotros me ha realizado alguna pregunta en privado y por correo, a raíz los post que publique en mi blog sobre Always On o incluso la Combinación de Always On con Service Broker + Multitas, artículos que recomiendo su lectura para tener una visión general, ahora voy a comentaros algo mas sobre el mundo de la Alta disponibilidad ligado con SQL Server desde la versión 2008 R2, versión que bajo mi punto de vista, es donde se marca la diferencia respecto a versiones anteriores. Mi intención no es abordar el tema con un gran profundidad técnica, aunque si lo solicitáis me plantearé publicar algo mas técnico…
Desde el punto de vista de sistemas, las tecnologías que hay dentro de SQL Server 2008 R2 son:
- Database Mirroring (Failover a nivel de BD)
- Log Shipping (Segunda localización para recuperación de datos)
- Replicación (Informes y redundancias de consultas)
- Clustering (Failover a nivel de servicio)
Podemos diferenciar varios niveles para decidir que tipo de Disponibilidad implementaremos:
- Nivel Bajo à Sin recuperación automática con posible pérdida de datos
Backup / Restore
- Nivel Medio à Recuperación manual con posible pérdida de datos
Log Shipping
Replicatión
- Nivel Alto à Recuperación automática sin pérdida de datos.
Database Mirroring
Failover Clustering
Utilizando las diferentes tecnologías de alta disponibilidad, podemos llegar a diseñar e implementar arquitecturas, las cuales no tengan ningún tipo de limitación.
Una vez que nos digan, cual tiene que ser el tipo de repuesta (el RTO y el RPO que se necesitan), podremos decidir que vamos a poner en nuestra capa de datos. Ya no existen las limitaciones que existían antiguamente, que técnicamente llevaban a usar productos de terceros para poder decir que nunca se iba a perder un dato y/o con tiempo de respuesta igual a 0.
Lo bueno de la Alta Disponibilidad, es que esta definido como combinar un Failover Cluster + Database Mirroring o Database Mirroring + Log Shipping… Se puede llegar a replicar los datos, con estas combinaciones, en sistemas de alta disponibilidad, de forma sincrona transnacional, sin ninguna limitación de GeoCluster y/o Almacenamiento. El objetivo de SQL es llegar a tener un RTO (tiempo de respuesta) siempre 0 o tendiendo a 0, la tendencia a 0 depende mas realmente del hardware que metamos por debajo que de las funcionalidades del software.
Sobre estas tecnologías, he podido participar en proyectos, definiendo e implantando sobre sistemas de alta disponibilidad, de clientes grandes, con dos CPDs, que entre ellos formen un GeoCluster, que además usen cabinas de almacenamiento SAN donde meten un nivel de replicación hardware, mas la replicación software que queramos implementar con SQL Server, con nodos exclusivos y dedicados a BI como por ejemplo a Reporting…
O incluso definir entornos medios (algo más pequeños que los anteriores), en donde se delegua mas sobre los nodos que hay en los CPDs de respaldo, donde contámos con replicación de datos a nivel de software nada mas, sin ningún tipo de limitación…
Estas soluciones pueden darse, en ámbitos de maquinas físicas o “virtuales”.
En entornos virtuales he disfrutado de Live Migration con Hyper-V, donde podemos mover instancias ejecutándose en maquinas virtuales entre diferentes host. O nos permite mover las maquinas virtuales para mantenimiento o para balancear las cargas sobre los host. Y permite realizar mantenimientos de las maquinas físicas sin tiempos de caídas. Todo esto desde Windows Server 2008 R2 Hyper-V.
Desde mi punto de vista, hace un año o algo mas, yo me encontraba mas seguro con entornos de SQL sobre maquina físicas que en virtual, la verdad que no se porque, mas bien por cuestiones religiosasJ… digo yo… pero con el paso del tiempo, esta opinión ha ido desapareciendo. Ya que por requerimiento de los clientes, he montado y trabajado con soluciones de Hyper-V o VMware, estables y confiables. Insisto, simple pensando para implementar SQL en un entorno virtual: Hyper-V R2 à Windows Server 2008 R2 o superior, no la versión anterior… La versión R2 es a partir de la cual nos va a dar la funcionalidad del estilo Live Migración, es decir, que se tenga dos nodos, ambos nodos tenga una maquina virtual de SQL Server en memoria, y que no pierdas ninguna conexión cuando caiga uno de los nodos, dado que todo el contenido de memoria este sincronizado automáticamente, entre ambos nodos, y los clientes bien con aplicaciones externas o internas a tu infraestructura no pierdan ni un solo segundo, también para operaciones de mantenimiento (realizando movimiento de un nodo a otro), o migraciones de Datacenters,…
Fuentes:
Microsoft, msdn, TechNet blog, propias...
Apunte y recopilación por Norman M. Pardell
Puedes consultarme, si deseas cualquier aclaración, pregunta o sugerencia en: Contacto, contestaré tan pronto como me sea posible.
