Geografía y regiones

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

Los servicios de infraestructura deGoogle Cloud están disponibles en ubicaciones de América del Norte, América del Sur, Asia, Australia, Europa y Oriente Medio. Estas ubicaciones se dividen en regiones y zonas. Puedes elegir dónde quieres que se ubiquen tus aplicaciones de forma que cumplan los requisitos de latencia, disponibilidad y durabilidad que hayas definido.

Pruébalo

Si es la primera vez que utilizas Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los nuevos clientes también reciben 300 USD en crédito gratuito para ejecutar, probar y desplegar cargas de trabajo.

Empezar gratis

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. 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, Montreal y Osaka tienen tres zonas alojadas en uno o dos centros de datos físicos. Estas regiones están en proceso de ampliarse a al menos tres centros de datos físicos. Cuando diseñes tus soluciones enGoogle Cloud, ten en cuenta las directrices de Ubicaciones de Cloud, Google Cloud SLAs de la plataforma y la Google Cloud documentación del producto correspondiente.

Estos centros de datos pueden ser propiedad de Google y aparecer en la página de ubicacionesGoogle Cloud , o bien pueden alquilarse a proveedores externos de centros de datos. Para ver la lista completa de ubicaciones de centros de datos de Google Cloud, consulte nuestro certificado ISO/IEC 27001. Independientemente de si el centro de datos es de su propiedad o está alquilado, Google Cloud selecciona centros de datos y diseña su infraestructura para ofrecer un nivel uniforme de rendimiento, seguridad y fiabilidad.

Una zona es un área de implementación de Google Cloud recursos dentro de una región. Las zonas se consideran como un único dominio del fallo dentro de una región. Para desplegar aplicaciones tolerantes a fallos con alta disponibilidad y protegerte frente a fallos inesperados, despliega tus aplicaciones en varias zonas de una región.

Para protegerte frente a la pérdida de una región completa debido a un desastre natural, ten un plan de recuperación tras desastres y sepas cómo poner en marcha tu aplicación en el improbable caso de que se pierda tu región principal. Consulta 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 en cada opción de ubicación, consulta nuestras ubicaciones de Cloud.

Los servicios y recursos deGoogle Cloudpueden ser de zona, regionales o gestionados por Google en varias regiones. Para obtener más información sobre lo que significan estas opciones para tus datos, consulta el artículo sobre la gestión geográfica de los datos.

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

Recursos de zona

Los recursos de zona operan en una única zona. Las interrupciones zonales pueden afectar a algunos o a todos los recursos de esa zona. Un ejemplo de recurso de zona es una instancia de máquina virtual de Compute Engine que reside en una zona específica.

Recursos regionales

Los recursos regionales son recursos que se despliegan de forma redundante en varias zonas de una región. Por ejemplo, las aplicaciones de App Engine o los grupos de instancias gestionadas regionales. De esta manera, tienen una mayor disponibilidad que los recursos de zona.

Recursos multirregionales

Google gestiona varios Google Cloud servicios para que sean redundantes y estén distribuidos dentro de una misma región y en distintas regiones. Estos servicios optimizan la disponibilidad, el rendimiento y la eficacia de los recursos. Por lo tanto, estos servicios requieren un equilibrio entre la latencia y el modelo de coherencia. Las medidas que se toman para conseguir ese equilibrio se documentan por separado para cada producto.

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

• Artifact Registry
• Bigtable
• Protección de datos sensibles
• API de Cloud Healthcare
• Cloud KMS
• Container Registry
• Spanner
• Cloud Storage
• Database Migration Service
• Datastore
• Firestore

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

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

Servicios globales

Google Cloud se ha diseñado para operar a nivel mundial desde el principio y realiza tareas de mantenimiento y actualizaciones de forma continua, las 24 horas del día, los 7 días de la semana y los 365 días del año, sin causarte molestias. Nuestra red troncal mundial ofrece una gran flexibilidad para el balanceo de carga y reduce la latencia de los usuarios finales al tener interconexiones cerca de ti. Nuestro plano de gestión en la nube global simplifica la gestión de los desarrollos multirregionales.

Servicios internos

Muchos servicios orientados al cliente se basan en un conjunto de servicios internos probados, como Spanner, Colossus, Borg y Chubby. Google Cloud

Estos servicios internos se balancean de carga de forma global en varias regiones o se dedican a cada región en la que están disponibles. Cuando los servicios tienen el balanceo de carga en varias regiones, desplegamos las actualizaciones de forma progresiva por regiones, lo que nos permite detectar y solucionar problemas sin que afecten al uso de tu 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é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

Por lo general, en el caso de los Google Cloud servicios, si falla una sola región, solo se verán afectados los clientes que se encuentren en esa región. Los clientes que tengan productos multirregionales no se verán afectados. Google Cloud tiene una arquitectura significativa para evitar que se produzcan fallos correlacionados en varias regiones.

Todos los Google Cloud servicios dependen de herramientas internas básicas para proporcionar servicios fundamentales, como 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 dejan de estar disponibles.

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

Nuestras principales dependencias se enumeran a continuación, empezando por las dependencias comunes a todos los servicios, con la condición de que los detalles de implementación de nivel inferior están sujetos a cambios.

Dependencias comunes de todos los servicios

• Plano de datos de identidad para la autenticación y la autorización
• Servicios internos que proporcionan registro, almacenamiento de metadatos y gestión de flujos de trabajo
• El acceso a las APIs de Google Cloud depende del DNS, de los balanceadores de carga distribuidos a nivel mundial y de los puntos de presencia (PoPs).
• La configuración de los recursos globales: por ejemplo, las políticas de gestión de identidades y accesos, las reglas de firewall globales, las configuraciones de balanceadores de carga globales y los temas de Pub/Sub se almacenan en bases de datos replicadas.
• Cuando los servicios hacen solicitudes a endpoints controlados por el cliente (por ejemplo, Cloud EKM obtiene claves del cliente o Pub/Sub envía mensajes), esas solicitudes dependen de nuestra infraestructura de red global para acceder a esos endpoints controlados por el cliente. Google Cloud

Servicios con dependencias adicionales

• Servicios de Compute Engine
  • Los planos de datos de las Google Cloud VMs y los discos persistentes 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 lo siguiente:
  • Infraestructura de encriptado y gestión de claves para clientes (Cloud KMS y Cloud EKM) e infraestructura interna para claves propiedad 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 y la replicación configuradas explícitamente en otras regiones dependen de la red entre regiones
• Servicios de mensajería
  • Pub/Sub depende de nuestra infraestructura de red global para acceder a los endpoints controlados por los clientes.
• Servicios de redes
  • El balanceo de carga global, el DNS y la conmutación por error entre regiones dependen de la infraestructura de redes físicas.
  • La prevención de ataques DDoS y similares depende de la infraestructura de Compute Engine de nivel inferior.
• Servicios gestionados 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 de nivel inferior independiente
  • Nuestro plano de control interno a nivel de clúster, que incluye Borg y tejidos de red
  • Almacenamiento a nivel de clúster, como Colossus
  • Infraestructura de encriptado 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 se relacionan con la implementación de código nuevo o con cambios en el entorno. Al usar las prácticas recomendadas del sector, los ingenieros de fiabilidad de sitios equilibran la necesidad de lanzar software nuevo y mantienen el entorno seguro, sabiendo que esos cambios necesarios pueden provocar tiempos de inactividad.

Colaboración con los clientes para crear servicios resilientes

Si tienes necesidades críticas y necesitas diseñar una arquitectura para la resiliencia y la recuperación ante desastres, nuestros equipos de ingenieros de fiabilidad de sitios y de ingenieros de fiabilidad de clientes, así como el equipo de Servicios Profesionales, pueden ayudarte a diseñar tus aplicaciones para que abarquen varias regiones y zonas, y también pueden ayudarte a diseñar sistemas de alta disponibilidad.

Si tienes requisitos de disponibilidad más exigentes en fechas concretas, como el Black Friday y el Cyber Monday, Google Cloud dispone de un programa para colaborar contigo en la comprobación y validación de tu aplicación específica enGoogle Cloud , así como para identificar dependencias de servicios inesperadas entre tu aplicación y nuestros servicios.

Puntos de presencia (POPs)

Google opera una red mundial de puntos de presencia de emparejamiento, lo que significa que el tráfico de los clientes puede viajar dentro de la red de Google hasta que esté cerca de su destino, lo que proporciona a los usuarios una mejor experiencia y mayor seguridad. Para obtener más información, consulta las ubicaciones de la red perimetral.

Gestión geográfica de datos

La localidad de los datos de los servicios de Google Cloud se rige por los términos del servicio, incluidos los términos específicos del servicio. Google es consciente de que cada cliente puede tener necesidades de seguridad y cumplimiento únicas. El equipo de Ventas de Google Cloud puede ayudarte a cumplir tus requisitos.

Cuando uses recursos de almacenamiento regionales o zonales, te recomendamos que repliques los datos en otra región o que crees una instantánea en un recurso de almacenamiento multirregional para poder recuperarlos si se produce un desastre.

Consideraciones sobre la implementación de aplicaciones

Para crear servicios y aplicaciones de alta disponibilidad que puedan resistir la falta de disponibilidad de las zonas

Utiliza lo siguiente:

• Recursos regionales, como aplicaciones de App Engine, grupos de instancias gestionados regionales o recursos multirregionales gestionados, como Cloud Storage, Datastore, Firestore o Spanner.
• Recursos zonales, como las máquinas virtuales de Compute Engine, pero gestiona tu propia redundancia de almacenamiento y computación en zonas o regiones.

Para crear aplicaciones capaces de recuperarse tras fallos que puedan resistir la pérdida prolongada de regiones enteras

Para los datos, utiliza una o varias de las siguientes estrategias:

• Utiliza servicios de almacenamiento multirregionales gestionados, como Cloud Storage, Datastore, Firestore o Spanner.
• Usa recursos zonales o regionales, pero crea una instantánea de los datos en un recurso multirregional, como Cloud Storage, Datastore, Firestore o Spanner.
• Usa recursos zonales o regionales, pero gestiona tu propia replicación de datos en una o varias regiones.

Para el cálculo, sigue esta estrategia:

• Usa recursos zonales o regionales, como Compute Engine o App Engine, pero activa tu aplicación de forma manual o automática en otra región (en caso de fallo regional) haciendo referencia a copias de tus datos principales si estos aún no están en un recurso multirregional gestionado.

Para obtener más información sobre las dependencias de los servicios, ponte en contacto con el equipo de Ventas.

Soluciones y tutoriales adicionales

Las siguientes soluciones y tutoriales proporcionan directrices para asegurarse de que su aplicación tenga una alta disponibilidad y pueda resistir interrupciones: