Architecture

Ce document décrit l'architecture de déploiement, de cluster et de réseau de l'appliance Google Distributed Cloud (GDC) air-gapped.

Architecture de déploiement

Le schéma suivant illustre la façon dont le matériel de l'appliance s'intègre à un réseau client qui inclut des composants facultatifs tels que des HSM, un serveur NTP et des clients supplémentaires au sein du réseau. L'appliance est équipée d'un plan de gestion, d'un plan de données, de serveurs et d'un serveur compatible avec un GPU, tous conçus pour exécuter des charges de travail directement en périphérie.

Architecture d'un cluster

L'appliance GDC isolée par un espace vide exploite un seul cluster qui englobe les trois nœuds Bare Metal, appelé cluster d'infrastructure de l'organisation. Un serveur d'API de gestion dédié, qui s'exécute en tant que charges de travail de pod sur le cluster, héberge les API du plan de gestion. Les charges de travail utilisateur, qui incluent à la fois les VM et les pods Kubernetes, peuvent s'exécuter sur ce cluster. Ce modèle de cluster ne contient aucun cluster d'utilisateur.

Architecture de réseau

L'EL8000 inclut un fond de panier qui crée quatre réseaux de couche 2 (L2) distincts dans l'appareil :

1. Console Integrated Lights-Out (iLO) (1GbEth)
2. Réseau de gestion (1GbEth)
3. Réseau de données A (10GbEth)
4. Réseau de données B (10 GbEth)

Le diagramme suivant montre comment les réseaux de couche 2 sont connectés au commutateur Mellanox (https://www.hpe.com/psnow/doc/a00043975enw.html?jumpid=in_pdp-psnow-qs). Chaque réseau d'une lame se connecte à un seul commutateur réseau. Tous les réseaux de la console iLO de chaque lame de serveur se connectent au commutateur réseau 1. Les réseaux de gestion se connectent au commutateur réseau 2, et les réseaux de données se connectent aux commutateurs 3 et 4.

Les ports réseau client (15 et 17) ont accès au cluster (VLAN 100), et seul le trafic vers le CIDR d'entrée est autorisé. Le CIDR d'entrée est disponible pour les services, et la plage est annoncée sur le protocole BGP (Border Gateway Protocol) au réseau client.

Les ports réseau de gestion (16 et 18) ont accès à la gestion du système (VLAN 501). Les clients peuvent ainsi placer l'appareil sur un réseau plus étendu et n'utiliser que des connexions locales pour effectuer des tâches d'administration système.

Topologie de réseau inférieure

Réseau physique

GDC se compose d'un cluster hybride fonctionnant en mode locataire unique. Le cluster hybride, que nous appelons cluster d'infrastructure, se compose des clusters système et d'administrateur fusionnés :

La conception physique est axée sur un Mellanox SN2010 qui sert de passerelle entre le cluster d'infrastructure de l'appliance et le réseau client externe.

Le cluster d'infrastructure se compose de trois nœuds Bare Metal. Les connexions sur les modules de gestion peuvent être classées comme suit :

• Connectivité du réseau de données (sous-réseau 198.18.2.0/24) sur le VLAN 100. La BM dispose d'une carte d'interface réseau à deux ports, NIC0P1 et NIC0P2, qui sont agrégés et connectés au commutateur TOR. BM1 et BM2 se connectent directement au commutateur, tandis que BM3 se connecte au TOR à l'aide d'un commutateur non géré.
• La connectivité du réseau de gestion ( sous-réseau 198.18..0/24) s'effectue via le VLAN 501. Les interfaces ILO et MGMT sont connectées sur ce VLAN à l'aide d'interfaces 1G. Les interfaces ILO et MGMT sur les nœuds BM se connectent au commutateur à l'aide de commutateurs non gérés.
• Peut-être : ajouter la mise en réseau OTS sur les VLAN 200 à 203(?), sous-réseau 198.18.1.x

La connexion entre le commutateur Mellanox et le routeur client fournit une connectivité externe. Des interfaces 10G sont utilisées pour cette connectivité, et le protocole BGP est utilisé pour annoncer les adresses IP du réseau externe au client. Les clients utilisent les adresses IP externes pour accéder aux services nécessaires fournis par l'unité Appliance.

Remarque : Le schéma du réseau physique affiché précédemment montre un dispositif de bootstrap connecté au port 12 du commutateur. Ce programme d'amorçage permet de provisionner l'unité de l'appliance lors de la phase d'amorçage côté basse tension. Cette connexion ne sera pas présente lorsque l'appareil sera expédié au client.

Réseau logique

Deux réseaux locaux virtuels (VLAN) séparent les différents types de trafic :

1. VLAN 100 : cluster (adresses IP virtuelles d'Ingress, adresses IP de cluster/de nœud) avec sous-réseau IPv4 fourni par les clients.
2. VLAN 501 : gestion (iLO, Mgmt) avec sous-réseau IPv4 fourni par le client.

Topologie du réseau supérieur

Le cluster est configuré à l'aide de l'équilibrage de charge de couche 2 (L2). Les adresses IP virtuelles d'entrée du cluster proviennent du même sous-réseau que les nœuds. Lorsqu'une adresse IP virtuelle d'entrée est attribuée à un nœud, celui-ci utilise le protocole ARP (Address Resolution Protocol) pour être accessible depuis le TOR.

Le TOR est appairé au réseau client à l'aide de BGP et annonce la plage d'Ingress du cluster (préfixe agrégé fourni par le client) au réseau client. Lorsque le rack est déplacé vers un nouvel emplacement, nous pouvons faire la publicité de la plage d'Ingress du cluster sur le nouveau réseau client. Lorsque le rack est déplacé, vous devez mettre à jour manuellement les adresses IP sur les interfaces TOR qui se connectent au réseau client, et mettre à jour les informations d'appairage BGP pour ajouter les nouveaux pairs BGP.

Toutes les adresses IP utilisées par le cluster sont allouées à partir de externalCidrBlock du rack ou codées en dur (pour les adresses IP internes au cluster). Dans le schéma suivant, l'exemple externalCidrBlock est 10.0.0.0/24 :

Plages d'adresses IP du cluster

Plusieurs plages d'adresses IP doivent être configurées dans un cluster Bare Metal.

• CIDR des pods : plage d'adresses IP utilisée pour attribuer des adresses IP aux pods du cluster. Cette plage utilise le mode île, de sorte que le réseau physique (ToR) n'a pas besoin de connaître le CIDR du pod. La seule exigence est que la plage ne doit pas chevaucher les services auxquels les pods du cluster doivent accéder. Le CIDR du pod ne peut pas être modifié après la création du cluster.
• CIDR du service : utilisé pour les services de cluster internes avec les mêmes exigences que le CIDR du pod.
• CIDR du nœud : adresses IP des nœuds du cluster Kubernetes. Ces adresses ne peuvent pas non plus être modifiées une fois le cluster créé.
• Plage d'entrée : plage d'adresses IP utilisée pour tous les services du cluster qui sont exposés en externe. Les clients externes utilisent ces adresses IP pour accéder aux services du cluster. Cette plage doit être annoncée au réseau client afin que les clients puissent accéder aux adresses IP d'entrée.
• Adresse IP virtuelle du plan de contrôle : annoncée par le cluster pour accéder à l'api-server Kubernetes (semblable aux adresses IP virtuelles d'entrée). Cette adresse IP virtuelle doit provenir du même sous-réseau que le nœud lorsque le cluster est en mode d'équilibrage de charge L2.

Les CIDR de pod et de service pour les clusters sont codés en dur. Le CIDR du pod est 192.168.0.0/16 et le CIDR du service est 10.96.0.0/12. Le cluster utilise les deux mêmes CIDR, car ces adresses IP ne sont pas exposées en dehors du cluster.

Remarque : Les adresses IP des machines virtuelles (VM) sont attribuées à partir de la plage instance-default-vpc-cidr, qui est fixe à 192.168.0.0/16. Si l'appliance est connectée à un réseau client via le commutateur TOR, il est essentiel de s'assurer que la plage d'adresses IP du réseau client n'entre pas en conflit avec la plage 192.168.0.0/16. Le chevauchement des plages d'adresses IP peut entraîner un routage incorrect du trafic des appliances.

Les nœuds sont provisionnés avec des adresses IP issues de l'ensemble externalCidrBlock défini dans le cell.yaml GDC. Ces adresses IP sont fournies par le client avant le provisionnement du rack.

La plage d'entrée et l'adresse IP virtuelle du plan de contrôle pour le cluster sont également allouées à partir de externalCidrBlock. Le TOR doit annoncer externalCidrBlock au réseau client afin que ces VIP soient accessibles aux clients en dehors du rack.

Remarque : Les adresses IP des machines virtuelles (VM) sont attribuées à partir de la plage instance-default-vpc-cidr, qui est fixe à 192.168.0.0/16. Si l'appliance est connectée à un réseau client via le commutateur TOR, il est essentiel de s'assurer que la plage d'adresses IP du réseau client n'entre pas en conflit avec la plage 192.168.0.0/16. Le chevauchement des plages d'adresses IP peut entraîner un routage incorrect du trafic des appliances.