Como se describe en Disponibilidad de la plataforma, la infraestructura de Google Cloud está diseñada para admitir una disponibilidad objetivo del 99.9% en una carga de trabajo que se implementa en una sola zona. La disponibilidad objetivo es del 99.99% en una implementación multizona1 y del 99.999% en una implementación multirregional. En esta parte de la guía de confiabilidad de infraestructura de Google Cloud, se proporciona orientación de implementación, arquitecturas de ejemplo y técnicas de diseño que pueden ayudarte a proteger tus cargas de trabajo contra fallas en el recurso, la zona y el nivel de la región.
Evite los puntos únicos de fallo
Por lo general, las aplicaciones constan de varios componentes interdependientes, cada uno diseñado para realizar una función específica. Por lo general, estos componentes se agrupan en niveles según la función que realizan y su relación con los otros componentes. Por ejemplo, una aplicación de entrega de contenido puede tener tres niveles: un nivel web que contiene un balanceador de cargas y servidores web, un nivel de la app 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 solo recurso de infraestructura, una falla de ese recurso puede afectar la disponibilidad de toda la pila. Por ejemplo, si el nivel de la app se ejecuta en una sola VM y esta falla, toda la pila dejará de 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 de varios niveles que se muestra en el siguiente diagrama:
Como se muestra en el diagrama anterior, esta arquitectura de ejemplo contiene un solo balanceador de cargas, dos servidores web, un solo servidor de aplicaciones y una sola base de datos. El balanceador de cargas, el servidor de apps y la base de datos en este ejemplo son SPOFs. Una falla de cualquiera de estos componentes puede hacer que las solicitudes de los usuarios a la aplicación fallen.
Para quitar los SPOFs de tu pila de aplicaciones, distribuye recursos en ubicaciones e implementa recursos redundantes.
Distribuye recursos y crea redundancia
Según los requisitos de confiabilidad de tu aplicación, puedes elegir entre las siguientes arquitecturas de implementación:
| Arquitectura | Recomendación de carga de trabajo |
|---|---|
| Multirregión | Cargas de trabajo fundamentales para la empresa y en las que la alta disponibilidad es esencial, como las aplicaciones de venta minorista y redes sociales. |
| Varias zonas | Cargas de trabajo que necesitan resiliencia contra interrupciones zonales, pero pueden tolerar cierto tiempo de inactividad causado por interrupciones regionales. |
| Zona única | Cargas de trabajo que pueden tolerar tiempo de inactividad o que se pueden implementar en otra ubicación cuando sea necesario con un esfuerzo mínimo. |
Consideraciones operacionales, de costos y latencia
Cuando diseñas una arquitectura distribuida con recursos redundantes, además de los requisitos de disponibilidad de la aplicación, también debes considerar los efectos en la complejidad operativa, la latencia y el costo.
En una arquitectura distribuida, aprovisionas y administras una mayor cantidad de recursos. El volumen de tráfico de red entre ubicaciones es mayor. También almacenas y replicas más datos. Como resultado, el costo de los recursos de nube en una arquitectura distribuida es mayor, y operar esas implementaciones implica más complejidad. En el caso de las aplicaciones fundamentales para la empresa, la ventaja de tener una arquitectura distribuida podría superar el aumento de los costos y la complejidad operativa.
En el caso de las aplicaciones que no son fundamentales para la empresa, 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 latencia baja y ancho de banda alto entre las VM. Una arquitectura de zona única podría ser adecuada para esas aplicaciones y también puede ayudarte a reducir los costos de transferencia de datos.
Arquitecturas de implementación
En esta sección, se presentan las siguientes opciones de arquitectura a fin de compilar la infraestructura para las cargas de trabajo en Google Cloud:
- Implementación de una sola zona
- Implementación en varias zonas
- Implementación multirregional con balanceo de cargas regional
- Implementación multirregional con balanceo de cargas global
Implementación 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 lograr 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 cargas de HTTP/S regional externo para recibir y responder las solicitudes de los usuarios.
- Un grupo de instancias administrado zonal (MIG) como backend para el balanceador de cargas HTTP/S. El MIG tiene dos VMs de Compute Engine. Cada VM aloja una instancia de un servidor web.
- Un balanceador de cargas interno para controlar la comunicación entre el servidor web y las instancias del servidor de aplicaciones.
- Un segundo MIG zonal como backend para el balanceador de cargas interno. Este MIG contiene dos VMs de Compute Engine. Cada VM aloja una instancia de un servidor de apps.
- Una instancia de base de datos de Cloud SQL (edición Enterprise) en la que la aplicación escribe datos y se los lee. La base de datos se replica de forma manual en una segunda instancia de base de datos de Cloud SQL en la misma zona.
Disponibilidad total: Implementación de 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 | ANS |
|---|---|
| Balanceador de cargas externo | 99.99% |
| Nivel web: VMs de Compute Engine en una sola zona | 99.9% |
| Balanceador de cargas interno | 99.99% |
| Nivel de la aplicación: VMs de Compute Engine en una sola zona | 99.9% |
| Instancia de Cloud SQL (edición Enterprise) | 99.95% |
Puedes esperar que los recursos de la infraestructura de Google Cloud que se enumeran en la tabla anterior proporcionen la siguiente disponibilidad agregada y el tiempo de inactividad mensual máximo estimado:
- Disponibilidad total: 0.9999 x 0.999 x 0.9999 x 0.999 x 0.9995 = 99.73%
- Tiempo de inactividad mensual estimado: alrededor de 1 hora y 57 minutos
Este cálculo solo considera 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 herramientas de DevOps que se usan para compilar, implementar y mantener la aplicación, sus dependencias y la infraestructura de Google Cloud
Para obtener más información, consulta Factores que afectan la confiabilidad de las aplicaciones.
Efectos de las interrupciones y orientación 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 en funcionamiento con la capacidad adecuada. Por ejemplo, si una instancia del servidor web falla, el balanceador de cargas reenvía las solicitudes del usuario a las otras instancias del servidor web. Si una VM que aloja un servidor web o una instancia del servidor de apps falla, el MIG garantiza que se cree una VM nueva de forma automática. Si la base de datos falla, debes activar la segunda base de datos de forma manual y actualizar las instancias del servidor de aplicaciones para que se conecten con la base de datos.
Una interrupción zonal o regional afecta a las VM de Compute Engine y a las instancias de bases de datos de Cloud SQL en una implementación de zona única. Una interrupción zonal no afecta el balanceador de cargas en esta arquitectura porque es un recurso regional. Sin embargo, el balanceador de cargas no puede distribuir el tráfico porque no hay backends disponibles. Si se produce una interrupción zonal, debes esperar a que Google resuelva la interrupción y, luego, verificar que la aplicación funcione como se espera.
En la siguiente sección, se describe un enfoque arquitectónico que puedes usar para distribuir recursos en varias zonas, lo que ayuda a mejorar la resiliencia de la aplicación a las interrupciones zonales.
Implementación en varias zonas
En una implementación de una sola zona, si se produce una interrupción zonal, es posible que la aplicación no pueda entregar solicitudes hasta que se resuelva el problema. Para ayudar a mejorar la resiliencia de tu aplicación contra las interrupciones zonales, puedes aprovisionar varias instancias de recursos zonales (como las VMs de Compute Engine) en dos o más zonas. En el caso de los servicios que admiten recursos a nivel de región (como los buckets de Cloud Storage), puedes implementar recursos regionales.
En el siguiente diagrama, se muestra una arquitectura de varias zonas con 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 cargas de HTTP/S regional externo recibe y responde las solicitudes de los usuarios.
- Un MIG regional es el backend del balanceador de cargas de HTTP/S. El MIG contiene dos VMs de Compute Engine en diferentes zonas. Cada VM aloja una instancia de un servidor web.
- Un balanceador de cargas interno controla la comunicación entre el servidor web y las instancias del servidor de apps.
- Un segundo MIG regional es el backend del balanceador de cargas TCP. Este MIG tiene dos VMs de Compute Engine en diferentes zonas. Cada VM aloja una instancia de un servidor de apps.
- Una instancia de Cloud SQL (edición Enterprise) configurada para HA 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 en espera.
Disponibilidad total: Implementación multizona
En la siguiente tabla, se muestra la disponibilidad de cada nivel en el diagrama de arquitectura de zona doble anterior:
| Recurso | ANS |
|---|---|
| Balanceador de cargas externo | 99.99% |
| Nivel web: VMs de Compute Engine en zonas separadas | 99.99% |
| Balanceador de cargas interno | 99.99% |
| Nivel de la aplicación: VMs de Compute Engine en zonas diferentes | 99.99% |
| Instancia de Cloud SQL (edición Enterprise) | 99.95% |
Puedes esperar que los recursos de infraestructura de Google Cloud que se enumeran en la tabla anterior proporcionen la siguiente disponibilidad agregada y tiempo de inactividad mensual máximo estimado:
- Disponibilidad total: 0.9999 x 0.9999 x 0.9999 x 0.9999 x 0.9995 = 99.91%
- Tiempo de inactividad mensual estimado: 39 minutos
Este cálculo solo considera 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 herramientas de DevOps que se usan para compilar, implementar y mantener la aplicación, sus dependencias y la infraestructura de Google Cloud
Para obtener más información, consulta Factores que afectan la confiabilidad de las aplicaciones.
Efectos de las interrupciones y orientación para la recuperación
En una implementación de doble zona, si falla algún componente, la aplicación puede procesar solicitudes si existe al menos un componente en funcionamiento con capacidad adecuada en cada nivel. Por ejemplo, si una instancia del servidor web falla, el balanceador de cargas reenvía las solicitudes del usuario a la instancia del servidor web en la otra zona. Si una VM que aloja un servidor web o una instancia del servidor de apps falla, el MIG garantiza que se cree una VM nueva de forma automática. Si la base de datos principal de Cloud SQL falla, Cloud SQL realiza una conmutación por error automática a la instancia de base de datos en espera.
En el siguiente diagrama, se muestra la misma arquitectura que el diagrama anterior y los efectos de una interrupción zonal 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 cargas de esta arquitectura no se verá afectado, porque es un recurso regional. Una interrupción zonal puede afectar a las VMs de Compute Engine individuales y a una de las instancias de la base de datos de Cloud SQL. Sin embargo, la aplicación permanece disponible y responsiva, ya que las VMs están en MIGs regionales y la base de datos de Cloud SQL está configurada para la HA. Los MIGs garantizan que las VMs nuevas se creen de forma automática para mantener la cantidad mínima de VMs configurada. Si la instancia de base de datos principal de Cloud SQL se ve afectada por una interrupción zonal, Cloud SQL conmuta por error de forma automática a la instancia en espera en la otra zona. Después de que Google resuelva la interrupción, debes verificar que la aplicación se ejecute como se espera en todas las zonas en las que se implementa.
Nota: Las regiones de México, Montreal y Osaka tienen tres zonas dentro de uno o dos centros de datos físicos. Estas regiones están en proceso de expansión a, al menos, tres centros de datos físicos. Para obtener más información, consulta Ubicaciones de Cloud y ANS de Google Cloud Platform. Para mejorar la confiabilidad de tus cargas de trabajo, considera una implementación multirregional.Si ambas zonas de esta arquitectura tienen una interrupción, la aplicación no estará disponible. El balanceador de cargas seguirá estando disponible, a menos que se produzca una interrupción en toda la región. Sin embargo, el balanceador de cargas no puede distribuir el tráfico porque no hay backends disponibles. Si se produce una interrupción multizona o regional, debes esperar a que Google resuelva la interrupción y, luego, verificar que la aplicación funcione como se espera.
En las siguientes secciones, se presentan opciones de arquitectura para proteger tu aplicación contra interrupciones multizona y interrupciones regionales.
Implementación multirregional con balanceo de cargas regional
En una implementación de una o varias zonas, si se produce una interrupción regional, la aplicación no puede entregar solicitudes hasta que se resuelva el problema. Para proteger tu aplicación contra interrupciones regionales, puedes distribuir los recursos de Google Cloud en dos o más regiones.
En el siguiente diagrama, se muestra una arquitectura entre regiones con 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 de Google Cloud.
- Un balanceador de cargas de HTTP/S regional externo en cada región para recibir y responder las solicitudes de los usuarios.
- El backend de cada balanceador de cargas de HTTP/S regional es un MIG regional. Cada MIG contiene dos VMs de Compute Engine en diferentes zonas. Cada una de estas VMs aloja una instancia de un servidor web.
- Un balanceador de cargas interno en cada región se encarga de la comunicación entre las instancias del servidor web y las instancias del servidor de apps.
- Un segundo par de MIG regionales es el backend de los balanceadores de cargas internos. Cada uno de estos MIG contiene dos VMs de Compute Engine en diferentes zonas. Cada VM aloja una instancia de un servidor de apps.
- La aplicación escribe y lee desde una instancia multirregión de Spanner. 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 de forma equitativa en dos regiones y en zonas separadas. La configuración multirregional de Spanner también incluye una réplica testigo en una tercera región.
Disponibilidad total: Implementación multirregional con balanceo de cargas regional
En la implementación multirregional que se muestra en el diagrama anterior, los balanceadores de cargas 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 Cloud que se muestra en esta arquitectura, primero debemos calcular la disponibilidad total de los recursos en cada región y, luego, considerar los recursos que abarcan varias regiones. Usa el siguiente proceso:
- Calcula la disponibilidad total de los recursos de infraestructura por región, es decir, sin incluir los recursos de DNS y de la base de datos:
Recursos y ANS ANS Balanceador de cargas externo 99.99% Nivel web: VMs de Compute Engine en zonas separadas 99.99% Balanceador de cargas interno 99.99% Nivel de la aplicación: VMs de Compute Engine en zonas diferentes 99.99% Disponibilidad total por región: 0.9999 x 0.9999 x 0.9999 x 0.9999 = 99.96%
Calcula la disponibilidad total de los recursos de infraestructura teniendo en cuenta la redundancia birregional de los balanceadores de cargas y las VMs 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 se limita a la disponibilidad objetivo para implementaciones multirregionales, que es del 99.999%.
Calcula la disponibilidad total de todos los recursos de infraestructura, incluidos los recursos de Cloud DNS y Spanner:
- Disponibilidad total: 0.99999 x 1 x 0.99999 = 99.998%
- Tiempo de inactividad máximo estimado: Aproximadamente 52 segundos
Este cálculo solo considera 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, implementar y mantener la aplicación, sus dependencias y la infraestructura de Google Cloud
Para obtener más información, consulta Factores que afectan la confiabilidad de las aplicaciones.
Efectos de las interrupciones y orientación para la recuperación
Si cualquier componente de esta implementación multirregional falla, pero hay al menos un componente en funcionamiento con la capacidad adecuada en cada nivel, la aplicación continúa funcionando. Por ejemplo, si una instancia del servidor web falla, el balanceador de cargas de HTTP/S externo regional reenvía las solicitudes del usuario a las otras instancias del servidor web en la región. De manera similar, si una de las instancias del servidor de aplicaciones falla, los balanceadores de cargas internos envían solicitudes a las otras instancias del servidor de aplicaciones. Si alguna de las VMs falla, los MIGs garantizan que las VMs nuevas se creen de forma automática para mantener la cantidad mínima de VMs configuradas.
Una interrupción en una sola zona no afecta a los balanceadores de cargas, ya que son recursos regionales y son resilientes a las interrupciones de las zonas. Una interrupción zonal puede afectar a las VM individuales de Compute Engine. Sin embargo, las instancias del servidor web y del servidor de aplicaciones permanecen disponibles, ya que las VMs forman parte de los MIGs regionales. Los MIGs garantizan que las VMs nuevas se creen de forma automática para mantener la cantidad mínima de VMs configuradas. La instancia de Spanner en esta arquitectura usa una configuración multirregional, que es resiliente a las interrupciones zonales.
Para obtener información sobre cómo funciona la replicación multirregional en Spanner, consulta Configuración regional y multirregional y Desmitifica configuraciones multirregionales de Cloud Spanner.
En el siguiente diagrama, se muestra la misma arquitectura multirregional del diagrama anterior y los efectos de una interrupción regional única en la disponibilidad de la aplicación:
Como se muestra en el diagrama anterior, incluso si se produce una interrupción en ambas zonas de cualquier región, la aplicación permanece disponible, ya que se implementa 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 multirregional de Spanner es resiliente a las interrupciones regionales. Una vez que Google resuelve la interrupción, debes verificar que la aplicación se ejecute como se espera en la región que ocurrió la interrupción.
Si dos de las regiones en esta arquitectura tienen interrupciones, la aplicación no estará disponible. Espera a que Google resuelva las interrupciones. Luego, verifica que la aplicación se ejecute como se espera en todas las regiones en las que se implementa.
En el caso de las implementaciones multirregionales, en lugar de usar balanceadores de cargas regionales, puedes considerar usar un balanceador de cargas global. En la siguiente sección, se presenta una arquitectura de implementación multirregional que usa un balanceador de cargas global y se describen los beneficios y riesgos de ese enfoque.
Implementación multirregional con balanceo de cargas global
En el siguiente diagrama, se muestra una implementación multirregional alternativa que usa un balanceador de cargas global en lugar de balanceadores de cargas regionales:
Como se muestra en el diagrama anterior, esta arquitectura usa un balanceador de cargas de 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 cargas usa una única dirección IP externa. No es necesario configurar un registro DNS independiente para cada región. Los backends para el balanceador de cargas de HTTP/S externo global son dos MIG regionales. El balanceador de cargas 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 la arquitectura que se muestra en Implementación multirregional con balanceo de cargas regional.
Beneficios y riesgos del balanceo de cargas global para implementaciones multirregionales
Para balancear las cargas del tráfico externo a una aplicación que se distribuye en varias regiones, puedes usar un balanceador de cargas global o varios balanceadores de cargas regionales.
Los siguientes son los beneficios de una arquitectura que usa un balanceador de cargas global:
- Solo debes administrar un balanceador de cargas único.
- Los balanceadores de cargas globales usan una sola dirección IP Anycast para proporcionar balanceo de cargas en las regiones de Google Cloud.
- Los balanceadores de cargas globales son resilientes a las interrupciones regionales y proporcionan una conmutación por error automática entre regiones.
- Los balanceadores de cargas globales admiten las siguientes funciones, que pueden ayudar a mejorar la confiabilidad de tus implementaciones:
- Almacenamiento en caché perimetral con Cloud CDN
- La capacidad de usar buckets de Cloud Storage con alta durabilidad como backends
- Políticas de seguridad de Google Cloud Armor
Los siguientes son los riesgos de una arquitectura que usa un balanceador de cargas global:
- Un cambio de configuración incorrecto en el balanceador de cargas global podría hacer que la aplicación no esté disponible para los usuarios. Por ejemplo, mientras actualizas el frontend del balanceador de cargas global, si borras una regla de reenvío por accidente, el balanceador de cargas deja de recibir solicitudes de usuarios. El efecto de este riesgo es menor en el caso de una arquitectura multirregional que usa balanceadores de cargas regionales, incluso si el balanceador de cargas regional en una de las regiones se ve afectado por un error de configuración, los balanceadores de cargas de las otras regiones seguirán funcionando.
- Una interrupción global de la infraestructura que afecta a los recursos globales podría provocar que el balanceador de cargas global no esté disponible.
Para mitigar estos riesgos, debes administrar los cambios en el balanceador de cargas global con cuidado y considera usar resguardos en profundidad cuando sea posible. Si quieres obtener más información, consulta Recomendaciones para administrar el riesgo de interrupciones de los recursos globales.
Disponibilidad total: Implementación multirregional con balanceo de cargas global
En la implementación multirregional que se muestra en el diagrama anterior, las VMs y los balanceadores de cargas internos se distribuyen de forma redundante en dos regiones. El balanceador de cargas externo es un recurso global, y la instancia de Spanner es un recurso multirregional.
Para calcular la disponibilidad agregada de esta implementación, primero calculamos la disponibilidad agregada de los recursos en cada región y, luego, consideramos los recursos que abarcan varias regiones.
- Calcula la disponibilidad total de los recursos de infraestructura por región, sin incluir el balanceador de cargas externo ni la base de datos:
Recurso ANS Nivel web: VMs de Compute Engine en zonas separadas 99.99% Balanceador de cargas interno 99.99% Nivel de la aplicación: VMs de Compute Engine en zonas diferentes 99.99% Disponibilidad total por región: 0.9999 x 0.9999 x 0.9999 = 99.97%
Calcula la disponibilidad total de los recursos de infraestructura teniendo en cuenta la redundancia birregional del balanceador de cargas 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 para implementaciones multirregionales, que es del 99.999%.
Calcula la disponibilidad total de todos los recursos de infraestructura, incluidos el balanceador de cargas global y los recursos de Spanner:
- Disponibilidad total: 0.99999 x 0.9999 x 0.99999 = 99.988%
- Tiempo de inactividad máximo estimado: aproximadamente 5 minutos y 11 segundos
Este cálculo solo considera 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, implementar y mantener la aplicación, sus dependencias y la infraestructura de Google Cloud
Para obtener más información, consulta Factores que afectan la confiabilidad de las aplicaciones.
Efectos de las interrupciones y orientación para la recuperación
Si algún componente de esta arquitectura falla, la aplicación seguirá funcionando si existe al menos un componente en funcionamiento con capacidad adecuada en cada nivel. Por ejemplo, si una instancia del servidor web falla, el balanceador de cargas de HTTP/S externo global reenvía las solicitudes del usuario a las otras instancias del servidor web. Si una instancia del servidor de aplicaciones falla, los balanceadores de cargas internos envían las solicitudes a las otras instancias del servidor de aplicaciones. Si alguna de las VMs falla, los MIGs garantizan que se creen VMs nuevas de forma automática para mantener la cantidad mínima de VMs configuradas.
Si se produce una interrupción en una de las zonas de cualquier región, el balanceador de cargas no se verá afectado. El balanceador de cargas de HTTP/S externo global es resistente a las interrupciones por zona y región. Los balanceadores de cargas internos son recursos regionales y son resilientes a las interrupciones zonales. Una interrupción zonal puede afectar a las VMs individuales de Compute Engine. Sin embargo, las instancias del servidor web y del servidor de aplicaciones permanecen disponibles, ya que las VMs forman parte de los MIGs regionales. Los MIGs garantizan que las VMs nuevas se creen de forma automática para mantener la cantidad mínima de VMs configuradas. La instancia de Spanner en esta arquitectura usa una configuración multirregional, que es resiliente a las interrupciones zonales.
En el siguiente diagrama, se muestra la misma arquitectura multirregional del diagrama anterior y los efectos de una interrupción regional única en la disponibilidad de la aplicación:
Como se muestra en el diagrama anterior, incluso si se produce una interrupción en ambas zonas de cualquier región, la aplicación permanece disponible, ya que se implementa una pila de aplicaciones independiente en cada región. El balanceador de cargas de HTTP/S externo global enruta las solicitudes de los usuarios a la aplicación en la región que no se ve afectada por la interrupción. La instancia multirregional de Spanner es resiliente a las interrupciones regionales. Una vez que Google resuelve la interrupción, debes verificar que la aplicación se ejecute como se espera en la región que ocurrió la interrupción.
Para obtener información sobre cómo funciona la replicación multirregional en Spanner, consulta Configuración regional y multirregional y Desmitifica configuraciones multirregionales de Cloud Spanner.
Si dos de las regiones en esta arquitectura tienen interrupciones, la aplicación no estará disponible. El balanceador de cargas de HTTP/S externo global está disponible, pero no puede distribuir el tráfico porque no hay backends disponibles. Espera a que Google resuelva las interrupciones. Luego, verifica que la aplicación se ejecute como se espera en todas las regiones en las que se implementa.
Las implementaciones multirregionales pueden ayudar a garantizar una alta disponibilidad para las aplicaciones empresariales más importantes. Para garantizar la continuidad del negocio durante los eventos de falla, además de implementar la aplicación en varias regiones, debes tomar ciertos pasos adicionales. Por ejemplo, debes realizar una planificación de capacidad para asegurarte de que se acepte una capacidad suficiente en todas las regiones o que se acepten los riesgos asociados con el ajuste de escala automático de emergencia. También debes implementar prácticas operativas para pruebas de DR, administrar incidentes, verificar el estado de la aplicación después de incidentes y realizar retrospectivas.
-
Las regiones de México, Montreal y Osaka tienen tres zonas en uno o dos centros de datos físicos. Estas regiones están en proceso de expansión a, al menos, tres centros de datos físicos. Para obtener más información, consulta Ubicaciones de Cloud y ANS de Google Cloud Platform. Para mejorar la confiabilidad de tus cargas de trabajo, considera una implementación multirregional. ↩