¿Es lo mismo alta disponibilidad que recuperación en caso de catástrofe? ¿Son necesarias ambas?

La alta disponibilidad (HA) y la recuperación ante desastres (DR) se confunden fácilmente, pero son claramente distintas.

El diseño de alta disponibilidad en una carga de trabajo es un esfuerzo para evitar que una carga de trabajo falle. Por ejemplo, repartir los datos entre varios discos en una matriz RAID es un esfuerzo por evitar una interrupción causada por el fallo de un disco. Las fuentes de alimentación múltiples en un servidor son un esfuerzo para prevenir un fallo causado por un corte en un circuito de alimentación. Ejecutar aplicaciones a través de múltiples servidores en diferentes zonas es un esfuerzo para prevenir una interrupción causada por un fallo del servidor y un fallo de zona.

La recuperación de desastres es la práctica de recuperar una carga de trabajo después de que falle, a pesar de la disponibilidad de recursos de que disponga. Por ejemplo, una carga de trabajo puede estar altamente disponible y ser resistente a fallos porque se ejecuta a través de múltiples dispositivos de hardware en múltiples centros de datos, lo que puede proporcionar al sistema una disponibilidad 99.999. Sin embargo, sigue siendo susceptible a catástrofes como el borrado accidental o malintencionado de datos, o un desastre natural que arrasa una amplia zona que incluye todos los centros de datos.

Normalmente, cuanto mayor es la disponibilidad de una carga de trabajo, más valiosa y vital es para la empresa. Dado que una carga de trabajo es vital para la empresa, es más necesario que cuente con un plan de recuperación en caso de catástrofe bien documentado y riguroso.

¿Qué se considera una catástrofe?

Una catástrofe informática es un suceso que perturba gravemente una aplicación o un entorno, impidiendo que funcione según lo previsto. Las catástrofes pueden ser de corta o larga duración, pero suelen causar un perjuicio importante a la empresa, ya sea financiero, de reputación o de ambos tipos.

Las catástrofes pueden ser el resultado de las siguientes situaciones:

• Catástrofes naturales como inundaciones, incendios o terremotos.
• Problemas de infraestructura, como cortes de electricidad o fallos más amplios de la red.
• Acciones accidentales o malintencionadas que borran datos, servicios o configuración.
• Lanzar una actualización de software que contenga un fallo u otro error que no se había previsto.

En cada caso, es esencial contar con un plan de recuperación que restablezca los servicios en un plazo determinado y a un punto anterior a la catástrofe. También es importante tener en cuenta los costes, incluyendo tanto el impacto del tiempo de inactividad en la empresa como los gastos de la solución de recuperación.

¿Puede la RD tener lugar en una región?

Sí, la DR puede tener lugar en la misma región, y podría ser más rápida debido a la menor latencia y a la no necesidad de replicación de datos entre regiones. Sin embargo, se recomienda utilizar una región separada para mejorar la resistencia. Si la región primaria se ve gravemente afectada, la recuperación en la misma región podría no ser posible.

IBM Cloud trata de recuperar los servicios dentro de la región, de acuerdo con los objetivos de nivel de servicio(SLO) publicados. La recuperación puede durar minutos u horas, pero en el peor de los casos, como la destrucción física de bienes, puede llevar días, semanas o meses.

En IBM Cloud, si se produce una interrupción que IBM Cloud denomina desastre, es posible que IBM Cloud tenga que recuperar los servicios antes de que usted pueda recuperar sus cargas de trabajo. Si es así, tienes que añadir el tiempo que tarda IBM Cloud en completar su recuperación al tiempo que tarda en hacer la tuya. Téngalo en cuenta a la hora de decidir si confía en una sola región.

¿Todas las catástrofes requieren recuperación en una segunda región?

No todas las catástrofes requieren la recuperación en una segunda región. Un administrador de bases de datos puede eliminar accidentalmente una tabla de una base de datos, una liberación automatizada puede salir mal o un servicio esencial gestionado en la nube puede dejar de funcionar correctamente. En estos casos, la recuperación de datos es clave. Dependiendo de lo extendido que esté el problema, de lo preparada que esté la organización y de lo rápido que necesite recuperarse, un desastre de este tipo podría no forzar una conmutación por error a otra región. Dependiendo del escenario, la recuperación puede lograrse en la misma región. Considere en su plan múltiples escenarios de catástrofe.

¿Cómo puedo evitar el borrado accidental de servicios?

Muchos servicios de IBM Cloud incorporan protecciones contra el borrado accidental, pero puedes implementar más protecciones utilizando cuentas que tengan los derechos de acceso adecuados. Utilice Cloud Identity and Access Management (IAM) para crear cuentas con diferentes niveles de acceso y permisos. A continuación, utilice una cuenta adecuada para la tarea de operaciones en cuestión y asegúrese de que otros usuarios, como los desarrolladores, sólo tienen el acceso y los permisos que necesitan.

Si utiliza Terraform, utilice ID de servicio que tengan acceso de actualización pero no de eliminación.