Asumiendo que necesita asegurarse de que su aplicación que se basa en SQL Server 2012 como su backend de base de datos esté disponible las 24 horas, incluso si falla una máquina del servidor.

Como desarrollador y no como DBA, me cuesta entender cuándo usar qué escenario para mi conmutación por error / alta disponibilidad:

• Dos (o más) servidores en un clúster de conmutación por error de Windows, SQL Server como una instancia en clúster
• Dos (o más) instancias de SQL Server que se mantienen actualizadas con la replicación transaccional
• Dos (o más) servidores SQL en un grupo de disponibilidad de SQL Server, configurados en un modo de confirmación sincrónica

¿Cuál de cada uno de esos escenarios funciona para qué tipo de carga de trabajo y qué tipo de falla / interrupción puede ser manejada por esos escenarios? ¿Son incluso comparables / intercambiables?

La forma en que siempre me gusta visualizar soluciones de alta disponibilidad es la siguiente:

Instancia de clúster de conmutación por error de SQL Server (FCI)

¿Qué es altamente disponible? Toda la instancia. Eso incluye todos los objetos de servidor (inicios de sesión, trabajos del Agente SQL Server, etc.). Esto también incluye bases de datos y sus entidades que contienen. Es una gran solución para instancias de SQL Server de alta disponibilidad, ya que ese será el nivel de contención con esta solución dada.

¿Qué pasa con los informes? Ninguno, NULL, inexistente. Una instancia de clúster de conmutación por error tiene un nodo activo que entrega el grupo de clúster que contiene la instancia, VNN, etc. y todos los demás nodos son pasivos, inactivos (en lo que respecta al grupo de clúster actual) y esperan una conmutación por error.

¿Qué sucede cuando hay una conmutación por error? El tiempo de inactividad para un FCI estará determinado por la cantidad de tiempo que el nodo pasivo tarda en tomar el recurso del clúster y poner la instancia de SQL Server en un estado de ejecución. Esto suele ser mínimo en el tiempo.

¿Alguna abstracción del cliente? Sí, esto se integrará de forma innata con el nombre de red virtual para la instancia del clúster de conmutación por error. Esto siempre apuntará al nodo activo que actualmente está entregando el recurso de clúster de SQL Server.

Grupos de disponibilidad AlwaysOn

¿Qué es altamente disponible? Un grupo de disponibilidad será la contención lógica de alta disponibilidad aquí, mientras que un grupo de disponibilidad consta de varias bases de datos y un nombre de red virtual (el oyente, un recurso de clúster opcional). Vale la pena señalar que los objetos del servidor, como los inicios de sesión y los trabajos del Agente SQL Server, no serán parte de la solución de alta disponibilidad, y se debe tener especial consideración para garantizar que se implementen correctamente con un grupo de disponibilidad. No es un requisito demasiado pesado, pero debe ser atendido.

¿Qué pasa con los informes? Esta es una gran solución para informar, aunque probablemente no usaría una réplica sincrónica como mi instancia de informes. Hay dos relaciones de confirmación, sincrónica y asincrónica. En mi opinión y por lo que he visto en la práctica, es que su réplica secundaria síncrona está allí esperando un desastre. Piense en ello como esa réplica que está lista para realizar una conmutación por error sin pérdida de datos en caso de un problema. Luego, hay réplicas asíncronas que pueden manejar esa carga de trabajo de informes. No está utilizando esta réplica como la solución mencionada anteriormente, sino más para cosas como los informes. Las cargas de trabajo de informes pueden apuntar a esta réplica (ya sea directa o indirectamente a través del enrutamiento de solo lectura a través del oyente).

¿Qué sucede cuando hay una conmutación por error? Para una réplica secundaria de confirmación síncrona que se combina con la conmutación por error automática, este será el cambio de estado de la función de réplica de SECONDARY_NORMAL a PRIMARY_NORMAL. Para que haya una conmutación por error automática, debe tener una réplica secundaria síncrona que esté actualmente sincronizada, y lo que se implementa es la Política de conmutación por error flexible para determinar cuándo, en realidad, debería ocurrir esta conmutación por error. Esa política es de hecho configurable.

¿Alguna abstracción del cliente? Sí, opcionalmente puede configurar un oyente de AlwaysOn Availability Group. Esto es básicamente solo un nombre de red virtual (puede verse a través de WSFC como un recurso de clúster en el grupo de clúster de AG) que apunta a la réplica principal actual. Esta es una parte clave para cambiar su carga de trabajo de informes, así como para configurar una lista de enrutamiento de solo lectura en cualquier servidor que desee redirigir el tráfico de ReadOnly (esto se configura a través de la cadena de conexión, con .NET Framework Provider para SQL Servidor, este será el parámetro Intención de aplicación , establecido en Solo lectura ). También deberá establecer una URL de enrutamiento de solo lectura para cada réplica que desee recibir esta carga de trabajo de informes mientras esté en la función de réplica secundaria.

Replicación transaccional

¿Qué es altamente disponible? Esto es discutible, pero no voy a decir nada . No veo la replicación como una solución de alta disponibilidad. Sí, las modificaciones de datos se envían a los suscriptores, pero estamos hablando a nivel de publicación / artículo. Esto va a ser un subconjunto de los datos (podría incluir todos los datos, pero eso no se aplicará. Es decir, crea una nueva tabla en la base de datos del editor, y eso no se enviará automáticamente a los suscriptores). En cuanto a HA, este es el fondo del barril y no lo agruparé allí con una solución de HA sólida como una roca.

¿Qué pasa con los informes? Una gran solución para informar sobre un subconjunto de datos, no hay duda al respecto. Si tiene una base de datos de 1 TB que es altamente transaccional y desea mantener esa carga de trabajo de informes fuera de la base de datos OLTP, la replicación transaccional es una excelente manera de enviar un subconjunto de datos a un suscriptor (o suscriptores) para la carga de trabajo de informes. ¿Qué sucede si de esos 1 TB de datos su carga de trabajo de informes es solo de unos 50 GB? Esta es una solución inteligente y relativamente configurable para satisfacer las necesidades de su negocio.

Resumen

Todo se reduce a un puñado de preguntas que deben ser respondidas (en parte por el negocio):

1. ¿Qué necesita estar altamente disponible ?
2. ¿Qué dicta el SLA para HA / DR?
3. ¿Qué tipo de informes se llevarán a cabo y qué latencias son aceptables?
4. ¿Qué necesitamos manejar con HA dispersa geográficamente ? (la replicación de almacenamiento es costosa, pero imprescindible con una FCI. Los AG no requieren almacenamiento compartido de instancias independientes, y podría usar un testigo de uso compartido de archivos para el quórum, lo que podría eliminar la necesidad de almacenamiento compartido)

dos (o más) servidores en un clúster de conmutación por error de Windows, SQL Server como una instancia en clúster

1. ¿Qué tipo de carga de trabajo? "Depende", pero en serio, esto es útil para una aplicación en línea donde necesita tener alta disponibilidad local en el centro de datos. Usted está protegido contra una falla de una máquina o de un sistema operativo. Los inicios de sesión, trabajos, nuevas bases de datos, mantenimiento, etc., se mantienen automáticamente sincronizados por el hecho de que es un clúster con dos nodos que son exactamente iguales y comparten el mismo almacenamiento, por lo que tienen las mismas bases de datos del sistema. Conmutación por error muy rápida, pero todavía hay un problema que parece un reinicio de SQL Server cuando se produce la conmutación por error.

2. Contras / preocupaciones : el único punto de falla es su almacenamiento y todos sus componentes. Los proveedores de SAN siempre dicen "Las SAN no fallan", pero hay muchas partes móviles en una red de área de almacenamiento y, como escribí en un blog aquí , pueden hacerlo . Además, está pagando por un servidor secundario que no puede hacer nada más que esperar y esperar. Ahora puede hacer Active / Active / Multi-Node y tener dos instancias activas que pueden conmutar por error en cualquier dirección y usar el segundo nodo.

3. Conmutación por error automática? El "más" automático. No se necesita testigo, es un grupo. Este es el trabajo de un clúster, para que sea lo más fluido posible. Ahora con cualquiera de estos, cuando ocurre una conmutación por error, la "sentirá", porque SQL tiene que iniciarse o las conexiones tienen que apuntar. Aquí, cuando sucede, básicamente se sentirá como un reinicio de SQL, las bases de datos vuelven a funcionar y ejecutan recovery / etc.

Si tengo un cliente que dice "Quiero estar completamente al día con todas las bases de datos, todos los inicios de sesión, etc." en un entorno de alta disponibilidad en mi centro de datos local porque tengo una tolerancia increíblemente baja para el tiempo de inactividad, consideraría las instancias de clúster de conmutación por error (aunque el La última opción que menciona es un fuerte competidor, salvo por tener que hacer algunos gastos generales de gestión). Probablemente haría una FCI local y una secundaria asíncrona AG para protegerme contra fallas del sitio o fallas de SAN.

dos (o más) instancias de SQL Server que se mantienen actualizadas con la replicación transaccional

1. ¿Qué tipo de carga de trabajo? Sinceramente, no iría aquí por muchos casos de necesidad de alta disponibilidad o recuperación ante desastres como primera opción. No en SQL 2012 seguro. Pero básicamente esto es bueno si tuviera que ir a un centro de datos que no estaba cerca, no podría usar un AG (tal vez un problema de dominio que le impida usar el clúster de Windows requerido para el AG), tal vez quisiera estar en el estándar de SQL Server que puede hacer replicación, pero no AG, pero aún así quería tener la capacidad de leer en el lado secundario y ser asíncrono.
2. Contras / preocupaciones: es la replicación Tiene gastos generales, puede desincronizarse, puede desarrollar problemas con el rendimiento en el lado de origen, etc.
3. Conmutación por error automática : no, debe administrarlo usted mismo. ¿A través de CNAME que apuntan a uno u otro, y teóricamente podrías escribir tu propio proceso para hacer esto, pero fuera de la caja? Tenga en cuenta aquí.

dos (o más) servidores SQL en un grupo de disponibilidad de SQL Server, configurados en un modo de confirmación sincrónico

Esto es lo que he estado ayudando a las personas a implementar cada vez más últimamente, aunque a veces todavía me voy a agrupar.

1. ¿Qué tipo de carga de trabajo? Esto es excelente cuando tengo un conjunto manejable de bases de datos para mantener sincronizadas, y los recursos y el tiempo para asegurarme de que los trabajos, inicios de sesión, nuevas bases de datos, etc. permanezcan sincronizados (aunque el equipo de SQL Skills ha incorporado un gran complemento para automatice algo de esto para que sea una opción aún más fuerte). Me gusta esto cuando quiero mantener las cosas completamente separadas. Estoy protegiendo contra problemas de hardware, problemas de sistema operativo, problemas de instalación de SQL, problemas de parches y problemas de SAN / almacenamiento. También obtengo el beneficio de la capacidad de tener un secundario (si quiero pagar una licencia empresarial) para ser un secundario activo del que pueda leer, hacer copias de seguridad, etc. Además, en el futuro, puedo agregar un tercero secundario que es asíncrono en un sitio remoto y tiene failover / DR.
2. Contras / preocupaciones Licencias, número máximo de réplicas, costos de licencia para aprovechar algunos de los mayores beneficios (secundaria activa), requiere empresa, requiere el doble de almacenamiento que la agrupación.
3. Conmutación por error automática : sí. Esto puede ocurrir con una configuración de testigo, y los desarrolladores de su aplicación pueden conectarse al oyente en lugar de a un nodo para que la conmutación por error ocurra con el punto del oyente y usted debería ser bueno allí. Entonces sí, puedes hacer eso aquí, y deberías, pero, por supuesto, debes probarlo bien.

Resumen

HA y DR son diferentes. Y estas tecnologías ayudan a proporcionar piezas de ambos. Alta disponibilidad significa (para mí) que puede recuperarse rápidamente si algo malo le sucede a una máquina, tiene un objetivo de punto de recuperación corto y un objetivo de tiempo de recuperación. Eso es agrupación y un AG sincrónico.

La recuperación ante desastres es "puede levantarse cuando tiene una falla incluso en su solución de alta disponibilidad. Para mí eso puede ser AG cuando va a otro centro de datos, duplicación o incluso replicación.

También es importante tener en cuenta lo que se comparte .

El clúster de conmutación por error utiliza dos o más nodos de servidor que comparten una matriz de discos. Si la matriz de discos se cae, pierde el servicio, independientemente de cuántos nodos de servidor haya. Si la sala de servidores donde se encuentra esa matriz de discos se incendia o se inunda, entonces pierde el servicio.

Los grupos de disponibilidad AlwaysOn y la creación de reflejo de la base de datos son una tecnología de agrupación de "nada compartido". La base de datos está presente en múltiples matrices de discos en múltiples servidores. Si tiene buenos enlaces de red, los múltiples servicios pueden estar en múltiples salas de servidores, protegiéndolo contra incendios e inundaciones.

Solo para completar, existe la opción de usar un espejo antiguo simple. Las ventajas aquí incluyen tener dos copias de la base de datos sin la complejidad de usar Grupos de disponibilidad, y sin necesidad de almacenamiento compartido para el Failover Clustering. La desventaja, aunque leve, es que la duplicación está en desuso.

Los tiempos de conmutación por error con la duplicación son del orden de 10 segundos, aunque el código de la aplicación debe ser capaz de volver a intentar cualquier transacción que ocurra en el momento de la conmutación por error.