GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

SQL Server 2012 AlwaysON Availabity Groups (AG)


Sin lugar a dudas, AlwaysON Availability Groups (AG) es la principal novedad incluida en SQL Server 2012. El presente artículo presenta esta nueva tecnología de Bases de Datos en Alta Disponibilidad, describiendo diferentes casos de uso, así como varios detalles interesantes, como la utilización de Almacenamiento Asimétrico (Asymetric Storage) y la configuración de Nodos de Cluster sin Voto en el DataCenter de respaldo para aumentar la Disponibilidad. ¿Aún no conoces AlwaysON? A qué esperas !

SQL Server 2012 AlwaysON Availability Groups (AG) es capaz de juntar las tecnologías de Database Mirroring (DBM) y Windows Server Failover Cluster (WSFC), y obtener lo mejor de ambos mundos: una nueva tecnología de Bases de Datos en Alta Disponibilidad, que casi deberíamos llamar SuperMirror ó CachoMirror. Jeje ;-)

La configuración de AlwaysON Availability Groups sobre SQL Server 2012 requiere previamente de la instalación de un Failover Cluster, como paso previo requerido. Sin embargo, no se trata de una instalación típica, ya que dispondremos de diferentes alternativas de diseño, pudiendo utilizar discos locales y/o discos compartidos (incluyendo Almacenamiento Asimétrico), pudiendo realizar instalaciones de SQL Server 2012 en Cluster (Failover Cluster Instance - FCI) o en Standalone, más las propias configuraciones del AlwaysON Availability Groups. En este aspecto, resulta un cambio de diseño más que sorprendente, en comparación con las versiones anteriores de SQL Server, que llega incluso a resultar bastante confuso en la primera toma de contacto con AlwaysON, pero que finalmente acaba siendo muy fácilmente entendible, sensato, potente, y sobre todo divertido.

Alta Disponibilidad (HA) y Recuperación ante Desastre (DR)

Dos términos de los que hablaremos bastante junto con AlwaysON Availability Groups son HA y DR, por lo que antes de continuar con nuestro camino, vamos a hacer un kit-kat para introducir ambos conceptos, y evitar confusiones innecesarias desde un principio.

  • Alta Disponibilidad (High Availability – HA). Se refiere a la Tolerancia a Fallos, es decir, a la recuperación rápida del servicio en caso de fallo, evitando una indisponibilidad.
  • Recuperación ante Desastre (Disaster Recovery – DR). Se refiere a la capacidad de recuperar el servicio ante una situación de desastre, quizás en un CPD Secundario, incluso asumiendo que el CPD Principal se ha perdido definitivamente.

Dicho esto, parece que ambos términos se refieren a lo mismo, pero existe cierto matiz. Pongamos un ejemplo para aclararlo:

  • Si montamos una Instancia de SQL Server en un Cluster con dos Nodos en un mismo CPD, estaremos ofreciendo una solución de Alta Disponibilidad (HA), ya que ante la pérdida de uno de los Nodos, podremos continuar ofreciendo el servicio desde el otro Nodo. Y si además, existen múltiples caminos de red (Ethernet) y de almacenamiento (SAN), y la cabina de discos está replicada, pues mejor. Suele implicar la posibilidad de un Failover Automático. Sin embargo, ante una situación de desastre (ej: un desastre natural que arruine nuestro preciado CPD), estaríamos totalmente desprotegidos: tenemos todos los huevos en la misma cesta. No hay DR.
  • Si montamos una segunda Instancia de SQL Server en otro CPD (indiferentemente de que la montemos en Cluster o Standalone), y establecemos un Database Mirror (DBM) para cada BBDD, estaremos ofreciendo una solución de Recuperación ante Desastres (DR). En este caso, ante un desastre producido en el CPD Principal, podríamos ofrecer el servicio desde el CPD Secundario, aunque quizás necesitemos realizar alguna acción manual para completar correctamente el Failover (ej: cambiar las Cadenas de Conexión de alguna aplicación). Este tipo de solución se denomina FCI+DBM (Failover Cluster Instance + Database Mirroring)

Por poner otro ejemplo, podríamos tener montada una Instancia de SQL Server en un Cluster de dos Nodos, con cada Nodo en un CPD distinto (con una solución de Almacenamiento Compartido, Simétrico y Replicado entre CPDs), ofreciendo de este modo una solución de HA y DR. Este tipo de escenarios es bastante típico (al menos para mí, que trabajo en un entorno así todos los días desde hace unos años ;-), y en muchos casos suele montarse junto con alguna tecnología de Extensión de VLANs (stretch VLAN), de tal modo que la misma VLAN esté presente en ambos CPDs. En cualquier caso, se trata de una solución bastante cara (licencias del Almacenamiento Compartido y Replicado, Extensión de VLAN, más el resto de HW, SW, y Comunicaciones… una pasta…), y además el canuto que une ambos CPDs en ocasiones puede hacer de cuello de botella, añadiendo latencias.

Otro punto a recalcar: cuando hablamos de una Instancia en Cluster, estamos hablando de HA y/o DR a nivel de toda la Instancia, mientras que cuando hablamos de Database Mirroring estamos hablando de HA y/o DR a nivel de Base de Datos.

Antes de pasar al siguiente tema, es muy importante recordar que independientemente de las soluciones de HA y DR que usemos, deberemos seguir haciendo Backups. Sin Backups, no hay paraíso.

AlwaysON Availability Groups (AG)

AlwaysON nos permite poder definir Grupos de Disponibilidad (Availability Groups – AG), formados por una o más Bases de Datos, que pueden ser sincronizadas entre varias instancias, de tal modo, que pueda realizarse una sincronización síncrona (para propósitos de HA, con el correspondiente coste de Latencia por Transacción) o una sincronización asíncrona (para propósitos de DR).

El concepto de Réplicas dentro del contexto de AlwaysON, es similar al Database Mirroring (DBM), sólo que incluye varias diferencias y mejoras, que hace que podamos incluso denominarlo Mirror 2.0 ó SuperMirror:

  • Grupos de Disponibilidad (Availability Groups – AG). Podemos crear uno o varios Grupos de Disponibilidad, cada uno de los cuales puede incluir una o varias Bases de Datos, de tal modo que el balanceo (Failover) de las mismas se realice de todas las bases de datos a la vez. Cada Grupo de Disponibilidad se materializará en un Grupo de Recursos del Failover Cluster.
  • Es posible definir hasta cinco réplicas en cada Grupo de Disponibilidad, una réplica principal (accesible en modo lectura/escritura) y hasta cuatro secundarias.
  • Sólo podemos crear la Réplicas en Instancias SQL Server que se estén ejecutando en Nodos del mismo Failover Cluster (Standalone o FCI), no siendo posible entre Instancias miembros de Cluster distintos.
  • Es posible configurar una o varias réplicas secundarias como accesibles en modo sólo lectura, de forma que se puedan utilizar para ejecutar informes, realizar descargas de datos, etc., descargando de trabajo a la réplica principal. Téngase en cuenta que la carga de trabajo de sólo-lectura realizada con las Instancias Secundarias utilizarán de forma implícita (y automática) el Modo de Aislamiento de Versionado de Filas (Row Versioning), de tal modo que se minimicen los bloqueos que podrían ocurrir al aplicar las transaccinoes provenientes del Principal (escrituras) con las lecturas que se estén produciendo en el Secundario.
  • Es posible utilizar las réplicas secundarias para realizar Backups desde ellas, de tal modo, que se libera de la carga de trabajo de los Backup a la réplica principal, teniendo en cuenta que sólo estarán permitidos los Backups de LOG y los Backups FULL WITH COPY_ONLY, es decir, no podremos realizar Backups FULL convencionales ni Backups Diferenciales (estos sólo los podremos realizar desde la Instancia que actúe como Principal).
  • Es posible crear un Listener en cada Grupo de Disponibilidad, de tal modo, que los usuarios puedan conectarse utilizando los datos de conexión de dicho Listener, independientemente de qué Instancia esté actuando de Principal. Esto es posible porque cada Listener se materializará en un Recurso de Nombre con un Recurso de IP asociado (con el correspondiente registro Alias en DNS y la correspondiente Cuenta de Equipo en Directorio Activo), dentro del Grupo de Recursos correspondiente a dicho Grupo de Disponibilidad.
  • Si utilizamos una Instancia de SQL Server en Cluster (FCI) como Principal, estaremos condicionados a utilizar un Failover Manual. Esto es By Design: FCI nos dará el HA, mientras que AlwaysON nos dará DR.
  • Todas las Instancias en Cluster (FCI) deben tener Nombres de Instancia distintos (ej: no podemos tener dos Instancias por Defecto en el mismo Cluster). Bueno, esto realmente nos debe de dar igual, ya que podemos utilizar los Listener para abstraernos de este tipo de detalles.
  • A diferencia de Database Mirroring (DBM), en AlwaysON no existe el rol del árbitro (Witness).

Por lo demás es muy parecido al Database Mirroring (DBM), pues deberemos configurar nuestras Bases de Datos en Modo de Recuperación Completo, podremos configurar las réplicas como síncronas o como asíncronas, etc.

Realizada esta explicación, surge la siguiente duda: Entonces ¿Para qué queremos el Database Mirroring en SQL Server 2012? Pues por ejemplo como soporte de HA y/o DR entre instancias de SQL Server que no pertenezcan al mismo Failover Cluster (o que no pertenezcan a ningún Cluster en absoluto).

Failover Cluster y AlwaysON Availability Groups: vaya par de colegas !

Lo debemos tener muy claro: Para habilitar AlwaysON, deberemos haber instalado previamente el Failover Cluster. Esto es requisito, es By Design, como podemos ver a continuación (un screenshot vale más que mil palabras ;-).

Para habilitar AlwaysON, deberemos haber instalado previamente el Failover Cluster

Es más, todos los servidores SQL que intervengan en nuestra solución AlwaysON deben ser miembros del mismo Failover Cluster (esto también es requisito de AlwaysON). Es decir, AlwaysON nos ofrece una solución de HA y DR dentro del mismo Cluster (within), y no entre diferentes Clusters (between), en cuyo caso deberíamos de utilizar otras soluciones como Database Mirroring (DBM).

Sin embargo, esto no debemos verlo como un simple e incómodo requisito, ni como un inconveniente. Todo tiene una explicación, y es que, por decirlo de algún modo, AlwaysON Availability Groups junta lo mejor de dos mundos: Failover Cluster y Database Mirroring. Y esto, se puede ver muy claramente en el caso de los Listener.

Entendido. Hasta aquí todo bien, dentro de lo esperado. Sin embargo, ahora empieza lo gracioso del asunto.

No es necesario utilizar un Almacenamiento Compartido (Shared Disk), aunque si lo deseamos podemos utilizarlo, incluso podemos tener un Cluster con Almacenamiento Asimétrico. OK. Y esto ¿cómo se come?

Pues muy fácil. Hasta ahora, con las versiones anteriores de SQL Server, siempre que montábamos un Failover Cluster, seguidamente realizábamos la instalación de SQL Server en Cluster (lo que se llama una FCI – Failover Cluster Instance). Esto era así, sí o sí. Pero ahora la historia ha cambiado, y quizás, este sea uno de los aspectos que pueda causar más confusión al empezar a conocer AlwaysON: Con AlwaysON, podemos realizar instalaciones de SQL Server en Cluster (FCI) y/o instalaciones de SQL Server Standalone, pero en todos los casos, debe estar el Failover Cluster instalado, y todos los servidores deben ser miembros del mismo Cluster.

Quizás, dicho todo esto, la confusión causada pueda ser incluso mayor. Pero no pasa nada. Eso se soluciona mostrando algún escenario de ejemplo:

  • AlwaysON con dos servidores en CPDs distintos y almacenamiento local. En esta configuración, tendremos dos servidores miembros del mismo Failover Cluster, realizando una instalación de SQL Server 2012 Standalone sobre cada servidor, y configurando AlwaysON con una Replicación Síncrona con Failover Automático. Esta solución se la conoce como AlwaysON Availabity Groups for HA and DR.
  • AlwaysON con cuatro servidores en dos CPDs distintos (2 + 2), y almacenamiento compartido local en cada CPD (es decir, un Almacenamiento Asíncrono, con dos redes SAN completamente independientes). En este caso, tendremos cuatro servidores miembros del mismo Failover Cluster, con dos instalaciones de SQL Server 2012 en Cluster (FCI) para conseguir HA, una en cada CPD, y cada instancia con un almacenamiento compartido propio y local al CPD al que pertenece. Configuraremos AlwaysON con una Replicación Síncrona y Failover Manual (para conseguir DR), siendo también posible la opción de Replicación Asíncrona (mejorando el rendimiento a consta de asumir una posible pérdida de datos en el DR). Esta solución se la conoce como FCI+AG (Failover Cluster Instance con Availability Groups).
AlwaysON con cuatro servidores en dos CPDs distintos (2 + 2), y almacenamiento compartido local en cada CPD.
  • AlwaysON con tres servidores en dos CPDs distintos, 2 servidores en un CPD Principal con almacenamiento compartido y un tercer servidor en un CPD Secundario con almacenamiento local (Almacenamiento Asimétrico). En este caso tendremos una instalación de SQL Server 2012 en Cluster (FCI) sobre los dos Nodos que tienen el almacenamiento compartido para conseguir HA, así como otra instalación de SQL Server 2012 Standalone sobre el tercer Nodo. Configuraremos AlwaysON con una Replicación Síncrona con Failover Manual para conseguir DR. Esta solución se la conoce como Failover Cluster Instance for local HA and Availability Group for DR.
AlwaysON con tres servidores en dos CPDs distintos, 2 servidores en un CPD Principal con almacenamiento compartido y un tercer servidor en un CPD Secundario con almacenamiento local (Almacenamiento Asíncrono)

Almacenamiento Asimétrico

Tradicionalmente, siempre ha sido necesario la utilización de un Almacenamiento Compartido Simétrico para poder montar un Failover Cluster, es decir, todos los Nodos debían tener visibilidad sobre los mismos discos compartidos.

Sin embargo, como hemos comentado, con AlwaysON es posible montar un Failover Cluster con un Almacenamiento Compartido Asimétrico, en el que NO todos los Nodos tienen visibilidad sobre los mismos discos. Es decir, cada Disco Compartido puede ser presentado a sólo un sub-conjunto de los Nodos del Cluster.

Entonces ¿Es posible utilizar Almacenamiento Compartido Asimétrico al montar un Failover Cluster? Correcto y no. Me explico. Por defecto, ni en Windows Server 2008 R2 RTM, ni en versiones anteriores, es posible montar un Failover Cluster con Almacenamiento Asimétrico. Sin embargo, la instalación del SP1 de Windows Server 2008 R2 ó del correspondiente HotFix en Windows Server 2008, hace que sea posible montar un Failover Cluster con Almacenamiento Asimétrico, tal y como describe la siguiente KB: Hotfix to add support for asymmetric storages to the Failover Cluster Management MMC snap-in for a failover cluster that is running Windows Server 2008 or Windows Server 2008 R2

Realizado esto, podremos aprovecharnos del Almacenamiento Asimétrico en un Failover Cluster, teniendo en cuenta que para aquellos Discos Compartidos que sólo estén presentados a un sub-conjunto de los Nodos del Cluster, obtendremos un Warning como el siguiente al intentar Validar el Cluster: Disk with id XYZ is visible or cluster-able only from a subset of nodes

Además está recomendado que todas las Instancias involucradas en una instalación de AlwaysON Availability Groups, utilicen las mismas letras de unidad, incluso en el caso del Almacenamiento Asimétrico. En caso contrario, no podremos agregar ficheros a una BBDD replicada (deberemos quitar la réplica y volver a añadir la BBDD al Grupo de Disponibilidad).

En consecuencia, como podemos observar, el Almacenamiento Asimétrico es una de las claves de la tecnología AlwaysON de SQL Server 2012.

El Modelo de Quorum de Failover Cluster con SQL Server 2012 AlwaysON

Otro tema importante a tratar: El Modelo de Quorum. Las configuraciones de Failover Cluster con SQL Server 2012 AlwaysON, suelen implicar una configuración peculiar del Quorum. Pensemos en una solución FCI+AG (Failover Cluster Instance con Availability Groups), formada por dos FCIs, una en un DataCenter Principal y la otra en un DataCenter Secundario, con una Replicación Síncrona con Failover Manual. En este caso, al tener un número par de Nodos (4 Nodos), necesitaríamos añadir un árbitro (Witness), como Disco o un File Share, que proporcione un quinto voto de desempate, que permita que se produzca el síndrome del cerebro partido (Split Brain). Esto sería, a priori, una configuración normal y apropiada.

Pues estamos equivocados. Pensemos que en alguna ocasión el DataCenter Secundario no está disponible. En este caso, quedan tres de cinco Votos, por lo que el servicio se podrá seguir prestando (existe mayoría). Sin embargo, si en esta situación se produjese una indisponibilidad de uno de los Nodos existentes en el DataCenter Principal, tendríamos un serio problema, ya que perderíamos la mayoría (sólo tendríamos dos de cinco Votos), por lo que el servicio de Cluster de detendría.

Tenemos un problema, ya que el DataCenter Secundario está afectando a la forma de calcular la mayoría, lo que en algunas situaciones nos puede producir una indisponibilidad no deseada, un susto innecesario, y si tenemos SLAs hasta nos puede costar una penalización. ¿Qué podemos hacer?

Tenemos un problema, ya que el DataCenter Secundario está afectando a la forma de calcular la mayoría, lo que en algunas situaciones nos puede producir una indisponibilidad no deseada, un susto innecesario, y si tenemos SLAs hasta nos puede costar una penalización. ¿Qué podemos hacer?

Deberemos instalar en todos los Nodos del Failover Cluster el siguiente HotFix (require reinicio): A hotfix is available to let you configure a cluster node that does not have quorum votes in Windows Server 2008 and in Windows Server 2008 R2

Dicho HotFix, nos permitirá que podamos configurar cada Nodo del Cluster, para que cuente como un Voto para obtener la mayoría, o para que no cuente en absoluto. Volviendo a nuestro caso de ejemplo, después de aplicar el HotFix, configuraríamos los Nodos del DataCenter Secundario para no tener Voto, y añadiríamos un File Share Witness también en el DataCenter Principal, para tener así conseguir 3 Votos. Ahora, en caso de no estar disponible un Nodo del DataCenter Primario así como ninguno de los Nodos del DataCenter Secundario, se seguiría prestando el servicio, ya que estaría disponible aún un Nodo y el File Share Witness, por lo que tendríamos 2 de 3 Votos, existiendo mayoría, y ofreciéndose el servicio de Cluster y en consecuencia el servicio de SQL. Mola.

Dicho HotFix, nos permitirá que podamos configurar cada Nodo del Cluster, para que cuente como un Voto para obtener la mayoría, o para que no cuente en absoluto

En caso de un desastre del DataCenter Principal, sería necesario realizar un cambio en la configuración del Cluster, de tal modo que los Nodos del DataCenter Secundario cuenten como Voto para formar mayoría. Además, sería necesario añadir un File Share Witness en el DataCenter Secundario, y configurar los Nodos del DataCenter Primario para que no tengan Voto.

Despedida y Cierre

Hasta aquí llega el presente artículo, en el cual hemos intentado ofrecer una primera visión de SQL Server 2012 AlwaysON Availability Groups (AG), incluyendo ciertos detalles relevantes relacionado con el Windows Server Failover Cluster (WSFC). Por último, antes de finalizar, aprovecho para incluir varios enlaces de interés, para quien desee ampliar esta información:

Poco más por hoy. Como siempre, confío que la lectura resulte de interés.

 


]
[Autor: GuilleSQL]


Comentarios

juralo - 20/05/2014 (UTC)
Hola Guille.

Muy interesante el artículo.
He tratado de ponerlo en práctica pero todos los documentos que encuentro hablan de cómo habilitar AlwaysON con cuatro servidores en dos CPDs distintos (2 + 2), y almacenamiento compartido local en cada CPD,
Pero lo que Yo quiero hacer (porque el costo de licenciamiento es muy alto en esa opción) es AlwaysON con tres servidores en dos CPDs distintos, 2 servidores en un CPD Principal con almacenamiento compartido y un tercer servidor en un CPD Secundario con almacenamiento local.
O será posible que el 3r Nodo sea una instancia completamente independiente del CPD ?
Te agradeceré me comentes si sabes de algún documento que me ayude.

Gracias

JUAN RAMÓN


JSequeiros - 08/12/2017 (UTC)
Sin dudas es una de las características mas importantes que se agregó en Sql Server 2012 para alta disponibilidad y recuperación de desastres.


mcferhu - 08/09/2019 (UTC)
Hola!!!

Yo tengo un AG en 2012 , y tengo la necesidad de migrar a sql server 2017.

Mi pregunta es, hay posibilidad de agregar dos nodos en SQL server 2017, al AG actual con el objetivo final de eliminar del grupo los dos nodos de sql 2012?

Si no fuese posible, cuál sería la mejor forma de hacer la migración.

Millones de Gracias



Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Marzo de 2019 (1)
Octubre de 2018 (1)
Julio de 2018 (1)
Junio de 2018 (4)
Mayo de 2018 (5)
Abril de 2018 (3)
Marzo de 2018 (2)
Febrero de 2018 (7)
Enero de 2018 (1)
Diciembre de 2017 (15)
Noviembre de 2017 (7)
Junio de 2017 (3)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Copyright © 2007 GuilleSQL, todos los derechos reservados.