Como se describe en Disponibilidad de la plataforma, la infraestructura deGoogle Cloud se ha diseñado para admitir una disponibilidad objetivo del 99,9% para una carga de trabajo que se haya desplegado en una sola zona. La disponibilidad objetivo es del 99,99% para un despliegue multizona1 y del 99,999% para un despliegue multirregional. En esta parte de la Google Cloud guía de fiabilidad de la infraestructura se ofrecen directrices de implementación, arquitecturas de ejemplo y técnicas de diseño que pueden ayudarte a proteger tus cargas de trabajo frente a fallos a nivel de recurso, zona y región.
Evitar puntos únicos de fallo
Las aplicaciones suelen estar compuestas por varios componentes interdependientes, cada uno de ellos diseñado para realizar una función específica. Estos componentes suelen agruparse en niveles en función de la función que desempeñan y de su relación con los demás componentes. Por ejemplo, una aplicación de servicio de contenido puede tener tres niveles: un nivel web que contiene un balanceador de carga y servidores web, un nivel de aplicación con un clúster de servidores de aplicaciones y un nivel de datos para la persistencia. Si algún componente de esta pila de aplicaciones depende de un único recurso de infraestructura, un fallo en ese recurso puede afectar a la disponibilidad de toda la pila. Por ejemplo, si el nivel de aplicación se ejecuta en una sola VM y esta falla, toda la pila no estará disponible. Este componente es un punto único de fallo (SPOF).
Una pila de aplicaciones puede tener más de un SPOF. Considera la pila de aplicaciones multinivel que se muestra en el siguiente diagrama:
Como se muestra en el diagrama anterior, esta arquitectura de ejemplo contiene un único balanceador de carga, dos servidores web, un único servidor de aplicaciones y una única base de datos. El balanceador de carga, el servidor de aplicaciones y la base de datos de este ejemplo son SPOFs. Si falla alguno de estos componentes, las solicitudes de los usuarios a la aplicación no se podrán completar.
Para eliminar los SPOFs de tu pila de aplicaciones, distribuye los recursos en varias ubicaciones y despliega recursos redundantes.
Distribuir recursos y crear redundancia
En función de los requisitos de fiabilidad de tu aplicación, puedes elegir entre las siguientes arquitecturas de implementación:
| Arquitectura | Recomendación de carga de trabajo |
|---|---|
| Multirregional | Cargas de trabajo esenciales para el negocio en las que es fundamental la alta disponibilidad, como las aplicaciones de comercio y de redes sociales. |
| Multizona | Cargas de trabajo que necesitan resistencia frente a las interrupciones de zonas, pero que pueden tolerar cierto tiempo de inactividad provocado por interrupciones de regiones. |
| Zona única | Cargas de trabajo que pueden tolerar el tiempo de inactividad o que se pueden desplegar en otra ubicación cuando sea necesario con un esfuerzo mínimo. |
Costes, latencia y consideraciones operativas
Cuando diseñas una arquitectura distribuida con recursos redundantes, además de los requisitos de disponibilidad de la aplicación, también debes tener en cuenta los efectos en la complejidad operativa, la latencia y el coste.
En una arquitectura distribuida, se aprovisiona y gestiona un mayor número de recursos. El volumen de tráfico de red entre ubicaciones es mayor. También puedes almacenar y replicar más datos. Como resultado, el coste de tus recursos en la nube en una arquitectura distribuida es mayor y el funcionamiento de estas implementaciones implica más complejidad. En el caso de las aplicaciones críticas para la empresa, la ventaja de disponibilidad de una arquitectura distribuida puede compensar el aumento de los costes y la complejidad operativa.
En el caso de las aplicaciones que no son críticas para el negocio, la alta disponibilidad que proporciona una arquitectura distribuida puede no ser esencial. Algunas aplicaciones tienen otros requisitos que son más importantes que la disponibilidad. Por ejemplo, las aplicaciones de computación por lotes requieren conexiones de red de baja latencia y gran ancho de banda entre las máquinas virtuales. Una arquitectura de una sola zona puede ser adecuada para este tipo de aplicaciones y también puede ayudarte a reducir los costes de transferencia de datos.
Arquitecturas de despliegue
En esta sección se presentan las siguientes opciones de arquitectura para crear infraestructura para tus cargas de trabajo en Google Cloud:
- Implementación de una sola zona
- Despliegue multizona
- Despliegue multirregional con balanceo de carga regional
- Despliegue multirregional con balanceo de carga global
Despliegue de una sola zona
En el siguiente diagrama se muestra una arquitectura de aplicación de una sola zona con redundancia en cada nivel para conseguir una mayor disponibilidad de las funciones que realiza cada componente:
Como se muestra en el diagrama anterior, esta arquitectura de ejemplo incluye los siguientes componentes:
- Un balanceador de carga HTTP/S externo regional para recibir solicitudes de los usuarios y responder a ellas.
- Un grupo de instancias gestionado (MIG) zonal como backend del balanceador de carga HTTP/S. El MIG tiene dos VMs de Compute Engine. Cada VM aloja una instancia de un servidor web.
- Un balanceador de carga interno para gestionar la comunicación entre el servidor web y las instancias del servidor de aplicaciones.
- Un segundo MIG zonal como backend del balanceador de carga interno. Este MIG contiene dos VMs de Compute Engine. Cada VM aloja una instancia de un servidor de aplicaciones.
- Una instancia de base de datos de Cloud SQL (edición Enterprise) en la que la aplicación escribe y lee datos. La base de datos se replica manualmente en una segunda instancia de base de datos de Cloud SQL en la misma zona.
Disponibilidad agregada: implementación en una sola zona
En la siguiente tabla se muestra la disponibilidad de cada nivel en el diagrama de arquitectura de una sola zona anterior:
| Recurso | Acuerdo de nivel de servicio |
|---|---|
| Balanceador de carga externo | 99,99 % |
| Nivel web: máquinas virtuales de Compute Engine en una sola zona | 99,9 % |
| Balanceador de carga interno | 99,99 % |
| Nivel de aplicación: máquinas virtuales de Compute Engine en una sola zona | 99,9 % |
| Instancia de Cloud SQL (edición Enterprise) | 99,95 % |
Los Google Cloud recursos de infraestructura que se indican en la tabla anterior proporcionan la siguiente disponibilidad agregada y el tiempo de inactividad mensual máximo estimado:
- Disponibilidad agregada: 0,9999 × 0,999 × 0,9999 × 0,999 × 0,9995 = 99,73%
- Tiempo de inactividad mensual máximo estimado: aproximadamente 1 hora y 57 minutos
Este cálculo solo tiene en cuenta los recursos de infraestructura que se muestran en el diagrama de arquitectura anterior. Para evaluar la disponibilidad de una aplicación en Google Cloud, también debes tener en cuenta otros factores, como los siguientes:
- El diseño interno de la aplicación
- Los procesos y las herramientas de DevOps que se usan para compilar, desplegar y mantener la aplicación, sus dependencias y la Google Cloud infraestructura
Para obtener más información, consulta Factores que afectan a la fiabilidad de las aplicaciones.
Efectos de las interrupciones y directrices para la recuperación
En una arquitectura de implementación de una sola zona, si falla algún componente, la aplicación puede procesar solicitudes si cada nivel contiene al menos un componente que funcione con la capacidad adecuada. Por ejemplo, si falla una instancia de servidor web, el balanceador de carga reenvía las solicitudes de los usuarios a las otras instancias de servidor web. Si falla una VM que aloja una instancia de servidor web o de servidor de aplicaciones, el MIG se asegura de que se cree una nueva VM automáticamente. Si la base de datos falla, debes activar manualmente la segunda base de datos y actualizar las instancias del servidor de aplicaciones para que se conecten a la base de datos.
Una interrupción de una zona o una región afecta a las máquinas virtuales de Compute Engine y a las instancias de base de datos de Cloud SQL en una implementación de una sola zona. Una interrupción de la zona no afecta al balanceador de carga de esta arquitectura porque es un recurso regional. Sin embargo, el balanceador de carga no puede distribuir el tráfico porque no hay back-ends disponibles. Si se produce una interrupción en una zona, debes esperar a que Google la resuelva y, a continuación, verificar que la aplicación funciona correctamente.
En la siguiente sección se describe un enfoque de arquitectura que puedes usar para distribuir recursos en varias zonas, lo que ayuda a mejorar la resiliencia de la aplicación ante interrupciones de zonas.
Despliegue multizona
En una implementación de una sola zona, si se produce una interrupción en una zona, es posible que la aplicación no pueda atender solicitudes hasta que se resuelva el problema. Para mejorar la resiliencia de tu aplicación frente a las interrupciones de las zonas, puedes aprovisionar varias instancias de recursos zonales (como máquinas virtuales de Compute Engine) en dos o más zonas. En el caso de los servicios que admiten recursos con ámbito regional (como los segmentos de Cloud Storage), puedes desplegar recursos regionales.
En el siguiente diagrama se muestra una arquitectura entre zonas de alta disponibilidad, con los componentes de cada nivel de la pila de aplicaciones distribuidos en dos zonas:
Como se muestra en el diagrama anterior, esta arquitectura de ejemplo incluye los siguientes componentes:
- Un balanceador de carga HTTP/S externo regional recibe solicitudes de los usuarios y responde a ellas.
- Un MIG regional es el backend del balanceador de carga HTTP/S. El MIG contiene dos VMs de Compute Engine en zonas diferentes. Cada VM aloja una instancia de un servidor web.
- Un balanceador de carga interno gestiona la comunicación entre el servidor web y las instancias del servidor de aplicaciones.
- Un segundo MIG regional es el backend del balanceador de carga TCP. Este MIG tiene dos VMs de Compute Engine en zonas diferentes. Cada VM aloja una instancia de un servidor de aplicaciones.
- Una instancia de Cloud SQL (edición Enterprise) configurada para alta disponibilidad es la base de datos de la aplicación. La instancia de base de datos principal se replica de forma síncrona en una instancia de base de datos de reserva.
Disponibilidad agregada: despliegue multizona
En la siguiente tabla se muestra la disponibilidad de cada nivel en el diagrama de arquitectura de dos zonas anterior:
| Recurso | Acuerdo de nivel de servicio |
|---|---|
| Balanceador de carga externo | 99,99 % |
| Nivel web: máquinas virtuales de Compute Engine en zonas independientes | 99,99 % |
| Balanceador de carga interno | 99,99 % |
| Nivel de aplicación: máquinas virtuales de Compute Engine en zonas independientes | 99,99 % |
| Instancia de Cloud SQL (edición Enterprise) | 99,95 % |
Los Google Cloud recursos de infraestructura que se indican en la tabla anterior proporcionan la siguiente disponibilidad agregada y el tiempo de inactividad mensual máximo estimado:
- Disponibilidad agregada: 0,9999 × 0,9999 × 0,9999 × 0,9999 × 0,9995 = 99,91%
- Tiempo de inactividad mensual máximo estimado: aproximadamente 39 minutos
Este cálculo solo tiene en cuenta los recursos de infraestructura que se muestran en el diagrama de arquitectura anterior. Para evaluar la disponibilidad de una aplicación en Google Cloud, también debes tener en cuenta otros factores, como los siguientes:
- El diseño interno de la aplicación
- Los procesos y las herramientas de DevOps que se usan para compilar, desplegar y mantener la aplicación, sus dependencias y la Google Cloud infraestructura
Para obtener más información, consulta Factores que afectan a la fiabilidad de las aplicaciones.
Efectos de las interrupciones y directrices para la recuperación
En una implementación de doble zona, si falla algún componente, la aplicación puede procesar solicitudes si hay al menos un componente que funcione con la capacidad adecuada en cada nivel. Por ejemplo, si falla una instancia de servidor web, el balanceador de carga reenvía las solicitudes de los usuarios a la instancia de servidor web de la otra zona. Si falla una VM que aloja una instancia de servidor web o de servidor de aplicaciones, el MIG se asegura de que se cree una nueva VM automáticamente. Si la base de datos principal de Cloud SQL falla, Cloud SQL cambia automáticamente a la instancia de base de datos de reserva.
En el siguiente diagrama se muestra la misma arquitectura que en el anterior y los efectos de una interrupción de la zona en la disponibilidad de la aplicación:
Como se muestra en el diagrama anterior, si se produce una interrupción en una de las zonas, el balanceador de carga de esta arquitectura no se verá afectado, ya que es un recurso regional. Una interrupción de la zona puede afectar a máquinas virtuales de Compute Engine concretas y a una de las instancias de base de datos de Cloud SQL. Sin embargo, la aplicación sigue disponible y responde, ya que las VMs están en MIGs regionales y la base de datos de Cloud SQL está configurada para alta disponibilidad. Los grupos de instancias gestionados se encargan de crear automáticamente nuevas máquinas virtuales para mantener el número mínimo configurado. Si la instancia de base de datos principal de Cloud SQL se ve afectada por una interrupción de la zona, Cloud SQL conmuta por error automáticamente a la instancia de espera de la otra zona. Una vez que Google haya resuelto la interrupción, debes verificar que la aplicación funciona correctamente en todas las zonas en las que se haya implementado.
Si se produce una interrupción en ambas zonas de esta arquitectura, la aplicación no estará disponible. El balanceador de carga seguirá estando disponible a menos que se produzca un corte en toda la región. Sin embargo, el balanceador de carga no puede distribuir el tráfico porque no hay back-ends disponibles. Si se produce una interrupción en varias zonas o en una región, debes esperar a que Google la resuelva y, a continuación, verificar que la aplicación funciona correctamente.
En las siguientes secciones se presentan opciones de arquitectura para proteger tu aplicación frente a interrupciones multizonales y regionales.
Despliegue multirregional con balanceo de carga regional
En una implementación de una o varias zonas, si se produce una interrupción en una región, la aplicación no puede atender solicitudes hasta que se resuelva el problema. Para proteger tu aplicación frente a las interrupciones de la región, puedes distribuir los recursos de Google Clouden dos o más regiones.
En el siguiente diagrama se muestra una arquitectura entre regiones de alta disponibilidad, con los componentes de cada nivel de la pila de aplicaciones distribuidos en varias regiones:
Como se muestra en el diagrama anterior, esta arquitectura de ejemplo incluye los siguientes componentes:
- Una zona pública de Cloud DNS con una política de enrutamiento que dirige el tráfico a dos regiones Google Cloud .
- Un balanceador de carga HTTP/S externo regional en cada región para recibir y responder a las solicitudes de los usuarios.
- El backend de cada balanceador de carga HTTP/S regional es un MIG regional. Cada MIG contiene dos VMs de Compute Engine en zonas diferentes. Cada una de estas máquinas virtuales aloja una instancia de un servidor web.
- Un balanceador de carga interno de cada región gestiona la comunicación entre las instancias del servidor web y las instancias del servidor de aplicaciones.
- Un segundo par de MIGs regionales es el backend de los balanceadores de carga internos. Cada uno de estos MIGs contiene dos VMs de Compute Engine en zonas diferentes. Cada VM aloja una instancia de un servidor de aplicaciones.
- La aplicación escribe datos en una instancia de Spanner multirregional y los lee de ella. La configuración multirregional que se usa en esta arquitectura (
eur5) incluye cuatro réplicas de lectura y escritura. Las réplicas de lectura y escritura se aprovisionan por igual en dos regiones y en zonas independientes. La configuración multirregional de Spanner también incluye una réplica testigo en una tercera región.
Disponibilidad agregada: despliegue multirregional con balanceo de carga regional
En el despliegue multirregional que se muestra en el diagrama anterior, los balanceadores de carga y las VMs se aprovisionan de forma redundante en dos regiones. La zona DNS es un recurso global y la instancia de Spanner es un recurso multirregional.
Para calcular la disponibilidad agregada de la infraestructura de Google Cloudque se muestra en esta arquitectura, primero debemos calcular la disponibilidad agregada de los recursos de cada región y, después, tener en cuenta los recursos que abarcan varias regiones. Sigue este proceso:
- Calcula la disponibilidad agregada de los recursos de infraestructura por región, es decir, sin incluir los recursos de DNS y de base de datos:
Recursos y SLA Acuerdo de nivel de servicio Balanceador de carga externo 99,99 % Nivel web: máquinas virtuales de Compute Engine en zonas independientes 99,99 % Balanceador de carga interno 99,99 % Nivel de aplicación: máquinas virtuales de Compute Engine en zonas independientes 99,99 % Disponibilidad agregada por región: 0,9999 × 0,9999 × 0,9999 × 0,9999 = 99,96%
Calcula la disponibilidad agregada de los recursos de infraestructura teniendo en cuenta la redundancia birregional de los balanceadores de carga y las máquinas virtuales de Compute Engine.
La disponibilidad teórica es 1-(1-0,9996)(1-0,9996) = 99,999984%. Sin embargo, la disponibilidad real que puedes esperar está limitada a la disponibilidad objetivo de los despliegues multirregionales, que es del 99,999%.
Calcula la disponibilidad agregada de todos los recursos de infraestructura, incluidos los recursos de Cloud DNS y Spanner:
- Disponibilidad agregada: 0,99999 × 1 × 0,99999 = 99,998%
- Tiempo de inactividad mensual máximo estimado: aproximadamente 52 segundos
Este cálculo solo tiene en cuenta los recursos de infraestructura que se muestran en el diagrama de arquitectura anterior. Para evaluar la disponibilidad de una aplicación en Google Cloud, también debes tener en cuenta otros factores, como los siguientes:
- El diseño interno de la aplicación
- Los procesos y las herramientas de DevOps que se usan para compilar, desplegar y mantener la aplicación, sus dependencias y la Google Cloud infraestructura
Para obtener más información, consulta Factores que afectan a la fiabilidad de las aplicaciones.
Efectos de las interrupciones y directrices para la recuperación
Si falla algún componente de esta implementación multirregión, pero hay al menos un componente que funciona con capacidad suficiente en cada nivel, la aplicación seguirá funcionando. Por ejemplo, si falla una instancia de servidor web, el balanceador de carga HTTP/S externo regional reenvía las solicitudes de los usuarios a las otras instancias de servidor web de la región. Del mismo modo, si falla una de las instancias del servidor de aplicaciones, los balanceadores de carga internos envían solicitudes a las otras instancias del servidor de aplicaciones. Si alguna de las VMs falla, los MIGs se aseguran de que se creen automáticamente VMs nuevas para mantener el número mínimo de VMs configurado.
Una interrupción en una sola zona no afecta a los balanceadores de carga, ya que son recursos regionales y pueden resistir las interrupciones de zona. Una interrupción de la zona puede afectar a máquinas virtuales de Compute Engine concretas. Sin embargo, las instancias del servidor web y del servidor de aplicaciones siguen disponibles, ya que las VMs forman parte de MIGs regionales. Los grupos de instancias gestionados se aseguran de que se creen máquinas virtuales automáticamente para mantener el número mínimo configurado de máquinas virtuales. La instancia de Spanner de esta arquitectura usa una configuración multirregional, que es resistente a las interrupciones de zonas.
Para obtener información sobre cómo funciona la réplica multirregional en Spanner, consulta Configuraciones regionales y multirregionales y Desmitificando las configuraciones multirregionales de Spanner.
En el siguiente diagrama, se muestra la misma arquitectura multirregional que en el diagrama anterior y los efectos de una interrupción en una sola región en la disponibilidad de la aplicación:
Como se muestra en el diagrama anterior, aunque se produzca una interrupción en ambas zonas de cualquier región, la aplicación seguirá estando disponible, ya que se ha desplegado una pila de aplicaciones independiente en cada región. La zona DNS dirige las solicitudes de los usuarios a la región que no se ve afectada por la interrupción. La instancia de Spanner multirregional es resistente a las interrupciones de la región. Una vez que Google haya resuelto la interrupción, debes verificar que la aplicación funciona correctamente en la región en la que se ha producido.
Si se produce una interrupción en dos de las regiones de esta arquitectura, la aplicación no estará disponible. Espera a que Google resuelva las interrupciones. A continuación, comprueba que la aplicación funciona correctamente en todas las regiones en las que se ha implementado.
En los despliegues multirregionales, en lugar de usar balanceadores de carga regionales, puedes usar un balanceador de carga mundial. En la siguiente sección se presenta una arquitectura de implementación multirregional que usa un balanceador de carga mundial y se describen las ventajas y los riesgos de este enfoque.
Despliegue multirregional con balanceo de carga global
En el siguiente diagrama se muestra una implementación multirregional alternativa que usa un balanceador de carga global en lugar de balanceadores de carga regionales:
Como se muestra en el diagrama anterior, esta arquitectura usa un balanceador de carga HTTP(S) externo global (con Cloud CDN habilitado) para recibir y responder a las solicitudes de los usuarios. Cada regla de reenvío del balanceador de carga usa una única dirección IP externa, por lo que no es necesario configurar un registro DNS independiente para cada región. Los backends del balanceador de carga HTTP/S global externo son dos MIGs regionales. El balanceador de carga enruta las solicitudes a la región más cercana a los usuarios.
Todos los demás componentes de esta arquitectura son idénticos a los de la arquitectura que se muestra en Despliegue multirregional con balanceo de carga regional.
Ventajas y riesgos del balanceo de carga global en despliegues multirregionales
Para balancear la carga del tráfico externo a una aplicación distribuida en varias regiones, puedes usar un balanceador de carga global o varios balanceadores de carga regionales.
Estas son las ventajas de una arquitectura que usa un balanceador de carga mundial:
- Solo tiene que gestionar un balanceador de carga.
- Los balanceadores de carga globales usan una sola dirección IP anycast para proporcionar balanceo de carga en varias Google Cloud regiones.
- Los balanceadores de carga globales son resistentes a las interrupciones de las regiones y proporcionan una conmutación por error multirregional automática.
- Los balanceadores de carga globales admiten las siguientes funciones, que pueden ayudarte a mejorar la fiabilidad de tus implementaciones:
- Almacenamiento en caché perimetral con Cloud CDN
- Posibilidad de usar segmentos de Cloud Storage de alta durabilidad como backends
- Políticas de seguridad de Google Cloud Armor
Estos son los riesgos de una arquitectura que usa un balanceador de carga global:
- Si se cambia de forma incorrecta la configuración del balanceador de carga global, es posible que los usuarios no puedan acceder a la aplicación. Por ejemplo, si eliminas por error una regla de reenvío al actualizar el frontend del balanceador de carga global, este dejará de recibir solicitudes de los usuarios. El efecto de este riesgo es menor en el caso de una arquitectura multirregional que utiliza balanceadores de carga regionales, ya que, aunque el balanceador de carga regional de una de las regiones se vea afectado por un error de configuración, los balanceadores de carga de las otras regiones seguirán funcionando.
- Si se produce una interrupción de la infraestructura que afecte a los recursos globales, es posible que el balanceador de carga global no esté disponible.
Para mitigar estos riesgos, debe gestionar los cambios en el balanceador de carga global con cuidado y plantearse usar alternativas de defensa en profundidad siempre que sea posible. Para obtener más información, consulta las recomendaciones para gestionar el riesgo de interrupciones de recursos globales.
Disponibilidad agregada: implementación multirregional con balanceo de carga global
En la implementación multirregional que se muestra en el diagrama anterior, las VMs y los balanceadores de carga internos se distribuyen de forma redundante en dos regiones. El balanceador de carga externo es un recurso global y la instancia de Spanner es un recurso multirregional.
Para calcular la disponibilidad agregada de este despliegue, primero calculamos la disponibilidad agregada de los recursos de cada región y, después, tenemos en cuenta los recursos que abarcan varias regiones.
- Calcula la disponibilidad agregada de los recursos de infraestructura por región, sin incluir el balanceador de carga externo ni la base de datos:
Recurso Acuerdo de nivel de servicio Nivel web: máquinas virtuales de Compute Engine en zonas independientes 99,99 % Balanceador de carga interno 99,99 % Nivel de aplicación: máquinas virtuales de Compute Engine en zonas independientes 99,99 % Disponibilidad agregada por región: 0,9999 × 0,9999 × 0,9999 = 99,97%
Calcula la disponibilidad agregada de los recursos de infraestructura teniendo en cuenta la redundancia birregional del balanceador de carga interno y las VMs de Compute Engine.
La disponibilidad teórica es 1-(1-0,9997)(1-0,9997) = 99,999991%. Sin embargo, la disponibilidad real que puedes esperar se limita a la disponibilidad objetivo de los despliegues multirregionales, que es del 99,999%.
Calcula la disponibilidad agregada de todos los recursos de infraestructura, incluidos el balanceador de carga global y los recursos de Spanner:
- Disponibilidad agregada: 0,99999 × 0,9999 × 0,99999 = 99,988%
- Tiempo de inactividad mensual máximo estimado: aproximadamente 5 minutos y 11 segundos
Este cálculo solo tiene en cuenta los recursos de infraestructura que se muestran en el diagrama de arquitectura anterior. Para evaluar la disponibilidad de una aplicación en Google Cloud, también debes tener en cuenta otros factores, como los siguientes:
- El diseño interno de la aplicación
- Los procesos y las herramientas de DevOps que se usan para compilar, desplegar y mantener la aplicación, sus dependencias y la Google Cloud infraestructura
Para obtener más información, consulta Factores que afectan a la fiabilidad de las aplicaciones.
Efectos de las interrupciones y directrices para la recuperación
Si falla algún componente de esta arquitectura, la aplicación seguirá funcionando si hay al menos un componente que funcione correctamente y tenga capacidad suficiente en cada nivel. Por ejemplo, si falla una instancia de servidor web, el balanceador de carga HTTP/HTTPS externo global reenvía las solicitudes de los usuarios a las otras instancias de servidor web. Si falla una instancia del servidor de aplicaciones, los balanceadores de carga internos envían las solicitudes a las otras instancias del servidor de aplicaciones. Si alguna de las VMs falla, los MIGs se aseguran de que se creen automáticamente VMs nuevas para mantener el número mínimo de VMs configurado.
Si se produce una interrupción en una de las zonas de cualquier región, el balanceador de carga no se verá afectado. El balanceador de carga HTTP/S externo global es resistente a las interrupciones de zonas y regiones. Los balanceadores de carga internos son recursos regionales, por lo que son resistentes a las interrupciones de las zonas. Una interrupción de una zona puede afectar a máquinas virtuales de Compute Engine concretas. Sin embargo, las instancias del servidor web y del servidor de aplicaciones siguen disponibles porque las VMs forman parte de grupos de instancias gestionados regionales. Los grupos de instancias gestionados se encargan de que se creen automáticamente nuevas VMs para mantener el número mínimo de VMs configurado. La instancia de Spanner de esta arquitectura usa una configuración multirregional, que es resistente a las interrupciones de zonas.
En el siguiente diagrama, se muestra la misma arquitectura multirregional que en el diagrama anterior y los efectos de una interrupción en una sola región en la disponibilidad de la aplicación:
Como se muestra en el diagrama anterior, aunque se produzca una interrupción en ambas zonas de cualquier región, la aplicación seguirá estando disponible, ya que se ha desplegado una pila de aplicaciones independiente en cada región. El balanceador de carga HTTP/S mundial externo dirige las solicitudes de los usuarios a la aplicación de la región que no se vea afectada por la interrupción. La instancia de Spanner multirregional es resistente a las interrupciones de la región. Una vez que Google haya resuelto la interrupción, debes verificar que la aplicación se ejecuta correctamente en la región en la que se ha producido.
Para obtener información sobre cómo funciona la réplica multirregional en Spanner, consulta Configuraciones regionales y multirregionales y Desmitificando las configuraciones multirregionales de Spanner.
Si se produce una interrupción en dos de las regiones de esta arquitectura, la aplicación no estará disponible. El balanceador de carga HTTP/S global externo está disponible, pero no puede distribuir el tráfico porque no hay back-ends disponibles. Espera a que Google resuelva las interrupciones. A continuación, comprueba que la aplicación funciona correctamente en todas las regiones en las que se ha implementado.
Las implementaciones multirregionales pueden ayudar a garantizar la alta disponibilidad de tus aplicaciones empresariales más importantes. Para asegurar la continuidad del negocio durante los fallos, además de desplegar la aplicación en varias regiones, debes seguir ciertos pasos adicionales. Por ejemplo, debes llevar a cabo una planificación de la capacidad para asegurarte de que se reserva suficiente capacidad en todas las regiones o de que los riesgos asociados al autoescalado de emergencia son aceptables. También debes implementar prácticas operativas para las pruebas de recuperación ante desastres, gestionar incidentes, verificar el estado de las aplicaciones después de los incidentes y realizar retrospectivas.
-
Para obtener más información sobre las consideraciones específicas de cada región, consulta el artículo sobre geografía y regiones. ↩