El principal motivo para considerar la continuidad empresarial para los sistemas de servicio crítico es ayudar a una organización a ser resiliente y continuar con sus operaciones comerciales durante y después de los eventos de falla. Si replicas los sistemas y los datos en múltiples regiones geográficas y evitas los puntos únicos de falla, puedes minimizar el riesgo de que un desastre natural afecte a la infraestructura local. Otras situaciones de falla incluyen fallas graves del sistema, ataques de ciberseguridad o incluso errores de configuración del sistema.
Optimizar un sistema para que resista las fallas es fundamental para establecer una continuidad empresarial eficaz. La confiabilidad del sistema puede verse afectada por varios factores, incluidos, sin limitaciones, el rendimiento, la resiliencia, la disponibilidad del tiempo de actividad, la seguridad y la experiencia del usuario. Para obtener más información sobre cómo diseñar y operar servicios confiables enGoogle Cloud, consulta el pilar de confiabilidad del Google Cloud Well-Architected Framework y los componentes básicos de la confiabilidad en Google Cloud.
Este patrón de arquitectura se basa en una implementación redundante de aplicaciones en múltiples entornos de computación. En este patrón, implementas las mismas aplicaciones en múltiples entornos de computación con el objetivo de aumentar la confiabilidad. La continuidad del negocio se puede definir como la capacidad de una organización para continuar con sus funciones o servicios comerciales clave en niveles aceptables predefinidos después de un evento disruptivo.
La recuperación ante desastres (DR) se considera un subconjunto de la continuidad del negocio y se enfoca de forma explícita en garantizar que los sistemas de TI que admiten funciones empresariales fundamentales estén en funcionamiento lo antes posible después de una interrupción. En general, los planes y las estrategias de DR a menudo ayudan a formar una estrategia de continuidad empresarial más amplia. Desde el punto de vista de la tecnología, cuando comienzas a crear estrategias de recuperación ante desastres, tu análisis del 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 deseas obtener más orientación sobre cómo usar Google Cloud para abordar la recuperación ante desastres, consulta la Guía de planificación de recuperación ante desastres.
Cuanto menores sean los valores objetivo de RPO y RTO, más rápido se recuperarán los servicios de una interrupción con una pérdida de datos mínima. Sin embargo, esto implica un costo más alto, ya que significa crear sistemas redundantes. Los sistemas redundantes que pueden realizar la replicación de datos casi en tiempo real y que operan a la misma escala después de un evento de falla aumentan la complejidad, los gastos administrativos y los costos.
La decisión de seleccionar una estrategia o un patrón de DR debe basarse en un análisis del impacto en el negocio. Por ejemplo, las pérdidas financieras que se producen incluso por unos pocos minutos de inactividad en una organización de servicios financieros podrían superar con creces el costo de implementar un sistema de DR. Sin embargo, las empresas de otros sectores pueden soportar horas de inactividad sin que esto tenga un efecto significativo en el negocio.
Cuando ejecutas sistemas esenciales en un centro de datos local, un enfoque de DR es mantener los sistemas en modo de espera en un segundo centro de datos en una región diferente. Sin embargo, un enfoque más rentable es usar un entorno de computación basado en la nube pública para fines de conmutación por error. Este enfoque es el principal factor del patrón híbrido de continuidad empresarial. La nube puede ser especialmente atractiva desde el punto de vista de los costos, ya que te permite desactivar parte de tu infraestructura de DR cuando no está en uso. Para lograr una solución de DR de menor costo, una solución en la nube permite que una empresa acepte el posible aumento en los valores de RPO y RTO.
En el diagrama anterior, se ilustra el uso de la nube como un entorno de recuperación ante desastres o conmutación por error para un entorno local.
Una variante menos común (y rara vez obligatoria) de este patrón es el patrón de multicloud de continuidad empresarial. En ese patrón, el entorno de producción usa un proveedor de servicios en la nube y el entorno de DR usa otro proveedor de servicios en la nube. Si implementas copias de cargas de trabajo en múltiples proveedores de servicios en la nube, puedes aumentar la disponibilidad más allá de lo que puede ofrecer una implementación de varias regiones.
Evaluar una DR en varias nubes en comparación con el uso de un proveedor de servicios en la nube con diferentes regiones requiere un análisis exhaustivo de varias consideraciones, incluidas las siguientes:
- Administración
- Seguridad
- Viabilidad general
- Costo
- Los posibles cargos por transferencia de datos salientes de más de un proveedor de servicios en la nube podrían ser costosos con la comunicación continua entre nubes.
- Puede haber un gran volumen de tráfico cuando se replican bases de datos.
- El TCO y el costo de administrar la infraestructura de red entre nubes
Si tus datos deben permanecer en tu país para cumplir con los requisitos reglamentarios, usar un segundo proveedor de servicios en la nube que también se encuentre en tu país como DR puede ser una opción. El uso de un segundo proveedor de servicios en la nube supone que no hay opción de usar un entorno local para crear una configuración híbrida. Para evitar reestructurar tu solución en la nube, lo ideal es que tu segundo proveedor de servicios en la nube ofrezca todas las capacidades y los servicios necesarios en la región.
Consideraciones del diseño
- Expectativa de DR: Los objetivos de RPO y RTO que tu empresa desea alcanzar deben impulsar la planificación de la arquitectura y la compilación de DR.
- Arquitectura de la solución: Con este patrón, debes replicar las funciones y capacidades existentes de tu entorno local para cumplir con tus expectativas de DR. Por lo tanto, debes evaluar la factibilidad y la viabilidad de volver a alojar, refactorizar o rediseñar tus aplicaciones para proporcionar las mismas funciones y el mismo rendimiento (o más optimizados) en el entorno de la nube.
- Diseño y compilación: Compilar una zona de destino casi siempre es 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 destino en Google Cloud.
Invocación de DR: Es importante que tu diseño y proceso de DR tengan en cuenta las siguientes preguntas:
- ¿Qué activa una situación de DR? Por ejemplo, un DR puede activarse por la falla de funciones o sistemas específicos en el sitio principal.
- ¿Cómo se invoca la conmutación por error al entorno de DR? ¿Es un proceso de aprobación manual o se puede automatizar para lograr un objetivo de RTO bajo?
- ¿Cómo se deben diseñar los mecanismos de detección y notificación de fallas del sistema para invocar la conmutación por error en consonancia con el RTO esperado?
- ¿Cómo se redirecciona el tráfico al entorno de DR después de que se detecta la falla?
Valida tus respuestas a estas preguntas con pruebas.
Pruebas: Prueba y evalúa a fondo la conmutación por error en DR. Asegúrate de que cumpla con tus expectativas de RPO y RTO. Si lo haces, podrías tener más confianza para invocar la DR cuando sea necesario. Cada vez que se realice un cambio o una actualización nuevos en el proceso o la solución tecnológica, vuelva a realizar las pruebas.
Habilidades del equipo: Uno o más equipos técnicos deben tener las habilidades y la experiencia necesarias para compilar, operar y solucionar problemas de la carga de trabajo de producción en el entorno de la nube, a menos que un tercero administre tu entorno.
Ventajas
Usar Google Cloud para la continuidad empresarial ofrece varias ventajas:
- Debido a que Google Cloud tienemuchas regiones en todo el mundo para elegir, puedes usarlo para crear copias de seguridad o replicar datos en un sitio diferente dentro del mismo continente. También puedes crear copias de seguridad o replicar datos en un sitio de otro continente.
- Google Cloud ofrece la capacidad de almacenar datos en Cloud Storage en un bucket de región doble o multirregión. Los datos se almacenan de forma redundante en al menos dos regiones geográficas separadas. Los datos almacenados en buckets de región doble y múltiple se replican en regiones geográficas a través de la replicación predeterminada.
- Los buckets birregionales proporcionan redundancia geográfica para admitir planes de continuidad empresarial y DR. Además, para replicar más rápido, con un RPO más bajo, los objetos almacenados en regiones dobles pueden usar de forma opcional la replicación turbo en esas regiones.
- Del mismo modo, la replicación multirregional proporciona redundancia en varias regiones, ya que almacena tus datos dentro del límite geográfico de la multirregión.
- Proporciona una o más de las siguientes opciones para reducir los gastos de capital y los gastos operativos para compilar una DR:
- Las instancias de VM detenidas solo generan costos de almacenamiento y son mucho más económicas que las instancias de VM en ejecución. Esto significa que puedes minimizar el costo de mantener los sistemas en modo de espera fríos.
- El modelo de pago por uso de Google Cloud significa que solo pagas por la capacidad de almacenamiento y procesamiento que realmente usas.
- Las capacidades de elasticidad, como el ajuste de escala automático, te permiten ajustar la escala de tu entorno de DR automáticamente según sea necesario.
Por ejemplo, en el siguiente diagrama, se muestra una aplicación que se ejecuta en un entorno local (producción) y que usa componentes de recuperación enGoogle Cloud con Compute Engine, Cloud SQL y Cloud Load Balancing. En esta situación, la base de datos se aprovisiona previamente con una base de datos basada en VM o con una base de datos administrada por Google Cloud , como Cloud SQL, para una recuperación más rápida con replicación de datos continua. Puedes iniciar VMs de Compute Engine a partir de instantáneas creadas previamente para reducir los costos durante las operaciones normales. Con esta configuración, y después de un evento de falla, 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 VMs de la aplicación y la Web. Según el nivel de RTO objetivo y las políticas de la empresa, todo el proceso para invocar un DR, aprovisionar la carga de trabajo en la nube y redireccionar el tráfico se puede completar de forma manual o automática.
Para acelerar y automatizar el aprovisionamiento de la infraestructura, considera administrarla 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 Administra la infraestructura como código con Terraform, Cloud Build y GitOps.
Prácticas recomendadas
Cuando uses el patrón de continuidad empresarial, ten en cuenta las siguientes prácticas recomendadas:
- Crea un plan de recuperación ante desastres que documente tu infraestructura y los procedimientos de recuperación y conmutación por error.
- Ten en cuenta las siguientes acciones según tu análisis de impacto comercial y los objetivos de RPO y RTO requeridos que se identificaron:
- Decide si es suficiente crear una copia de seguridad de los datos en Google Cloud o si necesitas considerar otra estrategia de DR (sistemas en espera pasiva, semiactiva o activa).
- Define los servicios y productos que puedes usar como componentes básicos para tu plan de DR.
- Enmarca las situaciones de DR aplicables para tus aplicaciones y datos como parte de la estrategia de DR seleccionada.
- Considera usar el patrón de traspaso cuando solo realices copias de seguridad de datos. De lo contrario, el patrón de malla podría ser una buena opción para replicar la arquitectura de red del entorno existente.
- Minimiza las dependencias entre sistemas que se ejecutan en diferentes entornos, en especial, cuando la comunicación se maneja de forma síncrona. Estas dependencias pueden disminuir el rendimiento y la disponibilidad general.
Evita el problema de cerebro dividido. Si replicas datos de forma bidireccional entre entornos, puede que te expongas al problema de cerebro dividido. El problema de cerebro dividido se produce cuando dos entornos que replican datos de forma bidireccional pierden la comunicación entre sí. Esta división puede hacer que los sistemas en ambos entornos concluyan que el otro entorno no está disponible y que tienen acceso exclusivo a los datos. Esto puede generar modificaciones conflictivas de los datos. Existen dos formas comunes de evitar el problema de cerebro dividido:
- Usar un tercer entorno de procesamiento Este entorno permite que los sistemas verifiquen un quórum antes de modificar los datos.
Permite que se concilien las modificaciones de datos en conflicto después de que se restablezca 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 comiencen a usar la instancia principal nueva. Para obtener más información, consulta Recuperación ante desastres de bases de datos de Cloud SQL.
Asegúrate de que los sistemas de CI/CD y los repositorios de artefactos no se conviertan en un único punto de falla. Incluso cuando un entorno no esté disponible, deberías poder implementar nuevas versiones o aplicar cambios en la configuración.
Haz que todas las cargas de trabajo sean portátiles cuando uses sistemas en espera. Todas las cargas de trabajo deben ser portátiles (cuando las aplicaciones lo admitan y sea factible) para que los sistemas permanezcan coherentes en todos los entornos. Puedes lograr este enfoque considerando los contenedores y Kubernetes. Con Google Kubernetes Engine (GKE), puedes simplificar la compilación y las operaciones.
Integra la implementación de sistemas en modo de espera en tu canalización de CI/CD. Esta integración ayuda a garantizar que las versiones y configuraciones de las aplicaciones sean coherentes en todos los entornos.
Para garantizar que los cambios de DNS se propaguen con rapidez, configura tu DNS con un valor de tiempo de actividad razonablemente corto para poder redirigir a los usuarios a sistemas en modo de espera cuando ocurra un desastre.
Selecciona la política de DNS y de enrutamiento que se alinee con tu arquitectura y el comportamiento de la solución. Además, puedes combinar varios balanceadores de cargas regionales con políticas de enrutamiento de DNS para crear arquitecturas de balanceo de cargas globales para diferentes casos de uso, incluida la configuración híbrida.
Usa varios proveedores de DNS. Cuando usas varios proveedores de DNS, puedes hacer lo siguiente:
- Mejora la disponibilidad y la capacidad de recuperación de tus aplicaciones y servicios.
Simplifica la implementación o migración de aplicaciones híbridas que tienen dependencias en entornos locales 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 operar un entorno con varios proveedores de DNS. Para obtener más información, consulta DNS público de varios proveedores con Cloud DNS.
Usa balanceadores de cargas cuando uses sistemas en modo de espera para crear una conmutación por error automática. Ten en cuenta que el hardware del balanceador de cargas puede fallar.
Usa Cloud Load Balancing en lugar de balanceadores de cargas de hardware para potenciar algunos casos de uso que se producen cuando se usa este patrón de arquitectura. Las solicitudes de clientes internos o las solicitudes de clientes externos se pueden redireccionar al entorno principal o al entorno de DR según diferentes métricas, como la división del tráfico basada en el peso. Para obtener más información, consulta Descripción general de la administración del tráfico en el balanceador de cargas de aplicaciones externo global.
Considera usar Cloud Interconnect o Cross‑Cloud Interconnect si el volumen de transferencia de datos salientes de Google Cloud hacia el otro entorno es alto. Cloud Interconnect puede ayudar a optimizar el rendimiento de la conectividad y puede reducir los cargos por transferencia de datos salientes para el tráfico que cumple con ciertas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.
Considera usar tu solución de socio preferida en Google Cloud Marketplace para facilitar las copias de seguridad de los datos, las replicaciones y otras tareas que cumplan con tus requisitos, incluidos tus objetivos de RPO y RTO.
Prueba y evalúa situaciones de invocación de DR para comprender con qué facilidad la aplicación se puede recuperar de un desastre en comparación con el valor del RTO objetivo.
Encripta las comunicaciones en tránsito. Para proteger la información sensible, te recomendamos que encriptes todas las comunicaciones en tránsito. Si se requiere encriptación en la capa de conectividad, hay varias opciones disponibles según la solución de conectividad híbrida seleccionada. Estas opciones incluyen túneles VPN, VPN con alta disponibilidad en Cloud Interconnect y MACsec para Cloud Interconnect.