El principal motivo para tener en cuenta la continuidad empresarial de los sistemas críticos es ayudar a una organización a ser resiliente y a continuar con sus operaciones empresariales durante y después de los fallos. Al replicar sistemas y datos en varias regiones geográficas y evitar los puntos únicos de fallo, puedes minimizar los riesgos de que una catástrofe natural afecte a la infraestructura local. Otros casos de fallo son los fallos graves del sistema, los ataques de ciberseguridad o incluso los errores de configuración del sistema.
Optimizar un sistema para que resista los fallos es esencial para establecer una continuidad de la actividad empresarial eficaz. La fiabilidad del sistema puede verse afectada por varios factores, como el rendimiento, la resiliencia, la disponibilidad, la seguridad y la experiencia de usuario. Para obtener más información sobre cómo diseñar y operar servicios fiables enGoogle Cloud, consulta el pilar de fiabilidad del Google Cloud framework Well-Architected y los componentes de fiabilidad en Google Cloud.
Este patrón de arquitectura se basa en una implementación redundante de aplicaciones en varios entornos informáticos. En este patrón, se implementan las mismas aplicaciones en varios entornos informáticos con el objetivo de aumentar la fiabilidad. La continuidad del negocio se puede definir como la capacidad de una organización para seguir ofreciendo sus funciones o servicios empresariales clave a niveles aceptables predefinidos tras un evento disruptivo.
La recuperación tras fallos (DR) se considera un subconjunto de la continuidad empresarial y se centra explícitamente en que los sistemas de TI en los que se basan funciones empresariales esenciales funcionen lo antes posible después de que se produzca una interrupción. En general, las estrategias y los planes de recuperación ante desastres a menudo contribuyen a crear una estrategia de continuidad de la actividad más amplia. Desde el punto de vista tecnológico, cuando empieces a crear estrategias de recuperación tras fallos, tu análisis de impacto en el negocio debe definir dos métricas clave: el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO). Si necesitas más ayuda para usar Google Cloud con el proceso de recuperación tras fallos, consulta la guía de planificación para la recuperación tras fallos.
Cuanto menores sean los valores de RPO y RTO, más rápido podrán recuperarse los servicios tras una interrupción con una pérdida de datos mínima. Sin embargo, esto implica un coste mayor, ya que significa crear sistemas redundantes. Los sistemas redundantes que pueden replicar datos casi en tiempo real y que operan a la misma escala tras un fallo aumentan la complejidad, los costes y la carga administrativa.
La decisión de seleccionar una estrategia de recuperación ante desastres o un patrón debe basarse en un análisis del impacto empresarial. Por ejemplo, las pérdidas financieras derivadas de unos pocos minutos de inactividad de una organización de servicios financieros pueden superar con creces el coste de implementar un sistema de recuperación ante desastres. Sin embargo, las empresas de otros sectores pueden sufrir horas de inactividad sin que esto tenga un impacto significativo en su actividad.
Cuando ejecutas sistemas críticos en un centro de datos local, una de las estrategias de recuperación tras desastres es mantener sistemas de reserva en un segundo centro de datos de otra región. Sin embargo, una opción más rentable es usar un entorno de computación basado en una nube pública para la conmutación por error. Este enfoque es el principal impulsor del patrón híbrido para la continuidad empresarial. La nube puede ser especialmente atractiva desde el punto de vista de los costes, ya que te permite desactivar parte de tu infraestructura de recuperación ante desastres cuando no se esté usando. Para conseguir una solución de recuperación tras fallos de menor coste, una solución en la nube permite a las empresas aceptar el posible aumento de los valores de RPO y RTO.
El diagrama anterior muestra el uso de la nube como entorno de conmutación por error o recuperación ante desastres para un entorno local.
Una variante menos habitual (y que rara vez se requiere) de este patrón es el patrón multicloud de continuidad empresarial. En ese patrón, el entorno de producción usa un proveedor de nube y el entorno de recuperación ante desastres usa otro proveedor de nube. Si despliegas copias de cargas de trabajo en varios proveedores de servicios en la nube, puedes aumentar la disponibilidad más allá de lo que ofrece un despliegue multirregional.
Evaluar una recuperación ante desastres en varias nubes en lugar de usar un proveedor de nube con diferentes regiones requiere un análisis exhaustivo de varios aspectos, entre los que se incluyen los siguientes:
- Facilidad de gestión
- Seguridad
- Viabilidad general.
- Coste
- Los posibles cargos por transferencia de datos salientes de más de un proveedor de servicios en la nube podrían ser costosos si la comunicación entre nubes es continua.
- Puede haber un gran volumen de tráfico al replicar bases de datos.
- El coste total de propiedad y el coste de gestionar la infraestructura de red entre nubes.
Si tus datos deben permanecer en tu país para cumplir los requisitos normativos, puedes usar un segundo proveedor de servicios en la nube que también esté en tu país como recuperación ante desastres. Para usar un segundo proveedor de servicios en la nube, se presupone que no hay ninguna opción para usar un entorno local con el fin de crear una configuración híbrida. Para evitar tener que rediseñar tu solución en la nube, lo ideal es que tu segundo proveedor de servicios en la nube ofrezca todas las funciones y los servicios que necesites en la región.
Factores del diseño
- Expectativas de recuperación ante desastres: los objetivos de RPO y RTO que quiera alcanzar tu empresa deben determinar la arquitectura de recuperación ante desastres y la planificación de la compilación.
- Arquitectura de la solución: con este patrón, debe replicar las funciones y las capacidades de su entorno local para cumplir sus expectativas de recuperación ante desastres. Por lo tanto, debe evaluar la viabilidad de volver a alojar, refactorizar o rediseñar sus aplicaciones para ofrecer las mismas funciones y el mismo rendimiento (o uno mejor) en el entorno de la nube.
- Diseño y creación: la creación de una zona de aterrizaje es casi siempre un requisito previo para implementar cargas de trabajo empresariales en un entorno de nube. Para obtener más información, consulta Diseño de la zona de aterrizaje en Google Cloud.
Activación de la recuperación tras fallos: es importante que tu diseño y proceso de recuperación tras fallos tengan en cuenta las siguientes preguntas:
- ¿Qué activa un escenario de recuperación tras desastres? Por ejemplo, un DR puede activarse si fallan funciones o sistemas específicos del sitio principal.
- ¿Cómo se invoca la conmutación por error al entorno de recuperación ante desastres? ¿Es un proceso de aprobación manual o se puede automatizar para conseguir un objetivo de RTO bajo?
- ¿Cómo deben diseñarse los mecanismos de detección y notificación de fallos del sistema para invocar la conmutación por error de acuerdo con el RTO esperado?
- ¿Cómo se redirige el tráfico al entorno de recuperación tras fallos una vez que se detecta el fallo?
Valida tus respuestas a estas preguntas mediante pruebas.
Pruebas: prueba y evalúa a fondo la conmutación por error a la recuperación ante desastres. Asegúrate de que cumpla tus expectativas de RPO y RTO. De esta forma, tendrás más confianza para invocar la recuperación ante desastres cuando sea necesario. Cada vez que se haga un cambio o una actualización en el proceso o en la solución tecnológica, vuelve a realizar las pruebas.
Habilidades del equipo: uno o varios equipos técnicos deben tener las habilidades y los conocimientos necesarios para crear, operar y solucionar problemas de la carga de trabajo de producción en el entorno de la nube, a menos que tu entorno esté gestionado por un tercero.
Ventajas
Usar Google Cloud para la continuidad empresarial ofrece varias ventajas:
- Como Google Cloud tiene muchas regiones en todo el mundo, puedes usarlo para crear copias de seguridad o replicar datos en otro sitio del mismo continente. También puedes crear copias de seguridad o replicar datos en un sitio de otro continente.
- Google Cloud ofrece la posibilidad de almacenar datos en Cloud Storage en un segmento birregional o multirregional. Los datos se almacenan de forma redundante en al menos dos regiones geográficas distintas. Los datos almacenados en los contenedores birregionales y multirregionales se replican en regiones geográficas mediante la replicación predeterminada.
- Los segmentos de dos regiones proporcionan redundancia geográfica para admitir planes de continuidad del negocio y de recuperación tras fallos. Además, para replicar más rápido y con un RPO más bajo, los objetos almacenados en dos regiones pueden usar opcionalmente la replicación turbo entre esas regiones.
- Del mismo modo, la replicación multirregional proporciona redundancia en varias regiones almacenando los datos dentro del límite geográfico de la multirregión.
- Ofrece una o varias de las siguientes opciones para reducir los gastos de capital y los gastos operativos a la hora de crear una recuperación tras fallos:
- Las instancias de VM detenidas solo generan costes de almacenamiento y son mucho más económicas que las instancias de VM en ejecución. Esto significa que puedes minimizar el coste de mantener sistemas de reserva inactivos.
- El modelo de pago por uso de Google Cloud significa que solo pagas por el almacenamiento y la capacidad de computación que utilizas.
- Las funciones de elasticidad, como el escalado automático, te permiten escalar o reducir automáticamente tu entorno de recuperación ante desastres según sea necesario.
Por ejemplo, el siguiente diagrama muestra una aplicación que se ejecuta en un entorno local (producción) que usa componentes de recuperación enGoogle Cloud con Compute Engine, Cloud SQL y Cloud Load Balancing. En este caso, la base de datos se aprovisiona previamente mediante una base de datos basada en una VM o una base de datos gestionada de Google Cloud , como Cloud SQL, para que la recuperación sea más rápida con la replicación continua de datos. Puedes iniciar VMs de Compute Engine a partir de snapshots creados previamente para reducir los costes durante las operaciones normales. Con esta configuración, y tras un evento de fallo, el DNS debe apuntar a la dirección IP externa de Cloud Load Balancing.
Para que la aplicación funcione en la nube, debes aprovisionar las máquinas virtuales web y de aplicación. En función del nivel de RTO objetivo y de las políticas de la empresa, todo el proceso para invocar una recuperación tras fallos, aprovisionar la carga de trabajo en la nube y redirigir el tráfico se puede completar de forma manual o automática.
Para acelerar y automatizar el aprovisionamiento de la infraestructura, considera la posibilidad de gestionarla como código. Puedes usar Cloud Build, que es un servicio de integración continua, para aplicar automáticamente manifiestos de Terraform a tu entorno. Para obtener más información, consulta el artículo Gestionar la infraestructura como código con Terraform, Cloud Build y GitOps.
Prácticas recomendadas
Cuando uses el patrón de continuidad de negocio, ten en cuenta las siguientes prácticas recomendadas:
- Crea un plan de recuperación tras fallos que documente tu infraestructura junto con los procedimientos de conmutación por error y recuperación.
- Tenga en cuenta las siguientes acciones en función de su análisis del impacto empresarial y de los objetivos de RPO y RTO identificados:
- Decide si es suficiente con hacer una copia de seguridad de los datos en Google Cloud o si necesitas plantearte otra estrategia de recuperación ante desastres (sistemas de reserva inactivos, activos o en espera).
- Define los servicios y productos que puedes usar como bloques de creación para tu plan de recuperación tras desastres.
- Define los escenarios de recuperación ante desastres aplicables a tus aplicaciones y datos como parte de la estrategia de recuperación ante desastres que hayas seleccionado.
- Si solo vas a crear copias de seguridad de los datos, te recomendamos que uses el patrón de transferencia. De lo contrario, el patrón en malla puede ser una buena opción para replicar la arquitectura de red del entorno.
- Minimiza las dependencias entre los sistemas que se ejecutan en entornos diferentes, sobre todo cuando la comunicación se gestiona de forma síncrona. Estas dependencias pueden ralentizar el rendimiento y reducir la disponibilidad general.
Evita el problema del cerebro dividido. Si replicas datos de forma bidireccional entre entornos, es posible que te enfrentes al problema de cerebro dividido. El problema de cerebro dividido se produce cuando dos entornos que replican datos bidireccionalmente pierden la comunicación entre sí. Esta división puede provocar que los sistemas de ambos entornos concluyan que el otro entorno no está disponible y que tienen acceso exclusivo a los datos. Esto puede provocar que los datos se modifiquen de forma contradictoria. Hay dos formas habituales de evitar el problema de split-brain:
- Usar un entorno informático de terceros. Este entorno permite que los sistemas comprueben si hay un quórum antes de modificar los datos.
Permite que se concilien las modificaciones de datos conflictivas después de que se restaure la conectividad.
Con las bases de datos SQL, puedes evitar el problema de cerebro dividido haciendo que la instancia principal original sea inaccesible antes de que los clientes empiecen a usar la nueva instancia principal. Para obtener más información, consulta Recuperación tras fallos de la base de datos de Cloud SQL.
Asegúrate de que los sistemas CI/CD y los repositorios de artefactos no se conviertan en un único punto de fallo. Cuando un entorno no esté disponible, debes poder implementar nuevas versiones o aplicar cambios en la configuración.
Haz que todas las cargas de trabajo sean portátiles cuando utilices sistemas de reserva. Todas las cargas de trabajo deben ser portátiles (si las aplicaciones lo permiten y es viable) para que los sistemas sigan siendo coherentes en todos los entornos. Para ello, puedes usar contenedores y Kubernetes. Si usas la edición Enterprise de Google Kubernetes Engine (GKE), puedes simplificar la compilación y las operaciones.
Integra el despliegue de sistemas de reserva en tu flujo de procesamiento de CI/CD. Esta integración ayuda a garantizar que las versiones y las configuraciones de las aplicaciones sean coherentes en todos los entornos.
Para asegurarte de que los cambios en el DNS se propaguen rápidamente, configura tu DNS con un valor de tiempo de vida razonablemente corto, de forma que puedas redirigir a los usuarios a los sistemas de reserva cuando se produzca un desastre.
Seleccione la política de DNS y la política de enrutamiento que se ajusten a su arquitectura y al comportamiento de la solución. Además, puedes combinar varios balanceadores de carga regionales con políticas de enrutamiento de DNS para crear arquitecturas de balanceo de carga globales para diferentes casos prácticos, incluida la configuración híbrida.
Utiliza varios proveedores de DNS. Si usas varios proveedores de DNS, puedes hacer lo siguiente:
- Mejora la disponibilidad y la resiliencia de tus aplicaciones y servicios.
Simplifica el despliegue o la migración de aplicaciones híbridas que tienen dependencias en entornos on-premise y de nube con una configuración de DNS de varios proveedores.
Google Cloud ofrece una solución de código abierto basada en octoDNS para ayudarte a configurar y gestionar un entorno con varios proveedores de DNS. Para obtener más información, consulta DNS público de varios proveedores con Cloud DNS.
Utiliza balanceadores de carga cuando uses sistemas de reserva para crear una conmutación por error automática. Ten en cuenta que el hardware del balanceador de carga puede fallar.
Usa Cloud Load Balancing en lugar de balanceadores de carga de hardware para llevar a cabo algunos de los casos que se dan al usar este patrón de arquitectura. Las solicitudes de clientes internos o las solicitudes de clientes externos se pueden redirigir al entorno principal o al entorno de recuperación tras desastres en función de diferentes métricas, como la división del tráfico basada en el peso. Para obtener más información, consulta la descripción general de la gestión del tráfico del balanceador de carga de aplicación externo global.
Si el volumen de transferencia de datos salientes de Google Cloud hacia el otro entorno es alto, plantéate usar Cloud Interconnect o Cross-Cloud Interconnect. Cloud Interconnect puede ayudar a optimizar el rendimiento de la conectividad y reducir los cargos por transferencia de datos salientes del tráfico que cumpla determinadas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.
Te recomendamos que uses la solución de tu partner preferido en Google Cloud Marketplace para facilitar las copias de seguridad de los datos, las replicaciones y otras tareas que cumplan tus requisitos, incluidos tus objetivos de RPO y RTO.
Prueba y evalúa escenarios de invocación de recuperación ante desastres para saber con qué facilidad puede recuperarse la aplicación de un desastre en comparación con el valor de RTO objetivo.
Cifra las comunicaciones en tránsito. Para proteger la información sensible, te recomendamos que cifres todas las comunicaciones en tránsito. Si se requiere cifrado en la capa de conectividad, hay varias opciones disponibles en función de la solución de conectividad híbrida seleccionada. Entre estas opciones se incluyen los túneles VPN, la VPN de alta disponibilidad mediante Cloud Interconnect y MACsec para Cloud Interconnect.