Embed Size (px)
Citation preview
Guía de la arquitectura de AlwaysOn: crear una solución de alta disponibilidad y recuperación ante desastres con instancias de clúster de conmutación por error y grupos de disponibilidad
Artículo técnico de SQL Server
Redactores: Joseph Sack (SQLskills.com), Sanjay Mishra (Microsoft)
Revisores técnicos: Min He (Microsoft), Chuck Heinzelman (Microsoft), Alexi Khalyako (Microsoft), Charles Mathews (Microsoft), Prem Mehra (Microsoft) , Juergen Thomas (Microsoft), Mike Weiner (Microsoft), Amitabh Tamhane (Microsoft), Brent Ozar (Brent Ozar PLF), Gianluca Hotz (SolidQ), David P. Smith (ServiceU), Michael Steineke (Edgenet), Glenn Berry (SQLskills.com)
Director del programa de contenido: Glenn Minch (Microsoft)
Fecha de publicación: junio de 2012
Corresponde a: SQL Server 2012
Resumen: las instancias de clúster de conmutación por error (FCI) AlwaysOn de SQL Server 2012 y los grupos de disponibilidad AlwaysOn proporcionan una completa solución de recuperación ante desastres y alta disponibilidad. Antes de SQL Server 2012, muchos clientes usaban FCI para proporcionar una alta disponibilidad local dentro de un centro de datos y la creación de reflejos de base de datos para la recuperación ante desastres en un centro de datos remoto. Con SQL Server 2012, este patrón de diseño puede reemplazarse con una arquitectura que utilice FCI para lograr una alta disponibilidad y grupos de disponibilidad para las necesidades empresariales relativas a la recuperación ante desastres. Los grupos de disponibilidad aprovechan la funcionalidad de Clústeres de conmutación por error de Windows Server (WSFC) y permiten el uso de varias características que no están disponibles en el reflejo de la base de datos. En este documento se detallan los requisitos clave de la topología de este patrón determinado de diseño con consideraciones sobre el almacenamiento asimétrico, la selección del modelo de cuórum, los votos de cuórum, el procedimiento para crear el entorno y un flujo de trabajo que ilustra cómo tratar un evento de recuperación ante desastres en la nueva topología a través de los roles de trabajo participantes.
Copyright
Este documento se proporciona "tal cual". La información y los puntos de vista que se ofrecen en él, incluidas las direcciones URL y otras referencias a sitios web de Internet, pueden sufrir modificaciones sin previo aviso. Usted acepta el riesgo de utilizarlo.
Algunos ejemplos descritos aquí se proporcionan solo para servir de ilustración y son ficticios. No se pretende ni debería deducirse ninguna asociación o conexión real.
En este documento no se proporciona ningún derecho legal de ninguna propiedad intelectual de ningún producto de Microsoft. Puede copiar y utilizar este documento para su propia referencia.
© 2012 Microsoft. Todos los derechos reservados.
2
ContenidoIntroducción................................................................................................................................................4
FCI para la alta disponibilidad local y la creación de reflejo de la base de datos para la recuperación ante desastres...........................................................................................................4
FCI para lograr una alta disponibilidad local y grupos de disponibilidad para la recuperación ante desastres...........................................................................................................5
Planeamiento y consideraciones.................................................................................................................7
Requisitos del Clúster de conmutación por error de Windows Server....................................................7
Almacenamiento asimétrico....................................................................................................................7
Denominación de instancias y ruta de acceso de archivos......................................................................7
Modo de disponibilidad y modo de conmutación por error....................................................................8
Modelo de cuórum y votos en los nodos.................................................................................................8
Herramientas para ver y cambiar el modelo de cuórum y los votos de los nodos.............................11
Configurar el modelo de cuórum WSFC.............................................................................................11
Usar vistas de administración dinámica (DMV) y el Panel de AlwaysOn para ver la información de cuórum...................................................................................................12
Configurar los votos de los nodos......................................................................................................13
Conectividad de cliente.........................................................................................................................14
Cargas de trabajo de lectura/escritura..............................................................................................14
Cargas de trabajo de solo lectura......................................................................................................14
Compatibilidad con conexiones de varias subredes..........................................................................15
Configurar la solución FCI+AG...................................................................................................................15
Requisitos previos de la instalación.......................................................................................................15
Configurar la solución en el centro de datos principal..........................................................................16
Configurar la solución en el centro de datos de recuperación ante desastres......................................21
Consideraciones sobre la supervisión........................................................................................................25
Recuperarse de un desastre......................................................................................................................26
Revertir al centro de datos principal.........................................................................................................32
Conclusión.................................................................................................................................................36
Referencias................................................................................................................................................37
3
Introducción AlwaysOn de Microsoft SQL Server 2012 proporciona diversas opciones flexibles de diseño que permiten seleccionar una solución apropiada de recuperación ante desastres (DR) y alta disponibilidad (HA) para una aplicación. Para obtener más información sobre los patrones de diseño de recuperación ante desastres y alta disponibilidad de AlwaysOn de SQL Server 2012, vea Patrones de diseño de alta disponibilidad y recuperación ante desastres de AlwaysOn en SQL Server 2012 .
En estas notas del producto se describe la solución que usa instancias de clúster de conmutación por error (FCI) para la alta disponibilidad y grupos de disponibilidad para la recuperación ante desastres. Esta arquitectura combina una solución de almacenamiento compartido (FCI) y una solución de almacenamiento no compartido (AG).
Antes de SQL Server 2012, una arquitectura de implementación de alta disponibilidad y recuperación ante desastres implicaba el uso de FCI para conseguir una alta disponibilidad local y de la creación de reflejo de la base de datos (DBM) para la recuperación ante desastres remota. Con SQL Server 2012, los grupos de disponibilidad pueden sustituir al componente de creación de reflejo de la base de datos de la solución.
En este documento se tratan consideraciones acerca del planeamiento y se detalla el procedimiento necesario para crear esta solución. También se describen los pasos requeridos para recuperarse de un desastre y se explica cómo revertir al centro de datos principal una vez restaurado.
En este documento se supone un conocimiento básico de los conceptos relativos a las instancias de clúster de conmutación por error (FCI), los grupos de disponibilidad, la alta disponibilidad y la recuperación ante desastres. Para obtener más información acerca del conjunto completo de características de la solución AlwaysOn, vea las notas del producto Guía de soluciones AlwaysOn de Microsoft SQL Server para lograr alta disponibilidad y recuperación ante desastres. Para obtener más información sobre los pasos de la migración, vea las notas del producto Guía de migración: migrar a clústeres de conmutación por error y grupos de disponibilidad de SQL Server 2012 desde implementaciones anteriores de agrupación en clústeres y creación de reflejo.
Los destinatarios de estas notas del producto son los arquitectos de tecnología y los administradores de base de datos de SQL Server, entre otros. También son adecuadas para los administradores del sistema que colaboran con el administrador de base de datos en la administración de Windows Server, Servicios de dominio de Active Directory (AD DS), WSFC y redes.
FCI para la alta disponibilidad local y la creación de reflejo de la base de datos para la recuperación ante desastres Como se indicaba en la introducción, antes de SQL Server 2012, una arquitectura de implementación habitual de SQL Server implicaba el uso de FCI para lograr una alta disponibilidad local y el uso de la creación de reflejo de la base de datos para la recuperación ante desastres del centro de datos. Esto es lo que se conocía como solución FCI+DBM. En esta solución, se configura una FCI dentro del centro de datos principal utilizando el almacenamiento en disco compartido (a través de la red SAN, por ejemplo) a fin de proporcionar protección en las instancias de SQL Server. Si se produce un error de hardware en uno de los nodos, otro nodo puede asumir el control como host de la FCI dentro del mismo centro de datos.
La creación de reflejo de la base de datos se usa entre el sitio principal y el sitio de recuperación ante desastres para proteger las bases de datos. En caso de que se produzca una interrupción del centro de datos principal o un error de su almacenamiento compartido, se podría usar el reflejo del centro de datos de recuperación ante desastres para restaurar el servicio en las aplicaciones. El centro de datos de recuperación
4
ante desastres hospeda otra FCI en un WSFC independiente, con su propio almacenamiento compartido. La Ilustración 1 proporciona una representación de esta arquitectura de la solución.
Ilustración 1: FCI para lograr una alta disponibilidad y creación de reflejo de la base de datos para la recuperación ante desastres
Normalmente, el centro de datos de recuperación ante desastres se encuentra apartado del centro de datos principal y la sesión de creación de reflejo se establece en el modo asincrónico de "alto rendimiento" a fin de minimizar la sobrecarga para las transacciones. Ocasionalmente, también se observa la creación de reflejo de la base de datos sincrónica entre los centros de datos.
Para obtener más información, incluido un ejemplo práctico de esta solución específica, vea Alta disponibilidad y recuperación ante desastres en ServiceU: un caso práctico de SQL Server 2008.
FCI para lograr una alta disponibilidad local y grupos de disponibilidad para la recuperación ante desastres Con SQL Server 2012, una solución similar implica el uso de FCI para lograr una alta disponibilidad local, como la solución FCI+DBM, pero para la recuperación ante desastres se usan los grupos de disponibilidad (AG). Esto se conoce como solución FCI+AG.
La Ilustración 2 muestra la solución que emplea FCI para lograr una alta disponibilidad local y grupos de disponibilidad para la recuperación ante desastres en los centros de datos.
Ilustración 2: FCI para lograr una alta disponibilidad y grupos de disponibilidad para la recuperación ante desastres
5
La Ilustración 2 muestra dos FCI, una en el centro de datos principal y otra en el centro de datos de recuperación ante desastres. Cada FCI tiene dos nodos y su propio almacenamiento compartido. Sin embargo, los cuatro nodos forman parte del mismo WSFC. El que todos esos nodos pertenezcan al mismo WSFC es un requisito de los grupos de disponibilidad.
La Ilustración 2 ilustra la topología de un escenario simple con dos centros de datos y cada uno hospeda una réplica del grupo de disponibilidad en una FCI de dos nodos. La arquitectura permite variaciones en esta topología:
Varios centros de datos Varias réplicas, hasta cinco incluida una réplica principal y de una a cuatro secundarias Más de dos nodos en cada FCI si se desea que haya nodos pasivos adicionales para lograr
una alta disponibilidad No todas las réplicas de un grupo de disponibilidad tienen que residir en instancias de FCI;
algunas pueden residir en instancias independientes de SQL Server que no sean FCI Varios grupos de disponibilidad según la agrupación lógica de las bases de datos en el entorno
de aplicación
La explicación de estas notas del producto se centra en la topología mostrada en la Ilustración 2; sin embargo, los conceptos generales se aplican también a las otras variaciones.
Dado que los cuatro nodos en dos sitios forman parte del mismo WSFC, hay consideraciones adicionales para el uso de almacenamiento compartido que solo es visible en los nodos locales del centro de datos. También hay consideraciones adicionales acerca de los votos y del modelo de cuórum. En este documento se describen estas y otras consideraciones.
El grupo de disponibilidad se puede configurar con una o varias bases de datos de usuario y puede usar el movimiento de datos sincrónico o asincrónico. Las réplicas sincrónicas agregan latencia a las transacciones de base de datos ya que la principal necesita recibir el reconocimiento de que las entradas de los registros se han reforzado en los registros de la réplica secundaria antes de que la réplica principal confirme la transacción.
También es importante tener en cuenta que la instancia de SQL Server de recuperación ante desastres no necesita ser una FCI. Asimismo, un grupo de disponibilidad podría tener una instancia independiente de SQL Server para la réplica secundaria. Con los grupos de disponibilidad, puede mezclar ambas FCI e instancias independientes dentro de una única topología en el mismo WSFC. La Ilustración 3 muestra una topología mixta.
Ilustración 3: FCI para lograr una alta disponibilidad, grupos de disponibilidad para la recuperación ante desastres y la recuperación ante desastres como instancia independiente
6
En el resto del documento se supone que tanto la réplica principal como la secundaria son FCI hospedadas y no instancias independientes.
Planeamiento y consideraciones En esta sección se describen las consideraciones de planeamiento, los requisitos y los requisitos previos que hay que tener en cuenta antes de implementar una solución FCI+AG para lograr una alta disponibilidad y para la recuperación ante desastres.
Requisitos del Clúster de conmutación por error de Windows ServerUn cambio fundamental de una solución FCI+DBM frente a una solución FCI+AG es que va a pasar de usar dos FCI en dos WSFC independientes a usar dos FCI en un único WSFC. Todas las réplicas de un grupo de disponibilidad deben existir en un único WSFC dentro de un único dominio de Active Directory, incluso entre los centros de datos.
Almacenamiento asimétricoEl uso de dos FCI, una en cada sitio en un solo WSFC de varios sitios, presenta consideraciones con respecto a cómo se trata el almacenamiento compartido. Cada FCI tiene su propio almacenamiento compartido. Los nodos del sitio principal comparten el almacenamiento para formar una FCI de almacenamiento compartido y los nodos del sitio de recuperación ante desastres comparten el almacenamiento para formar otra FCI de almacenamiento compartido. El almacenamiento en el sitio principal no está visible para los nodos del sitio de recuperación ante desastres y viceversa. Esta organización del almacenamiento, en la que un disco de clúster se comparte entre un subconjunto de nodos en un WSFC, se conoce como almacenamiento asimétrico. Antes de que existiera la capacidad de almacenamiento asimétrico, el almacenamiento compartido tenía que estar visible para todos los nodos del WSFC (almacenamiento simétrico). El almacenamiento asimétrico se incluyó como opción de implementación en Windows Server 2008 a través de una revisión. También se admite en Windows Server 2008 R2 mediante el Service Pack 1. Para obtener más información sobre esta revisión, vea el artículo de Knowledge Base Revisión para agregar compatibilidad con los almacenamientos asimétricos al complemento MMC de Administración de clústeres de conmutación por error para un clúster de conmutación por error que ejecute Windows Server 2008 o Windows Server 2008 R2.
Esta mejora de Windows Server es la pieza clave de la funcionalidad que habilita la arquitectura de la solución FCI + AG descrita en estas notas del producto. Al habilitar esta funcionalidad, puede combinar la solución de almacenamiento compartido (FCI) con la solución de almacenamiento no compartido (grupos de disponibilidad), en un única solución de alta disponibilidad y recuperación ante desastres (HA + DR). Por consiguiente, esta mejora también permite usar letras de unidad idénticas para los recursos de disco compartido a través de centros de datos.
Observe que, al configurar el almacenamiento asimétrico, puede recibir un mensaje durante las comprobaciones de validación de WSFC que indique que "El disco con el identificador XYZ está visible o solo podrá estar en clúster desde un subconjunto de nodos". Para el almacenamiento asimétrico, esto es previsible.
Denominación de instancias y ruta de acceso de archivosLas dos FCI deben utilizar nombres de instancia diferentes dentro del mismo WSFC, por ejemplo, usar "INST_A" como nombre de instancia para la FCI principal e "INST_B" como nombre de instancia para la FCI de recuperación ante desastres. (A diferencia de los grupos de disponibilidad, la creación de reflejo de la base de datos permite que cada FCI utilice el mismo nombre de instancia si la FCI está en WSFC independientes. En la ilustración 1, ambas FCI usaban el mismo nombre de instancia, INST_A, con la solución FCI+DBM).
7
Cada FCI tiene su propio almacenamiento compartido, que no es accesible por los nodos en el otro centro de datos y que debe utilizar letras de unidad idénticas para los discos, así como rutas de acceso idénticas para los archivos de base de datos y los archivos de registro de transacciones en ambas FCI. El que las letras de unidad y las rutas de acceso de los archivos sean idénticas no es un requisito absoluto pero, si las rutas de acceso difieren, deberá hacer una operación RESTORE WITH MOVE manual al restaurar las bases de datos de réplica en la secundaria. Además, las rutas de acceso heterogéneas a través de las dos FCI invalidarán las operaciones posteriores de agregación de archivos, por ejemplo, la creación de grupos de archivos o los archivos de datos o de registro secundarios. Para obtener más información, incluido un escenario con un problema y su resolución, vea Solucionar problemas relativos a una operación de agregar archivo con error (grupos de disponibilidad AlwaysOn).
Modo de disponibilidad y modo de conmutación por errorPara el grupo de disponibilidad creado entre las dos FCI, puede designar cualquiera de los modos de disponibilidad de confirmación sincrónica o asincrónica. Si el modo de disponibilidad es sincrónico, la réplica principal espera a confirmar las transacciones de usuario hasta que se hayan enviado y reforzado en las réplicas secundarias. Esto puede agregar latencia a las transacciones de usuario pero también ayuda a evitar la posibilidad de perder datos en la réplica secundaria al asegurarse de que las transacciones se envían a la FCI de recuperación ante desastres antes de que se señale una confirmación en la transacción de la réplica principal.
Si el modo de disponibilidad es asincrónico, las transacciones de usuario de la réplica principal no esperan a que las transacciones se refuercen en los registros de la réplica secundaria. Esto reduce la latencia de las transacciones, pero aumenta el riesgo de perder datos en el caso de que se produzca una interrupción del sistema.
Respecto a los modos de conmutación por error, cuando las FCI se usan en una topología de grupos de disponibilidad, el modo de conmutación por error de los grupos de disponibilidad debe ser manual (no automático). Sin embargo, dentro de cada FCI, la conmutación por error de FCI de la instancia de SQL Server a otros nodos es automática.
Modelo de cuórum y votos en los nodosNota: las explicaciones sobre los modelos de cuórum e información relacionada en estas notas del producto se aplican a las soluciones que se ejecutan en los sistemas operativos Windows Server 2008 y Windows Server 2008 R2, con los Service Pack y otras actualizaciones de software adecuados.
Dado que la infraestructura subyacente de la solución FCI+AG es un WSFC, es importante considerar el modelo de cuórum adecuado para el WSFC. La configuración de cuórum se administra en los WSFC, con independencia del número de FCI, el número de réplicas y el número de grupos de disponibilidad hospedados en el WSFC.
En WSFC, hay cuatro modelos de cuórum: Mayoría de nodos, Mayoría de recurso compartido de archivos y nodo, Mayoría de disco y nodo, Sin mayoría: solo disco. Para obtener más información acerca de los modelos de cuórum, vea Guía paso a paso de clústeres de conmutación por error: configurar el cuórum en un clúster de conmutación por error.
8
Antes de seleccionar un modelo de cuórum, es importante tener en cuenta el número de nodos que votan. La asignación adecuada de los votos de los nodos desempeña un papel importante en el diseño HA+DR. De forma predeterminada, cada nodo de un clúster de conmutación por error tiene un voto, pero eso puede no ser adecuado para una solución HA+DR determinada, según la distribución de nodos en los centros de datos principales y de recuperación ante desastres. Hay una revisión disponible (http://support.microsoft.com/kb/2494036) que permite asignar un voto a algunos nodos y cero votos a otros nodos del WSFC. La propiedad NodeWeight del nodo WSFC representa el voto para ese nodo concreto. El valor "0 " significa que el nodo no tiene ningún voto. El valor "1 " significa que el nodo tiene un voto de cuórum. Esta revisión se debe instalar en cada nodo de la topología.
Las recomendaciones generales de los votos de cuórum para una solución HA+DR AlwaysOn se proporcionan en el tema Ajustes recomendados para los votos de cuórum de los Libros en pantalla de SQL Server. Se deben tratar como directrices para decidir el esquema de votos en la solución AlwaysOn. Si se tienen en cuenta estas directrices, para asegurarse de que el cuórum de los nodos del centro de datos principal no se ve comprometido por interrupciones del centro de datos de recuperación ante desastres ni por la pérdida de conectividad entre los dos centros de datos, para la solución FCI+AG que aparece en la ilustración 2, el esquema de votos será:
1 voto para cada nodo del centro de datos principal 0 votos para cada nodo del centro de datos de recuperación ante desastres
Esta asignación de votos se traduce en un total de dos votos para el WSFC. Como práctica recomendada, el número total de votos para el WSFC debe ser un número impar. Si hay un número par de nodos que votan (como en nuestra topología de ejemplo), considere agregar un testigo de recurso compartido de archivos y entonces elija el modelo de cuórum Mayoría de recurso compartido de archivos y nodo.
Nota: en numerosos entornos empresariales, es común que un recurso compartido de archivos sea propiedad de un equipo diferente que también lo administra. Ese equipo tendrá control sobre el voto de un nodo y, por lo tanto, influencia sobre el estado del clúster de conmutación por error. Un recurso compartido de archivos se convierte en un voto y, en consecuencia, tiene que estar siempre disponible. La agrupación en clústeres u otras tecnologías de alta disponibilidad son recomendables para garantizar la disponibilidad del voto de los recursos compartidos de archivos.
También puede agregar un nodo adicional y usar el modelo de cuórum Mayoría de nodo. El nodo adicional debe estar dentro del WSFC pero no necesita ser parte de la configuración de FCI. También debe estar situado en el mismo centro de datos principal, junto a los otros dos nodos de WSFC de ese centro de datos.
La Ilustración 4 muestra la asignación de votos utilizando el modelo de cuórum Mayoría de recurso compartido de archivos y nodo.
9
Ilustración 4: solución FCI+AG de alta disponibilidad y recuperación ante desastres con asignaciones de votos de nodo
En la Ilustración 4, cada uno de los dos nodos del centro de datos principal tiene un voto. Un testigo de recurso compartido de archivos también se define en el centro de datos principal e, igualmente, tiene un voto. A los dos nodos del centro de datos de recuperación ante desastres no se les da ningún voto y no pueden afectar al cuórum.
Las opciones adicionales de modelo de cuórum posibles para esta arquitectura de implementación son Mayoría de disco y nodos (con un disco asimétrico) o Sin mayoría: solo disco (con un disco asimétrico). Antes de que el almacenamiento asimétrico estuviera disponible en un WSFC, un disco compartido podía actuar como un recurso de cuórum si estaba visible desde todos los nodos WSFC. Con el almacenamiento asimétrico, el almacenamiento de clúster puede estar visible en un subconjunto de nodos y seguir usándose como recurso de cuórum. Con el modelo de cuórum asimétrico Sin mayoría: solo disco, puede implementar un escenario de tipo "el último se lo queda", donde el WSFC conserva el cuórum mientras un solo nodo tenga contacto con el disco asimétrico que actúa como recurso de cuórum.
Puede habilitar esto mediante la línea de comandos de cluster.exe. No podrá habilitarlo a través del Administrador de clústeres de conmutación por error ni de Windows PowerShell. Para obtener un ejemplo de esta configuración, vea la sección Cambiar la configuración de cuórum en un clúster de conmutación por error con almacenamiento asimétrico del artículo Guía paso a paso del clúster de conmutación por error: configurar el cuórum en un clúster de conmutación por error.
Importante: el uso de un disco asimétrico como recurso de cuórum proporciona numerosas ventajas, pero también requiere una experiencia con los clústeres y un planeamiento mucho mayores. Debe conocer muy bien esta configuración antes de implementarla en un entorno de producción.
Si se produce una interrupción del centro de datos principal que requiera poner en marcha el servicio en el centro de datos de recuperación ante desastres, debe evaluar de nuevo la configuración del cuórum. A cada nodo del centro de datos de recuperación ante desastres se le debe asignar un voto y debe quitarse el voto de cada nodo del centro de datos principal (estableciéndose en "0 ") hasta que el servicio se restaure. Suponiendo que la FCI tiene dos nodos y se produce una interrupción prolongada del centro de datos principal, también debe configurar el testigo del recurso compartido de archivos (u otro voto adicional) en el centro de datos de recuperación ante desastres y establecer el modelo de cuórum en consecuencia. Una vez que el centro de datos principal vuelva a estar preparado para reanudar su actividad, los votos deben ajustarse de nuevo y el modelo de cuórum debe volver a evaluarse. Más adelante en este documento se examinará un escenario de recuperación ante desastres y el flujo de proceso asociado.
10
Con el modelo de cuórum y las asignaciones de votos que se presentan en la ilustración 4, se supone que la solución tiene dos réplicas: una en cada uno de los dos centros de datos. Si tiene más centros de datos y piensa colocar parte de la solución en un tercero, las decisiones relativas al modelo de cuórum y a las asignaciones de votos pueden variar.
Herramientas para ver y cambiar el modelo de cuórum y los votos de los nodosHay varias maneras de ver y cambiar el modelo de cuórum del clúster y/o los votos del quorum. En la tabla siguiente se enumeran varias herramientas para estas tareas.
Para ver el modelo de cuórum Para cambiar el modelo de cuórum
Administrador de clústeres de conmutación por error de WindowsWindows PowerShell
Cluster.exeDMV de SQL Server
Panel de AlwaysOn en SQL Server Management Studio
Administrador de clústeres de conmutación por error de WindowsWindows PowerShell
Cluster.exe
Nota: solo se puede usar Cluster.exe para establecer el modelo de cuórum en
"Mayoría de nodo y disco (asimétrico)" o en "Sin mayoría: solo disco (asimétrico)"
Para ver los votos de nodos Para cambiar los votos de nodosWindows PowerShell
Cluster.exeDMV de SQL ServerPanel de AlwaysOn
Windows PowerShellCluster.exe
Configurar el modelo de cuórum WSFCA continuación se muestran ejemplos del uso de Windows PowerShell a través de la línea de comandos para ver el modelo de cuórum actual y cambiarlo.
Para ver el modelo de cuórum existente
Get-ClusterQuorum
Para configurar el modelo de cuórum Mayoría de nodos
Set-ClusterQuorum -NodeMajority
Para cambiar el modelo de cuórum a Mayoría de recurso compartido de archivos y nodo
Set-ClusterQuorum -NodeAndFileShareMajority \\FileShare\Witness
El recurso compartido de archivos testigo que elija no debe estar en un nodo que ya participe en la configuración WSFC de AlwaysOn. Sin embargo, se puede colocar como recurso compartido en otra configuración de WSFC. Debe existir en el mismo dominio de Active Directory que el WSFC. Además, la cuenta de servicio de clúster de WSFC requiere permisos de lectura y escritura en el testigo de recurso compartido de archivos. El Administrador de clústeres de conmutación por error tiene la lógica integrada para agregar estos permisos al testigo de recurso compartido de archivos siempre que la cuenta con la que se cambia el modelo de cuórum tenga permisos en el recurso compartido de archivos.
11
Usar vistas de administración dinámica (DMV) y el Panel de AlwaysOn para ver la información de cuórumAunque no puede establecer ni cambiar el modelo de cuórum ni los votos de los nodos a través de las herramientas de SQL Server, puede usar consultas Transact-SQL en las vistas de administración dinámica y el Panel de AlwaysOn en SQL Server Management Studio para ver los votos de los nodos y el modelo de cuórum del clúster de Windows que hospeda el grupo de disponibilidad.
Para ver el modelo de cuórum del clúster de Windows que hospeda el grupo de disponibilidad, consulte la vista de administración dinámica sys.dm_hadr_cluster (http://technet.microsoft.com/es-es/library/hh212952(v=sql.110).aspx).
SELECT cluster_name, quorum_type_desc, quorum_state_descFROM sys.dm_hadr_cluster;
Cuando esta consulta se ejecuta en el ejemplo que se incluye en estas notas del producto, devuelve lo siguiente.
cluster_name quorum_type_desc quorum_state_desc------------ ---------------- -----------------contosocluster NODE_AND_FILE_SHARE_MAJORITY NORMAL_QUORUM
Para ver los votos de los nodos, vea la vista de administración dinámica sys.dm_hadr_cluster_members.
SELECT member_name, number_of_quorum_votesFROM sys.dm_hadr_cluster_members;
Cuando esta consulta se ejecuta en el ejemplo que se incluye en estas notas del producto, devuelve lo siguiente. La asignación de votos se tratará en una sección posterior.
member_name number_of_quorum_votes------------------ ----------------------PrimaryNode1 1PrimaryNode2 1DRNode1 0DRNode2 0File Share Witness 1
El Panel de AlwaysOn de SQL Server Management Studio se puede utilizar para mostrar los votos de cuórum y el estado de un clúster. La Ilustración 5 muestra esta información para un clúster de Windows con el modelo de cuórum Mayoría de nodos (se resaltan los votos de cuórum y el estado del clúster).
12
Ilustración 5: mostrar los votos de cuórum y el estado del clúster en el Panel de AlwaysOn
Aunque la columna Votos de cuórum no se muestra de forma predeterminada, puede agregarla al panel haciendo clic con el botón secundario en el encabezado de la columna de la tabla Réplica de disponibilidad y seleccionando la columna específica que desea ver.
En un modelo de cuórum Mayoría de recurso compartido de archivos y nodo, esta vista del Panel de AlwaysOn solo muestra los nodos, no el recurso compartido de archivos. Para obtener la información del cuórum completa, a la derecha, haga clic en Ver información de cuórum de clúster. Aparece una ventana emergente similar a la de la Ilustración 6.
Ilustración 6: información de cuórum de clúster para el modelo de cuórum Mayoría de recurso compartido de archivos y nodo
Configurar los votos de los nodosLa propiedad NodeWeight del nodo WSFC representa el voto para ese nodo concreto. En los ejemplos siguientes se muestra cómo configurar la propiedad NodeWeight de un nodo en un WSFC mediante Windows PowerShell. Para ejecutar Windows PowerShell en el nodo servidor, haga clic en Iniciar, seleccione Herramientas administrativas y haga clic en Módulos de Windows PowerShell. En este ejemplo, DRNode1 representa un nodo específico de WSFC que se encuentra en el centro de datos de recuperación ante desastres.
13
Para ver la configuración actual del voto de todos los nodos
Get-ClusterNode | fl NodeName, NodeWeight
Para establecer el voto de un nodo en "0"
(Get-ClusterNode "DRNode1").NodeWeight=0
Nota: el valor "0" significa que el nodo no tiene ningún voto. El valor "1" significa que el nodo tiene un voto de cuórum.
Conectividad de clienteLos métodos de conexión de FCI son los mismos en SQL Server 2012 y en las versiones anteriores, pero en las migraciones de la creación de reflejo de la base de datos a los grupos de disponibilidad hay cambios que debería considerar y prever para poder utilizar la nueva funcionalidad secundaria disponible. Para obtener más información acerca de la migración, incluidas consideraciones detalladas y procedimientos, vea la Guía de migración: migrar a clústeres de conmutación por error y grupos de disponibilidad de SQL Server 2012 desde implementaciones anteriores de agrupación en clústeres y creación de reflejo.
Cargas de trabajo de lectura/escritura Con las cargas de trabajo de lectura y escritura que se ejecutan con las bases de datos de disponibilidad en un grupo de disponibilidad, dispone de dos opciones para conectarse a la réplica principal. La primera opción es conectarse directamente al nombre de red virtual (VNN) de FCI; cada réplica tiene otro VNN de FCI. La segunda opción es usar el nombre del agente de escucha del grupo de disponibilidad. Es preferible usar el agente de escucha del grupo de disponibilidad porque proporciona transparencia y permite la redirección automática a la réplica principal actual, y el nombre en la cadena de conexión permanece invariable para todas las instancias. El agente de escucha del grupo de disponibilidad es un VNN que está enlazado a una o más direcciones TCP/IP y puertos de escucha y se usa para conectarse automáticamente a cualquier réplica sin tener que designar explícitamente cada grupo de disponibilidad posible en la cadena de conexión.
Si va a migrar las conexiones de la aplicación de carga de trabajo de lectura/escritura desde una solución de creación de reflejo de la base de datos que use el atributo de asociado de conmutación por error, puede seguir usando la cadena de conexión de creación de reflejo de la base de datos, pero solo si el grupo de disponibilidad se configura con una sola réplica secundaria para la actividad de lectura/escritura. Entonces puede usar el nombre del servidor de la réplica principal inicial como origen de datos y (opcionalmente) el nombre de la réplica secundaria como el asociado de conmutación por error. Sin embargo, esta no debe ser una solución a largo plazo.
Cargas de trabajo de solo lectura También dispone de dos opciones para las conexiones de carga de trabajo de solo lectura. Puede usar la VNN de FCI o el agente de escucha del grupo de disponibilidad y especificar el nuevo atributo ApplicationIntent en la cadena de conexión como "Solo lectura".
14
Si usa una cadena de conexión de creación de reflejo de la base de datos heredada, solo puede conectarse al grupo de disponibilidad mientras este esté configurado como una única réplica secundaria para la actividad de lectura/escritura.
Si desea aprovechar el enrutamiento de solo lectura, debe usar el nombre del agente de escucha del grupo de disponibilidad junto con el atributo ApplicationIntent y el valor “ReadOnly”. También debe hacer referencia a una base de datos de disponibilidad dentro del grupo de disponibilidad. El grupo de disponibilidad también se debe configurar para el enrutamiento de solo lectura a las réplicas secundarias legibles mediante la creación de direcciones URL de enrutamiento y listas de enrutamiento, ambas de solo lectura. Para obtener más información acerca de este proceso, vea Configurar el enrutamiento de solo lectura para un grupo de disponibilidad (SQL Server).
Compatibilidad con conexiones de varias subredesEl agente de escucha del grupo de disponibilidad también puede aprovechar el atributo de conexión MultiSubnetFailover en las bibliotecas de cliente. Se recomienda que las cadenas de conexión del grupo de disponibilidad designen el atributo MultiSubnetFailover para las topologías de varias subredes cuando hagan referencia a un nombre de agente de escucha del grupo de disponibilidad. La opción de conexión MultiSubnetFailover habilita la compatibilidad con las conexiones de varias subredes y abre los sockets TCP para las direcciones IP del agente de escucha del grupo de disponibilidad en paralelo. En las bibliotecas de cliente heredadas que no admiten el atributo MultiSubnetFailover, debe considerar cuál es el tiempo de espera adecuado para el inicio de sesión de cliente.
Para obtener más información sobre las consideraciones de la conmutación por error de la aplicación y la conectividad de cliente, vea Conectividad de cliente y conmutación por error de una aplicación (grupos de disponibilidad AlwaysOn) en los Libros en pantalla de SQL Server.
Configurar la solución FCI+AG En este flujo de trabajo se describen los pasos necesarios para crear una solución FCI+AG. Aunque aquí no se describe cada paso concreto, la finalidad de esta sección es ayudar a clarificar el procedimiento de implementación del flujo de trabajo y las tareas de cada rol de trabajo implicado. Siempre que es conveniente, se hace referencia a documentación complementaria. Los pasos se dividen según el rol de trabajo porque la mayoría de los entornos de grandes empresas definen una separación de labores entre los roles de administrador de base de datos, de administrador de Windows (o clúster) y de administrador de red. Por ello, es importante establecer una correcta comunicación y coordinar las actividades a través de los diversos roles.
Requisitos previos de la instalaciónAntes de implementar la solución de grupos de disponibilidad AlwaysOn, es importante comprobar que el sistema cumple los requisitos, incluso en el caso de las actualizaciones. Para obtener más información sobre los requisitos previos para implementar una solución de grupos de disponibilidad AlwaysOn, vea Requisitos previos, restricciones y recomendaciones para grupos de disponibilidad AlwaysOn (SQL Server). Se recomienda que revise este tema antes de continuar.
Todos los nodos deben tener instalada la misma versión del sistema operativo y de las actualizaciones de software de Windows Server. El sistema operativo de servidor debe ser, como mínimo, Windows Server 2008 SP2 o Windows Server 2008 R2 SP1 con, al menos, las siguientes actualizaciones:
15
Almacenamiento asimétrico (si está usando Windows Server 2008): http://support.microsoft.com/kb/976097
Votos de nodo: http://support.microsoft.com/kb/2494036 Validar la prueba de disco durante la validación del clúster:
http://support.microsoft.com/kb/2531907
Puede que necesite actualizaciones adicionales.
Configurar la solución en el centro de datos principalLa Tabla 1 proporciona el flujo de trabajo para configurar los nodos del centro de datos principal. Se supone que hay dos nodos.
16
Paso Administrador de base de datos
Administrador de clústero Windows Server
Administrador de red
1. Agregue la característica de clústeres de conmutación por error a los dos nodos que se encuentran en el centro de datos principal. Para obtener más información sobre este proceso, vea Instalar la característica de clústeres de conmutación por error. Para obtener más información sobre cómo validar la infraestructura de red y otros requisitos, vea Descripción de los requisitos de los clústeres de conmutación por error.
Sí (coordinación de actividades a través de roles)
Sí
2. Revise los requisitos previos necesarios e instale las actualizaciones de software de Windows Server necesarias en cada nodo del centro de datos principal.
Sí
3. Asegúrese de que los volúmenes de almacenamiento compartido designados para la FCI del centro de datos principal tienen formato y una letra de unidad.
Se recomienda que las letras de unidad y la ruta de acceso al directorio para la FCI de recuperación ante desastres coincidan con las de la FCI principal. Tenga esta consideración en cuenta al asignar letras de unidad en la FCI principal.
Sí
4. Compruebe que la cuenta que va a usar para instalar y configurar el WSFC es una cuenta de dominio. Esta cuenta debe tener permisos de administrador en cada nodo del clúster y los permisos Crear objetos de equipo y Leer todas las propiedades en el contenedor usado para las cuentas de equipo de dominio.
O bien, puede probar previamente las cuentas de objeto de nombre o usar una cuenta de administrador de dominio para la instalación. Para obtener más información sobre los permisos y las opciones de aprovisionamiento requeridos, vea Guía paso a paso del clúster de conmutación por error: configurar cuentas en Active Directory.
Sí
17
Paso Administrador de base de datos
Administrador de clústero Windows Server
Administrador de red
5. Mediante el Administrador de clústeres de conmutación por error, realice la validación del clúster de los dos nodos de servidor en el centro de datos principal y el almacenamiento compartido que se agregarán al WSFC. Realice la validación varias veces hasta que no haya errores de bloqueo.
Si se le permite continuar en el paso siguiente con las advertencias existentes, debe comprender todas las advertencias para ayudar a garantizar que la configuración sea estable. Para obtener más información sobre cómo realizar una comprobación de validación, vea Validar una configuración de clúster de conmutación por error.
Sí Sí: para los problemas que puedan surgir en la conexión de red de los nodos
6. Al final del paso de la validación del clúster, use el Administrador de clústeres de conmutación por error para crear un WSFC con dos nodos. Para obtener más información con información general detallada de este proceso, vea Crear un nuevo clúster de conmutación por error.
Sí Sí: para los problemas que puedan surgir en la conexión de red de los nodos
7. Asegúrese de que haya un número impar de votos; por ejemplo, puede hacerlo agregando un recurso compartido de archivos o un nodo adicional, como se indica anteriormente en este documento.
Si elige Mayoría de recurso compartido de archivos y nodo, antes de cambiar la configuración, asegúrese de que ha concedido permisos de lectura y escritura en el recurso compartido de archivos testigo a la cuenta del clúster de WSFC.
Sí
8. Asegúrese de que la instalación usa el almacenamiento compartido y con formato, y que solo está accesible para los dos nodos que se encuentran en el centro de datos principal. Estos discos se utilizarán para SQL Server en el paso siguiente.
Sí
18
Paso Administrador de base de datos
Administrador de clústero Windows Server
Administrador de red
9. Instale una instancia de FCI de SQL Server 2012 Enterprise en el centro de datos principal. Para obtener más información, vea Crear un nuevo clúster de conmutación por error de SQL Server.
Debe realizar dos instalaciones: la primera es una instalación nueva de un clúster de conmutación por error de SQL Server, que crea la FCI, y la segunda es para agregar un nodo a un clúster de conmutación por error de SQL Server en el segundo nodo del centro de datos principal.
Sí
10. Después de instalar la primera FCI, habilite las funciones del grupo de disponibilidad AlwaysOn para ambas instancias de SQL Server.
Para obtener más información sobre cómo usar el Administrador de configuración de SQL Server o, como alternativa, SQL Server PowerShell, vea Habilitar y deshabilitar grupos de disponibilidad AlwaysOn. Observe que, al habilitar los grupos de disponibilidad AlwaysOn para la instancia, debe reiniciar la instancia para que el cambio surta efecto.
19
Paso Administrador de base de datos
Administrador de clústero Windows Server
Administrador de red
11. Después de habilitar la FCI de recuperación ante desastres para admitir grupos de disponibilidad AlwaysOn, haga una copia de seguridad de las bases de datos de usuario para producción de la topología heredada y después restáurelas en la FCI del centro de datos principal.
Nota: puede optar por demorar este paso hasta que la FCI de recuperación ante desastres también esté disponible y el grupo de disponibilidad se pueda configurar con dos réplicas.
También debe generar un script para otros objetos de SQL Server a partir de la topología heredada de la que dependerán las bases de datos de usuario pero no estarán contenidos dentro de las bases de datos de usuario restauradas (por ejemplo, los inicios de sesión de SQL Server, los permisos asociados de nivel de servidor, los trabajos del Agente SQL Server).
Esto es similar al proceso que se sigue al crear scripts de objetos dependientes externos a la base de datos reflejada para una asociación de creación de reflejo de la base de datos. Puede usar diversos métodos para transferir objetos de base de datos y principios entre las instancias de SQL Server. Uno de dichos métodos es la tarea Transferir objetos de SQL Server, de Integration Services. A continuación se describe otro método en el que los inicios de sesión y las contraseñas se transfieren entre las instancias: http://support.microsoft.com/kb/918992/
Tabla 1: crear the solución FCI+AG en el centro de datos principal
20
Configurar la solución en el centro de datos de recuperación ante desastresEn esta tabla se proporciona el flujo de trabajo que permite configurar los nodos del centro de datos de recuperación ante desastres secundarios y crear el grupo de disponibilidad.
Paso Administrador de base de datos
Administrador de clúster o Windows Server
Administrador de red
1. Agregue la característica Clústeres de conmutación por error a todos los nodos que se encuentran en el centro de datos de recuperación ante desastres y que participan en la solución.
Sí (coordinación de actividades a través de roles)
Sí
2. Revise los requisitos previos requeridos e instale las actualizaciones de software de Windows Server necesarias en cada nodo del centro de datos de recuperación ante desastres.
Sí
3. Compruebe que la cuenta que usará para instalar y configurar el WSFC es de dominio. Esta cuenta debe tener permisos de administrador en cada nodo del clúster y los permisos Crear objetos de equipo y Leer todas las propiedades en el contenedor usado para las cuentas de equipo de dominio. Si va a usar las mismas cuentas que en el centro de datos principal, estos permisos ya están establecidos correctamente.
Sí
4. Mediante el Administrador de clústeres de conmutación por error, realice la validación del clúster de los dos nodos del servidor y el almacenamiento compartido que se une al WSFC existente. Si ve el mensaje de advertencia del almacenamiento asimétrico "El disco con el identificador XYZ está visible o solo podrá estar en clúster desde un subconjunto de nodos", no necesita tomar ninguna medida; esto es previsible y aceptable en el almacenamiento asimétrico. Realice la validación varias veces hasta que no haya errores de bloqueo.
Sí Sí: para los problemas que puedan surgir en la conexión de red de los nodos
5. Una vez finalizada la validación, use el Administrador de clústeres de conmutación por error para agregar los dos nodos de recuperación ante desastres al WSFC existente.
Sí Sí: para los problemas que puedan surgir en la conexión de red de los nodos
6. Establezca la propiedad NodeWeight de los nodos del WSFC del centro de datos de recuperación ante desastres en el peso 0 (cero) (vea la Ilustración 4: solución FCI+AG de alta disponibilidad y recuperación ante desastres con asignaciones de votos de nodo para obtener un ejemplo).
Sí
21
Paso Administrador de base de datos
Administrador de clúster o Windows Server
Administrador de red
7. Esta instalación debe usar un almacenamiento compartido y con formato, que solo sea accesible por los dos nodos que se encuentran en el centro de datos de recuperación ante desastres. Estos discos se utilizarán para SQL Server en el paso siguiente.
Conserve la letra de unidad y la asignación idénticos para simplificar la implementación del grupo de disponibilidad en pasos posteriores y permitir las operaciones de archivo de base de datos que no requieran una intervención manual o la interrupción de la sesión del grupo de disponibilidad.
Sí
8. Mueva el almacenamiento disponible a uno de los nodos del centro de datos de recuperación ante desastres para usarlo en el paso siguiente.
Sí
9. Instale una instancia de FCI de SQL Server 2012 Enterprise en el centro de datos de recuperación ante desastres. Tiene que realizar la instalación nueva de un clúster de conmutación por error de SQL Server en uno de los nodos, y crear así la FCI, y después agregar un nodo a un clúster de conmutación por error de SQL Server en el segundo nodo del centro de datos de recuperación ante desastres.
Sí Sí: para coordinar las consideraciones de los puertos y la dirección IP (si usa direcciones IP estáticas)
10. Después de la instalación de las dos FCI, el paso siguiente es habilitar las funciones de los grupos de disponibilidad AlwaysOn en la instancia de SQL Server del centro de datos de recuperación ante desastres.
Para obtener los pasos detallados para usar el Administrador de configuración de SQL Server o, como alternativa, PowerShell, vea Habilitar y deshabilitar grupos de disponibilidad AlwaysOn. Observe que, para que tenga efecto habilitar el grupo de disponibilidad AlwaysOn para la instancia, habrá que reiniciar la instancia.
Sí
22
Paso Administrador de base de datos
Administrador de clúster o Windows Server
Administrador de red
11. Genere un script para otros objetos de SQL Server de la topología heredada de los que dependerán las bases de datos de usuario pero que no estarán contenidos dentro de las bases de datos de usuario restauradas (por ejemplo, los inicios de sesión de SQL Server, los permisos asociados de nivel de servidor, los trabajos del Agente SQL Server).
Estos son los mismos objetos que puede haber incluido ya en el script y copiado a la FCI del centro de datos principal.
Sí
12. Asegúrese de que los posibles propietarios de las dos FCI están establecidos correctamente, es decir, los propietarios posibles de INST_A deben ser PRIMARYNODE1 o PRIMARYNODE2; y los de INST_B deben ser DRNODE1 o DRNODE2.
13. Cree un grupo de disponibilidad (este paso implica tanto a las FCI de recuperación ante desastres como a la principal). Puede establecer el modo de disponibilidad en asincrónico o en sincrónico, en función de las características de la carga de trabajo y de red del entorno. Seleccione la conmutación por error manual para los grupos de disponibilidad. En una solución FCI+AG, la conmutación por error de la FCI es automática y la conmutación por error del grupo de disponibilidad es manual. Para obtener más información sobre cómo configurar la conmutación por error para esta solución, vea Creación y configuración de grupos de disponibilidad.
Sí Sí: para garantizar que los puertos del extremo estén abiertos y solucionar problemas, según convenga
23
Paso Administrador de base de datos
Administrador de clúster o Windows Server
Administrador de red
14. Cree el agente de escucha del grupo de disponibilidad. Este paso no es necesario si ya ha configurado esto como parte de la creación del grupo de disponibilidad. Puede crear el agente de escucha del grupo de disponibilidad con Transact-SQL, SQL Server PowerShell o un asistente de SQL Server Management Studio. Para obtener más información sobre cómo utilizar los distintos métodos, vea Crear o configurar un agente de escucha del grupo de disponibilidad.
Sí Sí Sí: consideraciones para coordinar los puertos y las direcciones IP
Tabla 2: crear the solución FCI+AG en el centro de datos de recuperación ante desastres
Cuando termine con estos pasos, en el Administrador de clústeres de conmutación por error de Windows puede ver que se crea un nuevo grupo en Servicios y aplicaciones con el mismo nombre que el grupo de disponibilidad. Dentro de ese nuevo grupo también encontrará el recurso de agente de escucha del grupo de disponibilidad y las direcciones IP asociadas del agente de escucha (vea la Ilustración 5).
Ilustración 7: tras la configuración de la FCI para la solución de diseño de alta disponibilidad y recuperación ante desastres con grupos de disponibilidad
La Ilustración 7 muestra la vista WSFC de la implementación. Observe que el agente de escucha AG en la ilustración muestra una dirección IP asociada como ejemplo; sin embargo, en las topologías con varios centros de datos es común usar dos direcciones IP.
24
Nota: aunque el grupo de disponibilidad aparece como un recurso del WSFC, no debe intentar administrarlo con las interfaces del ámbito del WSFC o del Administrador de clústeres de conmutación por error. En su lugar, administre el grupo de disponibilidad dentro del contexto de la instancia de SQL Server a través de SQL Server Management Studio, Transact-SQL o Windows PowerShell. Para obtener más información sobre por qué no debe usar el Administrador de clústeres de conmutación por error u otras interfaces del ámbito de WSFC, vea la publicación del blog No usar el Administrador de clústeres de conmutación por error de Windows para la conmutación por error del grupo de disponibilidad.
La Ilustración 8 muestra la implementación en SQL Server Management Studio. La vista muestra una de las FCI con la jerarquía de carpetas del Explorador de objetos de alta disponibilidad AlwaysOn abierta. En este ejemplo, la FCI de recuperación ante desastres es la réplica secundaria y la otra FCI es la réplica principal. Se enumeran las tres bases de datos de disponibilidad que participan en el grupo, junto con el nombre del agente de escucha del grupo de disponibilidad.
Ilustración 8: después de la configuración de la FCI para la solución de diseño de alta disponibilidad y recuperación ante desastres con grupos de disponibilidad en SQL Server Management Studio
Consideraciones sobre la supervisiónAl migrar una topología de creación de reflejo de la base de datos y una FCI a una solución de grupo de disponibilidad y FCI, serán necesarios nuevos métodos para supervisar la topología. Entre los métodos y las herramientas que puede utilizar para supervisar la infraestructura del grupo de disponibilidad se incluyen el Panel de AlwaysOn en SQL Server Management Studio, la información de estado del Explorador de objetos, las directivas de Administración basada en directivas, nuevos contadores de rendimiento relacionados con el grupo de disponibilidad, vistas de catálogo, vistas de administración dinámica y una sesión de Eventos extendidos que realice el seguimiento de las ejecuciones de instrucciones relacionadas con DDL de AlwaysOn, los problemas de conectividad de WSFC, los eventos de conmutación por error, los cambios de estado y los bloques de subprocesos para rehacer.
25
Se recomienda usar el Panel de AlwaysOn para ver rápidamente el estado de un grupo de disponibilidad específico. En él puede ver la ubicación de la instancia principal, el modo de conmutación por error de las réplicas, el estado de sincronización de las réplicas y la preparación para la conmutación por error de las diferentes réplicas. También puede acceder directamente a los datos de la sesión de Eventos extendidos de eventos de estado AlwaysOn desde el panel para ver la disponibilidad reciente de la actividad de los grupos, los cambios de estado y los eventos.
Ilustración 9: Panel de AlwaysOn
Además, puede crear alertas del Agente SQL Server y respuestas de trabajos según los umbrales de los contadores de rendimiento y los cambios de estado del grupo de disponibilidad. Para obtener más información e instrucciones con respecto a la supervisión de un entorno de grupos de disponibilidad, vea Supervisar los grupos de disponibilidad.
Recuperarse de un desastreEn esta sección se describe el flujo de trabajo de los pasos que debe seguir en el caso de que se produzca una interrupción de la réplica principal en el centro de datos principal. También se describen los pasos necesarios para restaurar la disponibilidad de la réplica principal del centro de datos de recuperación ante desastres. La interrupción de la réplica principal puede deberse a uno de los siguientes motivos:
El error de todos los nodos de las FCI del centro de datos principal El error del almacenamiento de la FCI del centro de datos principal Interrupciones de la red o errores que afectan a todo el centro de datos principal
En cualquiera de estos escenarios, se requieren ciertas acciones en el centro de datos de recuperación ante desastres para reanudar el servicio de SQL Server en las aplicaciones.
La Ilustración 10 muestra la ventana de información de cuórum de clúster para este escenario (esta información es accesible desde el Panel de AlwaysOn y el vínculo Ver información de cuórum de clúster). Muestra el cuórum antes de un desastre, donde ambos nodos de recuperación ante desastres tienen cero votos.
26
Ilustración 10: estado "anterior" de los votos del cuórum de clúster
El siguiente flujo de trabajo especifica los pasos necesarios para recuperar un grupo de disponibilidad en el centro de datos de recuperación ante desastres en el caso de una interrupción del centro de datos principal:
1. Fuerce el cuórum en uno de los nodos de recuperación ante desastres y asegúrese de que los nodos del centro de datos principal no formen su propio cuórum.
No es probable que el Administrador de clústeres de conmutación por error iniciado en un nodo de recuperación ante desastres proporcione información útil (inicialmente) en el estado del WSFC porque el clúster ya no tiene el cuórum.
Ilustración 11: Administrador de clústeres de conmutación por error después de un desastre y antes de la recuperación
Dado que las FCI dependen de un WSFC funcional, son accesibles a menos que se ejecuten tanto un cuórum de clúster como el servicio de clúster. En un escenario en el que el estado del centro de datos principal sea dudoso y el servicio deba restaurarse desde el centro de datos secundario de recuperación ante desastres a fin de adecuarse a los objetivos relativos al tiempo de recuperación de la empresa, debe forzar el cuórum en uno de los nodos de recuperación ante desastres.
27
El siguiente comando para Windows PowerShell muestra cómo forzar el cuórum en uno de los nodos de recuperación ante desastres.
Start-ClusterNode –Name "DRNODE1" –FixQuorum
Después de ejecutar este comando, debe ver algo similar a lo siguiente.
Nombre Estado------- --------drnode1 Joining
Nota: si el servicio de clúster se sigue ejecutando en "DRNODE1", puede utilizar el siguiente comando en Windows PowerShell para detener el servicio antes de iniciar el servicio de clúster de nuevo con el cuórum forzado:
Stop-ClusterNode –Name "DRNODE1"
Para conocer las herramientas adicionales que puede utilizar para forzar el cuórum, como cluster.exe o el Administrador de clústeres de conmutación por error, vea Forzar el inicio de un clúster de WSFC sin un cuórum.
2. Abra el Administrador de clústeres de conmutación por error para ver el estado del clúster de Windows. En este momento, el clúster de Windows debe estar activo en el estado de cuórum forzado, al igual que la FCI secundaria. La FCI del centro de datos principal todavía estará sin conexión, como los recursos del grupo de disponibilidad.
Ilustración 12: Administrador de clústeres de conmutación por error tras forzar el cuórum
3. Ponga el grupo de disponibilidad en línea en la FCI de recuperación ante desastres.
Advertencia: si la réplica se configuró con el modo asincrónico, esto significa que al restaurar el servicio podría provocarse la pérdida de datos para cualquier registro sin enviar. Asegúrese de comprender bien las consecuencias de esta acción.
Para obtener más información sobre lo que hacer antes, durante y después de este tipo de conmutación por error manual, vea Realizar una conmutación por error manual forzada de un grupo de disponibilidad.
28
Conéctese a la FCI en el centro de datos de recuperación ante desastres con SQL Server Management Studio. SQL Server Management Studio debe mostrar las bases de datos de disponibilidad en un estado "sin sincronización". La FCI de recuperación ante desastres también se muestra como "resolviendo" según se ilustra en la Ilustración 13.
Ilustración 13: el Explorador de objetos de SQL Server Management Studio después de forzar el cuórum
Observe en la Ilustración 13 que la otra réplica, que en este ejemplo es "SQLFCIPrimary \ INST_A", no muestra ningún estado en el explorador de objetos debajo de la carpeta 'Réplicas de disponibilidad' de AG1. Esta es la FCI del centro de datos principal que ya no está accesible debido a la interrupción del sistema.
Si el riesgo de perder datos es aceptable y se debe restaurar el servicio en el centro de datos, ejecute la sintaxis de Transact-SQL siguiente en la FCI de recuperación ante desastres para forzar la conmutación por error.
ALTER AVAILABILITY GROUP [AG1] FORCE_FAILOVER_ALLOW_DATA_LOSS;
En este punto, sus bases de datos dentro del grupo de disponibilidad deben estar disponibles. Vea la Ilustración 14 para obtener un ejemplo del estado posterior al fuerce de la conmutación por error.
29
Ilustración 14: el Explorador de objetos después de forzar la conmutación por error
Después de ponerse de nuevo en línea, las nuevas conexiones con el agente de escucha del grupo de disponibilidad se enrutan automáticamente a la réplica principal actual, que ahora se hospeda en la FCI de la recuperación ante desastres.
Observe también que seguirá viendo diferentes mensajes de advertencia acerca de que los nodos del centro de datos principal no están disponibles en SQL Server Management Studio. La Ilustración 15 muestra un ejemplo de su posible apariencia.
30
Ilustración 15: Panel de AlwaysOn después de una conmutación por error forzada
4. Desde un nodo WSFC de recuperación ante desastres, quite los votos de los nodos del centro de datos principal y dé votos a los nodos del centro de datos de recuperación ante desastres. Los votos pueden quitarse aunque los nodos del centro de datos principal no estén disponibles. Los dos nodos que tienen asignado el peso "1" son los nodos del WSFC de recuperación ante desastres.
(Get-ClusterNode "DRNode1").NodeWeight=1
(Get-ClusterNode "DRNode2").NodeWeight=1
(Get-ClusterNode "PrimaryNode1").NodeWeight=0
(Get-ClusterNode "PrimaryNode2").NodeWeight=0
Nota: si el sitio de recuperación ante desastres tiene que usarse durante un período de tiempo más largo, se recomienda agregar miembros que votan adicionales (recurso compartido de archivos o nodo WSFC).
Antes de continuar, puede comprobar que los votos de los nodos se han modificado como se esperaba con el comando siguiente de Windows PowerShell.
Get-ClusterNode | fl NodeName, NodeWeight
Según se mencionó antes en el documento, los entornos de grandes empresas suelen hacer una separación de labores entre los roles de administrador de base de datos, de administrador de Windows Server (o clúster) y de administrador de red. En la tabla siguiente se resume el flujo de trabajo de recuperación ante desastres descrito antes, con las áreas que suelen encontrarse en los diversos roles empresariales desde la perspectiva del planeamiento.
31
Paso Administrador de base de datos
Administrador de clúster o Windows Server
Administrador de red
1. Confirme el estado actual del centro de datos principal y el resto de los nodos de recuperación ante desastres de WSFC, que coordinan los trabajos.
Sí Sí Sí
2. Fuerce el cuórum en uno de los nodos en el sitio de recuperación ante desastres para tener acceso a la FCI de recuperación ante desastres.
Sí
3. Fuerce la conmutación por error del grupo de disponibilidad en la FCI de recuperación ante desastres.
Sí
4. Agregue votos a los nodos de recuperación ante desastres y quite votos de los nodos principales.
Sí
Tabla 3: recuperarse de un desastre según el rol de trabajo
Revertir al centro de datos principalCon el servicio restaurado en el centro de datos de recuperación ante desastres, se supone que el escenario ilustrado en este documento es un estado temporal hasta que se resuelven los problemas del centro de datos principal. Un escenario en el que se interrumpa el servicio puede experimentar diversas variaciones y, por lo tanto, la recuperación también varía. En el escenario descrito aquí se supone un desastre en el que los servidores del centro de datos principal están inactivos durante un período prolongado de tiempo.
Tras resolver los problemas con el centro de datos principal y volver a poner en marcha sus nodos, estos intentan conectarse al WSFC. Después de volver a conectarse al WSFC con los servicios de clúster en ejecución, los pesos de los nodos asignados al nodo de recuperación ante desastres deberían estar en vigor. En este escenario también se supone que las instalaciones originales de SQL Server y las bases de datos asociadas siguen intactas.
La réplica en la FCI del centro de datos principal que ha sufrido antes la interrupción estará en el estado "sin sincronización" (vea la Ilustración 16).
32
Ilustración 16: SQL Server Management Studio después de la recuperación de la FCI principal pero antes de reanudar el grupo de disponibilidad
La instancia de SQL Server del sitio de recuperación ante desastres (en nuestro ejemplo "SQLFCIDR\DC2") sigue siendo la réplica principal. Observe también el símbolo de "pausa" por cada base de datos de disponibilidad debajo de la carpeta de bases de datos de disponibilidad.
En este punto, debe evaluar si necesita poner a salvo los datos (es decir, los cambios de los datos realizados en la réplica principal original, pero que no se enviaron a la réplica de recuperación ante desastres justo antes del desastre), o seguir en cambio para restablecer las sesiones de réplica.
Advertencia: si se reanudan las réplicas del grupo de disponibilidad en este momento puede ocasionarse la pérdida de datos, de modo que, si esto no es aceptable, los datos deben guardarse antes de que se reanude el movimiento de datos. A la inversa, si no se reanuda el grupo de disponibilidad, los archivos de registro de transacciones seguirán creciendo en las bases de datos de la réplica de recuperación ante desastres.
Un método para ello sería crear una instantánea de base de datos en las bases de datos secundarias suspendidas (principal original) con el fin de extraer los datos necesarios para volver a sincronizar con la versión de la réplica de recuperación ante desastres de las bases de datos de disponibilidad. En el ejemplo siguiente se muestra cómo crear una instantánea de base de datos en una base de datos de disponibilidad "sin sincronización".
-- Crear la instantánea de base de datosCREATE DATABASE AppDB_A1 ON( NAME = AppDB, FILENAME = 'R:\MSSQL11.MSSQLSERVER\MSSQL\Data\AppDB_A1.ss' )AS SNAPSHOT OF AppDB;GO
33
Los datos necesarios ahora se pueden extraer de la instantánea de base de datos e insertar correctamente en la réplica principal actual, antes de reanudar el movimiento de datos.
Nota: para obtener más información acerca de los riesgos que supone forzar la conmutación por error y mitigar la pérdida de datos, vea Conmutación por error y modos de conmutación por error.
Una vez que la pérdida de datos se aborda correctamente y cuando llegue la hora de revertir el servicio de nuevo al centro de datos principal, el paso siguiente será mover el rol de réplica principal de vuelta al centro de datos principal de un modo controlado:
1. Inicie la migración controlada de nuevo al centro de datos principal agregando otra vez el voto de cuórum a los dos nodos del centro de datos principal. Después de configurar esta opción, asegúrese de comprobar otra vez que todos los nodos del WSFC tienen un voto.
2. Para reanudar cada base de datos que participa en el grupo de disponibilidad, ejecute los comandos ALTER DATABASE de Transact-SQL en la FCI del centro de datos principal. A continuación se muestra un ejemplo.
ALTER DATABASE AppDB SET HADR RESUME;GOALTER DATABASE ConfigDB SET HADR RESUME;GOALTER DATABASE ReportDB SET HADR RESUME;GO
3. Para sincronizar antes de la conmutación por error, modifique el grupo de disponibilidad en la FCI de recuperación ante desastres para utilizar temporalmente el modo de disponibilidad de confirmación sincrónica. La configuración de la confirmación sincrónica se debería realizar durante un período de poca actividad de la aplicación para minimizar el efecto de la latencia de las transacciones en los usuarios.
A continuación se muestra un ejemplo del comando de Transact-SQL (ejecutado en la FCI principal actual del centro de datos de recuperación ante desastres). En este ejemplo, AG1 es el grupo de disponibilidad y la réplica del centro de datos principal se designa como SQLFCIPrimary\INST_A.
USE [maestra]GOALTER AVAILABILITY GROUP [AG1]MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);GO
En la misma sesión de SQL Server Management Studio, ejecute el siguiente comando para establecer la confirmación sincrónica también en la réplica de recuperación ante desastres.
34
USE [maestra]GOALTER AVAILABILITY GROUP [AG1]MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);GO
4. Confirme el estado de sincronización entre las dos ubicaciones (ambos estados de réplica deben indicar que son "correctos" antes de continuar con el paso siguiente, lo que significa ambas réplicas de confirmación sincrónica están sincronizadas).
SELECT role_desc,synchronization_health_desc
FROM sys.dm_hadr_availability_replica_states;
5. Para conmutar por error de la FCI del centro de datos de recuperación ante desastres a la FCI del centro de datos principal anterior, conéctese y ejecute el script siguiente en la FCI del centro de datos principal, que se convertirá en la nueva réplica principal.
ALTER AVAILABILITY GROUP [AG1] FAILOVER;
6. Si en la topología se utiliza el modo de alto rendimiento, como se ha mencionado anteriormente, cambie el nodo de la réplica de FCI de recuperación ante desastres de nuevo a la confirmación asincrónica. Ejecute las siguientes instrucciones de Transact-SQL en la réplica principal.
USE [maestra]GOALTER AVAILABILITY GROUP [AG1]MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);GO
USE [maestra]GOALTER AVAILABILITY GROUP [AG1]MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);GO
7. Quite los votos de cuórum de los nodos de recuperación ante desastres.
35
En la tabla siguiente se resume el flujo de trabajo de recuperación ante desastres descrito antes, con las áreas que suelen encontrarse en los diversos roles empresariales desde la perspectiva del planeamiento.
Paso Administrador de base de datos
Administrador de clúster o Windows Server
Administrador de red
1. Después de restaurar el servicio del centro de datos principal, los nodos y la FCI, agregue de nuevo los votos de cuórum a los nodos principales originales.
Sí
2. Reanude las sesiones de la base de datos de disponibilidad de cada réplica secundaria.
Sí
3. Cambie la réplica de la FCI de recuperación ante desastres y la réplica de la FCI del centro de datos principal a confirmación sincrónica.
Sí
4. Confirme el estado de sincronización entre las dos ubicaciones (ambos estados de réplica deben indicar que es "correcto" antes de ir al paso siguiente).
Sí
5. Conmute por error a la réplica de la FCI del centro de datos principal.
Sí
6. Revierta la réplica de recuperación ante desastres de nuevo a confirmación asincrónica (para coincidir con la configuración original).
Sí
7. Quite los votos de los nodos de WSFC de recuperación ante desastres.
Sí
Tabla 4: revertir al centro de datos principal
ConclusiónLos grupos de disponibilidad AlwaysOn de SQL Server 2012 se pueden utilizar para reemplazar la creación de reflejo de la base de datos en las topologías que usan FCI para lograr una alta disponibilidad y la creación de reflejo de la base de datos en la recuperación ante desastres. Este patrón de diseño amplía las capacidades de las versiones anteriores, posibilitando así una unidad de múltiples bases de datos de conmutación por error, réplicas de solo lectura, etcétera. En estas notas de producto se ha intentado presentar una nueva solución con una alta disponibilidad y recuperación ante desastres en la que la arquitectura heredada se reemplazaba con las FCI y los grupos de disponibilidad AlwaysOn.
La implementación correcta de este tipo de solución HA/DR implica no solo al equipo de administradores de base de datos sino también la estrecha colaboración entre dicho equipo, el equipo de administración de Windows Server y el equipo de red en la organización de TI. Compartir los conocimientos es muy útil cuando se trata de implementar una solución HA/DR.
36
Referencias Patrones de diseño de alta disponibilidad y recuperación ante desastres de AlwaysOn en
SQL Server 2012 (http://go.microsoft.com/fwlink/?LinkId=255048) Guía de Soluciones de AlwaysOn de Microsoft SQL Server para lograr alta disponibilidad y
recuperación ante desastres (http://msdn.microsoft.com/library/hh781257.aspx) Instancias de clúster de conmutación por error AlwaysOn
(http://technet.microsoft.com/library/ms189134.aspx) Información general de los grupos de disponibilidad AlwaysOn
(http://technet.microsoft.com/library/ff877884(v=SQL.110).aspx) Clústeres de conmutación por error y grupos de disponibilidad AlwaysOn
(http://technet.microsoft.com/library/ff929171.aspx) Requisitos previos, restricciones y recomendaciones para los grupos de disponibilidad AlwaysOn
(http://technet.microsoft.com/library/ff878487(v=sql.110).aspx) Guía paso a paso del clúster de conmutación por error: configurar el cuórum en un clúster de
conmutación por error (http://technet.microsoft.com/library/cc770620(v=WS.10).aspx) Revisión de Windows Server para los votos de cuórum (http://support.microsoft.com/kb/2494036) Windows PowerShell (http://technet.microsoft.com/library/bb978526) Asignar comandos de Cluster.exe a los cmdlets de Windows PowerShell para los clústeres de
conmutación por error (http://technet.microsoft.com/library/ee619744(v=WS.10).aspx) Guía de supervivencia de Windows PowerShell
(http://social.technet.microsoft.com/wiki/contents/articles/183.windows-powershell-survival-guide-en-us.aspx)
Cmdlets de clúster de conmutación por error en Windows PowerShell (http://technet.microsoft.com/library/ee461009.aspx)
SQL Server PowerShell (http://msdn.microsoft.com/es-es/library/hh245198.aspx)
Para obtener más información:
Sitio web de SQL Server (http://www.microsoft.com/sqlserver/)
SQL Server TechCenter (http://technet.microsoft.com/sqlserver/)
SQL Server DevCenter (http://msdn.microsoft.com/sqlserver/)
¿Le sirvió de ayuda este documento? Proporciónenos su opinión. Díganos, en una escala de 1 (poco útil) a 5 (excelente), cómo calificaría este documento y por qué lo valora con esta puntuación. Por ejemplo:
¿Lo valora positivamente debido a que tiene buenos ejemplos, capturas de pantalla excelentes, una redacción comprensible u otra razón?
¿Lo valora negativamente debido a que sus ejemplos son escasos, las capturas de pantalla son borrosas o su redacción es poco clara?
Esta información nos ayudará a mejorar la calidad de las notas del producto que publicamos.
Enviar comentarios
37
