El recurso de organización representa una unidad administrativa o una función empresarial que comparte el mismo grupo de recursos y las mismas políticas. Google Distributed Cloud (GDC) con air gap proporciona aislamiento físico entre organizaciones mediante funciones de multitenancy a nivel de hardware. Cada organización también tiene sus propios componentes del plano de control para sus servicios, que no se comparten con otras organizaciones. Todos los recursos, como proyectos, clústeres y servicios, pertenecen a una organización en lugar de a sus creadores. Por lo tanto, los recursos no se eliminan si el usuario que los creó abandona la organización. En su lugar, todos los tipos de recursos siguen el ciclo de vida de la organización. Para obtener más información, consulta la jerarquía de recursos de GDC.
Conectividad de red externa
Para ser útil, una organización necesita conectividad a redes externas. Esto permite a los administradores de la plataforma y a los operadores de aplicaciones gestionar la organización y sus recursos, así como a los usuarios finales consumir los servicios implementados en ella. En GDC, Interconnects proporciona toda la conectividad externa.
Cuando se crea una organización, no se conecta automáticamente a ninguna red. Como operador, debes seguir pasos de configuración adicionales para asociar una organización a una interconexión o aprovisionar una nueva interconexión dedicada. Normalmente, esto implica lo siguiente:
- Añadir la organización a un
AttachmentGroup. - Crear recursos de
Interconnectpara conexiones físicas o lógicas nuevas. - Definir recursos
RoutePolicypara anunciar las rutas de la red de la organización a la red externa.
Las organizaciones ofrecen funciones de red mejoradas, como la posibilidad de que las organizaciones con interconexiones dedicadas usen direcciones IP externas superpuestas, lo que simplifica la gestión de IP.
Para obtener información detallada sobre los conceptos y los procedimientos de configuración, consulta la descripción general de Interconnect.
Modelos de conectividad de Interconnect
GDC Interconnects admite dos configuraciones principales que se ajustan a diferentes requisitos de seguridad y gestión de IP.
Conectividad de red externa compartida
Este modelo permite que varias organizaciones se conecten a una zona de GDC a través de una red externa común. En esta configuración, el operador de infraestructura (IO) suele gestionar la conexión física y el emparejamiento de BGP. Un requisito fundamental es que las direcciones IP externas que utilice cada organización deben ser únicas en la red compartida. Este modelo es más fácil de gestionar en entornos con un dominio de confianza común.
Conectividad de red externa dedicada
Este modelo está dirigido a organizaciones que requieren un mayor grado de aislamiento y que se conectan a una red externa diferente. Con la conectividad dedicada, el proveedor de acceso puede gestionar el emparejamiento BGP, lo que le da más control.
Una ventaja importante de este modelo es que las organizaciones pueden usar direcciones IP externas superpuestas. Esta función simplifica la gestión de direcciones IP, ya que elimina la necesidad de resolver conflictos de intervalos de IP en todos los inquilinos del universo de GDC.
Para obtener información detallada sobre los conceptos y los procedimientos de configuración, consulta la descripción general de Interconnect.
Arquitecturas de organización
GDC ofrece dos arquitecturas para las organizaciones:
- Arquitectura de la organización v1 de GDC con air gap (organización v1)
- Arquitectura de la organización de GDC con air gap (versión 2)
A primera vista, las organizaciones con cualquiera de las dos arquitecturas se aprovisionan, usan y gestionan de forma similar. Sin embargo, las arquitecturas subyacentes de clústeres, redes y almacenamiento son diferentes en cada tipo de organización.
Arquitectura de la organización de GDC con air gap (versión 1)
Una organización de la versión 1 consta de dos clústeres:
- Clúster de administrador de la organización: ejecuta los componentes del plano de control de los servicios gestionados y de Marketplace de la organización. También aloja algunos servicios de infraestructura principales.
- Clúster del sistema: ejecuta cargas de trabajo de máquinas virtuales y algunas cargas de trabajo del plano de datos de servicios gestionados de la organización. El número de nodos de trabajador depende del uso del clúster.
El PA y el AO deben acceder a estos tipos de clústeres en ocasiones para desplegar cargas de trabajo y gestionar el sistema.
El almacenamiento de clústeres virtuales se gestiona mediante un controlador de CSI específico del proveedor dentro del clúster.
Arquitectura de la organización de GDC con air gap (versión 2)
Una organización de la versión 2 consta de un clúster llamado clúster de infraestructura de la organización, que ejecuta los componentes del plano de control y del plano de datos de la organización. Este clúster también aloja el servidor de la API de gestión, donde se implementan todas las cargas de trabajo y los servicios que no son de contenedor. El servidor de la API de gestión proporciona una capa en la que los administradores principales y los administradores de organizaciones pueden desplegar cargas de trabajo, pero no interactuar directamente con el clúster de infraestructura de la organización.
El almacenamiento de los clústeres virtuales se gestiona mediante un controlador de CSI proxy que permite que el controlador de CSI del clúster de infraestructura de org gestione las operaciones.
Los componentes de red, como la gestión de direcciones IP, el cambio de ruta de entrada y salida, y la estructura de VRF, ofrecen mejoras en la arquitectura de la organización de la versión 1 en cuanto a seguridad y usabilidad del sistema.
¿Qué novedades hay para las organizaciones de la versión 2?
La arquitectura de organización de la versión 2 introduce cambios en varios componentes en comparación con la arquitectura de organización de la versión 1.
Arquitectura de APIs y clústeres
La arquitectura de organización de la versión 2 solo proporciona un clúster para la organización, en lugar de los dos clústeres que se proporcionaban en la arquitectura anterior. La reducción de clústeres permite un uso más flexible de los recursos de hardware.
También se ha separado la red del plano de control y del plano de datos, algo que no estaba disponible para las organizaciones de la versión 1. El servidor de la API de gestión o el plano de control ahora se pueden exponer en una red de cliente distinta de la red de cliente en la que se expone el plano de datos. Esta separación ofrece una capa adicional opcional de aislamiento entre el aprovisionamiento y el consumo de recursos en la nube. Tus administradores y desarrolladores deben tener conexiones a ambas redes externas.
Almacenamiento
La nueva arquitectura de organización de la versión 2 elimina las credenciales de almacenamiento de NetApp del clúster de usuario implementando el controlador CSI de KubeVirt en lugar del controlador CSI de NetApp Trident, que se encontraba en la arquitectura anterior. Esta actualización del controlador de CSI reduce aún más los privilegios de la matriz de almacenamiento directa.
Redes
Las siguientes mejoras de redes están disponibles para las organizaciones de la versión 2:
- Cifrado de nodo a nodo
- Clúster dedicado para gestionar el tráfico de red
- Redes de máquinas virtuales simplificadas
- Uso y gestión más eficientes de las direcciones IP
Cifrado de nodo a nodo
La arquitectura de organización de la versión 2 proporciona cifrado entre los nodos de hardware de la organización para que todo el tráfico de red de los clientes se cifre al salir del nodo físico. De esta forma, los conmutadores de red no pueden ver el tráfico sin cifrar.
Clúster dedicado para gestionar el tráfico de red
El clúster perimetral es un clúster virtual escalable que gestiona todo el tráfico de entrada y salida (norte/sur) de la organización. Este clúster también permite que tu universo de GDC se traslade a opciones de sistema de detección y prevención de intrusiones (IDPS) virtuales más escalables en el futuro.
Redes de máquinas virtuales simplificadas
La arquitectura de organización de la versión 2 converge dos interfaces por VM de la arquitectura anterior en una sola interfaz. Las VMs se mueven a un modelo de red de nube privada virtual (VPC) predeterminado, lo que significa que las VMs se conectan a la red en la capa 3 (L3).
Los clientes también pueden definir sus propias subredes, lo que no se admite en las organizaciones de la versión 1.
Uso y gestión eficientes de las direcciones IP
La arquitectura de organización de la versión 2 permite que las organizaciones tengan direcciones IP externas superpuestas. Las direcciones IP externas superpuestas permiten que las organizaciones se conecten directamente a las redes de los clientes, lo que elimina la necesidad de un único espacio de direcciones IP externas de gran tamaño alineado en todas las organizaciones del universo de GDC.
Las direcciones IP también se proporcionan por organización en lugar de estar vinculadas a una única subred principal con ámbito zonal. Esta función permite a los administradores especificar sus propias direcciones IP, en lugar de que seas tú, como operador, quien tenga que especificar una. Esta función ofrece una mayor elasticidad y aislamiento a las organizaciones que quieran un aislamiento de red sólido al no compartir una superred superior.
En las organizaciones de la versión 1, se necesitaba una dirección IP de NAT de salida por proyecto, por clúster de usuario y por organización. En el caso de las organizaciones de la versión 2, este requisito se ha mejorado considerablemente y ahora es de una por proyecto y por organización. Este cambio ofrece una mayor eficiencia en el uso de las direcciones IP proporcionadas por los clientes.
Diferencias funcionales entre las organizaciones de la versión 1 y la versión 2
Una organización de la versión 2 ofrece las mismas funciones que una organización de la versión 1. Las únicas funciones que no están disponibles en una organización de la versión 2 son las siguientes:
- Vertex AI
- CLI de Database Service
¿Qué arquitectura usarán las organizaciones multizonales?
En un universo de GDC multizona, si se amplía una organización a una zona nueva, la organización de la zona nueva debe usar la misma arquitectura que la zona ya disponible. Por lo tanto, no se admite el uso de arquitecturas de organización diferentes por zona.
Cómo aprovisionar una organización de la versión 2
Cuando se aprovisiona una organización, se crean organizaciones de la versión 2 de forma predeterminada para los clientes que no están sujetos a procesos de acreditación.
Sin embargo, las organizaciones de la versión 2 suponen un cambio arquitectónico significativo. En el caso de las implementaciones de clientes sujetas a acreditación, la arquitectura de organización de la versión 1 sigue siendo la predeterminada hasta que se complete la acreditación de la arquitectura de organización de la versión 2.
La arquitectura de organización predeterminada se controla mediante una marca de función configurada al implementar una zona.
Cómo forzar la arquitectura de la organización
En casos excepcionales, puede que quieras anular el comportamiento de aprovisionamiento predeterminado y forzar una arquitectura de organización específica añadiendo el campo spec.compatibilityOptions.architectureOverridePolicy al recurso Organization durante el proceso de aprovisionamiento. Para obtener más información, consulta la página Crear una organización de cliente.
No se recomienda anular la arquitectura de tu organización predeterminada a menos que tengas un motivo de peso para forzar un comportamiento específico.
Por ejemplo, puedes forzar una organización de la versión 1 si tienes un problema importante con una organización de la versión 2 que te impide completar una tarea. Del mismo modo, puedes forzar una organización de la versión 2 si necesitas una acreditación y una sola organización de la versión 2 para iniciar el proceso de acreditación. Estas marcas de anulación deben eliminarse cuando ya no sean estrictamente necesarias para evitar que se aprovisionen organizaciones con una arquitectura incorrecta en el futuro.
¿Qué ocurre con las organizaciones de la versión 1?
Las organizaciones creadas antes de la versión 1.14.2 de GDC con aislamiento físico seguirán usando la misma arquitectura aunque la zona de GDC se actualice a la versión 1.14.2 o a una posterior. Aunque no se puede actualizar la versión de las organizaciones de la versión 1 a la versión 2, las funciones de las organizaciones de la versión 1 seguirán estando disponibles hasta que se retire la arquitectura de la versión 1.
Es posible que las nuevas funciones que se lancen en el futuro solo se añadan a las organizaciones de la versión 2. Por lo tanto, te recomendamos que transfieras tus cargas de trabajo de tus organizaciones de la versión 1 a la nueva arquitectura de la versión 2 lo antes posible. Un único universo aislado de GDC puede contener ambas arquitecturas de organización simultáneamente, lo que facilita la transición.