Regiones y zonas

Los recursos de Compute Engine se alojan en varias ubicaciones en todo el mundo. Estas ubicaciones se componen de regiones y zonas. Una región es una ubicación geográfica específica donde puedes alojar recursos. Cada región tiene una o más zonas. La mayoría de las regiones tienen tres o más zonas. Por ejemplo, la región us-west1 corresponde a una región en la costa oeste de Estados Unidos que tiene tres zonas: us-west1-a, us-west1-b y us-west1-c.

Los recursos que se ubican en una zona, como las instancias de máquina virtual o los discos persistentes zonales, se denominan recursos zonales. Otros recursos, como las direcciones IP externas estáticas, son regionales. Los recursos regionales los puede usar cualquier recurso en esa región, sin importar la zona, mientras que los recursos zonales solo los pueden usar otros recursos en la misma zona.

Por ejemplo, para adjuntar un disco persistente zonal a una instancia, ambos recursos deben estar en la misma zona. Del mismo modo, si quieres asignar una dirección IP estática a una instancia, esta debe estar en la misma región que la dirección IP estática.

Ubicar recursos en diferentes zonas de una misma región proporciona aislamiento de la mayoría de los tipos de fallas de infraestructura física y servicio de software de infraestructura. Ubicar recursos en diferentes regiones proporciona un grado aún mayor de independencia de fallas. Esto te permite diseñar sistemas sólidos mediante la distribución de recursos en diferentes dominios con fallas.

Solo ciertos recursos son específicos de una región o zona. Otros recursos, como las imágenes, son recursos globales que cualquier otro recurso puede usar en cualquier ubicación. Para obtener información sobre los recursos globales, regionales y zonales de Compute Engine, consulta Recursos globales, regionales y zonales.

Zonas y clústeres

Compute Engine implementa una capa de abstracción entre las zonas y los clústeres físicos donde estas se alojan. Un clúster representa una infraestructura física definida que se aloja en un centro de datos. Cada clúster posee infraestructura de software, alimentación, enfriamiento, infraestructura de seguridad y redes independientes, además de un gran conjunto de recursos de procesamiento y almacenamiento.

Cada zona se aloja en uno o más clústeres, y Compute Engine asigna las zonas a los clústeres de manera independiente para cada organización. Por ejemplo, la zona us-central1-a de tu organización puede no tener asignado el mismo clúster que la zona us-central1-a de otra organización.

Separar las zonas de los clústeres proporciona una serie de beneficios para Compute Engine y para ti:

  • Permite a Compute Engine garantizar que los recursos estén equilibrados entre los clústeres de una región.
  • La lista de zonas de la que puedes elegir sigue siendo administrable a medida que Compute Engine continúa aumentando sus regiones mediante la adición de más clústeres.

Para la mayoría de las organizaciones, Compute Engine garantiza que todos los proyectos de una organización tengan una asignación de zona a clúster coherente. En el caso de aquellas organizaciones con proyectos que usan el Intercambio de tráfico entre redes de VPC o el Acceso privado a servicios para compartir redes o servicios con otras organizaciones, Compute Engine intenta garantizar que todas las organizaciones con intercambio de tráfico tengan una asignación de zona a clúster coherente. En el caso de los proveedores de SaaS a gran escala, por ejemplo, es posible que Compute Engine no pueda proporcionar una asignación coherente para todas las organizaciones con intercambio de tráfico. En estos casos, Compute Engine garantiza que los proyectos con intercambio de tráfico tengan una asignación de zona a clúster coherente.

Ubicaciones

En la siguiente tabla, se muestran las ubicaciones de todas las regiones de Compute Engine y sus zonas asociadas. Consulta la sección sobre las regiones y zonas disponibles para obtener una descripción detallada de los tipos de máquina disponibles en cada zona y sus características.

Región Zonas Ubicación
asia-east1 a, b, c Condado de Changhua, Taiwán
asia-east2 a, b, c Hong Kong
asia-northeast1 a, b, c Tokio, Japón
asia-northeast2 a, b, c Osaka, Japón
asia-south1 a, b, c Bombay, India
asia-southeast1 a, b, c Jurong West, Singapur
australia-southeast1 a, b, c Sídney, Australia
europe-north1 a, b, c Hamina, Finlandia
europe-west1 b, c, d Saint-Ghislain, Bélgica
europe-west2 a, b, c Londres, Inglaterra, Reino Unido
europe-west3 a, b, c Fráncfort, Alemania
europe-west4 a, b, c Puerto de Ems, Países Bajos
europe-west6 a, b, c Zúrich, Suiza
northamerica-northeast1 a, b, c Montreal, Quebec, Canadá
southamerica-east1 a, b, c Osasco (São Paulo), Brasil
us-central1 a, b, c, f Council Bluffs, Iowa, EE.UU.
us-east1 b, c, d Moncks Corner, Carolina del Sur, EE.UU.
us-east4 a, b, c Ashburn, Virginia, EE.UU.
us-west1 a, b, c The Dalles, Oregón, EE.UU.
us-west2 a, b, c Los Ángeles, California, EE.UU.

Elige una región y una zona

Tú eliges qué región o zona aloja tus recursos, y esto controla dónde se almacenan y usan tus datos. Elegir una región y una zona es importante por varias razones:

Manejo de fallas
Distribuye tus recursos en varias zonas y regiones para tolerar interrupciones. Google diseña las zonas de modo que sean independientes unas de otras: por lo general, una zona cuenta con alimentación, enfriamiento, herramientas de redes y planos de control que están aislados de otras zonas. De este modo, la mayoría de los eventos de fallas individuales afectarán solo a una zona. Por lo tanto, si una zona deja de estar disponible, puedes transferir el tráfico a otra zona en la misma región para que tus servicios sigan en funcionamiento. Del mismo modo, ante la posibilidad de que una región experimente alguna alteración, debes tener servicios de respaldo en funcionamiento en otra región. Para obtener más información sobre la distribución de recursos y el diseño de sistemas sólidos, consulta Diseña sistemas sólidos.
Disminución de la latencia de red
Para disminuir la latencia de red, te recomendamos elegir una región o zona que esté cerca de tu punto de servicio. Por ejemplo, si la mayoría de tus clientes están en la Costa Este de EE.UU., es conveniente que elijas una región y zona principales que estén cerca de esa área y, una región y zona de respaldo que también estén cerca.

Identifica una región o zona

Cada región en Compute Engine contiene varias zonas. El nombre de cada zona se forma con dos partes que describen la zona en detalle. La primera parte del nombre de la zona es la región y la segunda parte describe la zona en la región:

  • Región

    Las regiones son conjuntos de zonas. Las zonas se comunican con otras zonas de una misma región mediante conexiones de red con un amplio ancho de banda y latencia baja. Para implementar aplicaciones tolerantes a errores que tengan alta disponibilidad, Google recomienda implementar las aplicaciones en varias zonas y regiones. Esto ayuda a proteger las aplicaciones contra las fallas inesperadas de los componentes en una sola zona o región.

    Elige las regiones adecuadas para tu caso particular. Por ejemplo, si solo tienes clientes en EE.UU., o si tienes necesidades específicas que requieren que tus datos se ubiquen en EE.UU., es lógico que almacenes los recursos en zonas dentro de las regiones us-central1 o us-east1.

  • Zona

    Una zona es una ubicación aislada dentro de la región. El nombre completo de una zona está compuesto por <region>-<zone>. Por ejemplo, el nombre completo de la zona a en la región us-central1 es us-central1-a.

    Según la amplitud con que desees distribuir los recursos, crea instancias en varias zonas en distintas regiones para generar redundancia.

Regiones y zonas disponibles

En la siguiente tabla, se enumeran las regiones, sus ubicaciones, las zonas disponibles en cada región y las características disponibles en las zonas de cada región.

Cada zona es compatible con combinaciones de las plataformas Ivy Bridge, Sandy Bridge, Haswell, Broadwell, Skylake, o Cascade Lake. Cuando crees una instancia en una zona, la instancia usará el procesador que esa zona admite de forma predeterminada. Por ejemplo, si creas una instancia en la zona us-central1-a, la instancia usará un procesador Haswell de forma predeterminada, a menos que especifiques otra opción.

De forma alternativa, puedes elegir la plataforma de CPU que desees. Para obtener más información, consulta Especifica una plataforma de CPU mínima para instancias de VM.

Nombre de la región Descripción de la región Ubicación Zonas Características
asia-east1 Taiwán Condado de Changhua, Taiwán asia-east1-a
asia-east1-b
asia-east1-c
asia-east2 Hong Kong Hong Kong asia-east2-a
asia-east2-b
asia-east2-c
asia-northeast1 Tokio Tokio, Japón asia-northeast1-a
asia-northeast1-b
asia-northeast1-c
asia-northeast2 Osaka Osaka, Japón asia-northeast2-a
asia-northeast2-b
asia-northeast2-c
asia-south1 Bombay Bombay, India asia-south1-a
asia-south1-b
asia-south1-c
asia-southeast1 Singapur Jurong West, Singapur asia-southeast1-a
asia-southeast1-b
asia-southeast1-c
australia-southeast1 Sídney Sídney, Australia australia-southeast1-a
australia-southeast1-b
australia-southeast1-c
europe-north1 Finlandia Hamina, Finlandia europe-north1-a
europe-north1-c
europe-north1-b
europe-west1 Bélgica Saint-Ghislain, Bélgica europe-west1-b
europe-west1-c
europe-west1-d
europe-west2 Londres Londres, Inglaterra, Reino Unido europe-west2-a
europe-west2-b
europe-west2-c
europe-west3 Fráncfort Fráncfort, Alemania
europe-west3-a
europe-west3-b
    europe-west3-c
europe-west4 Países Bajos Puerto de Ems, Países Bajos europe-west4-a
europe-west4-b
europe-west4-c
europe-west6 Zúrich Zúrich, Suiza europe-west6-a
europe-west6-b
europe-west6-c
northamerica-northeast1 Montreal Montreal, Quebec, Canadá northamerica-northeast1-a
northamerica-northeast1-b
northamerica-northeast1-c
southamerica-east1 Osasco Osasco, São Paulo, Brasil southamerica-east1-a
southamerica-east1-b
southamerica-east1-c
us-central1 Iowa Council Bluffs, Iowa, EE.UU. us-central1-a
us-central1-b
us-central1-c
us-central1-f
us-east1 Carolina del Sur Moncks Corner, Carolina del Sur, EE.UU. us-east1-b
    us-east1-c
    us-east1-d
us-east4 Virginia del Norte Ashburn, Virginia, EE.UU. us-east4-a
us-east4-b
us-east4-c
us-west1 Oregón The Dalles, Oregón, EE.UU. us-west1-a
us-west1-b
us-west1-c
us-west2 Los Ángeles Los Ángeles, California, EE.UU. us-west2-a
us-west2-b
us-west2-c

Regiones anunciadas

Durante 2019 y 2020, Google se expandirá en las siguientes regiones nuevas:

  • Zúrich (Suiza) ¡Lanzado!
  • Osaka (Japón) ¡Lanzado!
  • Seúl, (Corea del Sur)
  • Salt Lake City, Utah (EE.UU.)
  • Las Vegas, Nevada (EE.UU.)
  • Yakarta, (Indonesia)
  • Varsovia (Polonia)

Mantenimiento transparente

Google lleva a cabo el mantenimiento de su infraestructura de forma periódica mediante la aplicación de parches en los sistemas con el software más reciente, la realización de pruebas de rutina y el mantenimiento preventivo. Google se asegura de que su infraestructura sea tan rápida y eficiente como solo ellos saben hacerlo.

De forma predeterminada, todas las instancias están configuradas a fin de que estos eventos de mantenimiento sean transparentes para tus aplicaciones y cargas de trabajo. Google usa una combinación de innovaciones de centros de datos, prácticas recomendadas operativas y tecnología de migración en vivo para mover las instancias de máquina virtual en ejecución de modo que no obstaculicen el mantenimiento que se lleva a cabo. Tu instancia continúa ejecutándose dentro de la misma zona sin ninguna acción de tu parte.

De forma predeterminada, todas las máquinas virtuales están configuradas en el modo de migración en vivo, pero también puedes configurarlas para que se detengan y se reinicien. A continuación, se explican las diferencias entre ambas opciones:

  • Migración en vivo

    Compute Engine migra tu instancia en ejecución de forma automática. El proceso de migración afecta el rendimiento del invitado en cierta medida, pero la instancia permanece en línea durante todo el proceso de migración. El impacto y la duración exactos del rendimiento del invitado dependen de muchos factores, pero se espera que la mayoría de las aplicaciones y cargas de trabajo no lo noten. Para obtener más información, consulta la documentación sobre migración en vivo.

  • Finalizar y reiniciar

    Compute Engine le indica a tu instancia de forma automática que se apague, espera un período corto hasta que se apague de forma correcta y, luego, la reinicia lejos del evento de mantenimiento.

Para obtener más información sobre cómo configurar las opciones de instancia antes descritas, consulta Configura políticas de disponibilidad de instancia.

Baja de zonas

Nunca es necesario inhabilitar una zona existente para actualizar la infraestructura desde cero (alimentación, enfriamiento, estructura de red, servidores, etcétera). Las actualizaciones de infraestructura son poco frecuentes y las zonas suelen ejecutarse durante un período de tres a cinco años entre actualizaciones. Estas actualizaciones deben ser transparentes para los clientes.

Si alguna vez se vuelve necesario dar de baja una zona, Compute Engine les notificará a los usuarios con mucha anticipación cuándo quedará sin conexión a fin de que tengan tiempo suficiente para mover las instancias de máquina virtual y las cargas de trabajo.

Cuotas

Algunos recursos, como direcciones IP estáticas, imágenes, reglas de firewall y redes de VPC, tienen límites de cuota en todo el proyecto y límites de cuota por región definidos. Cuando creas estos recursos, se usa tu cuota total del proyecto o la cuota por región, si corresponde. Si se excede alguno de los límites de cuota afectados, no podrás agregar más recursos del mismo tipo en ese proyecto o región.

Para ver una lista completa de las cuotas que se aplican a tu proyecto, visita la página sobre cuotas en Google Cloud Platform Console.

Por ejemplo, supongamos que tu cuota global de grupos de destino es de 50. Si creas 25 grupos de destino en región-ejemplo-1 y 25 grupos de destino en región-ejemplo-2, alcanzas tu cuota de todo el proyecto y no puedes crear más grupos de destino en ninguna región dentro del proyecto hasta que liberes espacio. Del mismo modo, si tienes una cuota por región de 7 direcciones IP reservadas, solo puedes reservar hasta 7 direcciones IP en una misma región. Una vez alcanzado ese límite, deberás reservar direcciones IP en una región nueva o liberar algunas direcciones IP.

Sugerencias

A continuación, se describen algunos aspectos para tener en cuenta al momento de seleccionar zonas:

  • La comunicación dentro de las regiones, y entre ellas, generará diferentes costos.

    En general, la comunicación dentro de una misma región siempre será más barata y rápida que la comunicación entre diferentes regiones.

  • Diseña sistemas importantes con redundancia en varias zonas.

    En algún momento, es posible que las instancias experimenten una falla inesperada. Para mitigar los efectos de estos posibles eventos, debes duplicar los sistemas importantes en varias zonas y regiones.

    Por ejemplo, si alojas instancias en las zonas europe-west1-b y europe-west1-c, y falla de forma inesperada, tus instancias en la zona europe-west1-c aún estarán disponibles. Sin embargo, si alojas todas sus instancias en europe-west1-b, no podrás acceder a ninguna instancia si europe-west1-b se queda sin conexión. Además, considera alojar tus recursos en varias regiones. Por ejemplo, en el caso poco probable de que la región europe-west1 experimente una falla, considera alojar instancias de respaldo en una zona dentro de la región europe-west3. Si quieres obtener más sugerencias sobre cómo diseñar sistemas para tener disponibilidad, consulta Diseña sistemas sólidos.

Qué sigue

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

Documentación de Compute Engine