La planificación e implementación de un plan de alta disponibilidad y recuperación ante desastres que cumpla con todos los acuerdos de nivel de servicio no es una tarea trivial y requiere una comprensión muy clara de las fortalezas y debilidades nativas de SQL Server. Al hacer coincidir los requisitos con una combinación de características, algunos de los detalles críticos pueden pasarse por alto, y en esta publicación analizaré algunas distorsiones comunes y malas suposiciones que pueden colarse en una solución, lo que en última instancia nos hace perder el objetivo. en nuestros objetivos de punto y tiempo de recuperación. Algunos de los ejemplos de distorsiones o autoengaños que detallo aquí se pueden generalizar en diferentes funciones y algunos son específicos de funciones.
"Probamos nuestro plan de recuperación ante desastres cuando lanzamos nuestro proyecto por primera vez y sabemos que funcionará"
He trabajado con clientes que de hecho acertaron con su enfoque de recuperación ante desastres, una vez. Pero una vez que todos se sintieron seguros de la eficacia de la solución, no se volvieron a realizar otros ejercicios de recuperación ante desastres. Por supuesto, mientras tanto, el nivel de datos y la aplicación siguen cambiando con el tiempo. Esos cambios introducen nuevos objetos y procesos que son críticos para la aplicación. E incluso si todo permanece estático después del lanzamiento, aún debe tener en cuenta la rotación de personal y los diferentes conjuntos de habilidades. ¿Puede el personal de hoy realizar con éxito un ejercicio de recuperación ante desastres? E incluso el mejor personal necesita práctica continua.
"No tendremos pérdida de datos porque estamos utilizando la creación de reflejo síncrona de la base de datos"
Supongamos que está utilizando la creación de reflejo de la base de datos síncrona entre dos instancias de SQL Server, con cada instancia en un centro de datos separado. En este ejemplo, suponga que la latencia de la transacción es aceptable a pesar de que se trata de una sesión de creación de reflejo de la base de datos síncrona con unas pocas millas entre los centros de datos. No tiene un testigo en la mezcla porque desea controlar la conmutación por error del espejo de la base de datos manualmente.
Ahora supongamos que su centro de datos de recuperación ante desastres desaparece, pero su centro de datos principal aún está disponible. Su base de datos principal está desconectada de la base de datos reflejada, pero aún acepta conexiones y modificaciones de datos. ¿Qué pasa con el requisito de "sin pérdida de datos" ahora? Si las transacciones se ejecutaron contra el principal desconectado durante otra hora, ¿cuál es su plan si también se pierde el centro de datos principal?
"El dueño de nuestra empresa dice que podemos perder hasta 12 horas de datos"
Es importante hacer algunas preguntas más de una vez ya más de una persona en una organización. Si alguien le dice que "12 horas de pérdida de datos es aceptable", pregúntele nuevamente o pregúntele cuál sería la consecuencia de esa pérdida de datos. Pregúntale a otras personas también. Es posible que le den un requisito mucho más estricto. Descubrí que los objetivos del punto de recuperación requieren algo de negociación y más de unas pocas discusiones reflexivas y deliberadas.
"Estamos usando [duplicación de bases de datos o grupos de disponibilidad] y, por lo tanto, estamos cubiertos para lo que necesitamos en caso de un desastre"
La creación de reflejo de la base de datos y los grupos de disponibilidad ciertamente se pueden usar para protegerlo a nivel de la base de datos, pero ¿qué pasa con todo lo demás? ¿Qué pasa con sus inicios de sesión? ¿Paquetes SSIS? ¿Trabajos? ¿Bases de datos de modelos de recuperación no COMPLETAS? Servidores vinculados?
"Usamos la función XYZ de SQL Server, por lo que no perderemos ninguna transacción en curso"
No, lo siento. Si bien algunas funciones permiten una redirección transparente, esto no es lo mismo que retener y persistir las transacciones abiertas en el momento de la conmutación por error. Ninguna característica de SQL Server proporciona esta funcionalidad en la actualidad.
"El equipo que respalda el nivel de datos para esta aplicación odia la función XYZ de SQL Server, pero estamos avanzando con ella porque eso es lo que nos recomendó un consultor externo"
Si bien sería bueno que las personas no desarrollaran sesgos específicos en torno a las características de SQL Server, este no suele ser el caso. Si intenta forzar soluciones en un personal que no está de acuerdo con ellos, corre el riesgo de una falla predeterminada. Como parte de los ejercicios de HA/DR con los que he ayudado en el pasado, siempre estoy interesado en conocer las experiencias pasadas de las personas con funciones específicas. Por ejemplo, algunas empresas aprovechan muy bien cientos de instancias de clúster de conmutación por error, mientras que otras las evitan debido a las malas experiencias con versiones anteriores. Al planificar una solución, no puede ignorar el historial o las predisposiciones del personal que, en última instancia, será responsable de implementar y brindar soporte a la solución recomendada.
"Como DBA, decido qué tecnología HA/DR usar para el nivel de datos, así que vamos a usar grupos de disponibilidad en el futuro"
Un administrador de base de datos podría potencialmente configurar la creación de reflejo de la base de datos con poca o ninguna participación con otros equipos. Ahora, con los grupos de disponibilidad, incluso si un administrador de base de datos pudiera hacerlo todo por su cuenta, podría ser imprudente hacerlo. Después de todo, si está implementando grupos de disponibilidad con fines de recuperación ante desastres, querrá que todos los involucrados en una operación de recuperación ante desastres conozcan su solución y los requisitos necesarios para volver a conectarse y recuperar datos con éxito. Con los grupos de disponibilidad, deberá pensar en el clúster de conmutación por error de Windows Server, las configuraciones de quórum, los votos de los nodos, el agente de escucha del grupo de disponibilidad y más. Si necesita que otras personas faciliten una solución, asegúrese de que participen en la recomendación inicial.
"Usamos grupos de disponibilidad para poder tener disponibilidad de solo lectura en caso de una interrupción de nuestra réplica de lectura y escritura"
Este es solo un ejemplo de un escenario de "qué pasaría si". Con cualquier implementación de la funcionalidad, querrá imaginar las diversas formas en que puede ocurrir una falla y luego asegúrese de probarla para asegurarse de que se sigan cumpliendo sus requisitos. Por ejemplo, si cree que las réplicas asíncronas de solo lectura de su grupo de disponibilidad de SQL Server 2012 estarán disponibles cuando la réplica de lectura y escritura no esté disponible, se sorprenderá desagradablemente al ver el Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections mensaje en producción.
"Probamos la función XYZ de SQL Server y la conmutación por error fue rápida, por lo que hemos establecido que podemos cumplir nuestros objetivos de tiempo de recuperación fácilmente"
Supongamos que decide utilizar la creación de reflejo de la base de datos para lograr una alta disponibilidad en el nivel de la base de datos del usuario. Desea una conmutación por error rápida (medida en segundos) y, de hecho, ve una conmutación por error rápida durante la prueba. ¿Pero fue una prueba realista? ¿Estabas empujando una carga de trabajo significativa? En el ejemplo de la creación de reflejo de la base de datos, la parte más larga de su operación de conmutación por error puede ser para las operaciones de rehacer. Si no está impulsando cargas de trabajo realistas, entonces no puede decir realmente que su conmutación por error será realmente "rápida".
"Si tenemos un desastre y necesitamos recuperar y reconciliar datos, lo resolveremos cuando llegue el momento"
Esta es una pregunta difícil. Supongamos que tiene un desastre y necesita que su centro de datos secundario esté operativo. Decide forzar el servicio para las bases de datos más críticas en el centro de datos secundario y ahora tiene una división en el linaje de modificaciones de datos (algunas filas no reconciliadas en el centro de datos principal y ahora nuevas modificaciones en el centro de datos secundario). Eventualmente, su centro de datos principal se pone en línea, pero ahora tiene datos que deben recuperarse y reconciliarse antes de que pueda restablecer la solución general de HA/DR. ¿A qué te dedicas? ¿Qué puedes hacer? Esta discusión rara vez es fácil de tener y puede depender de varios factores, como los paquetes de software que ha comprado, la complejidad del nivel de datos y las herramientas de convergencia de datos a su disposición. De hecho, la discusión suele ser tan difícil que la gente no la tiene en absoluto. Pero si los datos son lo suficientemente críticos como para configurar un centro de datos secundario, entonces una parte clave de la discusión debe incluir la mejor manera de recuperar los datos y reconciliarlos después de que ocurra un desastre.
Resumen
Este artículo incluye solo algunos ejemplos de cómo podemos engañarnos a nosotros mismos pensando que una solución cumple completamente con sus requisitos. Si bien es la naturaleza humana hacer esto, cuando se trata de la pérdida de datos y la continuidad del negocio, nuestros trabajos dependerán de que seamos más agresivos al probar nuestras propias creencias y suposiciones.
