Planificar y diseñar un plan que no está listo para la producción

La capacidad de la infraestructura de DR debe poder gestionar las cargas de trabajo de producción, a menos que su plan dicte lo contrario. Implementar la DR con recursos que no se ajustan a su entorno de producción puede parecer atractivo desde el punto de vista de los costes, pero puede hacer que los efectos de un desastre sean mucho más graves.

Al planificar e implantar su entorno de recuperación ante desastres, tenga en cuenta sus propios requisitos de resistencia. No intente recortar costes reduciendo los requisitos de alta disponibilidad de la implantación de la RD. Si se produce un desastre, las cargas de trabajo de producción necesitan un entorno resistente. Los servicios en la nube son escalables, por lo que se puede añadir capacidad más adelante, pero el aumento de la demanda regional que provoca la catástrofe puede provocar escasez de capacidad a corto plazo.

Olvidar los puntos de fallo no técnicos

Los puntos únicos de fallo (SPOF) pueden estar en cualquier parte de una solución, no sólo en la tecnología. La solución puede depender de personas, vendedores, proveedores y otras dependencias externas. Identifique claramente sus SPOF y mitigue sus dependencias. Esté preparado para descubrir SPOF durante las primeras sesiones de su prueba de recuperación tras desastre.

Entre los SPOF, el riesgo de proveedor es una condición que debe tener en cuenta en su plan de DR. Cuando el mismo proveedor se encarga tanto de la producción como de la DR, se multiplica la condición de riesgo y se debe prestar una atención minuciosa al respecto.

Tener sólo un plan A

Las catástrofes pueden adoptar muchas formas, por lo que la planificación para un escenario de catástrofe específico le deja vulnerable ante otros. Al concebir el plan de RD, considere varios escenarios de catástrofe diferentes y demuestre la flexibilidad del plan.

Probar mal su plan

Una solución de RD no probada aumenta las posibilidades de encontrar un obstáculo cuando el éxito es más crítico. Las pruebas son esenciales para validar que la solución funciona. Las condiciones que se prueban también son importantes y requieren la creación de varios escenarios de prueba.

Realizar una prueba de RD mediante un cierre planificado de las operaciones en una ubicación y un reinicio bien organizado en la otra le ayudará a asegurarse de que su prueba de RD funciona. Sin embargo, un simple apagado completo no siempre ocurre en una emergencia real.

Diseñe sus pruebas de forma que imiten lo más fielmente posible las posibles condiciones de emergencia, simulando una "situación de catástrofe rodante" en la que la carga de trabajo se vea progresivamente afectada como consecuencia de la emergencia. El impacto progresivo pone a prueba la resistencia de su solución y proporciona información sobre su capacidad para resistir condiciones de estrés.

Alta disponibilidad

La alta disponibilidad no equivale a la recuperación en caso de desastre. IBM Cloud recomienda a los clientes que comprueben que sus despliegues son de alta disponibilidad, aprovechando las Regiones Multizona (MZR) de IBM Cloud. Cada MZR tiene un mínimo de tres zonas, que son centros de datos altamente interconectados, pero operativamente separados. A menudo, los problemas y cortes afectan sólo a una zona, no a toda la región. El despliegue de cargas de trabajo por defecto en todas las zonas de un MZR puede disminuir el tiempo de inactividad y la necesidad de convocar una catástrofe. La conmutación por error a una segunda región puede ser un proceso importante, al igual que la conmutación por error de vuelta, así que tome todas las medidas posibles para evitar tener que hacerlo. Sin embargo, los MZR no evitan desastres como la corrupción de datos o los daños malintencionados.

Normativa y cumplimiento

Algunas cargas de trabajo y datos están sujetos a estrictas normas de regulación y cumplimiento de la industria, que pueden afectar a la ubicación física en la que pueden ejecutarse o almacenarse. Cuando elija una ubicación para un centro de recuperación tras catástrofes, compruebe que la región elegida cumple la normativa y la conformidad necesarias. Las ubicaciones en las que decida replicar los datos también deben verificarse.

Los buckets interregionales Object Storage ofrecen una forma de replicar datos en diferentes regiones, pero utilícelos con cuidado si sus datos están sujetos a restricciones territoriales. Verifique que sus datos no se transfieren a una región de un país o territorio que infrinja las normas de cumplimiento de la organización o del sector.

Capacidad de recuperación en caso de catástrofe

Las catástrofes pueden afectar a muchos clientes, que entonces ponen en marcha sus planes de recuperación en caso de catástrofe. La demanda adicional podría poner a prueba la capacidad de una o varias de las regiones más cercanas a la región que ha fallado. Esto podría dar lugar a una escasez de recursos disponibles. Por ejemplo, si falla us-south, es probable que muchos clientes opten por recuperarse primero en la región us-east. Si eu-gb fracasa, se espera que haya más demanda en eu-de.

En caso de gran demanda provocada por una catástrofe, es posible que su primera opción de infraestructura no esté disponible para aprovisionar en su región de recuperación. Esto incluye los populares perfiles VPC VSI. Asegúrese de tener en cuenta varias arquitecturas para su aplicación que puedan dar cuenta de situaciones en las que se requiera un perfil VSI alternativo. Si su aplicación no puede tolerar el uso de una infraestructura alternativa, considere la posibilidad de crear o reservar tanta capacidad como necesite en la región de recuperación ante desastres que elija en previsión de una catástrofe, o considere otras ubicaciones más alejadas para evitar problemas de capacidad.

Compruebe que sus copias de seguridad pueden restaurarse en la región elegida. Por ejemplo, las bases de datos no pueden restaurarse en regiones que traspasan los límites de cumplimiento. Como práctica recomendada, asegúrese de comprobar los plazos de restauración de los datos y tenga en cuenta que podrían ampliarse en caso de catástrofe grave que afecte a toda una región, ya que muchos clientes intentarán restaurar los datos a la vez.

Conectividad

Los servicios de red pueden tardar algún tiempo en aprovisionarse y configurarse, ya que pueden requerir la actividad de terceros o la instalación adicional de infraestructura física. Cuando elabore un plan de RD, tenga en cuenta los plazos de entrega de estos servicios. Lo mejor es aprovisionar estos servicios con antelación:

• Direct Link Transit Gateway Local y Global Transit Gateway
• VPC Edge
• Pasarela VPN y conexiones
• DNS privado con configuración VPC de DNS Hub & Spoke
• VPE para servicios compartidos
• Reglas de restricción basadas en el contexto
• Equilibrador de carga global en DNS privado
• CIS con Public LBaaS, VPE Private Path y PPNLB

Aproveche la VPC landing zone arquitectura desplegable y la arquitectura de referencia de FS Cloud para preparar su conectividad con antelación o durante una recuperación de desastres.

Recuperación parcial o total

La nube se compone de diferentes servicios, y las aplicaciones pueden depender de múltiples componentes que trabajan juntos. Los planes de recuperación en caso de catástrofe suelen prepararse para fallos catastróficos a nivel regional y parten de la base de que se pierden todos los servicios de la región. Sin embargo, pueden producirse cortes aislados del servicio sin afectar a otros servicios de la región.

En estos casos, es crucial evaluar si es necesaria una conmutación por error completa a otra región o si sólo hay que ocuparse del componente que ha fallado.

Por ejemplo, si un servicio de base de datos sufre un fallo catastrófico, ¿hay que conmutar por error toda la carga de trabajo, incluidos los servicios web? ¿O pueden los demás componentes cambiar fácilmente a una base de datos de réplica de lectura en espera en otra región?

La facilidad para manejar estos escenarios depende de cómo esté diseñada y configurada la carga de trabajo. Evite codificar los nombres de los servicios y asegúrese de que su arquitectura tiene en cuenta factores como la latencia de la red para permitir transiciones fluidas durante interrupciones parciales.

Restablecimiento

Otro aspecto a tener en cuenta es la posición de seguridad tras una catástrofe. El procedimiento de recuperación ante fallos se documenta en el plan de recuperación ante desastres. Entre las consideraciones a tener en cuenta se incluyen:

• ¿Vuelve a fallar o sigue funcionando con normalidad en la ubicación de recuperación?
• Si el failback es obligatorio, ¿cuándo se intenta?
• ¿Cómo funciona el failback para causar el menor trastorno posible?

El failback puede ser tan complicado y perturbador como una catástrofe, por lo que hay que plantearse si es necesario. En su lugar, ¿pueden seguir funcionando los servicios en la segunda sede? El momento del failback también es importante. Hay que asegurarse de que se resuelven las circunstancias que causaron el desastre y de que el failback no causa interrupciones prolongadas.

Tanto si se realiza un failback como si no, es necesario volver a crear o restablecer la provisión de DR.