El factor principal para considerar la continuidad empresarial en los sistemas de misión crítica es ayudar a una organización a ser resiliente y continuar con sus operaciones comerciales durante y después de los eventos de fallas. 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, un ataque de seguridad cibernética o incluso un error de configuración del sistema.
Optimizar un sistema para que resista las fallas es esencial para establecer una continuidad empresarial eficaz. La confiabilidad del sistema puede verse influenciada 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 en Google Cloud, consulta el pilar de confiabilidad del marco de trabajo de arquitectura de Google Cloud y los elementos básicos de confiabilidad en Google Cloud.
Este patrón de arquitectura se basa en una implementación redundante de aplicaciones en varios entornos de computación. En este patrón, se implementan 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 un punto de vista tecnológico, cuando comiences a crear estrategias de recuperación ante desastres, tu análisis del impacto empresarial debe definir dos métricas clave: el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO). Para obtener más orientación sobre el uso de Google Cloud para abordar la recuperación ante desastres, consulta la Guía de planificación para la recuperación ante desastres.
Cuanto más bajos sean los valores objetivo de RPO y RTO, más rápido se podrán recuperar 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 implica la creación de 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, la sobrecarga administrativa y el costo.
La decisión de seleccionar una estrategia de DR o un patrón debe estar basada en un análisis del impacto en el negocio. Por ejemplo, las pérdidas financieras que se generan por unos pocos minutos de tiempo de inactividad para una organización de servicios financieros pueden superar con creces el costo de implementar un sistema de DR. Sin embargo, las empresas de otros sectores pueden soportar horas de tiempo de inactividad sin un efecto comercial significativo.
Cuando ejecutas sistemas esenciales en un centro de datos local, un enfoque para la 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 impulsor principal 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 conmutación por error o de recuperación ante desastres para un entorno local.
Una variante menos común (y rara vez obligatoria) de este patrón es el de múltiples nubes 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. 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 lugar de usar un proveedor de servicios en la nube con diferentes regiones requiere un análisis exhaustivo de varias consideraciones, como las siguientes:
- Administración
- Seguridad
- Viabilidad general
- Costo
- Los posibles cargos de transferencia de datos salientes de más de un proveedor de servicios en la nube podrían ser costosos con una 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, una opción puede ser usar un segundo proveedor de servicios en la nube que también esté en tu país como DR. El uso de un segundo proveedor de servicios en la nube supone que no hay opción para usar un entorno local para crear una configuración híbrida. Para evitar tener que volver a crear la arquitectura de 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 lograr deben guiar tu arquitectura de DR y la planificación de la compilación.
- 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 viabilidad de volver a alojar, refactorizar o reestructurar 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: Crear una zona de destino casi siempre es un requisito 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 el diseño y el proceso de DR tengan en cuenta las siguientes preguntas:
- ¿Qué activa una situación de DR? Por ejemplo, una DR puede activarse debido a 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 alineación con el RTO esperado?
- ¿Cómo se vuelve a enrutar el tráfico al entorno de DR después de detectar la falla?
Valida tus respuestas a estas preguntas mediante pruebas.
Pruebas: Prueba y evalúa en detalle la conmutación por error a la DR. Asegúrate de que cumpla con tus expectativas de RPO y RTO. De esta manera, 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, vuelve a realizar las pruebas.
Habilidades del equipo: Uno o más equipos técnicos deben tener las habilidades y la experiencia para compilar, operar y solucionar problemas de la carga de trabajo de producción en el entorno de 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 tiene muchas regiones en todo el mundo para elegir, puedes usarlas 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 manera redundante en al menos dos regiones geográficas
distintas. Los datos almacenados en buckets de región doble y múltiple se replican en regiones geográficas mediante la replicación predeterminada.
- Los buckets birregionales proporcionan redundancia geográfica para respaldar la continuidad de la actividad y los planes de 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.
- De manera similar, 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 crear una DR:
- Las instancias de VM detenidas solo generan costos de almacenamiento y son mucho más baratas que las instancias de VM en ejecución. Esto significa que puedes minimizar el costo de mantenimiento de los sistemas de espera en frío.
- El modelo de pago por uso de Google Cloud significa que solo paga por la capacidad de almacenamiento y procesamiento que realmente usa.
- Las capacidades de elasticidad, como el ajuste de escala automático, te permiten escalar o reducir automáticamente tu entorno de DR según sea necesario.
Por ejemplo, en el siguiente diagrama, se muestra una aplicación que se ejecuta en un entorno local (producción) que usa componentes de recuperación en Google 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 de Google Cloud , como Cloud SQL, para una recuperación más rápida con replicación de datos continua. Puedes lanzar VMs de Compute Engine desde 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 esté operativa en la nube, debes aprovisionar las VMs web y de la aplicación. Según el nivel de RTO objetivo y las políticas de la empresa, el proceso completo para invocar una 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 administrar la infraestructura como código. Puedes usar Cloud Build, que es un servicio de integración continua, para aplicar automáticamente los 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 recomendaciones:
- 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 el análisis del impacto comercial y
los objetivos de RPO y RTO identificados:
- 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.
- Define las situaciones de DR aplicables para tus aplicaciones y datos como parte de la estrategia de DR que seleccionaste.
- Considera usar el patrón de traspaso cuando solo crees copias de seguridad de los datos. De lo contrario, el patrón en 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 del cerebro dividido. Si replicas datos de forma bidireccional entre entornos, es posible que te expongas al problema de cerebro dividido. El problema del cerebro dividido ocurre cuando dos entornos que replican datos de forma bidireccional pierden la comunicación entre sí. Esta división puede hacer que los sistemas de ambos entornos concluyan que el otro entorno no está disponible y que tienen acceso exclusivo a los datos. Esto puede generar modificaciones de datos en conflicto. Existen dos formas comunes de evitar el problema del 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 de SQL, puedes evitar el problema del 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 la base 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 (siempre que las aplicaciones las admitan y sea factible) para que los sistemas permanezcan coherentes en todos los entornos. Para lograr este enfoque, considera los contenedores y Kubernetes. Si usas la edición Enterprise de 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 tu 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 resiliencia 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 algunas situaciones que se producen cuando se usa este patrón de arquitectura. Las solicitudes de clientes internas o externas 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.
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 datos, las réplicas y otras tareas que cumplan con tus requisitos, incluidos tus objetivos de RPO y RTO.
Prueba y evalúa las situaciones de invocación de DR para comprender con qué facilidad la aplicación puede recuperarse de un evento de desastre en comparación con el valor de 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.