Geografía y regiones

Los productos de Google Cloud se entregan desde dominios con fallas regional específicos y son totalmente compatibles con los Acuerdos de Nivel de Servicio para garantizar que diseñes la arquitectura de tu aplicación en la estructura de Google Cloud

Los servicios de infraestructura de Google Cloud están disponibles en diferentes ubicaciones de América del Norte, América del Sur, Europa, Asia y Australia. Estas ubicaciones se dividen en regiones y zonas. Para satisfacer los requisitos de latencia, disponibilidad y durabilidad, puedes elegir la ubicación de las aplicaciones.

Pruébalo tú mismo

Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Comenzar gratis

Regiones y zonas

Las regiones son áreas geográficas independientes que constan de zonas.

Una zona es un área de implementación para los recursos de Google Cloud dentro de una región. Las zonas se deben considerar como dominios con fallas únicos dentro de una región. Para implementar aplicaciones tolerantes a errores con alta disponibilidad y ayudar a proteger contra fallas inesperadas, implementa las aplicaciones en varias zonas de una región.

Para protegerte contra la pérdida de una región entera debido a un desastre natural, debes tener un plan de recuperación ante desastres y saber cómo abrir la aplicación en el caso de que se pierda la región principal. Consulta las consideraciones para implementar una aplicación a fin de obtener más información.

Si deseas obtener más información acerca de los recursos específicos disponibles dentro de cada opción de ubicación, consulta nuestras ubicaciones de Cloud.

Los servicios y recursos de Google Cloud pueden estar administrados por Google en varias regiones o bien ser zonales o regionales. Si quieres obtener más información sobre lo que implican estas opciones para los datos, consulta la administración geográfica de los datos.

Recursos zonales

Los recursos zonales operan dentro de una sola zona. Las interrupciones zonales pueden afectar a algunos o a todos los recursos de esa zona. Un ejemplo de un 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 manera redundante en varias zonas dentro de una región, por ejemplo, las aplicaciones de App Engine o los grupos de instancias regionales administrados. Esto les permite tener una disponibilidad más alta en comparación con los recursos zonales.

Recursos multirregionales

Google administra varios servicios de Google Cloud para que sean redundantes y se distribuyan dentro de las regiones y entre ellas. Estos servicios permiten optimizar la disponibilidad, el rendimiento y la eficiencia de los recursos. Como resultado, estos servicios requieren una compensación entre la latencia o el modelo de coherencia. Y se documentan específicamente para cada producto.

Los siguientes servicios tienen una o más ubicaciones multirregionales además de las ubicaciones regionales:

  • BigQuery
  • Cloud Bigtable
  • Cloud Data Loss Prevention
  • API de Cloud Healthcare
  • Cloud Key Management Service
  • Cloud Spanner
  • Cloud Storage
  • Datastore
  • Firestore

Estos servicios multirregionales están diseñados para poder funcionar después de la pérdida de una sola región.

Puedes encontrar los parámetros de configuración y opciones exactos de cada producto con respecto a las regiones y zonas de la documentación pública de Google Cloud.

Servicios globales

Google Cloud se diseñó para que funcione a nivel global desde cero y realiza de forma continua el mantenimiento y las actualizaciones las 24 horas, todos los días, sin interrupciones. Nuestra red global brinda flexibilidad para el balanceo de cargas y reduce la latencia del usuario final, ya que tiene interconexiones cercanas. Nuestro plano global de administración en la nube simplifica la administración de desarrollos multirregionales.

Servicios internos

El respaldo y la asistencia de muchos servicios de Google Cloud orientados a clientes son un conjunto de servicios internos comprobados como Spanner, Colossus, Borg y Chubby.

Estos servicios internos tienen balanceo de cargas global en varias regiones o dedicadas a cada región en la que están disponibles. Cuando los servicios se balancean según la carga en varias regiones, implementamos actualizaciones de forma progresiva por región, lo que nos permite detectar y solucionar problemas sin afectar el uso de tus servicios. Ninguno de estos servicios internos se limita a un único centro de datos lógico o a una sola región.

Dependencias de servicios

En general, para los servicios de Google Cloud, si falla una sola región, solo se ven afectados los clientes de esa región. los clientes que tienen productos multirregionales no se ven afectados. Google Cloud tiene una arquitectura significativa con el objetivo de prevenir fallas correlacionadas en todas las regiones.

Todos los servicios de Google Cloud dependen de herramientas internas centrales para proporcionar servicios fundamentales, como herramientas de redes (dentro y fuera de los centros de datos), acceso a 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 no están disponibles.

Google Cloud proporciona instrucciones claras sobre cómo los clientes pueden diseñar sus aplicaciones para el nivel deseado de resiliencia en nuestrositio web público, en especial para productos de Google Cloud más utilizados, como Compute Engine, BigQuery, Pub/Sub y otros servicios.

A continuación, se enumeran nuestras principales dependencias, comenzando con dependencias comunes a todos los servicios. El provisor que supervisa los detalles de implementación de nivel inferior 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 administración de flujo de trabajo
  • El acceso a las API de Google Cloud depende de DNS, balanceadores de cargas distribuidos en todo el mundo 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 cargas global y los temas de Pub/Sub se almacenan en bases de datos replicadas.
  • Cuando los servicios de Google Cloud realizan solicitudes a extremos controlados por el cliente, por ejemplo, que recupera las claves del cliente o envía mensajes Pub/Sub, esas solicitudes dependen de nuestra infraestructura de red global para acceder a esos clientes. extremos controlados.

Detalles adicionales sobre las dependencias

  • Servicios de Compute Engine
    • Los planos de datos de Persistent Disk y VM de Google Cloud dependen de los servicios de Cloud Storage y de Compute Engine de nivel inferior, como Borg y Colossus.
  • Los servicios de almacenamiento de infraestructura y Google Cloud, como Spanner, Bigtable y Cloud Storage dependen de lo siguiente:
    • Infraestructura de administración de claves y encriptación para clientes (Cloud KMS / Cloud EKM) y también infraestructura interna para claves de Google
    • Servicios internos para proporcionar registros y auditorías de acceso a los datos
    • Servicios de replicación de datos internos, en los que se espera que los datos estén disponibles en varias regiones
    • Las copias de seguridad configuradas de manera explícita y las otras regiones dependen de las redes entre regiones
  • Servicios de mensajes
    • Pub/Sub depende de nuestra infraestructura de red global para acceder a los extremos controlados por el cliente.
  • Servicios de Herramientas de redes
    • El balanceo de cargas global, el DNS y la conmutación por error entre regiones dependen de la infraestructura de red física.
    • Evitar ataques de 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 de Artifact Registry para las imágenes de VM.
  • Infraestructura de bajo nivel autónomo
    • Nuestro plano de control interno a nivel de clúster, como Borg y redes
    • Almacenamiento a nivel del clúster, como Colossus
    • Infraestructura de administración de claves y encriptación

Mantén y mejora la disponibilidad y la resiliencia

La ingeniería de confiabilidad de sitios (SRE) es la organización interna de Google dedicada a trabajar en disponibilidad, latencia, rendimiento y capacidad. Las interrupciones de servicio y la falta de disponibilidad se correlacionan con la implementación de código nuevo o con cambios en el entorno. Gracias a las prácticas recomendadas de la industria, SRE equilibra la necesidad de lanzar software nuevo y mantiene el entorno seguro con la comprensión de que esos cambios necesarios pueden causar tiempo de inactividad.

Asociación con clientes para compilar servicios resilientes

Si tienes necesidades esenciales y necesitas diseñar para la resiliencia y la recuperación ante desastres, nuestros equipos de SRE/CRE y PSO pueden trabajar contigo a fin de diseñar tus aplicaciones para que se conecten varias regiones y zonas, y te pueden ayudar aún más a diseñar sistemas de alta disponibilidad (HA).

Si aumentas los requisitos de disponibilidad en fechas específicas, como el Black Friday o el Cyber Monday, Google Cloud tiene un programa que te permitirá asociarte con el fin de verificar y validar tu aplicación específica que se ejecuta en GCP y que identifica las dependencias de servicio inesperadas entre tu aplicación y nuestros servicios.

Administración geográfica de los datos

La ubicación de los datos de los servicios de Google Cloud se rige por las Condiciones del Servicio, incluidos los términos específicos del servicio. Google comprende que cada cliente puede tener necesidades de seguridad y cumplimiento únicas. El equipo de ventas de Google Cloud puede ayudarte a satisfacer tus requisitos.

Cuando uses recursos de almacenamiento regionales o zonales, te recomendamos que repliques los datos en otra región o guardes instantáneas en un recurso de almacenamiento multirregional para la recuperación ante desastres.

Consideraciones para implementar aplicaciones

Puedes compilar servicios y aplicaciones con alta disponibilidad capaces de resistir las fallas de las zonas.

Para ello, usa los siguientes recursos:

Puedes compilar aplicaciones preparadas para la recuperación ante desastres y que puedan resistir la pérdida prolongada de regiones completas.

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

  • Usa servicios de almacenamiento multirregionales administrados, como Cloud Storage, Datastore, Firestore o Cloud Spanner.
  • Usa recursos zonales o regionales, pero guarda instantáneas de los datos en recursos multirregionales, como Cloud Storage, Datastore, Firestore o Cloud Spanner.
  • Usa recursos regionales o zonales, pero administra la replicación de tus datos en una o más regiones adicionales.

Para el procesamiento, usa la siguiente estrategia:

  • Usa recursos zonales o regionales, como Compute Engine o App Engine, pero activa la aplicación, de forma manual o automática, en otra región (en caso de fallas regionales) mediante referencias a copias de los datos principales, si es que estos no se encuentran en un recurso multirregional administrado.

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

Instructivos y soluciones adicionales

Los siguientes instructivos y soluciones sirven de guía para garantizar que tu aplicación pueda resistir las fallas y ofrecer alta disponibilidad:

Patrones de apps escalables y resilientes

Aprende a usar Google Cloud para compilar arquitecturas de aplicaciones escalables y resilientes mediante patrones y prácticas que se suelen usar en cualquier aplicación web.

Crea un balanceador de cargas de HTTPS

Configura las instancias de Compute Engine en regiones distintas y usa el balanceo de cargas de HTTP para distribuir el tráfico entre regiones y aumentar la disponibilidad entre estas, además de brindar conmutación por error en caso de que falle un servicio.

Diseña sistemas sólidos

Diseña la aplicación en el servicio de Compute Engine para que pueda resistir fallas, interrupciones de red y desastres inesperados.

Copia de seguridad y restablecimiento de Cassandra con Cloud Storage

Obtén información sobre cómo agregar la recuperación ante desastres básica a la instalación de Cassandra mediante la creación de una copia de seguridad de los datos y su restablecimiento desde Cloud Storage.

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

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