Conceptos relativos a la alta disponibilidad y la...

Guía de soluciones AlwaysOn de Microsoft SQL Serverpara lograr una alta disponibilidad con recuperación ante desastres

Redactor: LeRoy Tuttle, Jr. (Microsoft).

Colaboradores: Cephas Lin (Microsoft), Justin Erickson (Microsoft), Lindsey Allen (Microsoft), Min He (Microsoft), Sanjay Mishra (Microsoft).

Revisores: Alexei Khalyako (Microsoft), Allan Hirt (SQLHA), Ayad Shammout (Caregroup), Benjamin Wright-Jones (Microsoft), Charles Matthews (Microsoft), David P. Smith (ServiceU), Juergen Thomas (Microsoft), Kevin Farlee (Microsoft), Shahryar G. Hashemi (Motricity), Wolfgang Kutschera (Bwin Party).

Fecha de publicación: enero de 2012

Corresponde a: SQL Server 2012

Resumen: en estas notas del producto se describe cómo reducir el tiempo de inactividad planeado y no planeado, maximizar la disponibilidad de las aplicaciones y permitir la protección de datos mediante soluciones de alta disponibilidad y recuperación ante desastres AlwaysOn de SQL Server 2012.

Un objetivo clave de este documento es establecer un contexto común para los debates relacionados que se establecen entre los interesados corporativos, los responsables técnicos, los arquitectos del sistema, los ingenieros de infraestructura y los administradores de bases de datos.

El contenido se presenta en dos partes principales:

Conceptos relativos a la alta disponibilidad y la recuperación ante desastres. Proporciona una descripción breve de los elementos fundamentales y los retos del planeamiento, la administración y la cuantificación de los objetivos empresariales de un entorno de base de datos de alta disponibilidad. Esta explicación va seguida de una breve información general de las funciones de alta disponibilidad y recuperación ante desastres de las soluciones de Windows Server y AlwaysOn de SQL Server 2012.

Niveles de protección de AlwaysOn de SQL Server. Proporciona una explicación más profunda de las funciones de las características, la lógica y las dependencias de los niveles de protección que ofrece una solución AlwaysOn de SQL Server. Describe la disponibilidad de la infraestructura, las funciones de las aplicaciones de la capa de datos y la protección en las instancias de SQL Server y en las bases de datos.

Guía de soluciones AlwaysOn de Microsoft SQL Server para lograr alta disponibilidad y recuperación ante desastres i

Guía de soluciones AlwaysOn de Microsoft SQL Server para lograr alta disponibilidad y recuperación ante desastres ii

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 con fines meramente ilustrativos 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.

Guía de soluciones AlwaysOn de Microsoft SQL Server para lograr alta disponibilidad y recuperación ante desastres iii

ContenidoConceptos relativos a la alta disponibilidad y la recuperación ante desastres...........1

Qué supone una alta disponibilidad........................................................................................................1

Tiempo de inactividad planeado y no planeado.....................................................................................................................1

Degradación de la disponibilidad...........................................................................................................................................2

Cuantificación del tiempo de inactividad.................................................................................................2

Objetivos de recuperación.....................................................................................................................................................3

Justificar el ROI o el costo alternativo....................................................................................................................................3

Supervisar el estado de disponibilidad...................................................................................................................................4

Planear la recuperación de un desastre.................................................................................................................................4

Información general: alta disponibilidad con Microsoft SQL Server 2012...............................................5

AlwaysOn de SQL Server........................................................................................................................................................5

Reducir significativamente el tiempo de inactividad planeado..............................................................................................5

Eliminar el hardware inactivo y mejorar la eficacia de los costos y el rendimiento................................................................6

Facilidad de implementación y administración......................................................................................................................6

Comparación de las funciones RPO y RTO..............................................................................................................................6

Niveles de protección de AlwaysOn de SQL Server.............................................7Disponibilidad de la infraestructura........................................................................................................8

Sistema operativo Windows...................................................................................................................................................8

Clústeres de conmutación por error de Windows Server.......................................................................................................9

Asistente para la validación de clúster WSFC.......................................................................................................................11

Configuración de los votos y modos de cuórum WSFC.........................................................................................................12

Recuperación ante desastres WSFC mediante cuórum forzado...........................................................................................15

Protección de instancias de SQL Server.................................................................................................17

Mejoras de la disponibilidad: instancias de SQL Server........................................................................................................17

Instancias de clúster de conmutación por error de AlwaysOn.............................................................................................18

Disponibilidad de bases de datos..........................................................................................................21

Grupos de disponibilidad AlwaysOn.....................................................................................................................................21

Conmutación por error del grupo de disponibilidad............................................................................................................22

Agente de escucha de grupo de disponibilidad....................................................................................................................24

Mejoras de la disponibilidad: bases de datos.......................................................................................................................26

Recomendaciones para la conectividad de cliente................................................................................27

Conclusión....................................................................................................... 28

Guía de soluciones AlwaysOn de Microsoft SQL Server para lograr alta disponibilidad y recuperación ante desastres iv

Conceptos relativos a la alta disponibilidad y la recuperación ante desastresCuando las partes interesadas conocen bien los motores del negocio, los desafíos y las aspiraciones del planeamiento, la administración y la cuantificación de los objetivos RTO y RPO, es el mejor momento para elegir la tecnología de base de datos que permita una alta disponibilidad con recuperación ante desastres.

Los lectores que conocen estos conceptos pueden pasar a la sección Información general: alta disponibilidad con Microsoft SQL Server 2012 de este documento.

Qué supone una alta disponibilidadEn una aplicación de software o un servicio determinados, la alta disponibilidad se mide a la larga según la experiencia y las expectativas del usuario final. Las repercusiones del tiempo de inactividad tangibles y percibidas dentro de la empresa se pueden expresar en función de la pérdida de información, los daños materiales, la reducción de la productividad, los costos alternativos, los daños contractuales o la pérdida de errores.

El objetivo principal de una solución de alta disponibilidad es minimizar o mitigar las consecuencias del tiempo de inactividad. Una estrategia correcta equilibra óptimamente los procesos corporativos y los contratos de nivel de servicio (SLA) con los costos de infraestructura y las funciones técnicas.

Una plataforma se considera de alta disponibilidad según el contrato y las expectativas de los clientes y las partes interesadas. La disponibilidad de un sistema puede expresarse según este cálculo:

Tiempode actividad realTiempodeactividad esperado

×100%

El valor resultante a menudo se expresa en el sector con el número de nueves que la solución proporciona, lo que a la larga termina siendo un número anual de minutos de posible tiempo de actividad o, a la inversa, de minutos de tiempo de inactividad.

Número de nueves Porcentaje de disponibilidad

Tiempo de inactividad anual total

2 99% 3 días, 15 horas3 99.9% 8 horas, 45 minutos4 99.99% 52 minutos, 34 segundos5 99.999% 5 minutos, 15 segundos

Tiempo de inactividad planeado y no planeadoLas interrupciones del sistema pueden preverse o planearse o bien pueden ser el resultado de un error imprevisto. El tiempo de inactividad no tiene por qué considerarse negativamente si se administra de modo correcto. Hay dos tipos principales de tiempo de inactividad previsible:

Mantenimiento planeado. Una ventana de tiempo se anuncia por anticipado y se coordina para realizar tareas de mantenimiento planeadas como son los procedimientos de ensayo de la recuperación ante desastres, las revisiones de software, las actualizaciones de hardware, las actualizaciones de contraseñas, la reindización sin conexión o la carga de datos. Los procedimientos operativos deliberados y bien administrados deben minimizar el tiempo de inactividad y evitar la pérdida de datos. Las actividades planeadas de mantenimiento pueden verse como inversiones necesarias para evitar o mitigar otros escenarios de interrupción del sistema no planeados y, posiblemente, más graves.

Guía de soluciones AlwaysOn de Microsoft SQL Server para lograr alta disponibilidad y recuperación ante desastres 1

Interrupción del sistema no planeada. A veces, pueden ocurrir errores en los procesos, en la infraestructura o en el sistema que no pueden planearse ni controlarse, o que son imprevisibles pero se considera que es demasiado improbable que se produzcan o que tendrán una repercusión aceptable. Una solución sólida con alta disponibilidad detecta estos tipos de errores, recupera automáticamente el sistema después de la interrupción y, a continuación, restaura la tolerancia a errores.

Al establecer los SLA para que haya una alta disponibilidad, debe calcular los indicadores clave de rendimiento independientes (KPI) de las actividades de mantenimiento planeadas y del tiempo de inactividad no planeado. Este enfoque permite contrastar la inversión en actividades planeadas de mantenimiento frente al beneficio que supone evitar el tiempo de inactividad no planeado.

Degradación de la disponibilidadUn sistema con una alta disponibilidad no debe considerarse como una proposición en la que haya que tenerlo todo o nada. Como alternativa a una interrupción completa, el usuario final suele conformarse con un sistema que esté parcialmente disponible o que presente una funcionalidad o una degradación del rendimiento limitados. Estos diversos grados de disponibilidad son, por ejemplo:

Operaciones diferidas y de solo lectura. Durante un período de mantenimiento o durante una recuperación ante desastres organizada, la recuperación de datos todavía es posible, pero el procesamiento en segundo plano y los nuevos flujos de trabajo pueden detenerse o retrasarse temporalmente.

Capacidad de respuesta de las aplicaciones y latencia de datos. Si se produce una carga de trabajo excesiva, un trabajo acumulado de procesamiento o un error parcial de la plataforma, los recursos de hardware, que siempre son limitados, pueden verse fácilmente superados. La experiencia del usuario puede verse perjudicada, aunque el trabajo se pueda seguir realizando de un modo menos productivo.

Errores parciales, transitorios o inminentes. La solidez de la pila de hardware o de la lógica de una aplicación que sigue intentando ponerse en funcionamiento o que corrige su estado al encontrar un error. Estos tipos de problemas pueden dar la sensación al usuario final de que existe una latencia en los datos o de que la capacidad de respuesta de la aplicación es insuficiente.

Error parcial generalizado. Las interrupciones, planeadas o no, pueden producirse dentro de los niveles verticales de la pila de la solución (infraestructura, plataforma y aplicación) u horizontalmente entre componentes funcionales diferentes. Los usuarios pueden experimentar una degradación parcial o ninguna, según las características o los componentes afectados.

La aceptación de estos escenarios menos óptimos de lo deseable debe considerarse como parte de un espectro de degradación de la disponibilidad que conduce a una interrupción completa del sistema, además de como pasos intermedios de una recuperación ante desastres gradual.

Cuantificación del tiempo de inactividadCuando tiene lugar un tiempo de inactividad, ya sea planeado o no, el objetivo principal en la empresa es volver a poner el sistema en línea y minimizar la pérdida de datos. Cada minuto de tiempo de inactividad supone costos directos e indirectos. Con el tiempo de inactividad no planeado, debe equilibrar el tiempo y el esfuerzo necesarios para determinar las causas de la interrupción del sistema, cuál es el estado actual del mismo y qué pasos son necesarios para recuperarse de ella.


En un momento dado predeterminado de la interrupción, debe decidir si dejar de investigar la causa de la interrupción del sistema o realizar tareas de mantenimiento, recuperarse de la interrupción poniendo el sistema de nuevo en línea y, si es necesario, restablecer la tolerancia a errores.

Objetivos de recuperaciónLa redundancia de datos es un componente clave de una solución de base de datos de alta disponibilidad. La actividad transaccional en la instancia principal de SQL Server se aplica de modo sincrónico o asincrónico a una o varias instancias secundarias. Cuando se produce una interrupción del sistema, las transacciones que estaban en curso podrían revertirse o puede que se pierdan en las instancias secundarias debido a los retrasos en la propagación de los datos.

Puede medir el impacto y también establecer los objetivos de recuperación en función del tiempo que se tarda en volver a poner el sistema en funcionamiento y de cuánta latencia de tiempo hay en la última transacción recuperada:

Objetivo de tiempo de recuperación (RTO). Es la duración de la interrupción del sistema. El objetivo inicial es conseguir que el sistema vuelva a ponerse en línea al menos con la capacidad de solo lectura para facilitar la investigación del problema. Sin embargo, el objetivo principal es restaurar el servicio completo hasta el punto en que las nuevas transacciones puedan tener lugar.

Objetivo de punto de recuperación (RPO). Suele ser tomado como medida de una pérdida de datos aceptable. Es la latencia o la diferencia de tiempo entre la última transacción de datos confirmada antes del error y los datos más recientes recuperados después del mismo. La pérdida de datos real puede variar dependiendo de la carga de trabajo en el sistema en el momento del error, el tipo de error y el tipo de solución de alta disponibilidad utilizado.

Debe usar los valores de RTO y de RPO como los objetivos que marcan la tolerancia de la empresa al tiempo de inactividad y la pérdida de datos aceptable, y también como métricas para supervisar el estado de disponibilidad.

Justificar el ROI o el costo alternativoLos costos empresariales del tiempo de inactividad pueden ser financieros o también pueden cuantificarse con respecto a la buena disposición del cliente. Estos costos pueden acumularse con el tiempo o se puede incurrir en ellos en un momento determinado de la interrupción del sistema. Además de proyectar el costo que supone una interrupción del sistema con un punto de recuperación de datos y de tiempo de recuperación dado, también puede calcular las inversiones en infraestructura y en procesos corporativos necesarias para lograr los objetivos de RTO y de RPO o para evitar su interrupción simultánea. Estos factores que afectan a la inversión deben incluir:

Evitar el tiempo de inactividad. Los costos de recuperación de una interrupción del sistema se evitan de forma global si esta no se produce. Las inversiones son las que se derivan de la adquisición de infraestructura o hardware redundante y tolerante a errores, la distribución de las cargas de trabajo a través de puntos de error aislados y el tiempo de inactividad planeado para llevar a cabo un mantenimiento preventivo.

Recuperación automática. Si se produce un error del sistema, puede reducir mucho el impacto del tiempo de inactividad en la experiencia del cliente a través de un sistema de recuperación automática y transparente.

Uso de los recursos. La infraestructura de modo de espera o secundaria puede estar inactiva, esperando a que se produzca una interrupción del sistema. También puede aprovecharse para las cargas de trabajo de solo lectura o para mejorar el rendimiento general del sistema distribuyendo las cargas de trabajo en todo el hardware disponible.


Si se tienen en cuenta los objetivos dados de RTO y de RPO, las inversiones necesarias en sistemas de recuperación y disponibilidad, junto con los costos de tiempo de inactividad proyectados, se pueden expresar y justificar en función del tiempo. Durante una interrupción del sistema real, esto permite tomar decisiones económicas según el tiempo de inactividad transcurrido.

Supervisar el estado de disponibilidadDesde un punto de vista operativo, durante una interrupción real del sistema, no debe intentar considerar todas las variables pertinentes y calcular el ROI o los costos alternativos en ese momento. En cambio, es mejor supervisar la latencia de los datos en las instancias en espera que representan el RPO esperado.

En el caso de que se produzca una interrupción del sistema, también debe limitar el tiempo que se emplea al principio en investigar la causa original durante dicha interrupción. En cambio, es mejor centrarse en validar el estado del entorno de recuperación y confiar en los registros del sistema detallados y en las copias secundarias de los datos para llevar a cabo un análisis posterior.

Planear la recuperación de un desastreAunque el intento por mantener una alta disponibilidad conlleva el esfuerzo por evitar que se produzca una interrupción del sistema, la recuperación ante desastres trata de restablecer la alta disponibilidad tras la interrupción.

En la medida de lo posible, los procedimientos y las responsabilidades de la recuperación ante desastres deben formularse antes de que se produzca una interrupción efectiva del sistema. Una vez definidas las alertas y una supervisión activa, la decisión de iniciar un plan de recuperación y una conmutación por error manual o automatizada debe vincularse a los umbrales de RPO y de RTO preestablecidos equivalentes. El ámbito de un plan de recuperación ante desastres apropiado debe incluir:

Granularidad de los errores y la recuperación. En función de la ubicación y el tipo de error, puede realizar una acción correctora en diferentes niveles, es decir, el centro de datos, la infraestructura, la plataforma, la aplicación o la carga de trabajo.

Material de origen para la investigación. Las partes interesadas deben poder acceder sin problema al historial de supervisiones recientes y de referencia, a las alertas del sistema, a los registros de eventos y a las consultas de diagnóstico.

Coordinación de dependencias. Dentro de la pila de aplicaciones y entre las partes interesadas, ¿cuáles son las dependencias del sistema y empresariales?

Árbol de decisión. Un árbol de decisión predeterminado, repetible y validado que incluya las responsabilidades de los roles, la clasificación de los errores, los criterios de conmutación por error en función de los objetivos de RPO y de RTO, y los procedimientos de recuperación prescritos.

Validación. Después de seguir el procedimiento para recuperarse de una interrupción del sistema, ¿qué debe hacerse para comprobar que su funcionamiento ha vuelto a ser el normal?

Documentación. Recopile todos los elementos siguientes como documentación, con el detalle y la claridad suficientes para que terceros puedan ejecutar el plan de recuperación con una ayuda mínima. Este tipo de documentación suele conocerse como "libro de documentación de procesos" o "libro de recetas".

Ensayos de la recuperación. Practique con regularidad el plan de recuperación ante desastres para establecer las expectativas de referencia de los objetivos de RTO y considere rotar con frecuencia el hospedaje de producción principal dentro del sitio principal y de cada uno de los sitios de recuperación ante desastres.


Información general: alta disponibilidad con Microsoft SQL Server 2012Para lograr los objetivos requeridos en cuanto a RPO y RTO, es necesario garantizar que las aplicaciones esenciales están en funcionamiento de forma continuada y que los datos críticos están disponibles y no sufren ninguna interrupción del sistema, planeada o no. SQL Server proporciona un conjunto de características y funciones que pueden ayudar a lograr esos objetivos manteniendo un costo y una complejidad reducidos.

Los lectores que conozcan bien las nuevas funciones de AlwaysOn pueden avanzar hasta la explicación siguiente, más minuciosa, de la sección Niveles de protección de AlwaysOn de SQL Server .

AlwaysOn de SQL ServerAlwaysOn es una nueva solución de alta disponibilidad y recuperación ante desastres integrada, flexible y rentable. Permite disfrutar de hardware y datos redundantes dentro de los propios centros de datos y entre ellos, además de mejorar el tiempo de conmutación por error de las aplicaciones para aumentar la disponibilidad de las de gran importancia. AlwaysOn aporta flexibilidad en la configuración y permite la reutilización de las inversiones actuales en hardware.

Una solución AlwaysOn puede sacar provecho de dos características importantes de SQL Server 2012 para configurar la disponibilidad tanto en las bases de datos como en las instancias:

Los grupos de disponibilidad AlwaysOn, una novedad de SQL Server 2012, mejoran notablemente las funciones de creación de reflejo de la base de datos, ayudan a asegurar la disponibilidad de las bases de datos de aplicación y evitan la pérdida de datos gracias a que estos se mueven según registros y así se pueden proteger sin necesidad de compartir los discos.

Los grupos de disponibilidad proporcionan un conjunto integrado de opciones como son la conmutación por error manual y automática de un grupo lógico de bases de datos, la compatibilidad con hasta cuatro réplicas secundarias, la conmutación por error rápida de las aplicaciones y la reparación automática de las páginas.

Las instancias de clúster de conmutación por error (FCI) AlwaysOn mejoran la característica de clústeres de conmutación por error de SQL Server y admiten la agrupación en clústeres de varios sitios a través de las subredes, lo que habilita la conmutación por error entre centros de datos de las instancias de SQL Server. Una conmutación por error más rápida y más predecible de las instancias es otra ventaja clave que permite una recuperación más rápida de las aplicaciones.

Reducir significativamente el tiempo de inactividad planeadoLas causas más importantes del tiempo de inactividad de una aplicación en una organización son la aplicación de revisiones en un sistema operativo, el mantenimiento del hardware y otras similares, todas planeadas. Estas operaciones pueden constituir casi el ochenta por ciento de la interrupción del sistema en un entorno informático.

SQL Server 2012 ayuda a reducir el tiempo planeado de inactividad al aminorar en gran medida la necesidad de aplicar nuevas revisiones y habilitar más operaciones de mantenimiento en línea:

Windows Server Core. SQL Server 2012 admite las implementaciones con Windows Server Core, una opción de implementación mínima y mejorada de Windows Server 2008 y Windows Server 2008 R2. Esta configuración del sistema operativo puede reducir el tiempo de inactividad planeado reduciendo la necesidad de aplicar revisiones al sistema operativo hasta el sesenta por ciento.

Operaciones en línea. Las mejoras en la compatibilidad con operaciones en línea como la reindización LOB y la agregación de columnas con valores predeterminados ayuda a reducir el tiempo de inactividad durante las operaciones de mantenimiento de bases de datos.


Actualización gradual y revisiones. Las características de AlwaysOn facilitan las actualizaciones graduales y la aplicación de revisiones en las instancias, lo que ayuda en gran medida a reducir el tiempo de inactividad de la aplicación.

SQL Server en Hyper-V. Las instancias de SQL Server hospedadas en el entorno Hyper-V disfrutan de la ventaja adicional de la migración actualizada, que permite migrar equipos virtuales entre los hosts con un tiempo de inactividad cero. Los administradores pueden realizar operaciones de mantenimiento en el host sin afectar a las aplicaciones.

Eliminar el hardware inactivo y mejorar la eficacia de los costos y el rendimientoLas soluciones de alta disponibilidad típicas implican la implementación de servidores pasivos, redundantes y costosos. Los grupos de disponibilidad AlwaysOn le permiten usar réplicas de base de datos secundarias en servidores que, de otro modo, serían pasivos o estarían inactivos para las cargas de trabajo de solo lectura como son las operaciones de copia de seguridad o las consultas de informes de SQL Server Reporting Services. La capacidad de usar simultáneamente las réplicas tanto de la base de datos secundaria como de la principal ayuda a mejorar el rendimiento de todas las cargas de trabajo debido a que los recursos se equilibran mejor en las inversiones de hardware del servidor.

Facilidad de implementación y administraciónCaracterísticas como el Asistente para configuración, la compatibilidad con la interfaz de la línea de comandos de Windows PowerShell, los paneles, las vistas de administración dinámica (DMV), la administración basada en directivas y la ayuda de integración del Centro de sistema ayudan a simplificar la implementación y la administración de los grupos de disponibilidad.

Comparación de las funciones RPO y RTOLos objetivos empresariales del objetivo de punto de recuperación (RPO) y del objetivo de tiempo de recuperación (RTO) deben ser factores clave en la selección de una tecnología de SQL Server para una solución de alta disponibilidad y recuperación ante desastres.En esta tabla se ofrece una comparación aproximada del tipo de resultados que las diferentes soluciones pueden lograr:

Solución de SQL Server de alta disponibilidad y recuperación

ante desastres

Posible pérdida de datos

(RPO)

Posible tiempo de

recuperación (RTO)

Conmutación automática

por error

Secundarios legibles(1)

Grupo de disponibilidad AlwaysOn: confirmación sincrónica

Cero Segundos Sí(4) 0 - 2

Grupo de disponibilidad AlwaysOn: confirmación asincrónica

Segundos Minutos No 0 - 4

Instancia de clúster de conmutación por error AlwaysOn

N/D(5) Segundos a minutos

Sí N/D

Creación de reflejo de la base de datos(2) – Alta seguridad (sincrónico + testigo)

Cero Segundos Sí N/D

Creación de reflejo de la base de datos (2) – Alto rendimiento (asincrónico)

Segundos(6) Minutos(6) No N/D

Trasvase de registros Minutos(6) Minutos a horas(6)

No No duranteuna

restauraciónCopia de seguridad, copia, restauración.(3) Horas(6) Horas

a días(6)No No durante

una restauración

(1) Un grupo de disponibilidad AlwaysOn no puede tener más de cuatro réplicas secundarias en total, independientemente del tipo.(2) Esta característica se quitará en una versión futura de Microsoft SQL Server. Use grupos de disponibilidad AlwaysOn en su lugar.(3) La copia de seguridad, copia y restauración es adecuada para la recuperación ante desastres, pero no para lograr una alta disponibilidad.(4) La conmutación automática por error de un grupo de disponibilidad no se admite con una instancia de clúster de conmutación por error.(5) La FCI por sí sola no sirve para proteger los datos; la pérdida de datos depende de la implementación del sistema de almacenamiento.(6) Muy dependientes de los procedimientos de conmutación por error, la carga de trabajo y el volumen de datos.


Niveles de protección de AlwaysOn de SQL ServerLas soluciones AlwaysOn de SQL Server proporcionan tolerancia a errores y permiten la recuperación ante desastres a través de varios niveles lógicos y físicos de componentes de la aplicación e infraestructura. Desde siempre, ha sido una práctica habitual realizar una separación de labores y de responsabilidades de los diversos destinatarios y roles relacionados, por ejemplo, a cada uno le concernía fundamentalmente solo una parte de esos niveles de la solución.

Esta sección del documento se organiza de modo que se examina una descripción más profunda de cada uno de los niveles y se ofrecen unos fundamentos y una orientación para ayudarle en sus decisiones de implementación y en los pormenores del diseño.Una solución correcta de AlwaysOn de SQL Server requiere el conocimiento de estos niveles y la colaboración en los mismos: Nivel de infraestructura. La tolerancia a errores en el servidor y la comunicación de red entre nodos

sacan provecho de las características de Clústeres de conmutación por error de Windows Server (WSFC) para coordinar la supervisión del estado y la conmutación por error.

Nivel de la instancia de SQL Server. Una instancia de clúster de conmutación por error AlwaysOn (FCI) de SQL Server es una instancia de SQL Server que se instala a través de varios nodos de servidor y puede conmutar por error en ellos en un clúster WSFC. Los nodos que hospedan la FCI se asocian al almacenamiento compartido simétrico robusto (SAN o SMB).

Nivel de base de datos. Un grupo de disponibilidad es un conjunto de bases de datos de usuario que realizan la conmutación por error conjuntamente. Un grupo de disponibilidad consta de una réplica principal y de una a cuatro réplicas secundarias. Cada réplica está hospedada en una instancia de SQL Server (FCI o no FCI) en otro nodo del clúster WSFC.

Conectividad de cliente. Las aplicaciones cliente de la base de datos pueden conectarse directamente a un nombre de red de instancia de SQL Server o pueden conectarse a un nombre de red virtual (VNN) que está enlazado a un agente de escucha del grupo de disponibilidad. El VNN resume el clúster WSFC y la topología del grupo de disponibilidad, redirigiendo lógicamente las solicitudes de conexión a la réplica adecuada de la base de datos y la instancia de SQL Server.

La topología lógica de una solución AlwaysOn representativa se muestra en este diagrama:


Disponibilidad de la infraestructuraLos grupos de disponibilidad AlwaysOn y las instancias de clúster de conmutación por error AlwaysOn sacan provecho del sistema operativo Windows Server y de WSFC como una tecnología de plataforma. Más que nunca, los administradores de base de datos de Microsoft SQL Server profesionales basarán su trabajo en un conocimiento sólido de estas tecnologías.

Sistema operativo WindowsSQL Server se basa en la plataforma Windows para proporcionar la infraestructura y los servicios básicos para la conexión de red, el almacenamiento, la seguridad, la aplicación de revisiones y la supervisión.

Las diferentes ediciones de SQL Server 2012 se basan en las sucesivas funciones y la capacidad de las ediciones similares del sistema operativo Windows Server 2008 R2, como son las versiones Standard, Enterprise y Datacenter.

Para obtener más información, vea: Requisitos de hardware y software para instalar SQL Server 2012 (http://msdn.microsoft.com/es-es/library/ms143506(SQL.110).aspx).

Opción de instalación de Windows Server CoreUna característica clave de SQL Server 2012 para lograr una alta disponibilidad es que admite la implementación con la opción de instalación Server Core en Windows Server 2008 o versiones posteriores. La opción de instalación Server Core proporciona un entorno mínimo para ejecutar roles de servidor concretos con una funcionalidad restringida y una compatibilidad muy limitada de la aplicación de GUI. De forma predeterminada, solo se habilitan los servicios necesarios y un entorno del símbolo del sistema.

Este modo de funcionamiento reduce la sobrecarga del sistema y el área expuesta a ataques en el sistema operativo, y puede reducir significativamente los requisitos de mantenimiento continuado, de servicio y de aplicación de revisiones.

Una consideración clave para implementar SQL Server 2012 en Windows Server Core es que toda la implementación, la configuración, la administración y el mantenimiento de SQL Server y del sistema operativo deben realizarse con un entorno de scripting como Windows PowerShell o mediante herramientas remotas o de la línea de comandos.

Optimizar SQL Server para la nube privadaLos escenarios de alta disponibilidad y recuperación ante desastres son cada vez más esenciales en el entorno de la nube privada. Implemente SQL Server en su nube privada como ayuda para asegurarse de que los recursos de almacenamiento, la red y el equipo se usan de forma eficaz, con lo que se reduce tanto el espacio ocupado físicamente como los gastos operativos más importantes. Le ayuda a consolidar las implementaciones, a escalar sus recursos con eficacia y a implementar los recursos a petición sin comprometer el control.

Además de la compatibilidad de los Clústeres de conmutación por error de Windows Server con los sistemas invitado y host Hyper-V, SQL Server también admite la migración actualizada, que es la capacidad de mover equipos virtuales entre hosts sin que se perciba la existencia de ningún tiempo de inactividad. La migración actualizada también funciona junto con la agrupación en clústeres del invitado.

Para obtener más información, vea Informática en la nube privada: optimizar SQL Server para la nube privada (http://www.microsoft.com/SqlServerPrivateCloud).


http://www.microsoft.com/SqlServerPrivateCloud

http://www.microsoft.com/SqlServerPrivateCloud

http://msdn.microsoft.com/en-us/library/ms143506(SQL.110).aspx

Clústeres de conmutación por error de Windows ServerLos Clústeres de conmutación por error (WSFC) de Windows Server proporcionan características de infraestructura para disfrutar de escenarios de alta disponibilidad y recuperación ante desastres de aplicaciones de servidor hospedadas, como Microsoft SQL Server.

Si un nodo o un servicio de clúster WSFC sufre un error, los servicios o los recursos hospedados en ese nodo se pueden transferir automática o manualmente a otro nodo disponible en un proceso denominado conmutación por error. Con las soluciones AlwaysOn, este proceso se aplica tanto a las FCI como a los grupos de disponibilidad.

Los nodos del clúster WSFC colaboran para proporcionar colectivamente estos tipos de funciones:

Notificaciones y metadatos distribuidos. El servicio de WSFC y lo metadatos de aplicaciones hospedadas se mantiene en cada nodo del clúster. Estos metadatos incluyen la configuración y el estado de WSFC además de la configuración de la aplicación hospedada. Los cambios en los metadatos o el estado en un nodo se propagan automáticamente a los demás nodos del clúster.

Administración de recursos. Los nodos individuales del clúster pueden proporcionar recursos físicos como almacenamiento asociado directo (DAS), interfaces de red y acceso al almacenamiento en disco compartido. Las aplicaciones hospedadas, como SQL Server, se registran como un recurso de clúster y pueden configurar dependencias de inicio y de estado en otros recursos.

Supervisión de estado. La detección del estado del nodo principal y entre nodos se realiza mediante una combinación de comunicaciones de red de tipo latido y supervisión de recursos. Los votos de un quórum de nodos del clúster determinan el estado general del clúster.

Coordinación de conmutación por error. Cada uno de los recursos se configura para ser hospedado en un nodo principal y se pueden transferir automática o manualmente a uno o varios nodos secundarios. Una directiva de conmutación por error basada en el estado controla la transferencia automática de la propiedad de recursos entre los nodos. Se notifica a los nodos y las aplicaciones hospedadas cuando se produce la conmutación por error para que puedan reaccionar correctamente.

Para obtener más información, vea Windows Server | Equilibrio de clústeres de conmutación por error y de nodo (http://www.microsoft.com/windowsserver2008/es/es/failover-clustering-main.aspx).

Nota: ahora es muy importante que los administradores de bases de datos conozcan el funcionamiento interno de la administración de cuórum y los clústeres WSFC. Los pasos de la recuperación de errores, la administración y la supervisión del estado AlwaysOn están vinculadas intrínsecamente a la configuración de WSFC.

Configuraciones del almacenamiento WSFCLos Clústeres de conmutación por error de Windows Server se basan en cada nodo del clúster para administrar su sistema de archivos, sus volúmenes de disco y sus dispositivos de almacenamiento conectados. WSFC supone que el subsistema de almacenamiento es sumamente sólido y, por consiguiente, si el dispositivo de almacenamiento asociado a un nodo no está disponible, el nodo de clúster se considera erróneo.

Para las operaciones basadas en la escritura, un volumen de disco se asocia lógicamente a un único nodo de clúster al mismo tiempo mediante una reserva persistente SCSI-3. Dependiendo de la configuración y las funciones del subsistema de almacenamiento, si un nodo da error, la propiedad lógica del volumen de disco se puede transferir a otro nodo del clúster.


http://www.microsoft.com/windowsserver2008/es/es/failover-clustering-main.aspx

http://www.microsoft.com/windowsserver2008/es/es/failover-clustering-main.aspx

Las soluciones AlwaysOn de SQL Server aprovechan ciertas combinaciones de la configuración del almacenamiento WSFC, al tiempo que se limitan a ellas. Estas son, entre otras:

Asociado directo frente a remoto. Los dispositivos de almacenamiento están asociados directa y físicamente al servidor o son presentados por un dispositivo remoto a través de una red o un adaptador de bus de host (HBA). Entre las soluciones de almacenamiento remoto se incluyen las soluciones basadas en la Red de área de almacenamiento (SAN) como iSCSI o Fibre Channel, así como las soluciones basadas en los recursos compartidos de archivo Bloque de mensajería de servidor (SMB).

Simétrico o asimétrico. Los dispositivos de almacenamiento se consideran simétricos si a cada nodo del clúster se le presentan exactamente las mismas rutas de acceso de archivo y configuración del volumen de disco lógico. La capacidad y la implementación física de los volúmenes de disco subyacentes pueden variar.

Dedicado o compartido. El almacenamiento dedicado se reserva para ser utilizado y asignado a un único nodo del clúster. El almacenamiento compartido es accesible en varios nodos del grupo. El control y la propiedad de los dispositivos de almacenamiento compartido compatibles se pueden transferir de un nodo a otro utilizando los protocolos SCSI-3. WSFC admite el hospedaje en varios nodos simultáneamente de los volúmenes compartidos de clúster para el uso compartido de los archivos. Sin embargo, SQL Server no admite el acceso simultáneo de varios nodos a un volumen compartido.

Nota: las FCI de SQL Server siguen requiriendo almacenamiento compartido simétrico para estar accesibles a todos los posibles propietarios de nodos de la instancia. Sin embargo, con la introducción de los grupos de disponibilidad AlwaysOn, ahora puede implementar varias instancias diferentes que no sean FCI de SQL Server en un clúster WSFC, cada una con su propio almacenamiento único, dedicado, local o remoto.

Conmutación por error y detección del estado de los recursos WSFCCada recurso de un nodo de clúster WSFC puede notificar su condición y estado periódicamente o a petición. Diversas circunstancias pueden indicar un error de los recursos de clúster, como son: la interrupción del suministro eléctrico, errores de disco o de memoria, errores de la comunicación de red, una configuración errónea o servicios que no responden.

Puede hacer que los recursos de clúster WSFC como las redes, el almacenamiento o los servicios dependan unos de otros. El estado acumulativo de un recurso está determinado por la acumulación sucesiva de su condición con el estado de cada una de sus dependencias de recursos.

Para los grupos de disponibilidad AlwaysOn, el grupo de disponibilidad y el agente de escucha del grupo de disponibilidad se registran como recursos de clúster WSFC. En el caso de las instancias de clúster de conmutación por error AlwaysOn, se registran los servicios SQL Server y Agente SQL Server como recursos de clúster WSFC y ambos se hacen dependientes del recurso de nombre de red virtual de la instancia.

Si un recurso de clúster WSFC experimenta un determinado número de errores durante un tiempo, la directiva de conmutación por error configurada ocasiona que el servicio de clúster haga algo entre lo siguiente:

Reinicie el recurso en el nodo actual. Establezca el recurso sin conexión. Inicie una conmutación automática por error del recurso y sus dependencias en otro nodo.


Nota: la detección del estado de los recursos de clúster WSFC no tiene ningún efecto directo en el estado del nodo individual ni en el estado general del clúster.

Asistente para la validación de clúster WSFCEl Asistente para la validación de clúster es una característica que se integra en los clústeres de conmutación por error de Windows Server 2008 y Windows Server 2008 R2. Es una herramienta clave que un administrador de bases de datos puede usar para asegurarse de que existe un entorno WSFC estable, limpio y adecuado, antes de implementar una solución AlwaysOn de SQL Server.

Con el Asistente para validación de clúster, puede ejecutar un conjunto de pruebas concretas en una colección de servidores que vaya a utilizar como nodos de un clúster o en un grupo existente. Este proceso prueba el hardware y el software subyacentes directamente de forma individual para obtener una evaluación precisa del grado de idoneidad con que un clúster WSFC se admitiría en una configuración determinada.

Este proceso de validación está formado por una serie de pruebas y una recopilación de datos en cada nodo en estas categorías:

Inventario. Información sobre las versiones del BIOS, niveles de entorno, adaptadores de bus de host, RAM, versiones del sistema operativo, dispositivos, servicios, controladores, etcétera.

Red. Información sobre el orden de enlace de NIC, las comunicaciones de red, la configuración IP y la configuración de firewall. Valida las comunicaciones entre nodos en todas las NIC.

Almacenamiento. Información de los discos, la capacidad de las unidades, la latencia de acceso, los sistemas de archivos, etcétera. Valida los comandos SCSI, la funcionalidad de conmutación por error de disco y la configuración simétrica o asimétrica del almacenamiento.

Configuración del sistema. Valida la configuración de Active Directory, los controladores que están firmados, la configuración del volcado de memoria, las características y los servicios necesarios del sistema operativo, la arquitectura compatible del procesador y los niveles de actualizaciones de software de Windows y de Service Pack.

Los resultados de estas comprobaciones de validación proporcionan la información necesaria para ajustar una configuración de clúster, realizar un seguimiento de la configuración e identificar posibles problemas de configuración de los clústeres antes de que ocasionen una interrupción de la actividad. Puede guardar un informe de los resultados de las comprobaciones como documento HTML para consultarlo posteriormente.

Debe ejecutar estas comprobaciones antes y después de realizar los cambios en la configuración WSFC, antes de instalar SQL Server, como parte de cualquier proceso de recuperación ante desastres. Los servicios de soporte técnico al cliente de Microsoft (CSS) requieren un informe de validación del clúster como condición para que Microsoft dé soporte técnico a una determinada configuración de clústeres WSFC.

Para obtener más información, vea Guía paso a paso de clústeres de conmutación por error: validación de hardware para un clúster de conmutación por error (http://technet.microsoft.com/es-es/library/cc732035(WS.10).aspx).

Nota: si la configuración del clúster tiene almacenamiento asimétrico, como en el caso de las soluciones de almacenamiento de geo clústeres basada en hardware, o como puede ser el caso con los grupos de disponibilidad AlwaysOn, es posible que tenga que aplicar varias revisiones para evitar que el Asistente para la validación de clúster no pueda realizar los pasos de la validación del almacenamiento.

Para obtener más información, vea Requisitos previos, restricciones y recomendaciones para Grupos de disponibilidad AlwaysOn (http://msdn.microsoft.com/es-es/library/ff878487(SQL.110).aspx#SystemReqsForAOAG).


http://msdn.microsoft.com/en-us/library/ff878487(SQL.110).aspx#SystemReqsForAOAG

http://msdn.microsoft.com/en-us/library/ff878487(SQL.110).aspx#SystemReqsForAOAG

http://technet.microsoft.com/en-us/library/cc732035(WS.10).aspx


Configuración de los votos y modos de cuórum WSFCWSFC usa un método basado en cuórum para supervisar el estado general del clúster y maximizar la tolerancia a errores en los nodos. Entender los modos de cuórum WSFC y la configuración de las votaciones en los nodos es muy importante para el diseño, el funcionamiento y la solución de problemas de una solución de recuperación de desastres AlwaysOn de alta disponibilidad.

Detección del estado de clúster por cuórumCada nodo de un clúster WSFC participa en la comunicación periódica de latido para compartir el estado de mantenimiento del nodo con los demás nodos. Los nodos que no responden se consideran que se encuentran en estado de error.

Un conjunto de nodos de quórum es una mayoría de los nodos con derecho a voto y testigos en el clúster WSFC. Un voto de cuórum periódico determina el estado general de un clúster WSFC. La presencia de un cuórum significa que el estado del clúster es suficientemente correcto y puede proporcionar tolerancia a errores en los nodos.

La ausencia de un cuórum indica que el clúster no es correcto. El estado general del clúster WSFC debe mantenerse a fin de garantizar que los nodos secundarios sanos correctos disponibles para que los nodos primarios puedan conmutar por error. Si el voto de cuórum da error, todo el clúster WSFC se pondrá sin conexión como medida preventiva. También ocasiona que todas las instancias de SQL Server registradas con el clúster se detengan.

Nota: si un clúster WSFC se pone sin conexión debido a un error del cuórum, se requiere una intervención manual para volver a ponerlo en conexión. Para obtener más información, vea la sección Recuperación ante desastres WSFC mediante cuórum forzado más adelante en este documento.

Modos de cuórumUn modo de cuórum se configura en el clúster WSFC para especificar la metodología que se usa para los votos de cuórum. La utilidad Administrador de clústeres de conmutación por error recomienda un modo de cuórum basándose en el número de nodos del clúster.

Uno de los siguientes modos de cuórum determina qué constituye un cuórum de votos:

Mayoría de nodos. Más de la mitad de los nodos que votan en el clúster deben votar afirmativamente para que el clúster sea correcto.

Nodo y mayoría de recurso compartido de archivos. Similar al modo de cuórum Mayoría de nodos, excepto en que también se configura como testigo de la votación un recurso compartido de archivos remoto y la conectividad de cualquier nodo con ese recurso compartido se cuenta asimismo como voto afirmativo. Más de la mitad de los votos posibles deben ser afirmativos para que el clúster sea correcto.

Como práctica recomendada, el recurso compartido de archivos testigo no debe residir en ningún nodo del clúster y debe ser visible para todos los nodos del clúster.

Nodo y mayoría de disco. Similar al modo de cuórum Mayoría de nodos, excepto en que también se designa como testigo de la votación un recurso de clúster de disco compartido y la conectividad de cualquier nodo con ese disco compartido también se considera voto afirmativo. Más de la mitad de los votos posibles deben ser afirmativos para que el clúster sea correcto.


Solo disco. Un recurso de clúster de disco compartido se designa como testigo y la conectividad de cualquier nodo a ese disco compartido se considera voto afirmativo.

Para obtener más información, 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 (http://technet.microsoft.com/es-es/library/cc770620(v=WS.10).aspx).

Nota: a menos que cada nodo del clúster se configure para utilizar el mismo disco testigo de cuórum del almacenamiento compartido, normalmente debe usar el modo de cuórum Mayoría de nodos si tiene un número impar de nodos que votan o el modo de cuórum Mayoría de recurso compartido de archivos y nodo cuando tiene un número par de nodos que votan.

Nodos que votan y nodos que no votanDe forma predeterminada, cada nodo del clúster WSFC se incluye como miembro del cuórum del clúster; cada nodo, testigo del recurso compartido de archivos y testigo de disco tiene un único voto para determinar el estado general del clúster. En la explicación del cuórum hasta este punto del documento se ha calificado cuidadosamente el conjunto de nodos de clúster WSFC que votan sobre el estado del clúster como nodos que votan. En algunas circunstancias, puede no ser conveniente que cada nodo tenga un voto.

Cada nodo de un clúster WSFC intenta continuamente establecer un cuórum. Ningún nodo individual en el clúster puede determinar definitivamente que el clúster como conjunto sea correcto o incorrecto. En un momento dado, desde la perspectiva de cada nodo, puede parecer que alguno de los otros nodos están sin conexión, en el proceso de conmutar por error o que no responden debido a un error de comunicación de red. Una función clave del voto de cuórum es determinar si el estado aparente de cada uno de los nodos del clúster WSFC es de hecho ese estado real de los nodos.

Para todos los modelos de cuórum excepto Solo disco, la eficacia de un voto de cuórum depende de que las comunicaciones entre todos los nodos que votan del clúster sean confiables. Debe confiar en el voto de cuórum cuando todos los nodos están en la misma subred física.

Sin embargo, si un nodo de otra subred se considera que no responde en un voto de cuórum, pero realmente está en conexión y es correcta, es más probable que se deba a un error de comunicaciones de red entre las subredes. Según la topología de clúster, el modo de cuórum y la configuración de directivas de migración tras error, ese error de comunicaciones de red puede crear en efecto más de un conjunto (o subconjunto) de nodos que votan.

Si más de un subconjunto de nodos que votan puede establecer un cuórum por sí solo, esto se conoce como escenario de división de cerebro. En este escenario, los nodos de los cuórums independientes pueden comportarse de forma diferente y estar en conflicto entre sí.

Nota: el escenario de división de cerebro solo es posible si un administrador del sistema realiza manualmente una operación forzada de cuórum o, en circunstancias muy poco habituales, una conmutación por error manual forzada; subdividiendo explícitamente el conjunto de nodos de cuórum. Para obtener más información, vea la sección Recuperación ante desastres WSFC mediante cuórum forzado más adelante en este documento.

Para simplificar la configuración del cuórum y aumentar el tiempo de actividad, puede ser aconsejable ajustar el valor de NodeWeight (el valor 0 o 1) de cada nodo para que el voto del nodo no se cuente en el cuórum.




Ajustes recomendados para la votación de cuórumPara determinar la configuración de los votos de cuórum recomendada para el clúster, aplique estas instrucciones, por orden:

1. Ningún voto de forma predeterminada. Suponga que cada nodo no debe votar sin una justificación explícita.

2. Incluya todos los nodos primarios. Cada nodo que hospeda una réplica principal del grupo de disponibilidad AlwaysOn o es el propietario preferido de la instancia de clúster de conmutación por error AlwaysOn debe tener un voto.

3. Incluya los posibles propietarios de la conmutación automática por error. Cada uno de los nodos que puede hospedar una réplica principal o FCI, como resultado de una conmutación automática por error, debe tener un voto.

4. Excluye los nodos secundarios del sitio. En general, no proporcione votos a los nodos que residen en un sitio secundario de recuperación de desastres. No desea que los nodos del sitio secundario contribuyan a la decisión de poner el clúster fuera de conexión cuando no hay ningún problema con el sitio principal.

5. Número impar de votos. Si es necesario, agregue un recurso compartido de archivos testigo, un nodo testigo (con o sin una instancia de SQL Server) o un disco testigo al clúster y ajuste el modo de cuórum para evitar posibles empates en el voto de cuórum.

6. Vuelva a valorar las asignaciones de votos después de la conmutación por error. No es conveniente realizar la conmutación por error en una configuración de clúster que no admita un cuórum correcto.

Para obtener más información sobre cómo ajustar los votos de los nodos, vea Configurar los valores de NodeWeight de cuórum de clúster (http://msdn.microsoft.com/es-es/library/hh270281(SQL.110).aspx).

No puede ajustar el voto de un testigo de recurso compartido de archivos. En su lugar, debe seleccionar un modo de cuórum diferente para incluir o excluir su voto.

Nota: SQL Server expone varias vistas de administración dinámica (DMV) del sistema que pueden ayudarle a administrar la configuración de clúster WSFC relacionada y la votación del cuórum de los nodos.

Para obtener más información, vea Supervisar grupos de disponibilidad (http://msdn.microsoft.com/es-es/library/ff878305(SQL.110).aspx).


http://msdn.microsoft.com/en-us/library/ff878305(SQL.110).aspx

http://msdn.microsoft.com/en-us/library/hh270281(SQL.110).aspx


Recuperación ante desastres WSFC mediante cuórum forzadoEl error de cuórum se suele producir por un desastre sistémico o un error de comunicaciones persistente que incluye varios nodos del clúster WSFC. Recuerde que el error de cuórum provoca que todos los servicios de clúster, instancias de SQL Server y grupos de disponibilidad del clúster WSFC se establezcan como sin conexión porque el clúster no puede garantizar la tolerancia a errores en los nodos. Un error de cuórum significa que los nodos en buen estado que votan en el clúster WSFC ya no cumplen el modelo de cuórum. Puede que se haya producido un error en algunos nodos y puede que algunos simplemente hayan cerrado el servicio del clúster WSFC y de lo contrario estar en buen estado, excepto por la pérdida de la capacidad de comunicarse con un quórum.

Para volver a poner en línea el clúster WSFC, debe corregir la causa del error del cuórum en al menos un nodo con la configuración existente. En una situación de desastre, es posible que necesite reconfigurar o identificar el hardware alternativo para usarlo. Puede que también desee reconfigurar los nodos restantes del clúster WSFC para reflejar la topología de clústeres superviviente.

Puede usar el procedimiento de cuórum forzado en un nodo del clúster WSFC para invalidar los controles de seguridad que pusieron el clúster fuera de conexión. Esto indica al clúster de forma eficaz que suspenda las comprobaciones de votación de quórum y le permite poner de nuevo en línea los recursos del clúster WSFC y SQL Server en cualquiera de los nodos del clúster.

Este tipo de proceso de recuperación de desastres debe incluir los siguientes pasos:

1) Determinar el ámbito del error. Identifique los grupos de disponibilidad o las instancias de SQL Server que no responden, los nodos de clúster que están en línea y disponibles para usarse después de los desastres y, después, examine los registros de eventos de Windows y los registros del sistema de SQL Server. En la práctica, debe mantener los datos de incidentes y los registros del sistema para su análisis posterior.

2) Iniciar el clúster WSFC mediante cuórum forzado en un único nodo. En un nodo que esté en un estado correcto, fuerce manualmente el clúster para ponerlo en línea mediante el procedimiento de cuórum forzado. Para minimizar la posible pérdida de datos, seleccione un nodo que sea el último hospedaje de una réplica principal del grupo de disponibilidad.

Para obtener más información, vea Forzar el inicio de un clúster WSFC sin un cuórum (http://msdn.microsoft.com/es-es/library/hh270275(v=SQL.110).aspx).

Nota: si usa la configuración de cuórum forzado, las comprobaciones del cuórum se bloquean en todo el clúster hasta que el clúster WSFC logra una mayoría de votos y, de forma automática, cambia a un modo de funcionamiento normal de cuórum.

3) Iniciar el servicio del clúster WSFC normalmente en cada nodo en buen estado, de uno en uno. No tiene que especificar la opción de quórum forzado cuando inicia el servicio de clúster de los demás nodos.

Mientras el servicio del clúster WSFC en cada nodo vuelve a estar en línea, negocia con los otros nodos en buen estado para sincronizar el nuevo estado de configuración del clúster. Recuerde hacer esto en un nodo cada vez para evitar posibles condiciones de carrera al resolver el último estado conocido del clúster.

Nota: asegúrese de que cada nodo que inicia puede comunicarse con los demás nodos que se han puesto en línea recientemente o corre el riesgo de crear más de un conjunto de nodos de cuórum; esto es un escenario de división de cerebro. Si sus hallazgos del paso 1 son precisos, esto no debe suceder.


http://msdn.microsoft.com/en-us/library/hh270275(v=SQL.110).aspx

4) Aplicar una nueva configuración al modo de cuórum y voto de nodo. Si reinició correctamente todos los nodos del clúster con el procedimiento de cuórum forzado y corrigió la causa del error de cuórum, no es necesario realizar cambios en el modo de cuórum original y la configuración de voto de los nodos.

De lo contrario, debe evaluar el nodo de clúster recién recuperado y la disponibilidad de la topología de réplica, así como cambiar el modo de cuórum y las asignaciones de votos para cada nodo según corresponda. Establezca el servicio de clúster WSFC en los nodos no recuperados sin conexión o establezca sus votos de nodo en cero.

Nota: en este momento pueden aparecer los nodos y las instancias de SQL Server del clúster para restaurarlos de nuevo a una operación normal. Sin embargo, puede que aún no exista un cuórum en buen estado. Mediante el Administrador de clústeres de conmutación por error, el panel de AlwaysOn de SQL Server Management Studio o con las vistas de administración dinámica adecuadas, compruebe que se ha restaurado un cuórum correcto.

5) Recuperar réplicas de base de datos del grupo de disponibilidad según sea necesario. Algunas bases de datos pueden recuperarse y volver a ponerse en línea por sí mismas como parte del proceso normal de inicio de SQL Server. La recuperación de otras bases de datos puede requerir pasos manuales adicionales.

Puede minimizar la posible pérdida de datos y el tiempo de recuperación para las réplicas del grupo de disponibilidad poniéndolas en línea en esta secuencia, si es posible: réplica principal, réplicas secundarias sincrónicas, réplicas secundarias asincrónicas.

6) Reparar o reemplazar componentes con errores y volver a validar el clúster. Ahora que se ha recuperado del error de cuórum y el desastre inicial, debe reparar o reemplazar los nodos erróneos y ajustar en consecuencia las configuraciones del clúster WSFC y AlwaysOn relacionadas. Esto puede conllevar quitar las réplicas del grupo de disponibilidad, desalojar los nodos de clúster o quitar y volver a instalar el software en un nodo.

Nota: debe reparar o quitar todas las réplicas de disponibilidad con errores. SQL Server 2012 no trunca el registro de transacciones más allá del punto conocido más lejano de la última réplica de disponibilidad. Si una réplica con errores no se repara o se quita del grupo de disponibilidad, los registros de transacciones crecerán y se correrá el riesgo de quedarse sin espacio para los registros de transacciones en las otras réplicas.

7) Repetir el paso 4 según sea necesario. El objetivo es volver a establecer el nivel adecuado de tolerancia a errores y la alta disponibilidad para las operaciones correctas.

8) Análisis de la conducta de RPO/RTO. Debe analizar los registros del sistema de SQL Server, las marcas de tiempo de la base de datos y el registro de eventos de Windows para determinar la causa principal del error, así como para documentar las experiencias reales del punto de recuperación y del tiempo de recuperación.


Protección de instancias de SQL ServerEl nivel de protección siguiente en una solución AlwaysOn es la propia plataforma de datos; estas son las funciones y las características de Microsoft SQL Server 2012 y su integración con los componentes de infraestructura de Windows Server.

Mejoras de la disponibilidad: instancias de SQL ServerEstas son las nuevas características de las instancias de SQL Server 2012 que mejoran la disponibilidad tanto de las instancias de clúster de conmutación por error AlwaysOn como de las instancias independientes que hospedan los grupos de disponibilidad AlwaysOn.

Estas mejoras se han producido en la administración y la solución de problemas en escenarios de conmutación por error:

Directiva de conmutación por error flexible. El resultado del nuevo procedimiento almacenado del sistema utilizado para facilitar la detección de errores, sp_server_diagnostics, usa la propiedad FailureConditionLevel para comunicar la gravedad de un error que afecta a la instancia de SQL Server. Una directiva de conmutación por error WSFC rige la forma en que este valor afecta a la instancia de SQL Server, que abarca la tolerancia relativa de errores hasta estar pendiente de cualquier error del componente interno de SQL Server.

Puede configurar la conmutación por error para que se desencadene al producirse alguno de los siguientes niveles de errores: servidor inactivo, el servidor no responde, error crítico, error moderado o cualquier error pertinente. La propiedad FailureConditionLevel se puede utilizar para las directivas de conmutación por error de grupo de disponibilidad o FCI.

Antes de SQL Server 2012, las condiciones de error que provocaban la conmutación por error no eran específicas; cualquier error del servicio ocasionaba la conmutación por error.

Para obtener más información, vea Directiva de conmutación por error para instancias de clústeres de conmutación por error (http://msdn.microsoft.com/es-es/library/ff878664(SQL.110).aspx).

Registro e instrumental mejorados. Hay varias vistas de configuración del sistema específicas de AlwaysOn, vistas de administración dinámica, contadores de rendimiento y una sesión de estado de evento extendido que capturan y vuelcan la información necesaria para solucionar problemas, optimizar y supervisar la implementación AlwaysOn. Muchas se exponen a través de nuevas facetas y directivas de Administración de directivas de SQL Server.

Para obtener más información, vea Funciones y vistas de administración dinámica de grupos de disponibilidad AlwaysOn (http://msdn.microsoft.com/es-es/library/ff877943(SQL.110).aspx) y sys.dm_os_cluster_nodes (http://msdn.microsoft.com/es-es/library/ms187341(SQL.110).aspx).

Compatibilidad con recursos compartido de archivos SMB. Puede colocar los archivos de base de datos en un recurso compartido de archivos remoto de Windows Server 2008 o posterior tanto para instancias de clúster independientes como de conmutación por error, con lo que ya no es necesaria una letra de unidad independiente para cada FCI. Esta es una buena opción para la consolidación del almacenamiento o para hospedar el almacenamiento de archivos de base de datos en un servidor físico para un sistema operativo invitado en un equipo virtual. Con la configuración correcta, el rendimiento de E/S casi puede aproximarse al del almacenamiento asociado directo.

Para obtener más información, vea Bases de datos SQL en recursos compartidos de archivos: es el momento de reconsiderar el escenario (http://blogs.msdn.com/b/sqlserverstorageengine/archive/2011/10/18/sql-databases-on-file-shares-it-s-time-to-reconsider-the-scenario.aspx).


http://blogs.msdn.com/b/sqlserverstorageengine/archive/2011/10/18/sql-databases-on-file-shares-it-s-time-to-reconsider-the-scenario.aspx

http://blogs.msdn.com/b/sqlserverstorageengine/archive/2011/10/18/sql-databases-on-file-shares-it-s-time-to-reconsider-the-scenario.aspx






Nota: en un clúster WSFC, no puede agregar una dependencia de recursos compartidos de archivos SMB al grupo de recursos de SQL Server; debe tomar medidas adicionales para garantizar la disponibilidad del recurso compartido de archivos. Si el recurso compartido de archivos no está disponible, SQL Server inicia una excepción de E/S y se pone sin conexión.

Interoperabilidad WSFC con DNS. El nombre de red virtual (VNN) de una FCI o un agente de escucha del grupo de disponibilidad se registra con DNS solo durante la creación de la VNN o durante los cambios de configuración. Todas las direcciones IP virtuales, independientemente del estado en línea o sin conexión, se registran con DNS con el mismo nombre de red virtual. Las llamadas del cliente para resolver el nombre de red virtual en DNS devuelven todas las direcciones IP registradas en una secuencia de operación por turnos diferente.

Instancias de clúster de conmutación por error de AlwaysOnEl propósito principal de una instancia de clúster de conmutación por error (FCI) AlwaysOn de SQL Server es mejorar la disponibilidad de una instancia de SQL Server hospedada en el hardware de almacenamiento y del servidor local dentro de un único centro de datos.

Una FCI es una instancia lógica de SQL Server que se instala a través de los nodos en un clúster de Clústeres de conmutación por error de Windows Server (WSFC), pero solo está activa en un nodo al mismo tiempo. Las aplicaciones cliente se conectan a un nombre de red virtual y una dirección IP virtual que son propiedad del nodo de clúster activo.

Cada nodo instalado tiene un conjunto de archivos binarios de SQL Server y una configuración idénticos. El servicio de clúster WSFC también replica los cambios pertinentes de las entradas de la instancia activa en el Registro de Windows para cada nodo instalado. Cada nodo en que la FCI se instala se designa como un posible propietario de la instancia y sus recursos, dentro de una secuencia preferida de conmutación por error.

Los archivos de base de datos se almacenan en los volúmenes de almacenamiento, se registran como un recurso con el clúster WSFC y son propiedad del nodo que hospeda actualmente la FCI.

Para obtener más información, vea Instancias de clúster de conmutación por error AlwaysOn (http://msdn.microsoft.com/es-es/library/ms189134(SQL.110).aspx).

Procesos de conmutación por error FCISi un recurso de clúster dependiente da error, una instancia de clúster de conmutación por error AlwaysOn interactúa con el servicio de clúster WSFC mediante este proceso de alto nivel para realizar una conmutación por error:

1) Se indica un reinicio. Una comprobación periódica de la configuración de la directiva de conmutación por error WSFC o SQL Server indica que el estado es erróneo. De forma predeterminada, se intenta reiniciar el servicio antes de que se inicie la conmutación por error a otro nodo. Un tiempo de espera en el intento de reinicio indica un error del recurso.

2) Se indica una conmutación por error. Una comprobación de la directiva de conmutación por error indica que es necesario realizar una conmutación por error del nodo.

3) El servicio SQL Server se detiene. Si está ejecutándose, se intenta realizar un cierre del servicio SQL Server de forma ordenada.

4) El recurso de clúster WSFC se transfiere. La propiedad del grupo de recursos de clúster de SQL Server y sus recursos de almacenamiento compartido y red dependientes se transfieren al siguiente propietario del nodo preferido de la FCI.



5) SQL Server se inicia en el nuevo nodo. La instancia de SQL Server realiza sus procedimientos de inicio normales. Si no se pone en línea dentro de un período de tiempo de espera pendiente, el servicio de clúster coloca el recurso en este nuevo nodo en un estado de error.

6) Las bases de datos de usuario se recuperan en el nuevo nodo. Cada base de datos de usuario se coloca en modo de recuperación mientras se aplican las operaciones de puesta al día del registro de transacciones y las transacciones no confirmadas se revierten.

Mejoras de FCILas versiones anteriores de SQL Server proporcionaban una opción de instalación de FCI; no obstante, varias mejoras en las características de SQL Server 2012 mejoran la solidez y la utilidad de la disponibilidad:

Agrupación en clústeres de varias subredes. SQL Server 2012 admite nodos de clúster WSFC que residen en más de una subred. Una instancia de SQL Server determinada que reside en un nodo de clúster WSFC puede iniciarse si cualquier interfaz de red está disponible; esto se denomina dependencia de recurso de clúster "OR".

Las versiones anteriores de SQL Server requerían que todas las interfaces de red fueran funcionales para que el servicio SQL Server se iniciara o conmutara por error, y que todas existieran en la misma subred o VLAN.

Nota: la replicación en el nivel de almacenamiento entre los nodos de clúster no se habilita de forma implícita con la agrupación en clústeres de varias subredes. La solución FCI de varias subredes debe sacar provecho de una solución basada en SAN de terceros para replicar los datos y coordinar la conmutación por error del almacenamiento entre los nodos del clúster.

Para obtener más información, vea AlwaysOn de SQL Server 2012: instancia de clúster de conmutación por error de varios sitios (http://sqlcat.com/sqlcat/b/whitepapers/archive/2011/12/22/sql-server-2012-alwayson_3a00_-multisite-failover-cluster-instance.aspx).

Detección eficaz de errores. El servicio de clúster WSFC mantiene una conexión administrativa dedicada a cada FCI de SQL Server 2012 en el nodo. En esta conexión, una llamada periódica a un procedimiento almacenado especial del sistema, sp_server_diagnostics, devuelve una matriz completa de información de diagnóstico del estado del sistema.

Antes de SQL Server 2012, el mecanismo principal de detección del estado de una FCI se implementaba como un simple proceso unidireccional de sondeo. En este proceso, el servicio de clúster WSFC creaba periódicamente una nueva conexión de cliente SQL a la instancia, consultaba el nombre del servidor y después lo desconectaba. Si no se podía conectar o se agotaba el tiempo de espera de una consulta por alguna razón, se desencadenaba una conmutación por error con la información de diagnóstico disponible, que era muy poca.

Para obtener más información, vea sql_server_diagnostics (http://msdn.microsoft.com/es-es/library/ff878233(SQL.110).aspx).

Ahora hay mayor compatibilidad con escenarios de almacenamiento de FCI:

Una mejor compatibilidad con puntos de montaje. El programa de instalación de SQL Server reconoce ahora la configuración de los puntos de montaje de disco del clúster. Los discos de clúster



http://sqlcat.com/sqlcat/b/whitepapers/archive/2011/12/22/sql-server-2012-alwayson_3a00_-multisite-failover-cluster-instance.aspx

http://sqlcat.com/sqlcat/b/whitepapers/archive/2011/12/22/sql-server-2012-alwayson_3a00_-multisite-failover-cluster-instance.aspx

especificados y todos los discos montados en él se agregan automáticamente a la dependencia de los recursos de SQL Server durante la instalación.

tempdb en almacenamiento local. FCI admite ahora la ubicación de tempdb en almacenamiento no compartido local, por ejemplo, en una unidad sólida local, con lo que es posible que se descargue una cantidad significativa de operaciones de E/S de una SAN compartida.

Antes de SQL Server 2012, las FCI requerían que tempdb se encontrara en un volumen de almacenamiento compartido simétrico que conmutaba por error con otras bases de datos del sistema.

Nota: la ubicación de tempdb se almacena en la base de datos maestra, que se mueve entre los nodos durante la conmutación por error. Debe estar en una ruta de acceso de archivos simétrica válida (unidad, carpetas y permisos) en todos los posibles propietarios de nodos o bien el servicio SQL Server no se iniciará en algunos nodos.


Disponibilidad de bases de datosLas capacidades de alta disponibilidad que proporcionan los componentes de infraestructura y de nivel de instancia de SQL Server colaboran para proteger implícitamente las bases de datos hospedadas. Una solución AlwaysOn ofrece un conjunto adicional de opciones para proteger explícitamente los datos de la base de datos y aplicaciones de capa de datos.

Grupos de disponibilidad AlwaysOnUn grupo de disponibilidad es un conjunto de bases de datos de usuario que realizarán la conmutación por error conjuntamente desde una instancia de SQL Server a otra en el mismo clúster WSFC. Las aplicaciones cliente pueden conectarse a las bases de datos del grupo de disponibilidad a través de un nombre de red virtual WSFC, conocido como agente de escucha del grupo de disponibilidad, que resume las instancias de SQL Server subyacentes.

Los grupos de disponibilidad AlwaysOn se basan en los clústeres de conmutación por error de Windows Server para la supervisión del estado, la coordinación de la conmutación por error y la conectividad del servidor. Debe habilitar la compatibilidad de AlwaysOn en una instancia de SQL Server que resida en un nodo de clúster WSFC. Sin embargo, esa instancia no tiene que ser una FCI y no requiere el uso de almacenamiento compartido simétrico.

Para obtener más información, vea Información general de los grupos de disponibilidad AlwaysOn (http://msdn.microsoft.com/es-es/library/ff877884(SQL.110).aspx).

Roles y réplicas de disponibilidadCada instancia de SQL Server en el grupo de disponibilidad hospeda una réplica de disponibilidad que contiene una copia de las bases de datos de usuario en el grupo de disponibilidad. Una instancia de SQL Server solo puede hospedar una réplica de disponibilidad de un determinado grupo de disponibilidad, pero varios grupos de disponibilidad pueden residir en la misma instancia. La instancia de SQL Server debe tener volúmenes de almacenamiento dedicados (no compartidos).

Una de las réplicas de disponibilidad ejerce el rol de réplica principal. Se designa como copia maestra de las bases de datos del grupo de disponibilidad y se habilita para las operaciones de lectura/escritura.

Un grupo de disponibilidad puede contener entre una y cuatro réplicas de disponibilidad de solo lectura adicionales que cada una actúa de modo independiente con el rol de réplica secundaria.

Sincronización de las réplicas de disponibilidadEl contenido de cada base de datos de un grupo de disponibilidad se sincroniza desde la réplica principal a cada una de las réplicas secundarias a través de un mecanismo de movimiento de datos basado en registro de SQL Server. Por esta razón, todas las bases de datos del grupo de disponibilidad deben establecerse en el modelo de recuperación completa.

Las réplicas secundarias se inicializan con una copia de seguridad y restauración completa de las bases de datos y los registros de transacciones de la réplica principal. Mientras las nuevas transacciones se confirman en la réplica principal, la parte correspondiente del registro de transacciones se almacena en caché, se pone en la cola y, después, se envía a través de la red a un extremo de creación de reflejo de la base de datos en cada uno de los nodos de la réplica secundaria.

De esta manera, las nuevas entradas del registro de transacciones de la réplica principal se anexan en cada uno de los registros de transacciones de la réplica secundaria. Cada réplica secundaria comunica periódicamente un número de secuencia de registro (LSN) de nuevo a la réplica principal para indicar



una marca de hasta qué punto su registro de transacciones se ha reforzado y se ha vaciado en el disco remoto.

Nota: todas las réplicas de disponibilidad tienen su propio conjunto de subprocesos de puesta al día del registro de transacciones independientes que no forma parte del proceso de sincronización de la réplica de disponibilidad. Puede percibir retrasos en el proceso de puesta al día del registro en las réplicas secundarias como latencia de datos.

Además de tener un rol principal o secundario, todas las réplicas de disponibilidad también tienen un modo de disponibilidad, que dirige la coordinación del refuerzo de los registros de transacciones durante una instrucción COMMIT TRAN:

Modo de confirmación sincrónica. La réplica principal confirma una transacción determinada después de que todas las réplicas secundarias de confirmación sincrónica reconozcan que han finalizado el refuerzo de sus respectivos registros después del LSN de esa transacción. Un grupo de disponibilidad puede tener hasta dos réplicas secundarias de confirmación sincrónica.

El modo de confirmación sincrónica incluye la latencia de las transacciones en las bases de datos de réplica principales, pero garantiza que no haya pérdida de datos en las réplicas secundarias para las transacciones confirmadas.

Modo de confirmación asincrónica. La réplica principal confirma las transacciones después de reforzar el registro de transacciones local, pero no espera el reconocimiento de que una réplica secundaria de confirmación asincrónica ha reforzado su registro de transacciones. Un grupo de disponibilidad puede tener hasta cuatro réplicas secundarias de confirmación asincrónica, pero no más de un total de cuatro réplicas secundarias de cualquier tipo.

El modo de confirmación asincrónica minimiza la latencia de las transacciones en las bases de datos de réplica principal pero permite que los registros de transacciones de réplica secundaria se retrasen, posibilitando la pérdida de datos.

Para obtener más información, vea Modos de disponibilidad (http://msdn.microsoft.com/es-es/library/ff877931(SQL.110).aspx).

El estado general del flujo de datos entre las réplicas de disponibilidad se indica mediante el estado de sincronización de cada réplica. Es probable que se pierdan datos si conmuta por error a una réplica secundaria con un estado de sincronización distinto de "Sincronizado" o "Sincronizando".

El flujo de sincronización de cada réplica secundaria tiene una propiedad tiempo de espera de sesión. Cuando una réplica secundaria configurada con el modo de confirmación sincrónica da error al caducar el tiempo de espera de sesión, se marca internamente como asincrónica, de forma temporal. Esto se hace para que el error de la réplica secundaria no influya en el refuerzo del registro de transacciones de la réplica principal. Cuando la réplica secundaria es correcta y se ha capturado una copia de seguridad con la réplica principal, revierte automáticamente a las operaciones normales de modo de confirmación sincrónica.

Conmutación por error del grupo de disponibilidadEl grupo de disponibilidad y un nombre de red virtual correspondiente se registran como recursos del clúster WSFC. Un grupo de disponibilidad conmuta por error en el nivel de una réplica de disponibilidad, en función del estado y de la directiva de conmutación por error de la réplica principal.

Una directiva de conmutación por error de grupo de disponibilidad utiliza la propiedad FailureConditionLevel para indicar el nivel de tolerancia de la gravedad para un error que afecta al



grupo de disponibilidad, junto con el procedimiento almacenado del sistema sp_server_diagnostics. Este mismo mecanismo se utiliza para las directivas de conmutación por error de FCI.

En el caso de una conmutación por error, en lugar de transferir la propiedad de los recursos físicos compartidos a otro nodo, WSFC se emplea para reconfigurar una réplica secundaria en otra instancia de SQL Server y asumir el rol de réplica principal. El recurso de nombre de red virtual del grupo de disponibilidad se transfiere después a esa instancia. Todas las conexiones de cliente a las réplicas de disponibilidad implicadas se restablecen.

Según el estado actual, el estado de sincronización y el modo de disponibilidad de las réplicas, cada réplica tiene un estado de preparación para la conmutación por error compuesto que indica la posible pérdida de datos. Esta información de estado de la réplica se puede ver en el Panel de AlwaysOn o en la vista del sistema sys.dm_hadr_availability_replica_states.

Todas las réplicas de disponibilidad también tienen configurado un modo de conmutación por error, que controla el comportamiento de la réplica cuando se indica la conmutación por error.

Conmutación automática por error (sin pérdida de datos). Esto posibilita el período de tiempo más rápido de conmutación por error de cualquier configuración AlwaysOn porque el registro de transacciones de réplica secundaria ya está reforzado y sincronizado. Las transacciones abiertas en la réplica principal se revierten y el rol de réplica principal se transfiere a una réplica secundaria sin la intervención del usuario.

Las réplicas principales y secundarias se deben establecer en el modo de conmutación automática por error y en el de disponibilidad de confirmación sincrónica. El estado de sincronización entre las réplicas debe ser "Sincronizado". Además, el clúster WSFC debe tener un cuórum correcto.

La conmutación automática por error no se admite si la réplica principal o secundaria reside en una FCI. Esto se impide para evitar una posible condición de carrera entre las conmutaciones por error de FCI y el grupo de disponibilidad.

Conmutación por error manual. Esto permite que el administrador evalúe el estado de la réplica principal y tome una decisión para realizar deliberadamente una conmutación por error a una réplica secundaria o no.

En función del modo de disponibilidad y del estado de sincronización, tiene estas opciones:

o Conmutación por error manual planeada (sin pérdida de datos). Solo puede realizar este tipo de conmutación por error si tanto la réplica principal como la secundaria son correctas y están en estado "Sincronizado". Esto es funcionalmente equivalente a una conmutación automática por error.

o Conmutación por error manual forzada (que permite la posible pérdida de datos). Es la única forma de conmutación por error posible si la réplica secundaria de destino está en modo de disponibilidad de confirmación asincrónica o si no se sincroniza con la réplica principal.

Advertencia: solo debe utilizar esta opción de conmutación por error en una situación de recuperación ante desastres. Si la réplica principal es correcta y está disponible, debe cambiar el modo de disponibilidad de las réplicas implicadas a confirmación sincrónica y luego realizar una conmutación por error manual planeada.


Para obtener más información, vea Realizar una conmutación por error manual forzada de un grupo de disponibilidad (http://msdn.microsoft.com/es-es/library/ff877957(SQL.110).aspx).

Debe realizar una conmutación por error manual si alguna de las condiciones siguientes se cumple en la réplica principal o en la réplica secundaria que desee conmutar por error:

El modo de conmutación por error se establece en manual. El modo de disponibilidad se establece en confirmación asincrónica. La réplica reside en una FCI.

Para obtener más información, vea Modos de conmutación por error (grupos de disponibilidad AlwaysOn) (http://msdn.microsoft.com/es-es/library/hh213151(SQL.110).aspx).

Nota: después de una conmutación por error, si la nueva réplica principal no está configurada en modo de confirmación sincrónica, las réplicas secundarias indicarán el estado de sincronización "Suspendido". Ningún dato fluirá a las réplicas secundarias hasta que la réplica principal se establezca en el modo de confirmación sincrónica.

Agente de escucha de grupo de disponibilidadUn agente de escucha de grupo de disponibilidad es un nombre de red virtual (VNN) WSFC que los clientes pueden utilizar para tener acceso a una base de datos del grupo de disponibilidad. La instancia de SQL Server posee el recurso de clúster VNN en el que la réplica principal reside.

El nombre de red virtual se registra con DNS solo durante la creación del agente de escucha de grupo de disponibilidad o durante los cambios de configuración. Todas las direcciones IP virtuales que se definen en el agente de escucha de grupo de disponibilidad se registran con DNS bajo el mismo nombre de red virtual.

Para utilizar el agente de escucha del grupo de disponibilidad, una solicitud de conexión cliente debe especificar el nombre de red virtual como servidor y un nombre de base de datos que esté en el grupo de disponibilidad. De forma predeterminada, esto debe producir una conexión a la instancia de SQL Server que hospede la réplica principal.

En tiempo de ejecución, el cliente utiliza la resolución DNS local para obtener una lista de direcciones IP y puertos TCP asignados al nombre de red virtual. El cliente entonces intenta conectarse a cada una de las direcciones IP, hasta que lo consigue o hasta que alcanza el tiempo de espera de conexión. El cliente intentará realizar estas conexiones en paralelo si el parámetro MultiSubnetFailover se establece en true, habilitando conmutaciones por error de cliente más rápidas.

En el caso de que se produzca una conmutación por error, las conexiones de cliente se restablecen en el servidor, la propiedad del agente de escucha de grupo de disponibilidad pasa con el rol de réplica principal a una nueva instancia de SQL Server y el extremo VNN se enlaza a los puertos TCP y a las direcciones IP virtuales de la nueva instancia.

Para obtener más información, vea Conectividad de cliente y conmutación por error de la aplicación (http://msdn.microsoft.com/es-es/library/hh213417(SQL.110).aspx).






Filtrado de las intenciones de las aplicacionesMientras se conecta a través del agente de escucha del grupo de disponibilidad, la aplicación puede especificar si su intención es leer y escribir datos o si va a realizar exclusivamente operaciones de solo lectura. Si no se especifica, la intención predeterminada de la aplicación para el cliente es leer y escribir.

Para el rol principal y el rol secundario de cada réplica de disponibilidad, puede especificar una propiedad de acceso de conexión que se usará como filtro de nivel de conexión en la intención de la aplicación del cliente. De forma predeterminada, cuando se combina un acceso de conexión con una intención no válida de una aplicación, la conexión se rechaza. SQL Server debe filtrar las solicitudes de conexión de cliente utilizando las reglas siguientes.

Mientras la réplica de disponibilidad esté en el rol principal y el acceso de conexión sea:

Permitir cualquier intención de aplicación. No filtrar ninguna conexión de cliente para la intención de la aplicación.

Permitir solo la intención de lectura/escritura explícita. Si el cliente especifica que la intención sea de solo lectura, rechazar la conexión.

Mientras la réplica de disponibilidad esté en el rol secundario y el acceso de conexión sea:

No hay conexiones permitidas. Rechazar todas las conexiones; la réplica solo se utiliza para la recuperación ante desastres.

Permitir cualquier intención de aplicación. No filtrar ninguna conexión de cliente para la intención de la aplicación.

Intención de la aplicación de solo lectura. Si el cliente no especifica que la intención sea de solo lectura, rechazar la conexión.

Para obtener más información, vea Configurar el acceso de la conexión en una réplica de disponibilidad (http://msdn.microsoft.com/es-es/library/hh213002(SQL.110).aspx).

Enrutamiento de la intención de la aplicación de solo lecturaUna proposición de valor clave de los grupos de disponibilidad AlwaysOn es la capacidad de aprovechar la infraestructura de hardware de modo de espera para fines distintos de la recuperación ante desastres. Al configurar una o varias de sus réplicas secundarias para el acceso de solo lectura, puede descargar cargas de trabajo significativas de sus réplicas principales.

Algunas de las cargas de trabajo que se pueden pasar fácilmente a una réplica secundaria de solo lectura son: el informe de errores, las copias de seguridad de la base de datos, las comprobaciones de coherencia de la base de datos, los análisis de fragmentación de índices, la extracción de canalización de datos, la compatibilidad operativa y las consultas ad hoc.

Para cada réplica de disponibilidad, si lo desea, puede configurar una lista de enrutamiento de solo lectura secuencial de los extremos de la instancia de SQL Server para aplicarla mientras esa réplica esté en el rol principal. Si está presente, esta lista se utiliza para redirigir las solicitudes de conexión de cliente que especifican que la intención de la aplicación es realizar operaciones de solo lectura a la primera réplica secundaria disponible en la lista que satisfaga los filtros de intención de la aplicación indicadas anteriormente.

Nota: la redirección del enrutamiento de solo lectura se realiza mediante el agente de escucha del grupo de disponibilidad, que se enlaza a la réplica principal. Si la réplica principal está sin conexión, la redirección del cliente no funcionará.

Para obtener más información, vea Configurar el enrutamiento de solo lectura en un grupo de disponibilidad (SQL Server) (http://msdn.microsoft.com/es-es/library/hh653924(SQL.110).aspx)





Mejoras de la disponibilidad: bases de datosSQL Server 2012 incluye varias mejoras de características que son específicas de las funciones y la configuración de base de datos.

Las mejoras siguientes reducen el tiempo de recuperación:

Tiempo de recuperación previsible. Puede establecer un intervalo de tiempo de recuperación de destino por cada base de datos, que se utiliza para controlar la programación de un comando CHECKPOINT en segundo plano. Este punto de comprobación indirecto sucede periódicamente, según el tiempo estimado necesario para recuperar el registro de transacciones en el caso de que se produzca un reinicio o una conmutación por error. Esto tiene el efecto de suavizar la E/S para que en cada punto de comprobación se dé en una proporción parecida y de aumentar la previsibilidad del tiempo de recuperación (RTO).

Antes de SQL Server 2012, los comandos CHECKPOINT en segundo plano se emitían en un intervalo fijo, con independencia del volumen o la carga de transacciones, lo que podía provocar que los tiempos de recuperación fueran impredecibles.

Para obtener más información, vea Puntos de control de la base de datos (http://msdn.microsoft.com/es-es/library/ms189573(SQL.110).aspx).

Estas mejoras atenúan los escenarios comunes que pueden provocar tiempo de inactividad planeado:

Operaciones de índice en línea para columnas LOB. Los índices que contienen columnas con varbinary(max), varchar(max), nvarchar(max) o tipos de datos XML ahora se pueden volver a generar o reorganizar en línea.

Modificación de esquema en línea para las nuevas columnas NOT NULL. Si una columna NOT NULL nueva se agrega con un valor predeterminado a una tabla de base de datos de SQL Server 2012, solo se requiere un bloqueo de esquema para actualizar los metadatos del sistema; ninguna fila tiene que rellenarse durante la instrucción ALTER TABLE.

SQL Server mantendrá físicamente el valor predeterminado de la columna solo en el caso de que una fila realmente se modifique o se vuelva a indizar. Las consultas devuelven el valor predeterminado de los metadatos, a menos que exista un valor de columna real.

Hay un ejemplo de mayor compatibilidad con escenarios de almacenamiento:

Reparación de página automática. Ciertos tipos de errores del subsistema de almacenamiento pueden dañar una página de datos, con lo que lo convierten en ilegible. Los grupos de disponibilidad AlwaysOn pueden detectar estos tipos de errores y recuperarlos automáticamente solicitando y aplicando de forma asincrónica una nueva copia de las páginas de datos afectadas de otra réplica de disponibilidad.

Antes de SQL Server 2012 existía una funcionalidad similar para la creación de reflejo de la base de datos, pero ahora se ha mejorado para admitir varias réplicas.

Para obtener más información, vea Reparación de página automática (http://msdn.microsoft.com/es-es/library/bb677167(SQL.110).aspx).


http://msdn.microsoft.com/en-us/library/bb677167(SQL.110).aspx


Recomendaciones para la conectividad de clienteSiga estas instrucciones para que las aplicaciones cliente puedan sacar partido de las tecnologías AlwaysOn de Microsoft SQL Server 2012:

Biblioteca cliente relacionada con AlwaysOn. Utilice una biblioteca cliente que admita la versión 7.4 del protocolo de flujo TDS o una versión más reciente. Esto debe proporcionar la funcionalidad que se desea en el cliente para las características AlwaysOn. Algunos ejemplos de bibliotecas de cliente son el Proveedor de datos para SQL Server de .NET Framework 4.02 y SQL Native Client 11.0.

Propiedad del proveedor de conexión: MultiSubnetFailover = True. Utilice esta palabra clave en sus cadenas de conexión para que las bibliotecas de cliente puedan intentar conectarse en paralelo a todas las direcciones IP registradas para el agente de escucha del grupo de disponibilidad o la FCI que tenga una dirección IP en varias subredes.

Propiedad del proveedor de conexión: ApplicationIntent = ReadOnly. Cuando sea posible, pase las cargas de trabajo de solo lectura de la réplica principal a las réplicas secundarias.

Tiempo de espera de las conexiones de clientes heredados. Las bibliotecas de base de datos cliente heredadas no implementan intentos de conexión paralelos, de modo que, cuando hay presentes varias direcciones IP, intentan conectarse a cada una secuencialmente, hasta que encuentran un tiempo de espera TCP o hasta que se consigue establecer una conexión.

Debe ajustar el tiempo de espera de la conexión en los clientes heredados para acomodar los posibles reintentos y tiempos de espera secuenciales cuando hay varias direcciones IP, en un valor que sea, al menos, de 15 segundos más 21 segundos para cada réplica secundaria.


ConclusiónEn estas notas del producto se ha establecido el contexto de referencia para reducir el tiempo de inactividad planeado y no planeado, maximizar la disponibilidad de las aplicaciones y permitir la protección de datos mediante soluciones de alta disponibilidad y recuperación ante desastres AlwaysOn de SQL Server 2012.

Muchos de los estímulos empresariales y de los problemas del planeamiento, la administración y la cuantificación de un entorno de bases de datos altamente disponible se pueden cuantificar y expresar como objetos de punto de recuperación (RPO) y objetivos de tiempo de recuperación (RTO).

AlwaysOn de SQL Server 2012 proporciona funciones en la infraestructura, las plataformas de datos y las base de datos que pueden ayudar a una organización a abordar escenarios comunes de alta disponibilidad y recuperación ante desastres, de manera que se pueden justificar apropiadamente mediante los objetivos RPO y RTO.

Para obtener más información:

http://www.microsoft.com/sqlserver/: Sitio web de SQL Server

http://technet.microsoft.com/es-es/sqlserver/: SQL Server TechCenter

http://msdn.microsoft.com/es-es/sqlserver/: SQL Server DevCenter

¿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.

◊ Versión 1.1, de 21 de febrero de 2012.


mailto:[email protected]?subject=Comentarios%20sobre%20notas%20del%20producto:%20%5BGu%EDa%20de%20soluciones%20AlwaysOn%20de%20Microsoft%20SQL%20Server%20para%20lograr%20alta%20disponibilidad%20y%20recuperaci%F3n%20ante%20desastres%5D

http://msdn.microsoft.com/es-es/sqlserver/

http://technet.microsoft.com/es-es/sqlserver/

http://www.microsoft.com/sqlserver/

Conceptos relativos a la alta disponibilidad y la...

Documents

Transcript of Conceptos relativos a la alta disponibilidad y la...