Architettura

Questo documento descrive l'architettura di deployment, cluster e rete dell'appliance con air gap di Google Distributed Cloud (GDC).

Architettura di deployment

Il seguente diagramma illustra come l'hardware dell'appliance si inserisce in una rete del cliente che include componenti opzionali come HSM, un server NTP e client aggiuntivi all'interno della rete. L'appliance è dotata di un piano di gestione, un piano dati, server e un server abilitato per una GPU, tutti progettati per eseguire i carichi di lavoro direttamente all'edge.

Architettura di deployment

Architettura dei cluster

L'appliance GDC air-gapped gestisce un singolo cluster che comprende tutti e tre i nodi bare metal, noto come cluster di infrastruttura dell'organizzazione. Un server API di gestione dedicato, che viene eseguito come carichi di lavoro dei pod sul cluster, ospita le API del management plane. Su questo cluster possono essere eseguiti i workload utente, che includono sia VM sia pod Kubernetes. Non esiste alcun cluster utente in questo modello di cluster.

Architettura di rete

L'EL8000 include un backplane che crea quattro reti di livello 2 (L2) separate all'interno del dispositivo:

  1. Console Integrated Lights-Out (iLO) (1 GbEth)
  2. Rete di gestione (1 GbEth)
  3. Rete di dati A (10GbEth)
  4. Rete di dati B (10GbEth)

Il seguente diagramma mostra come le reti L2 sono connesse allo switch Mellanox (https://www.hpe.com/psnow/doc/a00043975enw.html?jumpid=in_pdp-psnow-qs). Ogni rete in una lama si connette a un singolo switch di rete. Tutte le reti della console iLO in ogni server blade si connettono allo switch di rete 1. Le reti di gestione si connettono allo switch di rete 2 e le reti di dati si connettono agli switch 3 e 4.

Reti di livello 2 che si connettono allo switch

Le porte di rete del cliente (15 e 17) hanno accesso al cluster (VLAN 100) e è consentito solo il traffico verso il CIDR Ingress. Il CIDR Ingress è disponibile per i servizi e l'intervallo viene pubblicizzato tramite Border Gateway Protocol (BGP) alla rete del cliente.

Le porte di rete di gestione (16 e 18) hanno accesso alla gestione del sistema (VLAN 501), in modo che i clienti possano avere il dispositivo su una rete più ampia e utilizzare solo connessioni locali per eseguire attività di amministrazione di sistema.

Topologia di rete inferiore

Rete fisica

Il GDC è costituito da un cluster ibrido che opera in modalità single tenant. Il cluster ibrido, che chiamiamo cluster dell'infrastruttura, è costituito dalla fusione dei cluster di sistema e di amministrazione:

Rete fisica

Il design fisico è incentrato su un Mellanox SN2010 che funge da gateway tra il cluster Appliance Infra e la rete esterna del cliente.

Il cluster dell'infrastruttura è costituito da tre nodi Bare Metal (BM). Le connessioni sui BM possono essere classificate come segue:

  • Connettività di rete dati (subnet 198.18.2.0/24) tramite la VLAN 100. Il BM ha una NIC con 2 porte, NIC0P1 e NIC0P2, che sono collegate e connesse allo switch TOR. BM1 e BM2 si connettono direttamente allo switch, mentre BM3 si connette al TOR utilizzando uno switch non gestito.
  • La connettività della rete di gestione ( subnet 198.18..0/24) avviene tramite la VLAN 501. Le interfacce ILO e MGMT sono connesse a questa VLAN utilizzando interfacce da 1 G. Le interfacce ILO e MGMT sui nodi BM si connettono allo switch utilizzando switch non gestiti.
  • Forse: aggiungi il networking OTS alle VLAN 200-203(?), subnet 198.18.1.x

La connessione dallo switch Mellanox al router del cliente fornisce connettività esterna. Per questa connettività vengono utilizzate interfacce da 10 G e il protocollo BGP viene utilizzato per annunciare gli IP di rete esterni al cliente. I clienti utilizzano gli IP esterni per accedere ai servizi necessari forniti dall'unità appliance.

Rete logica

Esistono due reti locali virtuali (VLAN) che separano il traffico:

  1. VLAN 100: cluster (indirizzi IP virtuali (VIP) in entrata, IP cluster/nodo) con subnet IPv4 fornita dai clienti.
  2. VLAN 501: gestione (iLO, Mgmt) con subnet IPv4 fornita dal cliente.

Rete logica

Topologia di rete superiore

Il cluster è configurato utilizzando il bilanciamento del carico di livello 2 (L2). I VIP Ingress per il cluster provengono dalla stessa subnet dei nodi. Quando un VIP Ingress viene assegnato a un nodo, il nodo utilizza il protocollo di risoluzione degli indirizzi (ARP) in modo che sia raggiungibile dal TOR.

Il TOR esegue il peering con la rete del cliente utilizzando BGP e pubblicizza l'intervallo Ingress del cluster (prefisso aggregato fornito dal cliente) alla rete del cliente. Quando il rack viene spostato in una nuova posizione, possiamo pubblicizzare l'intervallo Ingress del cluster alla nuova rete del cliente. Quando il rack viene spostato in una nuova posizione, devi aggiornare manualmente gli indirizzi IP sulle interfacce TOR che si connettono alla rete del cliente e aggiornare le informazioni di peering BGP per aggiungere i nuovi peer BGP.

Tutti gli IP utilizzati dal cluster vengono allocati da externalCidrBlock del rack o sono hardcoded (per gli IP interni al cluster). Nel seguente diagramma, l'esempio di externalCidrBlock è 10.0.0.0/24:

Il cluster utilizza L2 LB (ARP) per annunciare 10.0.0.224.

Intervalli IP cluster

In un cluster bare metal devono essere configurati diversi intervalli IP.

  • CIDR pod: l'intervallo IP utilizzato per assegnare IP ai pod nel cluster. Questo intervallo utilizza la modalità isolata, in modo che la rete fisica (ToR) non debba conoscere il CIDR del pod. L'unico requisito è che l'intervallo non possa sovrapporsi a nessun servizio a cui devono accedere i pod del cluster. Il CIDR del pod non può essere modificato dopo la creazione del cluster.
  • CIDR servizi: utilizzato per i servizi del cluster interni con lo stesso requisito del CIDR pod.
  • CIDR nodo: indirizzi IP dei nodi del cluster Kubernetes. Questi indirizzi non possono essere modificati dopo la creazione del cluster.
  • Intervallo in entrata: un intervallo di indirizzi IP utilizzato per tutti i servizi nel cluster esposti esternamente. I client esterni utilizzano questi IP per accedere ai servizi nel cluster. Questo intervallo deve essere pubblicizzato alla rete del cliente in modo che i client possano raggiungere gli IP Ingress.
  • VIP del control plane: annunciato dal cluster per l'accesso a Kubernetes api-server (simile ai VIP Ingress). Questo VIP deve provenire dalla stessa subnet del nodo quando il cluster è in modalità di bilanciamento del carico L2.

I CIDR di pod e servizi per i cluster sono hardcoded. Il CIDR del pod è 192.168.0.0/16 e il CIDR del servizio è 10.96.0.0/12. Il cluster utilizza gli stessi due CIDR, poiché questi IP non sono esposti all'esterno del cluster.

I nodi vengono sottoposti al provisioning con indirizzi IP dal externalCidrBlock impostato nel GDC cell.yaml. Questi indirizzi IP vengono forniti dal cliente prima del provisioning del rack.

Anche l'intervallo Ingress e il VIP del control plane per il cluster vengono allocati da externalCidrBlock. TOR deve pubblicizzare externalCidrBlock alla rete del cliente in modo che questi VIP siano accessibili ai client al di fuori del rack.