Los servicios de infraestructura de Google Cloud se ejecutan en ubicaciones de todo el mundo. Las ubicaciones se dividen en dominios con fallas llamados regiones y zonas, que son los componentes fundamentales para diseñar una infraestructura confiable en las cargas de trabajo en la nube.
Un dominio con fallas es un recurso o un grupo de recursos que pueden fallar de forma independiente de otros recursos. Una VM de Compute Engine independiente es un ejemplo de un recurso que es un dominio con fallas. Una región o zona de Google Cloud es un ejemplo de un dominio con fallas que consta de un grupo de recursos. Cuando una aplicación se distribuye de forma redundante entre dominios con fallas, puede lograr un nivel agregado de disponibilidad mayor que el que proporciona cada dominio con fallas.
En esta parte de la guía de confiabilidad de infraestructura de Google Cloud, se describen los componentes básicos de la confiabilidad en Google Cloud y cómo afectan la disponibilidad de tus recursos en la nube.
Regiones y zonas
Las regiones de Google Cloud son ubicaciones geográficas independientes. Cada región de Google Cloud contiene varias zonas. Es poco probable que una falla en una zona afecte la infraestructura en las otras zonas. En una red troncal global, se brinda conectividad de baja latencia y ancho de banda alto en todas las zonas y regiones de Google Cloud.
Disponibilidad de la plataforma
La infraestructura de Google Cloud está diseñada para tolerar y recuperar fallas. Google invierte de forma continua en enfoques innovadores para mantener y mejorar la confiabilidad de Google Cloud. Las siguientes capacidades de la infraestructura de Google Cloud ayudan a proporcionar una plataforma confiable para las cargas de trabajo en la nube:
- Regiones separadas geográficamente para mitigar los efectos de los desastres naturales y las interrupciones regionales en los servicios globales.
- Redundancia y replicación de hardware para evitar puntos únicos de fallo.
- Migración en vivo de los recursos durante los eventos de mantenimiento. Por ejemplo, durante el mantenimiento planificado de la infraestructura, las VMs de Compute Engine se pueden migrar a otro host en la misma zona con la migración en vivo.
- Una base de infraestructura con diseño de seguridad integral para la infraestructura física y el software en los que se ejecuta Google Cloud, y los controles de seguridad operacional para proteger tus datos y cargas de trabajo. Para obtener más información, consulta la Descripción general del diseño de seguridad de la infraestructura de Google.
- Una red troncal de alto rendimiento que usa un enfoque avanzado de red definida por software (SDN) para la administración de redes, con servicios de almacenamiento en caché perimetral a fin de entregar un rendimiento coherente que se escale bien.
- Informes y supervisión continuos. Puedes ver el estado de los servicios de Google Cloud en todas las ubicaciones con el panel de estado del servicio de Google Cloud.
- Eventos de prueba de recuperación ante desastres (DiRT) anuales y en toda la empresa para garantizar que los servicios de Google Cloud y las operaciones empresariales internas continúen ejecutándose durante un desastre.
La infraestructura de Google Cloud está diseñada para admitir los siguientes niveles de destino de disponibilidad en la mayoría de las cargas de trabajo de clientes:
| La ubicación de la implementación | % de disponibilidad (tiempo de actividad) | Tiempo de inactividad máximo estimado |
|---|---|---|
| Zona única | 3 nueves: 99.9% | 43.2 minutos en un mes de 30 días |
| Varias zonas en una región | 4 nueves: 99.99% | 4.3 minutos en un mes de 30 días |
| Varias regiones | 5 nueves: 99.999% | 26 segundos en un mes de 30 días |
Los porcentajes de disponibilidad de la tabla anterior son objetivos. Los Acuerdos de Nivel de Servicio (ANS) de tiempo de actividad para servicios específicos de Google Cloud pueden ser diferentes de estos objetivos de disponibilidad. Por ejemplo, el ANS de tiempo de actividad de una instancia de Bigtable depende de la cantidad de clústeres, su distribución entre ubicaciones y la política de enrutamiento que configures.
El ANS de tiempo de actividad mínimo para una instancia de Bigtable con clústeres en tres o más regiones es del 99.999% si está configurada la política de enrutamiento de varios clústeres. Sin embargo, si se configura la política de enrutamiento de un solo clúster, el ANS mínimo de tiempo de actividad es del 99.9%, sin importar la cantidad de clústeres y su distribución.
En los diagramas de esta sección, se muestran instancias de Bigtable con diferentes tamaños de clúster y las consiguientes diferencias en sus ANS de tiempo de actividad.
Un solo clúster
En el siguiente diagrama, se muestra una instancia de Bigtable de un solo clúster, con un ANS de tiempo de actividad mínimo de un 99.9%:
Varios clústeres
En el siguiente diagrama, se muestra una instancia de Bigtable de varios clústeres en varias zonas dentro de una sola región, con enrutamiento de varios clústeres (ANS de tiempo de actividad mínimo: 99.99%):
Varios clústeres
En el siguiente diagrama, se muestra una instancia de Bigtable de varios clústeres en tres regiones con enrutamiento de varios clústeres (ANS de tiempo de actividad mínimo: 99.999%):
Disponibilidad agregada de la infraestructura
Para ejecutar tus aplicaciones en Google Cloud, usa recursos de infraestructura como VMs y bases de datos. Estos recursos de infraestructura, juntos, constituyen la pila de infraestructura de tu aplicación.
En el siguiente diagrama, se muestra un ejemplo de una pila de infraestructura en Google Cloud y el ANS de disponibilidad para cada recurso de la pila:
Esta pila de infraestructura de ejemplo incluye los siguientes recursos de Google Cloud:
- Un balanceador de cargas de aplicaciones externo regional recibe y responde a las solicitudes de los usuarios.
- Un grupo de instancias administrado (MIG) regional es el backend para el balanceador de cargas de aplicaciones externo regional. 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 las instancias del servidor de aplicaciones y el servidor web.
- Un segundo MIG regional es el backend para el balanceador de cargas interno. 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 que se configura para la HA es la base de datos de la aplicación. La instancia de la base de datos principal se replica de forma síncrona en una instancia de base de datos en espera.
La disponibilidad total que puedes esperar de una pila de infraestructura como la del ejemplo anterior depende de los siguientes factores:
ANS de Google Cloud
Los ANS de tiempo de actividad de los servicios de Google Cloud que usas en tu pila de infraestructura influyen en la disponibilidad mínima agregada que puedes esperar de la pila.
En las tablas siguientes, se muestra una comparación de los ANS de tiempo de actividad para algunos servicios:
| Servicios de procesamiento | ANS de tiempo de actividad mensual | Tiempo de inactividad máximo estimado en un mes de 30 días |
|---|---|---|
| VM de Compute Engine | 99.9% | 43.2 minutos |
| Pods de GKE Autopilot en varias zonas | 99.9% | 43.2 minutos |
| Servicio de Cloud Run | 99.95% | 21.6 minutos |
| Servicios de base de datos | ANS de tiempo de actividad mensual | Tiempo de inactividad máximo estimado en un mes de 30 días |
|---|---|---|
| Instancia de Cloud SQL para PostgreSQL (edición Enterprise) | 99.95% | 21.6 minutos |
| Instancia de AlloyDB para PostgreSQL | 99.99% | 4.3 minutos |
| Instancia de Spanner multirregional | 99.999% | 26 segundos |
Para obtener información sobre los ANS de otros servicios de Google Cloud, consulta Acuerdos de Nivel de Servicio de Google Cloud.
Como se muestra en las tablas anteriores, los servicios de Google Cloud que eliges para cada nivel de pila de infraestructura afectan directamente el tiempo de actividad general que puedes esperar de la pila de infraestructura. Para aumentar la disponibilidad esperada de una carga de trabajo que se implementa en un recurso de Google Cloud, puedes aprovisionar instancias redundantes del recurso, como se describe en la siguiente sección.
Redundancia de recursos
La redundancia de recursos significa aprovisionar dos o más instancias idénticas de un recurso e implementar la misma carga de trabajo en todos los recursos del grupo. Por ejemplo, para alojar el nivel web de una aplicación, puedes aprovisionar un MIG que contenga varias VMs idénticas de Compute Engine.
Si distribuyes un grupo de recursos de forma redundante en varios dominios con fallas, por ejemplo, dos zonas de Google Cloud, la disponibilidad de recursos que puedes esperar de ese grupo es superior al ANS de tiempo de actividad de cada recurso en el grupo. Esta mayor disponibilidad se debe a que la probabilidad de que todos los recursos del grupo fallen al mismo tiempo es menor que la probabilidad de que los recursos en un solo dominio con fallas tengan una falla coordinada.
Por ejemplo, si el ANS de disponibilidad para un recurso es del 99.9%, la probabilidad de que el recurso falle es 0.001 (1 menos el ANS). Si distribuyes una carga de trabajo en dos instancias de este recurso que se aprovisionan en dominios con fallas separados, la probabilidad de que ambos recursos fallen al mismo tiempo sea 0.000001 (es decir, 0.001 x 0.001). Esta probabilidad de fallas se traduce en una disponibilidad teórica del 99.9999% para el grupo de dos recursos. Sin embargo, la disponibilidad real que puedes esperar se limita a la disponibilidad objetivo de la ubicación de implementación: el 99.9% si los recursos están en una sola zona de Google Cloud, el 99.99% para una implementación multizona y el 99.999% si los recursos redundantes se distribuyen en varias regiones.
Profundidad de la pila
La profundidad de una pila de infraestructura es el número de niveles (o capas) distintos en la pila. Cada nivel de una pila de infraestructura contiene recursos que proporcionan una función distinta para la aplicación. Por ejemplo, el nivel intermedio en una pila de tres niveles puede usar VMs de Compute Engine o un clúster de GKE para alojar servidores de aplicaciones. Cada nivel de una pila de infraestructura suele tener una interdependencia estricta con sus niveles adyacentes. Esto significa que si algún nivel de la pila no está disponible, toda la pila dejará de estar disponible.
Puedes calcular la disponibilidad agregada esperada de una pila de infraestructura de nivel N mediante la siguiente fórmula:
Por ejemplo, si cada nivel de una pila de tres niveles está diseñado para proporcionar una disponibilidad del 99.9%, la disponibilidad agregada de la pila es de alrededor del 99.7% (0.999 x 0.999 x 0.999). Esto significa que la disponibilidad agregada de una pila de varios niveles es menor que la disponibilidad del nivel que proporciona la menor disponibilidad.
A medida que aumenta la cantidad de niveles interdependientes en una pila, la disponibilidad agregada de la pila disminuye, como se muestra en la siguiente tabla. Cada pila de ejemplo en la tabla tiene un número diferente de niveles. Para facilitar la comparación, se supone que cada nivel proporciona una disponibilidad del 99.9%.
| Nivel | Pila A | Pila B | Pila C |
|---|---|---|---|
| Frontend | 99.9% | 99.9% | 99.9% |
| Nivel de la aplicación | 99.9% | 99.9% | 99.9% |
| Nivel intermedio | – | 99.9% | 99.9% |
| Nivel de los datos | – | – | 99.9% |
| Disponibilidad agregada de la pila | 99.8% | 99.7% | 99.6% |
| Tiempo de inactividad máximo estimado de la pila en un mes de 30 días | 86 minutos | 130 minutos | 173 minutos |
Resumen de las consideraciones de diseño
Cuando diseñes tus aplicaciones, considera la disponibilidad total de la pila de infraestructura de Google Cloud.
- La disponibilidad de cada recurso de Google Cloud en tu pila de infraestructura influye en la disponibilidad agregada de la pila. Cuando elijas los servicios de Google Cloud para compilar la pila de tu infraestructura, considera el ANS de disponibilidad de los servicios.
- Para mejorar la disponibilidad de la función (por ejemplo, procesamiento o base de datos) que proporciona un recurso, puedes aprovisionar instancias redundantes del recurso. Cuando diseñas una arquitectura con recursos redundantes, además de los beneficios de disponibilidad, también debes considerar los posibles efectos en la complejidad operativa, la latencia y el costo.
- La cantidad de niveles en una pila de infraestructura (es decir, la profundidad de la pila) tiene una relación inversa con la disponibilidad agregada de la pila. Ten en cuenta esta relación cuando diseñes o modifiques tu pila.
Para ver ejemplos de cálculos de disponibilidad total, consulta las siguientes secciones:
- Cálculo de ejemplo: Implementación de zona única
- Cálculo de ejemplo: implementación multizona
- Cálculo de ejemplo: implementación multirregional con balanceo de cargas regional
- Cálculo de ejemplo: implementación multirregional con balanceo de cargas global
Permisos de ubicación
El permiso de la ubicación de un recurso de Google Cloud determina hasta qué punto una falla de la infraestructura puede afectar al recurso. La mayoría de los recursos que aprovisionas en Google Cloud tienen uno de los siguientes alcances de ubicación: zonal, regional, multirregional o global.
El alcance de la ubicación de algunos tipos de recursos es fijo, es decir, no puedes elegir ni cambiar el alcance de la ubicación. Por ejemplo, las redes de nube privada virtual (VPC) son recursos globales y las máquinas virtuales (VMs) de Compute Engine son recursos zonales. Para ciertos recursos, puedes elegir el alcance de la ubicación mientras aprovisionas el recurso. Por ejemplo, cuando creas un clúster de Google Kubernetes Engine (GKE), puedes elegir crear un clúster de GKE zonal o regional.
En las siguientes secciones se describen los permisos de ubicación con más detalle.
Recursos zonales
Los recursos zonales se implementan dentro de una sola zona en una región de Google Cloud. Los siguientes son ejemplos de recursos zonales. Esta lista no es exhaustiva.
- VMs de Compute Engine
- Grupos de instancias administrados zonales (MIGs)
- Discos persistentes zonales
- Clústeres de GKE de zona única
- Instancias básicas y zonales de Filestore
- Trabajos de Dataflow
- Instancias de Cloud SQL
- Clústeres de Dataproc en Compute Engine
Una falla en una zona puede afectar los recursos zonales que se aprovisionan dentro de esa zona. Las zonas están diseñadas para minimizar el riesgo de fallas correlacionadas con otras zonas de la región. Por lo general, una falla en una zona no afecta los recursos de las otras zonas de la región. Además, una falla en una zona no necesariamente hace que toda la infraestructura en esa zona no esté disponible. La zona solo define el límite esperado para el efecto de una falla.
Para proteger las aplicaciones que usan recursos zonales contra incidentes zonales, puedes distribuir o replicar los recursos en varias zonas o regiones. Si deseas obtener más información, consulta Diseña una infraestructura confiable para las cargas de trabajo en Google Cloud.
Recursos regionales
Los recursos regionales se implementan de forma redundante en varias zonas dentro de una región. Los siguientes son ejemplos de recursos regionales. Esta lista no es exhaustiva.
- MIG regionales
- Buckets regionales de Cloud Storage
- Discos persistentes regionales
- Clústeres de GKE regionales con la configuración predeterminada (varias zonas)
- Subredes de VPC
- Balanceadores de cargas de aplicaciones regionales externos
- Instancias de Spanner regional
- Instancias de Filestore Enterprise
- Servicios de Cloud Run
Los recursos regionales son resilientes a los incidentes en una zona específica. Una interrupción regional puede afectar a algunos o a todos los recursos regionales aprovisionados dentro de esa región. Desastres naturales o fallas en la infraestructura a gran escala pueden causar estas interrupciones.
Recursos multirregionales
Los recursos multirregionales se distribuyen en regiones específicas. Los siguientes son ejemplos de recursos multirregionales. Esta lista no es exhaustiva.
- Buckets de Cloud Storage birregionales y multirregionales
- Instancias de Spanner multirregional
- Instancias de Bigtable de varios clústeres (multirregión)
- Llaveros de claves multirregionales en Cloud Key Management Service
Si deseas obtener una lista completa de los servicios de Google que están disponibles en las configuraciones multirregionales, consulta Productos disponibles por ubicación.
Los recursos multirregionales son resilientes a los incidentes en regiones y zonas específicas. Una interrupción de la infraestructura que ocurre en varias regiones puede afectar la disponibilidad de algunos o de todos los recursos multirregionales que se aprovisionan en las regiones afectadas.
Recursos globales
Los recursos globales están disponibles en todas las ubicaciones de Google Cloud. Los siguientes son ejemplos de recursos globales. Esta lista no es exhaustiva.
Proyectos. Para obtener orientación y prácticas recomendadas sobre la organización de los recursos de Google Cloud en carpetas y proyectos, consulta Elige una jerarquía de recursos para la zona de destino de Google Cloud.
Redes de VPC, incluidas las rutas asociadas y las reglas de firewall
Zonas de Cloud DNS
Balanceadores de cargas de aplicaciones externos globales
Llaveros de claves globales en Cloud Key Management Service
Temas de Pub/Sub
Secrets en Secret Manager
Para obtener una lista completa de los servicios de Google que están disponibles en todo el mundo, consulta Productos disponibles en todo el mundo.
Los recursos globales son resilientes a los incidentes zonales y regionales. Estos recursos no dependen de la infraestructura en ninguna región específica. Google Cloud tiene sistemas y procesos para minimizar el riesgo de interrupciones globales de la infraestructura. Google también supervisa la infraestructura de forma continua y resuelve con rapidez las interrupciones globales.
En la siguiente tabla, se resume la resiliencia relativa de los recursos zonales, regionales, multirregionales y globales para los problemas de infraestructura y aplicación. También se describe el esfuerzo necesario para configurar estos recursos y las recomendaciones a fin de mitigar los efectos de las interrupciones.
| Permiso del recurso | Resiliencia | Recomendaciones para mitigar los efectos de las interrupciones de la infraestructura |
|---|---|---|
| Zonal | Bajo | Implementa los recursos de forma redundante en varias zonas o regiones. |
| Regional | Medio | Implementa los recursos de forma redundante en varias regiones. |
| Multirregional o global | Alto | Administra los cambios con cuidado y usa resguardos en profundidad cuando sea posible. Si deseas obtener más información, consulta Recomendaciones para administrar el riesgo de interrupciones de los recursos globales. |
Recomendaciones para administrar el riesgo de interrupciones de los recursos globales
Para aprovechar la resiliencia de los recursos globales a las interrupciones zonales y regionales, puedes considerar usar ciertos recursos globales en tu arquitectura. Google recomienda los siguientes enfoques para administrar el riesgo de interrupciones de los recursos globales:
Administración cuidadosa de los cambios en los recursos globales
Los recursos globales son resilientes a las fallas físicas. La configuración de esos recursos tiene un alcance global. Por lo tanto, configurar un solo recurso global es más fácil que operar varios recursos regionales. Sin embargo, un error crítico en la configuración de un recurso global puede convertirlo en un punto único de fallo (SPOF). Por ejemplo, puedes usar un balanceador de cargas global como frontend para una aplicación distribuida de manera geográfica. Un balanceador de cargas global suele ser una buena opción para esa aplicación. Sin embargo, un error en la configuración del balanceador de cargas puede hacer que deje de estar disponible en todas las ubicaciones geográficas. Para evitar este riesgo, debes administrar los cambios de configuración en los recursos globales con cuidado. Para obtener más información, consulta Controla los cambios en los recursos globales.
Uso de recursos regionales como resguardos de defensa en profundidad
En el caso de las aplicaciones que tienen requisitos excepcionales de alta disponibilidad, los resguardos regionales de defensa en profundidad pueden minimizar el efecto de las interrupciones de los recursos globales. Analiza el ejemplo de una aplicación distribuida por ubicación geográfica que tiene un balanceador de cargas global como frontend. Para garantizar que la aplicación permanezca accesible, incluso si el balanceador de cargas global se ve afectado por una interrupción global, puedes implementar balanceadores de cargas regionales. Puedes configurar los clientes para que prefieran el balanceador de cargas global, pero conmutar por error al balanceador de cargas regional más cercano si este no está disponible.
Arquitectura de ejemplo con recursos zonales, regionales y globales
La topología de la nube puede incluir una combinación de recursos zonales, regionales y globales, como se muestra en el siguiente diagrama. En el diagrama siguiente, se muestra un ejemplo de arquitectura para una aplicación de varios niveles que se implementa en Google Cloud.
Como se muestra en el diagrama anterior, un balanceador de cargas HTTP/S externo global recibe solicitudes de clientes. El balanceador de cargas distribuye las solicitudes al backend, que es un MIG regional que tiene dos VMs de Compute Engine. La aplicación que se ejecuta en las VMs escribe y lee desde una base de datos de Cloud SQL. La base de datos está configurada para la HA. Las instancias principal y en espera de la base de datos se aprovisionan en zonas separadas y la base de datos principal se replica de forma síncrona en la base de datos en espera. Además, se crea una copia de seguridad automática de la base de datos en un bucket multirregional en Cloud Storage.
En la siguiente tabla, se resumen los recursos de Google Cloud en la arquitectura anterior y la resiliencia de cada recurso para las interrupciones zonales y regionales:
| Recurso | Resiliencia ante las interrupciones |
|---|---|
| Red de VPC | Las redes de VPC, incluidas sus reglas de firewall y rutas asociadas, son recursos globales. Son resilientes a las interrupciones zonales y regionales. |
| Subredes | Las subredes de VPC son recursos regionales. Son resilientes a las interrupciones zonales. |
| Balanceador de cargas de HTTP/S externo global | Los balanceadores de cargas de HTTP/S externos globales son resilientes a las interrupciones de zonas y regiones. |
| MIG regional | Los MIGs regionales son resilientes a las interrupciones zonales. |
| VM de Compute Engine | Las VMs de Compute Engine son recursos zonales. Si se produce una interrupción zonal, es posible que las VMs individuales de Compute Engine se vean afectadas. Sin embargo, la aplicación puede continuar entregando solicitudes porque el backend del balanceador de cargas es un MIG regional y no VMs independientes. |
| Instancias de Cloud SQL | La implementación de Cloud SQL en esta arquitectura está configurada para la alta disponibilidad. Es decir, la implementación incluye un par de instancias principales de base de datos en espera. La base de datos principal se replica de forma síncrona en la base de datos en espera mediante el uso de discos persistentes regionales.
|
| Bucket multirregional de Cloud Storage | Los datos que se almacenan en depósitos multirregión de Cloud Storage son resilientes a las interrupciones en una sola región. |
| Discos persistentes | Los discos persistentes pueden ser zonales o regionales. Los discos persistentes regionales son resilientes a las interrupciones zonales. A fin de prepararte para la recuperación ante interrupciones regionales, puedes programar instantáneas de discos persistentes y almacenarlas en un bucket multirregional de Cloud Storage. |