Geografía y regiones

Google Cloud Los productos se sirven desde dominios de falla regionales específicos y están totalmente respaldados por acuerdos de nivel de servicio para garantizar que esté diseñando la arquitectura de su aplicación dentro de la estructura de Google Cloud.

Google Cloud Los servicios de infraestructura están disponibles en ubicaciones en América del Norte, América del Sur, Europa, Asia, Medio Oriente y Australia. Estas ubicaciones se dividen en regiones y zonas. Puede elegir dónde ubicar sus aplicaciones para cumplir con sus requisitos de latencia, disponibilidad y durabilidad.

Pruébalo por ti mismo

Si eres nuevo en Google Cloud, cree una cuenta para evaluar cómo funcionan nuestros productos en escenarios del mundo real. Los nuevos clientes también obtienen $300 en créditos gratuitos para ejecutar, probar e implementar cargas de trabajo.

Comience gratis

Regiones y zonas

Las regiones son áreas geográficas independientes que constan de zonas . Las zonas y regiones son abstracciones lógicas de los recursos físicos subyacentes. Una región consta de tres o más zonas alojadas en tres o más centros de datos físicos. Las regiones de Estocolmo, México, Osaka y Montreal tienen tres zonas alojadas en uno o dos centros de datos físicos. Estas regiones están en proceso de expandirse a al menos tres centros de datos físicos. Cuando diseñas tus soluciones enGoogle Cloud, considere la orientación sobre ubicaciones en la nube , Google Cloud SLA de plataforma y los acuerdos apropiados Google Cloud documentación del producto .

Estos centros de datos pueden ser propiedad de Google y figurar en la lista Google Cloud página de ubicaciones , o pueden alquilarse a proveedores de centros de datos externos. Para obtener la lista completa de ubicaciones de centros de datos para Google Cloud, consulte nuestro certificado ISO/IEC 27001 . Independientemente de si el centro de datos es propio o está arrendado, Google Cloud selecciona centros de datos y diseña su infraestructura para proporcionar un nivel uniforme de rendimiento, seguridad y confiabilidad.

Una zona es un área de despliegue para Google Cloud recursos dentro de una región. Las zonas deben considerarse un dominio de falla único dentro de una región. Para implementar aplicaciones tolerantes a fallas con alta disponibilidad y ayudar a proteger contra fallas inesperadas, implemente sus aplicaciones en varias zonas de una región.

Para protegerse contra la pérdida de una región entera debido a un desastre natural, tenga un plan de recuperación ante desastres y sepa cómo abrir su aplicación en el improbable caso de que se pierda su región principal. Consulte las consideraciones sobre la implementación de aplicaciones para obtener más información.

Para obtener más información sobre los recursos específicos disponibles dentro de cada opción de ubicación, consulte nuestras Ubicaciones en la nube .

Google CloudLos servicios y recursos de Google pueden ser zonales , regionales o administrados por Google en varias regiones . Para obtener más información sobre lo que significan estas opciones para sus datos, consulte Gestión geográfica de datos .

Google Cloud tiene la intención de ofrecer un mínimo de tres zonas de disponibilidad (zonas física y lógicamente distintas) en cada región de propósito general.

Documentos de ubicación relacionados

Recursos zonales

Los recursos zonales operan dentro de una sola zona. Los cortes zonales pueden afectar algunos o todos los recursos en esa zona. Un ejemplo de recurso zonal es una instancia de máquina virtual (VM) de Compute Engine que reside dentro de una zona específica.

Recursos regionales

Los recursos regionales son recursos que se implementan de forma redundante en varias zonas dentro de una región, por ejemplo, aplicaciones de App Engine o grupos de instancias administrados regionales . Esto les da una mayor disponibilidad en relación con los recursos zonales.

Recursos multirregionales

Múltiple Google Cloud Google gestiona los servicios para que sean redundantes y se distribuyan dentro y entre regiones. Estos servicios optimizan la disponibilidad, el rendimiento y la eficiencia de los recursos. Como resultado, estos servicios requieren un equilibrio entre la latencia y el modelo de coherencia. Estas compensaciones se documentan sobre una base específica del producto.

Los siguientes servicios tienen una o más ubicaciones multirregionales además de cualquier ubicación regional:

  • Registro de artefactos
  • Mesa grande
  • Protección de datos sensibles
  • API de atención sanitaria en la nube
  • KMS en la nube
  • Registro de contenedores
  • Llave
  • Almacenamiento en la nube
  • Servicio de migración de bases de datos
  • almacén de datos
  • Tienda de fuego

Estos servicios multirregionales están diseñados para poder funcionar tras la pérdida de una única región.

Para obtener más información, consulte Productos disponibles por ubicación y la documentación de cada producto.

Servicios globales

Google Cloud ha sido diseñado para operar globalmente desde cero y realiza mantenimiento y actualizaciones continuamente las 24 horas del día, los 7 días de la semana, los 365 días del año, sin causarle inconvenientes. Nuestra red troncal global proporciona una tremenda flexibilidad para el equilibrio de carga y reduce la latencia del usuario final al tener interconexiones cerca de usted. Nuestro plano global de gestión de la nube simplifica la gestión de desarrollos multirregionales.

Servicios internos

Respaldar y respaldar a muchos clientes Google Cloud Los servicios son un conjunto de servicios internos probados como Spanner, Colossus, Borg y Chubby.

Estos servicios internos tienen un equilibrio de carga global en varias regiones o están dedicados a cada región en la que están disponibles. Cuando los servicios tienen equilibrio de carga en varias regiones, implementamos actualizaciones progresivamente región por región, lo que nos permite detectar y abordar problemas sin afectar el uso de su servicio. Ninguno de estos servicios internos se limita a un único centro de datos lógico o a una sola región.

Los servicios internos globales se pueden ejecutar o replicar en las siguientes regiones de la nube:

Américas

  • sudamerica-oeste1
  • nosotros-central1
  • nosotros-este1
  • nosotros-este4
  • nosotros-oeste1
  • nosotros-oeste4

Europa

  • europa-norte1
  • europa-oeste1
  • europa-oeste4

Asia

  • asia-este1
  • asia-sureste1

Dependencias del servicio

En general, para Google Cloud servicios, si una sola región falla, solo los clientes de esa región se verán afectados; los clientes que tienen productos multirregionales no se ven afectados. Google Cloud cuenta con una arquitectura importante con el objetivo de evitar fallos correlacionados entre regiones.

Todo Google Cloud Los servicios dependen de herramientas internas centrales para proporcionar servicios fundamentales como redes (dentro y fuera de los centros de datos), acceso a los centros de datos y sistemas de autorización de identidad. Estas herramientas son resistentes a las interrupciones regionales, con el objetivo de que una región no se vea afectada si otras regiones dejan de estar disponibles.

Google Cloud proporciona instrucciones claras sobre cómo los clientes pueden diseñar sus aplicaciones para el nivel deseado de resiliencia en nuestro sitio web público , especialmente para los de uso común. Google Cloud productos como Compute Engine, BigQuery, Pub/Sub y otros servicios.

Nuestras principales dependencias se enumeran a continuación, comenzando con las dependencias comunes a todos los servicios, con la condición de que los detalles de implementación de niveles inferiores estén sujetos a cambios.

Dependencias comunes para todos los servicios.

  • Plano de datos de identidad para autenticación y autorización.
  • Servicios internos que proporcionan registro, almacenamiento de metadatos y gestión del flujo de trabajo.
  • Acceso a Google Cloud Las API dependen de DNS, balanceadores de carga distribuidos globalmente y puntos de presencia (PoP).
  • La configuración de recursos globales: por ejemplo, las políticas de IAM, las reglas de firewall globales, las configuraciones del balanceador de carga global y los temas de Pub/Sub se almacenan en bases de datos replicadas.
  • Cuando Google Cloud Los servicios realizan solicitudes a puntos finales controlados por el cliente, por ejemplo, Cloud EKM obtiene claves de cliente o Pub/Sub entrega mensajes; esas solicitudes dependen de nuestra infraestructura de red global para acceder a esos puntos finales controlados por el cliente.

Servicios con dependencias adicionales

  • Servicios de motor de computación
    • El Google Cloud Los planos de datos de VM y Persistent Disk dependen de servicios de Compute Engine y Cloud Storage de nivel inferior, como Borg y Colossus.
  • Google Cloud y los servicios de almacenamiento de infraestructura como Spanner, Bigtable y Cloud Storage dependen de:
    • Infraestructura de cifrado y gestión de claves para el cliente (Cloud KMS/Cloud EKM) e infraestructura interna para claves propiedad de Google.
    • Servicios internos para proporcionar registro y auditoría del acceso a datos.
    • Servicios de replicación de datos internos, donde se espera que los datos estén disponibles en múltiples regiones.
    • Las copias de seguridad configuradas explícitamente y la replicación en otras regiones dependen de las redes entre regiones
  • Servicios de mensajería
    • Pub/Sub depende de nuestra infraestructura de red global para acceder a los puntos finales controlados por el cliente
  • Servicios de redes
    • El equilibrio de carga global, el DNS y la conmutación por error entre regiones dependen de la infraestructura de red física.
    • La prevención de ataques DDos y similares depende de la infraestructura de Compute Engine de nivel inferior.
  • Servicios administrados y alojados como GKE y Cloud SQL
    • Depende de Compute Engine y de Container Registry o Artifact Registry para las imágenes de VM.
  • Infraestructura autónoma de nivel inferior
    • Nuestro plano de control interno a nivel de clúster que incluye Borg y estructuras de red.
    • Almacenamiento a nivel de clúster, como Colossus
    • Infraestructura de cifrado y gestión de claves

Mantener y mejorar la disponibilidad y la resiliencia

Site Reliability Engineering (SRE) es la organización interna de Google dedicada a trabajar en la disponibilidad, la latencia, el rendimiento y la capacidad. Las interrupciones y la falta de disponibilidad del servicio están correlacionadas con la implementación de nuevo código o cambios en el entorno. Al utilizar las mejores prácticas de la industria, SRE equilibra la necesidad de lanzar nuevo software y mantiene el entorno seguro con el entendimiento de que esos cambios necesarios podrían causar tiempo de inactividad.

Asociarse con clientes para crear servicios resilientes

Si tiene necesidades de misión crítica y necesita diseñar una arquitectura para lograr resiliencia y recuperación ante desastres , nuestros equipos de SRE/CRE y PSO pueden trabajar con usted para diseñar sus aplicaciones para unir múltiples regiones y zonas y pueden ayudarlo aún más con el diseño de sistemas de alta disponibilidad (HA).

Si tiene mayores requisitos de disponibilidad en fechas específicas, como Black Friday y Cyber ​​Monday, Google Cloud tiene un programa para asociarse con usted para verificar y validar su aplicación específica que se ejecuta enGoogle Cloud e identificar cualquier dependencia de servicio inesperada entre su aplicación y nuestros servicios.

Puntos de presencia (POP)

Google opera una red global de puntos de presencia de peering, lo que significa que el tráfico de clientes puede viajar dentro de la red de Google hasta estar cerca de su destino, brindando a los usuarios una mejor experiencia y mayor seguridad. Para obtener más información, consulte Ubicaciones del borde de la red .

Gestión geográfica de datos.

Localidad de datos para Google Cloud Los servicios se rigen por los términos de servicio , incluidos los términos específicos del servicio . Google entiende que cada cliente puede tener necesidades únicas de seguridad y cumplimiento. El equipo de ventas de Google Cloud puede ayudarle a cumplir con sus requisitos.

Cuando utilice recursos de almacenamiento regionales o zonales, le recomendamos encarecidamente que replique los datos en otra región o los capture en un recurso de almacenamiento multirregional para fines de recuperación ante desastres.

Consideraciones de implementación de aplicaciones

Para crear servicios y aplicaciones de alta disponibilidad que puedan soportar zonas que dejen de estar disponibles.

Utilice lo siguiente:

Crear aplicaciones con capacidad de recuperación ante desastres que puedan soportar la pérdida prolongada de regiones enteras.

Para los datos, utilice una o más de las siguientes estrategias:

  • Utilice servicios de almacenamiento multirregionales administrados, como Cloud Storage, Datastore, Firestore o Spanner.
  • Utilice recursos zonales o regionales, pero realice instantáneas de datos en un recurso multirregional como Cloud Storage, Datastore, Firestore o Spanner.
  • Utilice recursos zonales o regionales, pero administre su propia replicación de datos en una o más regiones.

Para la computación, utilice la siguiente estrategia:

  • Utilice recursos zonales o regionales, como Compute Engine o App Engine, pero abra su aplicación de forma manual o automática en otra región (en caso de falla regional) haciendo referencia a copias de sus datos primarios si los datos aún no están en un recurso multirregional administrado.

Para obtener más información sobre las dependencias del servicio, comuníquese con ventas .

Soluciones y tutoriales adicionales

Las siguientes soluciones y tutoriales brindan orientación para garantizar que su aplicación tenga alta disponibilidad y pueda soportar interrupciones:

Patrones para aplicaciones escalables y resilientes

Aprende a usar Google Cloud para construir arquitecturas de aplicaciones escalables y resistentes utilizando patrones y prácticas que se apliquen ampliamente a cualquier aplicación web.

Creando un balanceador de carga HTTPS

Configure instancias de Compute Engine en diferentes regiones y use el equilibrio de carga HTTP para distribuir el tráfico entre las regiones para aumentar la disponibilidad entre regiones y proporcionar conmutación por error en caso de una interrupción del servicio.

Diseño de sistemas robustos

Diseñe su aplicación en el servicio Compute Engine para que sea sólida contra fallas, interrupciones de la red y desastres inesperados.

Cassandra Backup y restauración con almacenamiento en la nube

Aprenda cómo agregar recuperación ante desastres básica a su instalación de Cassandra haciendo una copia de seguridad de sus datos y restaurándolos desde Cloud Storage.

Guía de planificación de recuperación ante desastres

Principios generales para diseñar y probar un plan de recuperación ante desastres con Google Cloud.