Google Distributed Cloud (GDC) aislado ofrece capacidades de implementación que proporcionan alta disponibilidad y recuperación ante desastres. En esta página, se hace referencia a esta función como multizona.
Las capacidades de varias zonas te permiten ejecutar cargas de trabajo esenciales y desconectadas en GDC, ya que ofrecen alta disponibilidad (HA) y recuperación ante desastres (DR) similares a las de los proveedores de servicios en la nube hiperescalables públicos. El GDC proporciona servicios administrados y de infraestructura que son resistentes a las fallas locales. En el caso de algunos servicios, debes decidir el nivel de resiliencia que requiere tu carga de trabajo. Estos son algunos ejemplos de servicios que proporcionan capacidades multizona:
Para obtener una lista completa de los servicios que proporcionan capacidades multizona, consulta Servicios de GDC compatibles con varias zonas.
La función multizona de GDC proporciona capacidades de administración de recursos globales para simplificar la administración de recursos en las zonas de GDC. Puedes ver todos los recursos y servicios de GDC administrados en un universo con visibilidad sobre alertas, estado, uso, registro, supervisión y facturación.
Los universos multizona en GDC requieren simetría global de recursos y hardware. Esta simetría significa que el hardware y las organizaciones deben ser los mismos en todas las zonas y no se pueden modificar de forma independiente en una zona específica.
Las implementaciones en varias zonas también te proporcionan componentes básicos para cumplir con tus objetivos de recuperación ante desastres y continuidad empresarial. Hay tres capacidades principales que te proporcionan las implementaciones en varias zonas:
Continuidad de los servicios del plano de control. En caso de un desastre zonal, la funcionalidad crítica necesaria para recuperar una organización y sus servicios asociados ya estará presente en otra zona.
Recursos multizona. Por ejemplo, la replicación de almacenamiento asíncrona en las zonas de GDC.
Servicios administrados multizonales. Por ejemplo, los balanceadores de cargas ofrecen variantes multizonales controladas por un servicio administrado.
¿Qué es una zona?
Cada zona puede ser un dominio de desastre independiente según dónde se coloque. Por ejemplo, dos zonas ubicadas a 1 km de distancia entre sí en una zona de subducción estarían en el mismo dominio de desastres. Cada zona es una implementación completa de GDC aislado, una solución de hardware y software que no requiere conectividad a Google Cloud en ningún momento. Una zona administra la infraestructura, los servicios, las APIs y las herramientas que usan un plano de control local.
Una zona aislada de GDC se compone de cuatro capas:
Hardware: El diseño subyacente del hardware y el rack definido por Google.
Infraestructura: Administra el hardware y proporciona abstracciones que permiten que las capas de software se ejecuten sin referencia a configuraciones específicas del hardware.
Service Platform: Es un framework para compilar servicios en Distributed Cloud que proporciona coherencia entre los servicios administrados y los servicios de Marketplace.
Servicios administrados y de Marketplace: Servicios en la nube orientados al cliente que se ejecutan en la GDC.
Un grupo de zonas aisladas conectadas se denomina universo. Para implementar aplicaciones tolerantes a errores con alta disponibilidad que ayuden a proteger contra fallas inesperadas, debes implementar tus aplicaciones en varias zonas de un universo.
¿Qué es una región?
Una región es una agrupación de zonas en un universo dentro de nuestros requisitos de latencia definidos. Una zona sin pares lo suficientemente cerca se considera su propia región. Las zonas de una región deben estar separadas por al menos 10 km para garantizar que sean dominios de desastres separados en muchos regímenes de cumplimiento.
Las regiones pueden estar a cientos de kilómetros de distancia. Por este motivo, GDC solo ofrece servicios síncronos dentro de las regiones, mientras que los servicios asíncronos están disponibles dentro de las regiones y entre ellas.
Los servicios asíncronos realizan la replicación en segundo plano, lo que proporciona objetivos de punto de recuperación (RPO) bajos, pero no nulos. Por lo general, los servicios asíncronos permanecen disponibles durante las particiones de red.
Estos son algunos ejemplos de servicios asíncronos aislados de GDC:
- Almacenamiento en bloque
- Almacenamiento de objetos
Las zonas dentro de una misma región deben cumplir con los requisitos de latencia que permiten la entrega de servicios con coherencia sólida. Los servicios síncronos realizan la replicación de inmediato, lo que garantiza que cada escritura esté disponible en al menos dos zonas. Este es el paso principal necesario para lograr un RPO de cero. Por lo general, los servicios síncronos tienen una latencia más alta que los servicios no replicados y pueden dejar de estar disponibles durante las particiones de red.
Estos son algunos ejemplos de servicios síncronos aislados de GDC:
- Recursos compartidos de archivos NFS
- Almacenamiento de objetos
¿Qué es un universo?
Las zonas con conectividad de red directa, independientemente de la distancia o la latencia, y un plano de control y administración compartido pertenecen a un universo. Un universo puede tener un máximo de seis zonas.
Cada universo puede constar de varias zonas organizadas en regiones interconectadas. Por ejemplo, dos regiones en el estado de Virginia (EE.UU.) y Ámsterdam (Países Bajos), respectivamente, cada una con tres zonas:
Región 1 del GDC (Virginia)
- Zona 1 (us-virginia1-a)
- Zona 2 (us-virginia1-b)
- Zona 3 (us-virginia1-c)
Región 2 de GDC (Países Bajos)
- Zona 1 (eu-ams1-a)
- Zona 2 (eu-ams1-b)
- Zona 3 (eu-ams1-c)
En el siguiente diagrama, se muestra un ejemplo del universo de GDC.
Un universo puede tener de 1 a 6 zonas y uno o dos centros de operaciones.
Los universos ofrecen las siguientes estrategias de recuperación automatizadas, independientemente de la configuración regional:
- En el caso de los universos con dos zonas, la recuperación se debe activar de forma manual.
- En el caso de los universos con tres o más zonas, la recuperación se puede activar automáticamente.
Para obtener más información, comunícate con tu operador.
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) que reside dentro de una zona específica. Para obtener más información sobre cómo se administran los recursos zonales en un universo de GDC, consulta Servidores de la API de Management.
Recursos globales
Los recursos globales son aquellos que se implementan en todas las zonas de un universo, como las organizaciones. Esto les permite tener una disponibilidad más alta en comparación con los recursos zonales. Los recursos globales se implementan y administran en el servidor de la API de administración global.
Para cada organización, existen servidores de la API de administración globales y zonales.
Dominios de catástrofes
Un dominio de desastre representa una colección de recursos que podrían verse afectados al mismo tiempo debido a la proximidad física de los recursos. Por lo tanto, es una construcción relacionada con la durabilidad que se usa para simplificar los requisitos de separación de zonas. Por lo general, un solo dominio de desastre corresponde a un solo campus.
En la mayoría de los universos de GDC, Google no es propietario de las instalaciones, sino que trabaja con proveedores de colocación que tienen centros de datos que brindan acceso a una infraestructura sólida, energía redundante y conectividad de alta velocidad. Este enfoque proporciona un rendimiento y un tiempo de actividad óptimos para las aplicaciones y los servicios según la estrategia y las prácticas recomendadas de Google para la HA y la DR.
Comunícate con tu operador para obtener más información sobre las especificaciones del dominio de desastre para tu universo.
APIs globales y zonales
GDC con aislamiento de aire ofrece dos niveles de APIs del plano de administración para crear y administrar recursos globales y zonales: APIs globales y APIs zonales. Consulta la documentación sobre los servidores de la API de administración globales y zonales para obtener información sobre cómo se administran estos tipos de API en un universo de GDC.
Tanto las APIs globales como las zonales son APIs declarativas de Kubernetes que se publican en diferentes extremos, y los recursos de GDC se representan como recursos personalizados de Kubernetes en los servidores de la API. Los servidores de API globales comparten un solo clúster de etcd distribuido en todas las zonas para proporcionar una coherencia sólida con tolerancia a fallas, a costa de una mayor latencia y una menor cantidad de QPS (consultas por segundo) en comparación con los servidores de API zonales. En cada organización, un servidor de API de administración zonal proporciona la API zonal para que los administradores y desarrolladores administren los recursos zonales, y un servidor de API de administración global proporciona la API global para administrar los recursos globales.
Para obtener más información sobre las APIs en GDC, consulta la descripción general de las APIs.
CLI de gcloud
La CLI de gdcloud proporciona formas de interactuar con la API zonal o global para administrar tus recursos y su implementación, lo que incluye lo siguiente:
- Accede a la URL de la consola zonal o global con la CLI
- Usa una marca de CLI zonal para acciones de zona específicas
La URL global es la que se configura de forma predeterminada cuando se inicializa la CLI de gcloud. Puedes actualizar tu configuración de gdcloud para establecer URLs zonales y acceder a ellas para completar tareas específicas de la zona.
Del mismo modo, la CLI de gcloud ofrece una marca --zone que puedes configurar para muchas tareas de administración de recursos en todos los grupos de comandos. Cuando accedes a la configuración de URL global, las acciones de la CLI en los recursos globales se aplican a todas las zonas para las que están en alcance.
Para obtener más información sobre el uso de la CLI de gcloud para los servicios zonales y globales, consulta Administra recursos en todas las zonas.
Consola de GDC
Se puede acceder a la consola de GDC de una organización determinada desde cualquier zona del mismo universo. Por lo tanto, puedes usar la consola de GDC para administrar todos los recursos globales y zonales dentro de una organización.
Las siguientes funciones multizona están disponibles en la consola de GDC:
Navega con un nombre de dominio completamente calificado (FQDN): Puedes usar el FQDN global para resolver automáticamente el extremo de la consola zonal más adecuado. Si el FQDN global no se resuelve por algún motivo o quieres conectarte a una zona específica, puedes usar el FQDN zonal para navegar a un extremo de la consola específico en una zona de destino.
Administra la creación de recursos zonales: Hay un selector de zonas disponible cuando se crea un recurso zonal, que determina la zona en la que se crea un recurso. Por el contrario, el selector de zona no está visible cuando creas un recurso global.
Visualiza los recursos existentes en las zonas: Varias páginas de recursos en la consola de GDC muestran los recursos por zona. Puedes usar el selector de zonas para ver los recursos de la zona elegida. Se puede acceder a los recursos de todas las zonas navegando a las URLs de la consola de GDC globales y zonales, y seleccionando la zona adecuada en el selector, pero no hay una vista agregada de los recursos de todas las zonas.
Para obtener más información sobre cómo administrar recursos en varias zonas de un universo de GDC con la consola de GDC, consulta Administra recursos en varias zonas.
El GDC está diseñado para ser resiliente a las fallas. Por lo tanto, si se detecta un problema de conectividad zonal, la consola de GDC mostrará un banner persistente que te notificará que es posible que no puedas realizar cambios en los recursos globales.
Contenedores de recursos
Una organización define un límite de seguridad de los recursos que se administrarán en conjunto. Cada organización aislada de GDC proporciona una API global y una API zonal para permitir la creación de recursos globales y zonales dentro de la organización. Cuando se crea una organización global, el operador es responsable de implementar zonas y configurar parámetros zonales, como la cantidad de almacenamiento y la cantidad de servidores físicos disponibles para las cargas de trabajo de los usuarios.
Para obtener más información sobre la configuración de zonas específica de tu organización, comunícate con tu operador.
Un proyecto proporciona una agrupación lógica de los recursos de servicio dentro de una organización y proporciona un ciclo de vida y un límite de políticas para administrar los recursos. Todos los proyectos son globales y abarcan las zonas que configuraste en tu universo de forma predeterminada.
Si bien todos los recursos de servicio deben crearse en un proyecto, no todos los servicios son globales. En el caso de los servicios que solo se admiten a nivel zonal, debes implementarlos y administrarlos en las zonas que elijas. Consulta la documentación correspondiente de un tipo de recurso para obtener más información.
IAM
Los siguientes servicios de Identity and Access Management (IAM) deben configurarse como recursos globales:
- Proveedores de identidad (IdP) para la autenticación
- Control de acceso basado en roles (RBAC)
- Identidades de servicio
Cada configuración de IAM abarca todas las zonas de un universo.
Autenticación
Debes conectar un IdP a tu organización con el recurso global IdentityProviderConfig. Este recurso garantiza que uses el mismo IdP para conectarte a tu organización en todas las zonas del universo.
Para obtener más información, consulta Conéctate a un proveedor de identidad.
Acceso
A cada usuario o grupo se le debe asignar un recurso IAMRoleBinding global para obtener acceso a los servidores de la API de administración global y zonal, y a los clústeres de Kubernetes de manera coherente en cada zona de la organización.
Acceso al servidor de la API de Global Management:
IAMRoleBindingse propaga comoClusterRoleBindingoRoleBindinga unClusterRolepredefinido en el servidor de la API global.Acceso al servidor de la API de Management zonal:
IAMRoleBindingse propaga comoClusterRoleBindingoRoleBindingen el servidor de la API de Management zonal.Acceso al clúster de Kubernetes:
IAMRoleBindingse propaga comoProjectRoleyProjectRoleBindingpara propagarse comoRoleyRoleBindingde Kubernetes a los espacios de nombres de Kubernetes en el servidor de la API de Management y los clústeres de Kubernetes, lo que corresponde al proyecto en el que se encuentranProjectRoleyProjectRoleBinding.
Para obtener más información, consulta Cómo otorgar y revocar el acceso.
Identidad del servicio
Las cuentas de servicio son principales de usuario que las cargas de trabajo y los servicios usan para consumir recursos y acceder a microservicios de forma programática y segura. Son un tipo especial de identidad que usa una aplicación o carga de trabajo, en lugar de una persona. Al igual que las cuentas de usuario, a las cuentas de servicio se les pueden otorgar permisos y roles, pero no pueden acceder como un usuario humano. La función de identidad del servicio se incluye en el recurso global ProjectServiceAccount.
Para obtener más información, consulta Cómo autenticarse con cuentas de servicio.
Redes
Puedes configurar los siguientes servicios de redes para tus zonas de GDC:
- Servicios de Anycast
- Balanceo de cargas
- Políticas de red del proyecto
- DNS
Configura tus servicios de redes globales y zonales para administrar el tráfico de redes entre zonas y dentro de la misma zona en tu universo de GDC.
Servicios de Anycast
Las zonas múltiples proporcionan servicios de redes Anycast para ofrecer alta disponibilidad en los recursos de varias zonas. Del mismo modo, las opciones de interconexión de centros de datos (DCI) se implementan como una malla completa para interconectar varias zonas aisladas de GDC. Esto permite que GDC proporcione protección ante desastres en varias zonas y ubicaciones, a la vez que cumple con el requisito de desconexión completa de cualquier infraestructura de Google.
Los servicios de Anycast se representan con prefijos IPv4 únicos de /32, que se proporcionan a través del Protocolo de Puerta de Enlace Fronteriza (BGP) a las instalaciones del cliente, lo que garantiza la accesibilidad desde cualquier red conectada. Si bien se puede acceder a cada servicio de Anycast desde todas las zonas dentro de la red aislada de GDC, el extremo real al que se dirige el tráfico depende de factores como la proximidad y la preferencia de zona según tu política de enrutamiento personalizada.
La entrega de tráfico se optimiza enrutándolo a la instancia de servicio disponible más cercana, siempre dentro de la misma zona que la conexión del cliente. Esto no solo reduce la latencia, sino que también mejora el rendimiento general y la capacidad de respuesta del servicio. Por ejemplo, si se implementa un servicio de Anycast en la zona 1, la zona 2 y la zona 3, una solicitud del cliente que se origine en la zona 2 se enrutará, por lo general, a la instancia del servicio dentro de la zona 2, ya que es la opción más cercana y, por lo tanto, más eficiente.
Si bien se puede acceder al rango de Anycast a nivel global, solo se proporciona a los clientes de las zonas específicas en las que el servicio está implementado de forma activa. Esta configuración de acceso significa que un servicio implementado en la zona 1 solo estaría disponible para los clientes conectados a la zona 1 y no para los que están conectados a otras zonas.
Además, GDC implementa un sistema de preferencia de zonas en el que se les asigna un valor numérico durante la creación, independientemente de su nombre, que establece la atracción del cliente. Por ejemplo, si se implementa un servicio de Anycast en zonas con valores numéricos 1, 2 y 3, el tráfico de los clientes generalmente se dirigirá a la zona con el valor más bajo establecido antes que a las otras zonas como la ubicación preferida. Este sistema de preferencias proporciona un grado de previsibilidad y control sobre los patrones de tráfico, pero también incluye mecanismos de conmutación por error integrados. En caso de una falla o interrupción que afecte la zona preferida, el sistema cambiará automáticamente el tráfico a otra zona, lo que garantizará la disponibilidad ininterrumpida del servicio.
En una configuración de varias zonas, acceder a los servicios dentro de una zona específica requiere una interconexión de tu red a esa zona. Para una implementación coherente en varias zonas, las interconexiones creadas en cada zona de tu universo deben ser idénticas en términos de capacidad y configuración. Cada zona a la que pretendas acceder debe tener una interconexión correspondiente, y estas interconexiones deben ser idénticas entre sí.
Para obtener más información, comunícate con tu operador.
Balanceo de cargas
GDC proporciona un balanceador de cargas de transferencia de L4 para las cargas de trabajo de Kubernetes y de VM. Este balanceador de cargas proporciona los siguientes parámetros de configuración:
- Protocolo TCP o UDP.
- No hay proxy entre la carga de trabajo y el cliente.
- Balanceo de cargas dedicado para zonas particulares o de forma global en todas las zonas del universo
- Tráfico de red interno dentro de tu organización o tráfico de red externo entre organizaciones
En el siguiente diagrama, se ilustran los componentes de un balanceador de cargas de transferencia externo de L4 en un universo de GDC:
El balanceador de cargas se puede ajustar para que funcione dentro de una sola zona o de forma global para todas las zonas.
Para obtener más información sobre el balanceo de cargas en GDC, consulta Administra balanceadores de cargas.
Políticas de red del proyecto
Las políticas de red del proyecto definen reglas de transferencia de datos interna o externa para un proyecto. Dado que los proyectos son un recurso global, también debes definir las políticas de red de un proyecto de forma global para permitir el tráfico de redes entre zonas para los servicios y las cargas de trabajo dentro de un proyecto.
Para obtener más información, consulta Configura políticas de red del proyecto.
DNS
Los servicios del sistema de nombres de dominio (DNS) son globales y abarcan varias zonas. Si una instancia de servicio DNS deja de estar accesible en una zona, los clientes reciben servicio sin problemas de otra instancia de servicio DNS en otra zona.
Cada organización de una zona contiene tres servidores DNS autorizados globales:
Servidor interno de infraestructura global: Es el servidor autorizado que resuelve las solicitudes de DNS dentro de la red de nube privada virtual (VPC) de la infraestructura. Este servidor solo administra cargas de trabajo de infraestructura. Las cargas de trabajo del usuario no interactúan con este componente. Se puede acceder a todas las implementaciones internas de la infraestructura global de una organización en todas las zonas con una dirección IP de Anycast.
Servidor interno global del cliente: Es el servidor autorizado que resuelve las solicitudes de DNS dentro de la red de nube privada virtual (VPC) del cliente. Este servidor solo administra las cargas de trabajo del usuario, como un pod en un clúster de Kubernetes o una máquina virtual (VM), y resuelve todas las solicitudes de DNS que se originan en esas cargas de trabajo del usuario. Se puede acceder a todas las implementaciones internas globales de clientes de una organización en todas las zonas con una dirección IP de Anycast. Dado que las VPC abarcan varias zonas, una solicitud de resolución de un nombre de dominio completamente calificado (FQDN) global de una zona puede llegar a cualquiera de las zonas en buen estado.
Servidor externo global del cliente: Es el servidor autorizado que resuelve las solicitudes de DNS que se originan en la red del cliente. Se puede acceder a todas las implementaciones externas globales para clientes de una organización en todas las zonas con una dirección IP de Anycast.
Puedes conectarte a GDC con una red externa dedicada o una red externa compartida. Estos tipos de redes determinan cómo GDC resuelve tus solicitudes de DNS.
Una red externa dedicada se conecta directamente al servidor DNS externo global del cliente, que resuelve la solicitud. Como alternativa, una red externa compartida se conecta a la raíz de tu jerarquía de DNS. Este servidor raíz proporciona el registro del servidor de nombres (NS) de la solicitud para la zona de DNS adecuada al servidor DNS externo del cliente global. Luego, tu agente de resolución de DNS resuelve la solicitud de forma recursiva.
GDC proporciona resolución de DNS para el tráfico interno y externo, tanto a nivel global como dentro de una sola zona.
Las solicitudes que se originan en tu red externa se enrutan desde tu solucionador de DNS. Del mismo modo, las solicitudes de DNS internas se originan en tus cargas de trabajo dentro de un universo de GDC.
Las solicitudes de DNS tienen el siguiente formato de FQDN:
- Solicitudes de DNS global:
SERVICE_NAME.ORG_NAME.SUFFIX, comoservice-1.org-1.google.com. - Solicitudes de DNS zonales:
SERVICE_NAME.ORG_NAME.ZONE_NAME.SUFFIX, comoservice-1.org-1.zone-1.google.com
Para obtener más información sobre cómo configurar las redes en un universo de GDC, consulta la Descripción general de las redes.
Almacenamiento
En la versión 1.14.4 y posteriores, los universos multizonales ofrecen el uso de recursos de almacenamiento replicados, como volúmenes y buckets, en modo asíncrono para situaciones de recuperación ante desastres. Estas opciones de recursos de almacenamiento proporcionan replicación de datos asíncrona entre dos zonas cualesquiera del mismo universo. La replicación asíncrona se produce en segundo plano y proporciona un RPO bajo, pero no nulo, en caso de desastre. Todos los datos replicados están en línea y son accesibles de inmediato, pero es posible que se requiera un procedimiento de conmutación por error manual para habilitar la escritura en la zona secundaria.
Replicación de bloques asíncrona: Proporciona volúmenes replicados de forma asíncrona (PV) que mantienen la equivalencia de bloques entre los volúmenes principal y secundario. Debido a la naturaleza asíncrona, el volumen secundario reflejará el estado del principal en algún momento del pasado (RPO distinto de cero). El volumen secundario no se puede activar mientras siga siendo el destino de la replicación, lo que requiere una intervención manual para finalizar la relación y permitir que se realicen escrituras.
Replicación asíncrona de buckets: Los buckets replicados se vinculan entre zonas, lo que crea una relación de replicación de datos bidireccional. Los datos de objetos escritos en buckets de la zona principal o secundaria con esta función se copian en la otra zona. Dado que los datos se copian de forma asíncrona, es posible que los buckets no contengan las mismas versiones de objetos en ningún momento, pero, con el tiempo, se volverán coherentes si no se realizan cambios adicionales. A diferencia de la replicación de volúmenes, los buckets replicados se pueden escribir durante las particiones de zona. Cada escritura en un objeto produce una versión diferente, y la versión más reciente en cualquiera de las zonas será el estado final después de que se restablezca la conectividad.
Requisitos de latencia
Para asegurarnos de que puedas planificar las ubicaciones de las zonas de GDC para la funcionalidad actual y futura, basamos los requisitos de latencia en Google Cloud. Este enfoque te permite elegir con confianza ubicaciones aisladas de GDC sabiendo si esas zonas estarán en la misma región.
La latencia máxima admitida es inferior a 1 ms de tiempo de ida y vuelta (RTT) en la capa física entre dos zonas cualesquiera de una región. Dado que el cálculo de la latencia en la capa física requiere equipos especializados que no están disponibles en la mayoría de las instancias, se puede aproximar midiendo la longitud de la fibra entre dos zonas.
Una longitud de fibra para las zonas de una región de 50 km en la ruta principal y 100 km en la latencia de la ruta secundaria admitirá los servicios regionales. En una red en anillo, este requisito significa que la longitud de cada fibra no puede superar los 50 km.
Comunícate con tu operador para obtener más información sobre tus requisitos específicos de latencia.
¿Qué sigue?
- Obtén información sobre los servidores de API globales y zonales disponibles en un universo de GDC.
- Explora la guía de alta disponibilidad para asegurarte de que tu aplicación sea resistente a las fallas de la zona local.
- Lee la página sobre la jerarquía de recursos para obtener más información sobre cómo se administran los recursos de forma jerárquica dentro de una zona.