En este documento, se explica la virtualización de zonas, que es el método que Google usa para asignar zonas públicas a clústeres de hardware físico interno dentro de nuestros centros de datos. La virtualización de zonas nos permite expandir nuestra zona, actualizar el hardware y retirar la infraestructura física sin interrupciones ni impacto en el cliente. Lee sobre este tema si tus aplicaciones están distribuidas en múltiples proyectos y si deseas aprender cómo Google distribuye sus zonas a través de la infraestructura física.
Los recursos de Google Cloud se alojan en varias regiones en todo el mundo. 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. Una región consta de tres o más zonas que se alojan en tres o más centros de datos físicos. Las regiones México, Osaka y Montreal tienen tres zonas alojadas en uno o dos centros de datos físicos. Estas regiones están en proceso de expansión a al menos tres centros de datos físicos. Cuando diseñes tus soluciones en Google Cloud, ten en cuenta la orientación que se proporciona en Ubicaciones de Cloud, los ANS de Google Cloud Platform y la documentación del producto de Google Cloud adecuada.
Si colocas los recursos en varias zonas dentro de una región, se reduce el riesgo de que las fallas de la infraestructura correlacionada física y de software afecten a las aplicaciones. Colocar los recursos en regiones diferentes proporciona un grado aún mayor de independencia de fallas.
Para obtener una lista de las ubicaciones geográficas de Google Cloud, consulta Regiones y zonas. Para obtener información adicional sobre la compilación de aplicaciones resilientes, consulta la serie de soluciones de Google Cloud sobre la planificación de recuperación ante desastres.
Clústeres
Todo el hardware de Google Cloud se organiza en clústeres. Un clúster representa un conjunto de recursos de procesamiento, red y almacenamiento respaldado por la infraestructura de compilación, energía y enfriamiento. Los componentes de infraestructura suelen admitir un solo clúster, lo que garantiza que los clústeres compartan pocas dependencias.
Figura 1: Hay tres zonas en la región asia-east1. Cada zona tiene su propio clúster con recursos individuales.
Sin embargo, los componentes con confiabilidad altamente demostrada y redundancia descendente se pueden compartir entre clústeres. Por ejemplo, varios clústeres suelen compartir una subestación de red de servicios públicos porque las subestaciones son muy confiables y los clústeres usan sistemas de energía redundantes. Google Cloud diseña su infraestructura física para admitir los Acuerdos de Nivel de Servicio (ANS) y los Objetivos de Nivel de Servicio (SLO) de los servicios de Google Cloud.
Asignación de zona a clúster
Cuando un proyecto usa una región por primera vez, Google Cloud selecciona un clúster único para cada zona de la región que es el clúster predeterminado para los recursos zonales de ese proyecto. Sin embargo, las restricciones de hardware pueden dar como resultado que se usen clústeres adicionales para esa zona. Esta selección se llama asignación de zona a clúster. Las asignaciones de zona a clúster predeterminadas se seleccionan por proyecto para que cada cliente experimente las mismas funciones y el mismo rendimiento. Dentro de un proyecto, la asignación entre una zona lógica y un clúster físico es coherente. Sin embargo, otro proyecto puede tener una asignación de zona a clúster completamente diferente según los recursos zonales del proyecto. Un proyecto nunca tiene dos zonas asignadas al mismo clúster físico.
Puedes alinear las asignaciones de zona a clúster entre proyectos mediante las redes de nube privada virtual (VPC). Google Cloud intenta asignar la misma asignación de zona a clúster a todos los proyectos que comparten una red de VPC. Los mapas de zona a clúster coherentes en todos tus proyectos pueden ser convenientes para fallas de componentes de la aplicación atómicas y predecibles.
Zonas virtualizadas
A medida que se expanden las regiones, cada zona es compatible con varios clústeres. Nuestro objetivo es agrupar clústeres con infraestructura compartida, como una infraestructura de compilación o enfriamiento, en zonas lógicas para que las fallas compartidas en la infraestructura afecten solo a una zona dentro de una región.
Figura 2 Dos de las tres zonas en asia-east1 se expandieron y ahora tienen dos clústeres.
Las cargas de trabajo del cliente se mantienen en la menor cantidad posible de clústeres. Por lo general, tu carga de trabajo zonal se encuentra en un solo clúster. Sin embargo, las asignaciones de zona a clúster pueden incluir clústeres adicionales en casos en los que la capacidad adicional o el hardware especializado no está disponible en el clúster principal para la asignación.
Figura 3: Diagrama de la asignación de zona a clúster para dos proyectos:
- El proyecto Fizz tiene dos clústeres asignados a
asia-east1-aporque solo el clúster “z” admite cargas de trabajo de GPU y solo el clúster “y” admite cargas de trabajo de TPU. - Project Fizz y Project Buzz tienen diferentes clústeres asignados a
asia-east1-b.
Aunque la asignación de zona a clúster rara vez cambia, los cambios se producen a medida que evolucionan las necesidades de capacidad y la oferta de hardware subyacente. Por ejemplo, se agregan clústeres a una zona para aumentar la capacidad y se quitan de una zona cuando se dan de baja. Durante cualquier evento de mantenimiento, Google intenta limitar el tiempo de inactividad mediante la migración en vivo cuando es posible.
En el caso de una interrupción del clúster, la zona lógica asociada con ese clúster se informa como una interrupción en el Panel de estado de Google Cloud. Sin embargo, no todos los recursos del cliente se ven afectados, ya que la zona puede estar compuesta por varios clústeres. Por lo tanto, es posible que algunos clientes no se vean afectados por la interrupción de un solo clúster. Recomendamos encarecidamente adoptar las arquitecturas multizonales para minimizar el impacto de las interrupciones.
Redes compartidas y zonas virtualizadas
Las redes de nube privada virtual (VPC) son redes virtualizadas que proporcionan conectividad entre recursos dentro de un proyecto. Varios proyectos pueden compartir una red de VPC para habilitar la conectividad entre proyectos, y una organización puede realizar un intercambio de tráfico en una red de VPC compartida para habilitar la conectividad entre organizaciones. Nuestro algoritmo de asignación de virtualización de zona intenta aplicar la misma asignación de zona a clúster a todos los proyectos que comparten una red de VPC o extender su red de VPC mediante el intercambio de tráfico entre VPC. Esto es así incluso cuando los proyectos se encuentran en diferentes organizaciones de Google Cloud. A medida que la complejidad de la red aumenta con la cantidad de proyectos y VPC, mantener una asignación de zona coherente se vuelve más difícil y, por lo tanto, no se puede garantizar.
¿Qué sigue?
- Obtén más información sobre los recursos globales, regionales y zonales.
- Obtén más información sobre geografía y zonas.