Los servicios de infraestructuraGoogle Cloud se ejecutan en ubicaciones de todo el mundo. Las ubicaciones se dividen en dominios de errores llamados regiones y zonas, que son los componentes básicos para diseñar una infraestructura fiable para tus cargas de trabajo en la nube.
Un dominio de error es un recurso o un grupo de recursos que puede fallar de forma independiente a otros recursos. Una VM de Compute Engine independiente es un ejemplo de recurso que es un dominio de fallo. Una Google Cloud región o una zona es un ejemplo de dominio de fallo que consta de un grupo de recursos. Cuando una aplicación se distribuye de forma redundante en varios dominios de fallos, puede alcanzar un nivel de disponibilidad agregado superior al que proporciona cada dominio de fallos.
En esta parte de la Google Cloud guía de fiabilidad de la infraestructura se describen los componentes básicos de la fiabilidad en Google Cloud y cómo afectan a la disponibilidad de tus recursos en la nube.
Regiones y zonas
Las regiones son áreas geográficas independientes que están formadas por zonas. Las zonas y las regiones son abstracciones lógicas de los recursos físicos subyacentes. Para obtener más información sobre las consideraciones específicas de cada región, consulta el artículo Geografía y regiones.
Disponibilidad de la plataforma
LaGoogle Cloud infraestructura está diseñada para tolerar y recuperarse de los fallos. Google invierte continuamente en estrategias innovadoras para mantener y mejorar la fiabilidad de Google Cloud. Las siguientes funciones de la infraestructura deGoogle Cloud ayudan a proporcionar una plataforma fiable para tus cargas de trabajo en la nube:
- Regiones separadas geográficamente para mitigar los efectos de los desastres naturales y las interrupciones del servicio en distintas regiones en los servicios globales.
- Redundancia y replicación de hardware para evitar puntos únicos de fallo.
- Migración activa de recursos durante los eventos de mantenimiento. Por ejemplo, durante el mantenimiento de la infraestructura programado, las VMs de Compute Engine se pueden mover a otro host de la misma zona mediante la migración en tiempo real.
- Una base de infraestructura diseñada para ser segura para la infraestructura física y el software en los que se ejecuta Google Cloud , así como controles de seguridad operativos 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 de redes definidas por software (SDN) avanzado para gestionar la red, con servicios de almacenamiento en caché perimetral para ofrecer un rendimiento uniforme que se adapta bien.
- Monitorización e informes continuos. Puedes consultar el estado de los Google Cloud servicios en todas las ubicaciones mediante el Google Cloud panel de control de Service Health.
- Pruebas de recuperación tras fallos (DiRT) anuales en toda la empresa para asegurar que los servicios y las operaciones empresariales internas sigan funcionando durante un desastre. Google Cloud
- Una estrategia de gestión de cambios que enfatiza la fiabilidad en todas las fases del ciclo de vida del desarrollo de software para cualquier cambio en la plataforma y los servicios de Google Cloud .
La infraestructura deGoogle Cloud se ha diseñado para admitir los siguientes niveles de disponibilidad para la mayoría de las cargas de trabajo de los clientes:
| Ubicación de despliegue | Porcentaje de disponibilidad (tiempo de actividad) | Tiempo de inactividad máximo estimado |
|---|---|---|
| Una zona | Tres nueves: 99,9% | 43,2 minutos en un mes de 30 días |
| Varias zonas en una región | Cuatro nueves: 99,99% | 4,3 minutos en un mes de 30 días |
| Varias regiones | Cinco 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 (SLAs) de tiempo de actividad de determinados Google Cloud servicios pueden ser diferentes de estos objetivos de disponibilidad. Por ejemplo, el acuerdo de nivel de servicio de tiempo de actividad de una instancia de Bigtable depende del número de clústeres, de su distribución en las ubicaciones y de la política de enrutamiento que configures.
El tiempo de actividad mínimo garantizado de una instancia de Bigtable con clústeres en tres o más regiones es del 99,999% si se configura la política de enrutamiento multiclúster. Sin embargo, si se configura la política de enrutamiento de un solo clúster, el SLA de tiempo de actividad mínimo será del 99,9 %, independientemente del número de clústeres y de su distribución.
En los diagramas de esta sección se muestran instancias de Bigtable con tamaños de clúster variables y las diferencias resultantes en sus acuerdos de nivel de servicio 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 acuerdo de nivel de servicio de tiempo de actividad mínimo del 99,9%:
Varios clústeres
En el siguiente diagrama se muestra una instancia de Bigtable con varios clústeres en varias zonas de una misma región, con enrutamiento de varios clústeres (acuerdo de nivel de servicio de tiempo de actividad mínimo: 99,99%):
Varios clústeres
En el siguiente diagrama se muestra una instancia de Bigtable multiclúster en tres regiones, con enrutamiento multiclúster (acuerdo de nivel de servicio de tiempo de actividad mínimo: 99,999%):
Disponibilidad de la infraestructura agregada
En esta sección se describe cómo calcular la disponibilidad agregada de una pila de infraestructura en Google Cloud. Describe los factores que influyen en la disponibilidad agregada y proporciona ejemplos de cálculos.
Para ejecutar tus aplicaciones en Google Cloud, debes usar recursos de infraestructura, como máquinas virtuales y bases de datos. Estos recursos de infraestructura, en conjunto, 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 SLA de disponibilidad de cada recurso de la pila:
Esta pila de infraestructura de ejemplo incluye los siguientes Google Cloud recursos:
- Un balanceador de carga de aplicación externo regional recibe solicitudes de los usuarios y responde a ellas.
- Un grupo de instancias gestionado (MIG) regional es el backend del balanceador de carga de aplicación externo regional. 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 interno. 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 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.
La disponibilidad agregada que puedes esperar de una pila de infraestructura como la del ejemplo anterior depende de los siguientes factores:
Google Cloud SLA
Los acuerdos de nivel de servicio de tiempo de actividad de los Google Cloud servicios que usas en tu pila de infraestructura influyen en la disponibilidad agregada mínima que puedes esperar de la pila.
En las siguientes tablas se compara el SLA de tiempo de actividad de algunos servicios:
| Servicios de computación | Acuerdo de Nivel de Servicio de Tiempo de Funcionamiento 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 Autopilot de GKE en varias zonas | 99,9% | 43,2 minutos |
| Servicio de Cloud Run | 99,95% | 21,6 minutos |
| Servicios de bases de datos | Acuerdo de Nivel de Servicio de Tiempo de Funcionamiento 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 multirregional de Spanner | 99,999% | 26 segundos |
Para consultar los acuerdos de nivel de servicio de otros Google Cloud servicios, consulta los Google Cloud acuerdos de nivel de servicio.
Como se muestra en las tablas anteriores, los Google Cloud servicios que elijas para cada nivel de tu pila de infraestructura afectan directamente al tiempo de actividad general que puedes esperar de la pila de infraestructura. Para aumentar la disponibilidad prevista de una carga de trabajo que se ha desplegado en un recurso de Google Cloud , puedes aprovisionar instancias redundantes del recurso, tal como se describe en la siguiente sección.
Redundancia de recursos
La redundancia de recursos consiste en aprovisionar dos o más instancias idénticas de un recurso y desplegar 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 máquinas virtuales de Compute Engine idénticas.
Si distribuyes un grupo de recursos de forma redundante en varios dominios de errores (por ejemplo, dos zonas), la disponibilidad de recursos que puedes esperar de ese grupo es mayor que el SLA de tiempo de actividad de cada recurso del grupo. Google Cloud 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 de un solo dominio de fallo tengan un fallo coordinado.
Por ejemplo, si el acuerdo de nivel de servicio de disponibilidad de un recurso es del 99,9%, la probabilidad de que el recurso falle es del 0,001 (1 menos el acuerdo de nivel de servicio). Si distribuyes una carga de trabajo en dos instancias de este recurso aprovisionadas en dominios de errores independientes, la probabilidad de que ambos recursos fallen al mismo tiempo es de 0,000001 (es decir, 0,001 x 0,001). Esta probabilidad de fallo 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: 99,9% si los recursos están en una solaGoogle Cloud zona, 99,99% si la implementación es multizona y 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 distintos de 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 de 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 estrecha con los niveles adyacentes. Esto significa que, si no está disponible algún nivel de la pila, toda la pila dejará de estarlo.
Puedes calcular la disponibilidad agregada esperada de una pila de infraestructura de N niveles con la siguiente fórmula:
Por ejemplo, si cada nivel de una pila de tres niveles está diseñado para ofrecer una disponibilidad del 99,9 %, la disponibilidad agregada de la pila es de aproximadamente el 99,7% (0,999 x 0,999 x 0,999). Esto significa que la disponibilidad agregada de una pila multinivel es inferior a la disponibilidad del nivel que ofrece la menor disponibilidad.
A medida que aumenta el número de niveles interdependientes de una pila, la disponibilidad agregada de la pila disminuye, tal como se muestra en la siguiente tabla. Cada pila de ejemplo de la tabla tiene un número diferente de niveles y 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 aplicación | 99,9 % | 99,9 % | 99,9 % |
| Nivel medio | – | 99,9 % | 99,9 % |
| Nivel de 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, ten en cuenta la disponibilidad agregada de la Google Cloud pila de infraestructura.
- La disponibilidad de cada Google Cloud recurso de tu pila de infraestructura influye en la disponibilidad agregada de la pila. Cuando elijas los Google Cloud servicios para crear tu pila de infraestructura, ten en cuenta el SLA de disponibilidad de los servicios.
- Para mejorar la disponibilidad de la función (por ejemplo, de computación o de base de datos) que proporciona un recurso, puedes aprovisionar instancias redundantes del recurso. Cuando diseñas una arquitectura con recursos redundantes, además de las ventajas de disponibilidad, también debes tener en cuenta los posibles efectos en la complejidad operativa, la latencia y el coste.
- El número de niveles de 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 al diseñar o modificar tu pila.
Para ver más ejemplos de cálculos de disponibilidad agregada, consulta las siguientes secciones:
- Cálculo de ejemplo: implementación de una sola zona
- Cálculo de ejemplo: despliegue multizona
- Cálculo de ejemplo: despliegue multirregional con balanceo de carga regional
- Cálculo de ejemplo: despliegue multirregional con balanceo de carga global
Ámbitos de ubicación
El ámbito de ubicación de un Google Cloud recurso determina el grado en que un fallo de la infraestructura puede afectar al recurso. La mayoría de los recursos que aprovisionas en Google Cloud tienen uno de los siguientes ámbitos de ubicación: de zona, regional, multirregional o global.
El ámbito de ubicación de algunos tipos de recursos es fijo, es decir, no se puede elegir ni cambiar. Por ejemplo, las redes de nube privada virtual (VPC) son recursos globales y las máquinas virtuales (VMs) de Compute Engine son recursos zonales. En algunos recursos, puedes elegir el ámbito de la ubicación al aprovisionarlos. Por ejemplo, cuando creas un clúster de Google Kubernetes Engine (GKE), puedes elegir entre un clúster de GKE zonal o regional.
En las secciones siguientes se describen los ámbitos de ubicación con más detalle.
Recursos de zona
Los recursos de zona se despliegan en una sola zona de una Google Cloud región. Estos son algunos ejemplos de recursos zonales. Esta lista no es exhaustiva.
- VMs de Compute Engine
- Grupos de instancias gestionados por zonas
- Discos persistentes de zona
- Clústeres de GKE de una sola zona
- Instancias de Filestore Basic y Zonal
- Tareas de Dataflow
- Instancias de Cloud SQL
- Clústeres de Dataproc en Compute Engine
Si se produce un fallo en una zona, puede afectar a los recursos zonales aprovisionados en esa zona. Las zonas están diseñadas para minimizar el riesgo de fallos correlacionados con otras zonas de la región. Los fallos que se dan en una zona no suelen afectar a los recursos de las demás zonas de la región. Además, un fallo en una zona no implica necesariamente que toda la infraestructura de esa zona deje de estar disponible. La zona solo define el límite esperado del efecto de un error.
Para proteger las aplicaciones que usan recursos zonales frente a incidentes zonales, puedes distribuir o replicar los recursos en varias zonas o regiones. Para obtener más información, consulta el artículo Diseñar una infraestructura fiable para tus cargas de trabajo en Google Cloud.
Recursos regionales
Los recursos regionales se despliegan de forma redundante en varias zonas de una región. Estos son algunos ejemplos de recursos regionales. Esta lista no es exhaustiva.
- Grupos regionales de instancias gestionados
- Segmentos de Cloud Storage regionales
- Discos persistentes regionales
- Clústeres de GKE regionales con la configuración predeterminada (multizona)
- Subredes de VPC
- Balanceadores de carga de aplicación externos regionales
- Instancias regionales de Spanner
- Instancias de Filestore Enterprise
- Servicios de Cloud Run
Los recursos regionales son resistentes a los incidentes en una zona específica. Una interrupción en una región puede afectar a algunos o a todos los recursos regionales aprovisionados en esa región. Estas interrupciones pueden deberse a desastres naturales o a fallos de infraestructuras a gran escala.
Recursos multirregionales
Los recursos multirregionales se distribuyen en regiones específicas. A continuación, se muestran ejemplos de recursos multirregión. Esta lista no es exhaustiva.
- Segmentos de Cloud Storage birregionales y multirregionales
- Instancias de Spanner multirregionales
- Instancias de Bigtable multiclúster (multirregión)
- Conjuntos de claves multirregión en Cloud Key Management Service
Para ver una lista completa de los servicios de Google que están disponibles en configuraciones multirregión, consulta Productos disponibles por ubicación.
Los recursos multirregionales son resistentes a los incidentes en regiones y zonas específicas. Una interrupción de la infraestructura que se produce en varias regiones puede afectar a la disponibilidad de algunos o todos los recursos multirregionales aprovisionados en las regiones afectadas.
Recursos globales
Los recursos globales están disponibles en todas las Google Cloud ubicaciones. A continuación, se muestran ejemplos de recursos globales. Esta lista no es exhaustiva.
Projects. Para obtener directrices y prácticas recomendadas sobre cómo organizar tusGoogle Cloud recursos en carpetas y proyectos, consulta Decide una jerarquía de recursos para tu Google Cloud zona de aterrizaje.
Redes de VPC, incluidas las rutas y las reglas de cortafuegos asociadas
Zonas de Cloud DNS
Balanceadores de carga de aplicación externos globales
Anillos de claves globales en Cloud Key Management Service
Temas Pub/Sub
Secretos de Secret Manager
Para ver una lista completa de los servicios de Google disponibles en todo el mundo, consulta Productos globales.
Los recursos globales son resistentes a los incidentes zonales y regionales. Estos recursos no dependen de la infraestructura de ninguna región específica. Google Cloud tiene sistemas y procesos que ayudan a minimizar el riesgo de interrupciones en la infraestructura global. Google también monitoriza continuamente la infraestructura y resuelve rápidamente cualquier interrupción global.
En la siguiente tabla se resume la resiliencia relativa de los recursos zonales, regionales, multirregionales y globales ante problemas de aplicaciones e infraestructura. También se describe el esfuerzo necesario para configurar estos recursos y se ofrecen recomendaciones para mitigar los efectos de las interrupciones.
| Ámbito de los recursos | Resiliencia | Recomendaciones para mitigar los efectos de las interrupciones de la infraestructura |
|---|---|---|
| Por zonas | Bajo | Despliega los recursos de forma redundante en varias zonas o regiones. |
| Regional | Medio | Despliega los recursos de forma redundante en varias regiones. |
| Multirregional o global | Alta | Gestiona los cambios con cuidado y usa 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 los recursos globales. |
Recomendaciones para gestionar el riesgo de interrupciones de recursos globales
Para aprovechar la resiliencia de los recursos globales ante las interrupciones de zonas y regiones, puedes usar determinados recursos globales en tu arquitectura. Google recomienda los siguientes enfoques para gestionar el riesgo de interrupciones de los recursos globales:
Gestión cuidadosa de los cambios en los recursos globales
Los recursos globales son resistentes a los fallos físicos. La configuración de estos recursos tiene un ámbito global. Por lo tanto, es más fácil configurar un único recurso global que operar varios recursos regionales. Sin embargo, un error crítico en la configuración de un recurso global puede convertirlo en un único punto de fallo (SPOF). Por ejemplo, puedes usar un balanceador de carga global como frontend de una aplicación distribuida geográficamente. Un balanceador de carga global suele ser una buena opción para este tipo de aplicaciones. Sin embargo, un error en la configuración del balanceador de carga puede provocar que no esté disponible en todas las zonas geográficas. Para evitar este riesgo, debes gestionar los cambios de configuración de los recursos globales con cuidado. Para obtener más información, consulta Controlar los cambios en los recursos globales.
Uso de recursos regionales como alternativas de defensa reforzada
En el caso de las aplicaciones que tienen requisitos de disponibilidad excepcionalmente altos, las copias de seguridad de defensa en profundidad regionales pueden ayudar a minimizar el efecto de las interrupciones de los recursos globales. Veamos el ejemplo de una aplicación distribuida geográficamente que tiene un balanceador de carga global como frontend. Para asegurarte de que la aplicación siga siendo accesible aunque el balanceador de carga global se vea afectado por una interrupción global, puedes implementar balanceadores de carga regionales. Puedes configurar los clientes para que prefieran el balanceador de carga global, pero que pasen al balanceador de carga regional más cercano si el balanceador de carga global no está disponible.
Arquitectura de ejemplo con recursos de zona, regionales y globales
Tu topología de nube puede incluir una combinación de recursos zonales, regionales y globales, tal como se muestra en el siguiente diagrama. En el siguiente diagrama se muestra una arquitectura de ejemplo de una aplicación multinivel implementada enGoogle Cloud.
Como se muestra en el diagrama anterior, un balanceador de carga HTTP/S externo global recibe solicitudes de clientes. El balanceador de carga 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 datos en una base de datos de Cloud SQL y lee datos de ella. La base de datos está configurada para alta disponibilidad. Las instancias principal y de espera de la base de datos se aprovisionan en zonas independientes, y la base de datos principal se replica de forma síncrona en la base de datos de espera. Además, la base de datos se copia de seguridad automáticamente en un segmento multirregional de Cloud Storage.
En la siguiente tabla se resumen los Google Cloud recursos de la arquitectura anterior y la resiliencia de cada recurso ante las interrupciones de zonas y regiones:
| Recurso | Resiliencia ante interrupciones |
|---|---|
| Red VPC | Las redes de VPC, incluidas las rutas y las reglas de cortafuegos asociadas, son recursos globales. Son resistentes a las interrupciones de zonas y regiones. |
| Subredes | Las subredes de VPC son recursos regionales. Son resistentes a las interrupciones de la zona. |
| Balanceador de carga HTTP/S externo global | Los balanceadores de carga HTTP/S globales externos son resistentes a las interrupciones de zonas y regiones. |
| Grupo de instancias gestionado regional | Los MIGs regionales son resistentes a las interrupciones de las zonas. |
| VMs de Compute Engine | Las VMs de Compute Engine son recursos zonales. Si se produce una interrupción en una zona, puede que las VMs de Compute Engine se vean afectadas. Sin embargo, la aplicación puede seguir atendiendo solicitudes porque el backend del balanceador de carga es un MIG regional y no máquinas virtuales independientes. |
| Instancias de Cloud SQL | La implementación de Cloud SQL en esta arquitectura está configurada para alta disponibilidad, es decir, la implementación incluye un par de instancias de base de datos principal y de espera. La base de datos principal se replica de forma síncrona en la base de datos de espera mediante discos persistentes regionales.
|
| Segmento de Cloud Storage multirregional | Los datos almacenados en segmentos de Cloud Storage multirregionales son resistentes a las interrupciones de una sola región. |
| Discos persistentes | Los discos persistentes pueden ser de zona o regionales. Los discos persistentes regionales son resistentes a las interrupciones de zona. Para prepararte ante posibles interrupciones en una región, puedes programar capturas de discos persistentes y almacenarlas en un segmento multirregional de Cloud Storage. |