La implementación de una solución de recuperación ante desastres depende de tres factores:1) tiempo 2) recursos 3) monto en dólares.
La mayoría de las organizaciones ni siquiera piensan en DR cuando la infraestructura de TI y las aplicaciones se ejecutan sin problemas. La mayoría de ellos piensa en DR solo cuando se rompe algo que generó un gran impacto negativo en el negocio.
Si usted es un administrador de sistemas, o alguien responsable de mantener la TI en funcionamiento, debe estar trabajando constantemente. sobre la recuperación ante desastres. Ya sea que su empresa asignó tiempo y presupuesto o no, aún puede trabajar en algunos aspectos de DR.
La siguiente es una lista de varios elementos que quizás desee considerar al planificar un DR. Esta lista no es completa de ninguna manera, pero debería darle suficientes ideas para comenzar con DR.
- Centro de datos principal resistente. Antes de planificar un centro de datos remoto secundario, debe asegurarse de que todos los componentes de su centro de datos principal sean altamente redundantes. Su enfoque debe ser diseñar su centro de datos principal lo más resistente posible para que pueda recuperarse rápidamente de la mayoría de los desastres (excepto los desastres naturales) sin tener que usar el centro de datos remoto secundario. Por ejemplo, para su base de datos de producción, tenga una base de datos física en espera ejecutándose en el mismo centro de datos, configure tarjetas NIC dobles y tarjetas HBA en todos los servidores de producción, configure varios servidores web con un equilibrador de carga, conecte el servidor a dos circuitos de alimentación mediante el sistema redundante. fuente de alimentación en los servidores, etc.
- Centro de datos secundario remoto. Si implementa un centro de datos principal resistente, su objetivo para usar un centro de datos remoto redundante es principalmente para desastres naturales como terremotos, incendios, inundaciones, etc. Si bien esto puede ser muy obvio, vale la pena señalarlo, ya que he visto pocas empresas. hacer esto, tienen el centro de datos primario y secundario en la misma ciudad, lo que anula el propósito de DR. Si su centro de datos principal está en California, configure un centro de datos secundario en algún lugar de la costa este.
- Replicar componentes de producción en el centro de datos DR. No necesita replicar todo el hardware y las aplicaciones del centro de datos principal al secundario. Un administrador de sistemas o cualquier persona técnica puede identificar rápidamente todo el hardware y el software críticos que deben replicarse en el sitio DR, pero es posible que necesite ayuda de otros departamentos para identificar las aplicaciones que son críticas para el negocio. Debe asignar las funciones comerciales críticas a los componentes de la infraestructura de TI y asegurarse de que todos esos componentes de la infraestructura, junto con la aplicación y los datos, se repliquen en el sitio de recuperación ante desastres.
- Plan de almacenamiento. Si tiene algún tipo de almacenamiento SAN (o almacenamiento NAS) que admita la aplicación crítica en el DR principal, también debe tener un almacenamiento SAN similar (o almacenamiento NAS) en su sitio DR. Por motivos de rendimiento, los servidores de producción del sitio DR deben tener las mismas especificaciones que los servidores de producción del sitio principal. Sin embargo, para el almacenamiento, si tiene un almacenamiento SAN de gama alta de un gran proveedor en el sitio principal, considere implementar un almacenamiento SAN de gama alta similar de un pequeño proveedor, lo que podría costarle mucho menos dinero por la misma configuración y un rendimiento similar. .
- Replicar datos en el sitio DR de forma continua. La sincronización de datos entre el centro de datos principal y el de desastres es un aspecto crítico de una implementación exitosa de DR. Una vez que haya enumerado todas las aplicaciones que deben replicarse en el sitio DR, debe descubrir cómo sincronizar los datos entre estos dos sitios para todas estas aplicaciones. Por ejemplo, puede replicar la base de datos de Oracle a nivel de bloque utilizando las tecnologías de replicación proporcionadas por los proveedores de almacenamiento, o puede usar datagurad para replicar los datos a nivel de Oracle. Ambos tienen sus propios pros y contras. Tienes que analizarlos cuidadosamente y elegir el que se ajuste a tu presupuesto y alcance de la RD.
- Replicar los datos iniciales usando el método manual. Cuando configura el sitio DR por primera vez, debe decidir cómo realizará la sincronización de datos inicial. Por ejemplo, si está replicando una base de datos de almacén de datos de gran tamaño, no puede copiar la copia de seguridad inicial de la base de datos a través de la red al sitio remoto, ya que podría acaparar el ancho de banda. En su lugar, puede realizar una copia de seguridad en cinta en el centro de datos principal y utilizarla en el centro de datos secundario para configurar la base de datos inicial. Una vez realizada la configuración inicial, puede implementar algún tipo de sincronización incremental automática entre los sitios.
- RTO significa objetivo de tiempo de recuperación. Al trabajar con el equipo de administración, identifica el RTO aceptable para el negocio. Por ejemplo, su organización puede decidir que el RTO aceptable es de 8 horas. es decir, después de un desastre, dentro de un máximo de 8 horas, todas las aplicaciones críticas deberían estar completamente operativas en el sitio DR. RTO tiene un impacto directo en la cantidad de dinero que se gasta en la implementación de la solución DR. Por ejemplo, un RTO de 1 hora puede necesitar una solución DR muy sofisticada que sea demasiado costosa que la que requiere un RTO de 24 horas.
- RPO significa objetivo de punto de recuperación. Al igual que RTO, debe trabajar con la gerencia para decidir un RPO aceptable para el negocio. Por ejemplo, su organización puede decidir que el RPO aceptable es de 2 horas. es decir, después de un desastre, cuando realiza la conmutación por error del servicio a DR secundario, 2 horas de pérdida de datos son aceptables para el negocio. Por ejemplo, si el desastre ocurre a las 3:00 p. m., después de restaurar el sistema en el sitio DR, contendrá datos de producción solo a partir de la 1:00 p. m. Entonces, ha perdido datos de 1 p. m. a 3 p. m. En términos simples, si su RPO es de 2 horas, su empresa debería estar dispuesta a perder 2 horas de datos durante un desastre.
- ¿Conmutación por error automática o manual? Debe decidir si desea una conmutación por error automática o manual después de un desastre. En la mayoría de los casos, una intervención manual es aceptable, ya que no desea una conmutación por error automática a un sitio de recuperación ante desastres en función de alguna señal falsa. Tenga en cuenta que una vez que realiza la conmutación por error, implica mucho trabajo volver al centro de datos principal.
- Conmutación por error de la red. He visto planes de DR que se enfocan mucho en la replicación de datos, pero menos en los aspectos de redes de DR. Al trabajar con su equipo de redes, debe identificar todas las infraestructuras de red que deben replicarse. Por ejemplo, la conmutación por error de DNA para asegurarse de que su URL de producción apunte al sitio DR después de la conmutación por error. Si ha establecido conexiones VPN para sus clientes, identifique cómo conmutar por error las conexiones VPN. Cuando crea/modifica reglas de firewall (o cualquier cosa relacionada con la seguridad) en el centro de datos principal, debe identificar cómo se pueden replicar esas políticas de seguridad en el sitio DR de forma continua.
- Configuración de mano remota. Debe tener un plan apropiado para acceder al centro de datos remoto para depurar cualquier problema. Puede configurar KVM en el sitio de DR para acceder a la consola del hardware ubicado en el sitio de DR desde su oficina. O bien, debe planificar algún tipo de servicio manual remoto manual, en el que alguien pueda ir al sitio de DR físicamente y llevar a cabo sus instrucciones.
- Pruebas anuales de DR. Varias organizaciones gastan mucho tiempo y dinero en configurar un sitio de DR, solo para darse cuenta de que realmente no funciona como se esperaba cuando se encuentran en una situación de DR real. Una vez al año, debe validar sus configuraciones DR actuales para asegurarse de que el sitio DR funcione correctamente y cumpla con el objetivo original. Si todo está configurado correctamente, debería poder conmutar por error manualmente sus aplicaciones críticas desde el sitio principal al sitio DR y dejar que se ejecute allí durante unos días. Esto también le ayuda a ver cómo el sitio DR maneja la carga en tiempo real.
- Sitio DR como plataforma de control de calidad. En lugar de usar el sitio DR solo para situaciones de desastre, puede usarlos como una plataforma de control de calidad para realizar pruebas de rendimiento y carga de sus aplicaciones. Esto podría ser útil, ya que no necesita invertir en infraestructura de prueba adicional en el centro de datos principal. Cuando adopte este enfoque, seguirá sincronizando datos del sitio principal al sitio DR de forma continua. Sin embargo, siempre que realice una prueba de carga, debe implementar alguna solución adicional en la que tome un punto de control del estado actual del sitio DR, realice su prueba de control de calidad y luego retroceda inmediatamente al punto de control anterior y continúe sincronizando los datos del sitio principal. desde allí.
- Plan de respuesta DR. Una vez que haya implementado el sitio DR, debe tener un plan DR claro sobre cómo usted y su equipo responderán cuando ocurra un desastre real. Colabore con varios departamentos de su organización e identifique los recursos clave que formarán parte del equipo de respuesta de DR e identifique su rol específico en el plan de respuesta de DR. El plan de respuesta de DR es una simple instrucción paso a paso sobre lo que se debe hacer cuando hay un DR, quién realizará esas tareas y en qué secuencia se realizarán esas tareas.
- ¿No tiene un sitio DR? Muchas organizaciones no tienen un sitio DR. Si está trabajando para uno de ellos y es responsable de las aplicaciones críticas y la infraestructura de TI, es su responsabilidad elaborar un plan de DR y educar a su alta gerencia sobre la importancia de gastar tiempo y dinero en DR y obtener su aprobación. Cree tres planes DR diferentes:uno que cueste $$$, otro que cueste $$ y otro que cueste $. Como explicamos anteriormente, el plan DR puede variar dependiendo de varios factores, y el costo es uno de ellos. Después de haber presentado su plan de DR detallado a su gerencia, si aún no lo aprueban, al menos se sentirá bien de haber dado lo mejor de sí para elaborar un buen plan de DR.
- ¿Cuándo declarar un desastre? Es necesario identificar claramente esto antes de tiempo. Debe tener un criterio escrito muy claro sobre cuándo cambiará al sitio DR. es decir, ¿qué criterios desencadenan los criterios de conmutación por error de DR? ¿Cuándo se inicia un DR? ¿En qué momento declara que es un DR, agrega y comienza a trabajar en la conmutación por error al sitio de DR? La respuesta a estas preguntas debe estar claramente definida y revisada por todos los departamentos de su organización y, finalmente, estos criterios deben ser aprobados por la alta dirección. Para algunos, cuando la producción está inactiva, porque alguien eliminó algo en producción por error, es posible que no se active un DR. Para algunas organizaciones, probablemente sea mejor restaurar los datos de la copia de seguridad en el sitio principal. Para otras organizaciones, las empresas no pueden esperar hasta restaurar desde la copia de seguridad y deben cambiar al sitio DR.
- Copia de seguridad, copia de seguridad y copia de seguridad. Las copias de seguridad son un factor muy importante en un plan DR. Como mencionamos anteriormente, su objetivo debe ser nunca usar el sitio DR, a menos que ocurra un desastre natural real. Por lo tanto, una estrategia sólida de copia de seguridad en su sitio principal es muy importante. Debe hacer una copia de seguridad de todas sus aplicaciones críticas. Cuando haga una copia de seguridad de su base de datos, almacene la copia de seguridad en cuatro ubicaciones. Las copias de seguridad son prácticamente inútiles si no las restaura en un servidor de prueba para validar que funcionan de forma continua.
- Aplicación de parches. Cuando aplica un parche del sistema operativo, actualiza el firmware o realiza cualquier tipo de administración de configuración en el hardware en el sitio principal, debe tener una estrategia para hacerlo en el sitio DR de manera continua. No quiere estar en una situación en la que la configuración del sistema operativo en su sitio principal sea diferente a la del sitio DR.
- El éxito de la recuperación ante desastres depende de muchos factores. Bendición de la alta gerencia, asignación presupuestaria adecuada, participación de todas las divisiones comerciales, plan de DR sólido, recursos técnicos sólidos, implementación de DR completamente probada. Lo que es más importante, un alcance de DR bien definido que esté alineado con el objetivo comercial es muy crítico para una DR exitosa.
- Documentación DR. Una adecuada planificación de DR requiere que se establezcan muchos procesos. Todos estos procesos deben estar debidamente documentados. Por ejemplo, un documento que explica el proceso de escalamiento cuando ocurre un DR. Una documentación técnica que explica lo que se debe hacer para realizar la conmutación por error al sitio DR. Un documento de comunicación que enumera a todos los miembros del equipo involucrados en la DR, de qué son responsables y cómo se les puede contactar durante la DR. Un documento para el equipo de atención al cliente, que sabe lo que se debe comunicar al cliente y cómo llegar a los clientes durante un desastre. Un documento de prueba de DR que enumera todo lo que un equipo de control de calidad necesita probar después de que el sitio de DR esté activo, etc.
Solo hemos arañado la superficie de la recuperación ante desastres. Hay mucho más que los elementos anteriores. Si usted es un administrador de sistemas, o alguien que es responsable de sus aplicaciones e infraestructura de TI, y si no tiene un plan de recuperación ante desastres, considere esto como un recordatorio para comenzar con su estrategia de recuperación ante desastres.