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. Las zonas y las regiones son abstracciones lógicas de los recursos físicos subyacentes proporcionados en uno o más centros de datos físicos. Estos centros de datos pueden ser propiedad de Google y estar enumerados en la página de ubicación del centro de datos de Google, o pueden alquilarse a través de proveedores externos de centros de datos. Consulta también la lista completa de ubicaciones de los centros de datos de Google Cloud en nuestro certificado ISO/IEC 27001. Google Cloud selecciona los centros de datos y diseña su infraestructura para proporcionar un nivel uniforme de rendimiento, seguridad y confiabilidad, sin importar si el centro de datos es de propiedad o se puede alquilar.

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
  • Bigtable
  • DLP de Cloud
  • API de Cloud Healthcare
  • Cloud Key Management Service
  • Spanner
  • Cloud Storage
  • Database Migration Service
  • Datastore
  • Firestore

Estos servicios multirregión 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 operar a nivel global desde cero y realizar mantenimiento y actualizaciones de forma continua las 24 horas, todos los días del año, sin interrumpirte. Nuestra red troncal global proporciona una gran flexibilidad para el balanceo de cargas y reduce la latencia del usuario final, ya que tiene interconexiones cercanas. Nuestro plano de administración global de la nube simplifica la administración de los desarrollos multirregionales.

Servicios internos

Los servicios de Google Cloud que respaldan y respaldan a muchos de ellos 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 están dedicados a cada región en la que están disponibles. Mientras se balancean las cargas de los servicios en varias regiones, implementamos actualizaciones de forma progresiva región por región, lo que nos permite detectar y abordar problemas sin afectar el uso del servicio. Ninguno de estos servicios internos se limita a un solo 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érica

  • southamerica-west1
  • us-central1
  • us-east1
  • us-east4
  • us-west1
  • us-west4

Europa

  • europe-north1
  • europe-west1
  • europe-west4

Asia

  • asia-east1
  • asia-southeast1

Dependencias de servicios

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

Todos los servicios de Google Cloud se basan en herramientas internas 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 resilientes 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.

Nuestras dependencias principales se enumeran a continuación, y comienzan con dependencias comunes a todos los servicios, con la condición de que los detalles de la implementación de nivel inferior estén sujetos a cambios.

Dependencias comunes para todos los servicios

  • Plano de datos de identidad para la autenticación y la autorización
  • Servicios internos que proporcionan registros, almacenamiento de metadatos y administración de flujos de trabajo
  • El acceso a las API de Google Cloud depende del DNS, los balanceadores de cargas distribuidos en todo el mundo y los puntos de presencia (PoP).
  • La configuración de los 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, Cloud EKM recupera las claves del cliente o Pub/Sub envía mensajes, esas solicitudes dependen de nuestra infraestructura de red global para acceder a esos extremos de cleintes controlados.

Detalles adicionales sobre dependencias

  • Servicios de Compute Engine
    • Los planos de datos de VM de Google Cloud y Persistent Disk dependen de los servicios de Compute Engine y Cloud Storage 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 encriptación y administración de claves para el cliente (Cloud KMS / Cloud EKM) e infraestructura interna para claves de Google
    • Servicios internos para proporcionar registros y auditorías de acceso a los datos
    • Servicios de replicación interna de datos, en los que se espera que los datos estén disponibles en varias regiones
    • Las copias de seguridad configuradas de manera explícita y la replicación a 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.
    • La prevención de ataques de DSD, entre otros, depende de la infraestructura de nivel inferior de Compute Engine.
  • Servicios administrados y alojados, como GKE y Cloud SQL
    • Depende de Compute Engine y Container Registry o Artifact Registry para las imágenes de VM.
  • Infraestructura de nivel inferior independiente
    • Nuestro plano de control interno a nivel del clúster, incluidos Borg y las estructuras de red
    • Almacenamiento a nivel de clúster, como Colossus
    • Infraestructura de administración de claves y encriptación

Mantiene y mejora la disponibilidad y 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 y la falta de disponibilidad del servicio se correlacionan con la implementación de código nuevo o cambios en el entorno. Con las prácticas recomendadas del sector, SRE equilibra la necesidad de lanzar software nuevo y mantiene el entorno seguro, ya que comprende que los cambios necesarios podrían causar tiempo de inactividad.

Asociación con los 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 Spanner.
  • Usa recursos zonales o regionales, pero guarda instantáneas de los datos en recursos multirregionales, como Cloud Storage, Datastore, Firestore o 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 para 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.