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. Cualquier recurso de esa región puede usar los recursos regionales, sin importar la zona, mientras que, en el caso de los recursos zonales, solo los pueden usar otros recursos en la misma zona.

Por ejemplo, para conectar 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. La ubicación de recursos en diferentes regiones proporciona un grado aún mayor de independencia de fallas. Esto te permite diseñar sistemas sólidos con recursos distribuidos 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, Compute Engine podría no 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.

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 ordenable, puedes seleccionar diferentes opciones para ver dónde hay recursos disponibles. Por ejemplo, puedes seleccionar Europe en el menú desplegable Seleccionar una ubicación y M2 en el menú desplegable Seleccionar un tipo de máquina para ver una lista de las zonas donde hay máquinas M2 disponibles en Europa.

Cada zona admite una combinación de plataformas Ivy Bridge, Sandy Bridge, Haswell, Broadwell, Skylake o Cascade Lake, así como la plataforma EPYC Rome de AMD. Cuando creas una instancia en una zona, la instancia usa el procesador predeterminado que admite esa zona. 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.

Como alternativa, puedes elegir la plataforma de CPU que desees. Si deseas obtener más información, consulta la sección sobre cómo especificar una plataforma de CPU mínima para instancias de VM.

Zonas Ubicación Tipos de máquina CPU Recursos
asia-east1-a Condado de Changhua, Taiwán, APAC E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
asia-east1-b Condado de Changhua, Taiwán, APAC E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
asia-east1-c Condado de Changhua, Taiwán, APAC E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
asia-east2-a
asia-east2-b
asia-east2-c
Hong Kong, APAC E2, N1 Broadwell, Skylake
asia-northeast1-a Tokio, Japón, APAC E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
asia-northeast1-b Tokio, Japón, APAC E2, N2, N1 Broadwell, Skylake, Cascade Lake
asia-northeast1-c Tokio, Japón, APAC E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
asia-northeast2-a
asia-northeast2-b
asia-northeast2-c
Osaka, Japón, APAC E2, N1 Skylake
asia-northeast3-a
asia-northeast3-b
asia-northeast3-c
Seúl, Corea del Sur, APAC E2, N1 Skylake
asia-south1-a Bombay, India, APAC E2, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake GPU
asia-south1-b Bombay, India, APAC E2, N1, M2, M1 Broadwell, Skylake GPU
asia-south1-c Bombay, India, APAC E2, N1, M1 Broadwell, Skylake
asia-southeast1-a Jurong West, Singapur, APAC E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
asia-southeast1-b Jurong West, Singapur, APAC E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
asia-southeast1-c Jurong West, Singapur, APAC E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
asia-southeast2-a
asia-southeast2-b
asia-southeast2-c
Yakarta, Indonesia, APAC E2, N1 Skylake
australia-southeast1-a Sídney, Australia, APAC E2, N2, N1, C2 Broadwell, Skylake, Cascade Lake
australia-southeast1-b Sídney, Australia, APAC E2, N2, N1, C2, M1 Broadwell, Skylake, Cascade Lake GPU
australia-southeast1-c Sídney, Australia, APAC E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPU
europe-north1-a Hamina, Finlandia, Europa E2, N1, M1 Broadwell, Skylake
europe-north1-b Hamina, Finlandia, Europa E2, N1, Broadwell, Skylake
europe-north1-c Hamina, Finlandia, Europa E2, N1, M1 Broadwell, Skylake
europe-west1-b Saint-Ghislain, Bélgica, Europa E2, N2, N2D, N1, M1, C2 Sandy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
europe-west1-c Saint-Ghislain, Bélgica, Europa E2, N2, N2D, N1, C2 Ivy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
europe-west1-d Saint-Ghislain, Bélgica, Europa E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
europe-west2-a Londres, Inglaterra, Europa E2, N2, N1 Broadwell, Skylake, Cascade Lake GPU
europe-west2-b Londres, Inglaterra, Europa E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
europe-west2-c Londres, Inglaterra, Europa E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
europe-west3-a Fráncfort, Alemania, Europa E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
europe-west3-b Fráncfort, Alemania, Europa E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
europe-west3-c Fráncfort, Alemania, Europa E2, N1 Broadwell, Skylake
europe-west4-a Puerto de Ems, Países Bajos, Europa E2, N2, N1, C2 Broadwell, Skylake, Cascade Lake GPU
europe-west4-b Puerto de Ems, Países Bajos, Europa E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
europe-west4-c Puerto de Ems, Países Bajos, Europa E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
europe-west6-a
europe-west6-b
europe-west6-c
Zúrich, Suiza, Europa E2, N1 Skylake
northamerica-northeast1-a Montreal, Quebec, Norteamérica E2, N1 Broadwell, Skylake GPU
northamerica-northeast1-b Montreal, Quebec, Norteamérica E2, N1, M1 Broadwell, Skylake GPU
northamerica-northeast1-c Montreal, Quebec, Norteamérica E2, N1, M1 Broadwell, Skylake GPU
southamerica-east1-a Osasco, São Paulo, Brasil, Sudamérica E2, N2, N1 Broadwell, Skylake, Cascade Lake
southamerica-east1-b Osasco, São Paulo, Brasil, Sudamérica E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
southamerica-east1-c Osasco, São Paulo, Brasil, Sudamérica E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
us-central1-a Council Bluffs, Iowa, Norteamérica E2, N2, N2D, N1, M1, C2 Sandy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-central1-b Council Bluffs, Iowa, Norteamérica E2, N2, N1, M2, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake GPU
us-central1-c Council Bluffs, Iowa, Norteamérica E2, N2, N2D, N1, M2, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-central1-f Council Bluffs, Iowa, Norteamérica E2, N2, N2D, N1, C2 Ivy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east1-b Moncks Corner, Carolina del Sur, Norteamérica E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east1-c Moncks Corner, Carolina del Sur, Norteamérica E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east1-d Moncks Corner, Carolina del Sur, Norteamérica E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east4-a Ashburn, Virginia, Norteamérica E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east4-b Ashburn, Virginia, Norteamérica E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-east4-c Ashburn, Virginia, Norteamérica E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
us-west1-a The Dalles, Oregón, Norteamérica E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPU
us-west1-b The Dalles, Oregón, Norteamérica E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPU
us-west1-c The Dalles, Oregón, Norteamérica E2, N2, N2D, N1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
us-west2-a Los Ángeles, California, Norteamérica E2, N1, M2, C2 Broadwell, Skylake, Cascade Lake
us-west2-b Los Ángeles, California, Norteamérica E2, N1, M1 Broadwell, Skylake GPU
us-west2-c Los Ángeles, California, Norteamérica E2, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake GPU
us-west3-a
us-west3-b
us-west3-c
Salt Lake City, Utah, Norteamérica E2, N1 Skylake
us-west4-a
us-west4-b
us-west4-c
Las Vegas, Nevada, Norteamérica E2, N1 Skylake

Regiones anunciadas

En 2021, Google continuará su expansión a las siguientes regiones nuevas:

  • 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.

  • Detén y reinicia

    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 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 que debes tener en cuenta cuando selecciones 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, tus instancias pueden experimentar 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 europe-west1-b 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.

Próximos pasos