19. Bootstrap del cluster di amministrazione principale

Tempo stimato per il completamento: 7 ore

Proprietario del componente operabile: KUB/SERV/OBJ/FILE/PNET

Profilo delle competenze: ingegnere del deployment

Questa guida crea un cluster di amministrazione radice che funge da control plane per il cluster interno e i cluster dell'infrastruttura dell'organizzazione.

19.1. Configurare la configurazione del routing

Verifica che la route statica sia stata aggiunta durante l'installazione del server Bootstrapper. Se la route statica non è presente, aggiungi una route statica al bootstrapper:

DATA_CIDR=$(kubectl get cidrclaim -n gpc-system instance-external-cidr -o jsonpath={.spec.ipv4Spec.staticCidrBlocks[0]})
DATA_GATEWAY=$(kubectl get subnetclaims -n root control-plane-subnet -o jsonpath={.status.ipv4SubnetStatus.gateway})
ip route replace ${DATA_CIDR} via ${DATA_GATEWAY}

Questa route fornisce l'accesso al server API del cluster di amministrazione root dall'interfaccia dataplane sul bootstrapper. Per saperne di più sui server API in GDC, vedi Server API globali e di zona.

19.2. Crea il cluster di amministrazione principale

Il seguente comando crea un cluster di amministrazione principale con tre nodi del control plane. La modalità tenant predefinita è la modalità multi-tenant.

gdcloud system admin-cluster install -v=3 \
  --tenant-mode=multi \
  --root-admin-node-count=3 \
  --generate-admin-yaml \
  --addon-manager-manifests-set harbor.postgresqlHA.enabled=true \
  --addon-manager-manifests-set harbor.productionEnvironment.enabled=true \
  --addon-manager-manifests-set storage.mode=ontap \
  --addon-manager-manifests-set gpuFeature.enabled=true \
  --addon-manager-manifests-set rootAdmin.controller.adminLBPoolSize=23 \
  --addon-manager-manifests-set rootAdmin.controller.systemLBPoolSize=60 \
  --addon-manager-manifests-set network.noInternalSubnet=false \
  --addon-manager-manifests-set minStage=FEATURE_THRESHOLD

Nota :il parametro --addon-manager-manifests-set minStage=FEATURE_THRESHOLD non è necessario se la soglia della funzionalità è production. Il valore di FEATURE_THRESHOLD deve essere lo stesso impostato per l'intero deployment.

La creazione del cluster di amministrazione principale richiede un file di configurazione per il CR del cluster. La configurazione viene generata automaticamente per impostazione predefinita. È consentita anche la configurazione personalizzata del cluster impostando il flag --generate-admin-yaml su false e specificando --admin-yaml-path per indicare il percorso di configurazione di destinazione.

Al termine dell'installazione del cluster di amministrazione principale, il kubeconfig del cluster di amministrazione principale viene memorizzato in /root/release/root-admin/root-admin-kubeconfig.

Nota: Internet Protocol versione 6 (IPv6) è disponibile per il cluster di amministrazione principale per impostazione predefinita dopo il completamento del bootstrapping.

L'URL dell'interfaccia utente (UI) dell'amministratore utente viene stampato dopo l'installazione del cluster. Ricordalo per utilizzarlo nelle operazioni successive. Puoi anche recuperarlo utilizzando il seguente comando:

gdcloud system admin-cluster describe

19.3. Esegui il deployment dei componenti nel cluster di amministrazione principale

Il seguente comando esegue il deployment di modelli del ciclo di vita dei componenti operabili nel cluster di amministrazione radice.

gdcloud system component deploy --kubeconfig KUBECONFIG --names=* --pivot-from=/root/.kube/config

19.4. Configurare i feature gate per l'amministratore root

Avviso: segui le istruzioni riportate in questa sezione solo se hai impostato una soglia di fase della funzionalità diversa da production.

Se hai una soglia di fase delle funzionalità diversa da production, devi aggiornare i feature gate di conseguenza in modo che corrispondano alla soglia, seguendo OOPS-P0072.

19.5. Configura il resolver stub sul bootstrapper

Utilizza il seguente comando per configurare il resolver stub DNS sul bootstrapper. Questo resolver stub è necessario per accedere alla console.

gdcloud system dns install

Questa configurazione assicura che tutti i nomi di dominio delle organizzazioni siano risolvibili dal bootstrapper, come mostrato nel seguente diagramma:

19.6. Imposta gli indirizzi IP di iLO

I seguenti passaggi impostano gli indirizzi IP ILO su static per i nodi amministratore.

  ADMIN_NODE=NODE NAME
  RACK=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.metadata.labels.system\.private\.gdc\.goog/rack-name}')
  ILO_IP=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.ip}')
  ILO_GATEWAY=$(kubectl --kubeconfig KUBECONFIG get subnetclaims -n root $RACK-mgmtsw01-server-bmc-subnet -o jsonpath='{.status.ipv4SubnetStatus.gateway}')
  BMC_CREDS=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.credentialsRef.name}')
  ILO_USER=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.username}' | base64 --decode)
  ILO_PASS=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.password}' | base64 --decode)

  echo Target Server: $ADMIN_NODE
  echo ILO IP: $ILO_IP
  echo ILO Gateway: $ILO_GATEWAY
  echo ILO Username: $ILO_USER
  echo ILO Password: $ILO_PASS

Verifica che le informazioni precedenti siano corrette in base a quelle del cluster. Esegui il seguente comando se le informazioni precedenti sono corrette.

1. Disattiva DHCP.

   curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"DHCPv4": {"DHCPEnabled": false}}' | jq '.'
   

   Risultato previsto:

   MessageId: iLO.2.15.ResetRequired

2. Configura l'indirizzo IP e il gateway.

   curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"IPv4Addresses":[{"Address":"'${ILO_IP}'","Gateway":"'${ILO_GATEWAY}'","SubnetMask":"255.255.255.0"}],"IPv4StaticAddresses": [{"Address": "'${ILO_IP}'", "Gateway": "'${ILO_GATEWAY}'", "SubnetMask": "255.255.255.0"}]}' | jq .
   

   Risultato previsto:

   MessageId: Base.1.4.Success

3. Reimposta iLO Manager.

   curl -k -u ${ILO_USER}:${ILO_PASS}  -H "Content-Type: application/json" -H "OData-Version: 4.0" https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset --data '{"ResetType":"ForceRestart"}' -X POST | jq .
   

   Risultato previsto:

   MessageId: iLO.2.15.ResetInProgress

4. Verifica che le impostazioni Ethernet siano state applicate. Se la risposta è in attesa, il ripristino non è stato completato. Annulla il comando curl corrente, attendi 20 secondi e riprova.

   curl --insecure -u ${ILO_USER}:${ILO_PASS} https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 -X GET | jq .
   

Verifica la riuscita dell'operazione controllando che il valore restituito HTTP per ogni passaggio corrisponda al risultato previsto.

Ripeti i passaggi precedenti per tutti i nodi di amministrazione principale presenti nel cluster.

19.7. Stabilisci la connettività di rete OI e con air gap di Google Distributed Cloud (GDC)

Questa sezione descrive come eseguire il provisioning dei file di configurazione che le reti Operations Suite Infrastructure (OI) e Distributed Cloud devono stabilire la connettività.

Questi passaggi richiedono l'accesso ad alcuni file di Distributed Cloud, nonché la connettività al cluster di amministrazione principale dell'istanza Distributed Cloud per recuperare le informazioni di rete di runtime.

Importante: se non hai lavorato con il bootstrapper Distributed Cloud, potresti aver bisogno dell'assistenza di un ingegnere di deployment Distributed Cloud per ottenere l'accesso al bootstrapper e assicurarti l'accesso all'API Kubernetes del cluster di amministrazione principale.

19.7.1. Prima di iniziare

In questa fase del processo di deployment, devono essere vere tutte le seguenti condizioni:

1. Entrambi gli switch OIR sono collegati via cavo, accesi, aggiornati alla versione appropriata e hanno configurazioni di base e ACL applicate.

2. Entrambi i firewall OIF sono collegati con cavi, accesi, aggiornati alla versione appropriata, abilitati per la modalità FIPS-CC e hanno la configurazione di base applicata.

3. Per completare il provisioning dell'intera connettività Distributed Cloud, l'istanza Distributed Cloud deve aver completato il bootstrap di rete e non deve più trovarsi nel cluster kind, ma nel cluster di amministrazione root.

Importante: i passaggi che richiedono l'utilizzo dei file cellcfg devono comunque essere completati anche se il passaggio 3 non è ancora completamente terminato, ma il file cellcfg è disponibile. In questo modo, gli switch possono essere configurati e preparati per la connettività Distributed Cloud. Una volta che il cluster è attivo e completamente pronto, è necessario un passaggio aggiuntivo per generare e applicare i criteri di sicurezza del firewall.

19.7.2. Prepara l'ambiente

Prepara l'ambiente per i passaggi successivi raccogliendo le seguenti informazioni e impostando le variabili di ambiente.

L'OI può essere connesso in due modi: localmente o da remoto. Una connessione locale collega OI a Distributed Cloud direttamente utilizzando connessioni in fibra tra i rack dello stesso data center. Una connessione remota si connette a una posizione diversa utilizzando il trasporto a lungo raggio. Questa specifica può essere fornita nel file interconnect.yaml, necessario per il provisioning delle configurazioni di interconnessione Distributed Cloud. Questo file contiene tutte le informazioni necessarie per configurare le interconnessioni GDC.

19.7.2.1. Specifica YAML dell'interconnessione

Attributo	Descrizione	Esempio
zones [ ] map	Informazioni sulla cella Distributed Cloud a cui deve connettersi il deployment di OI. Per connetterti a un elenco di celle Distributed Cloud, specifica un elenco di zones con le informazioni di ogni cella Distributed Cloud in ogni zona. Opzioni relative alla zona	Esempio: zones: - zoneName: kb - uplinkSpeed: 10 localInstanceIDs: 2 remoteInstanceIDs: - 1 - cellCfg: path/to/cellcfg - zoneName: ah - uplinkSpeed: 100 localInstanceIDs: 3 - cellCfg: path/to/cellcfg

19.7.2.2. Opzioni relative alla zona

Contiene informazioni su una cella Distributed Cloud nel file interconnect.yaml:

Attributo	Descrizione	Utilizzo
zoneName stringa	Abbreviazione della cella Distributed Cloud a cui deve connettersi il deployment di OI.	zones: - zoneName: kb
uplinkSpeed uint32	(Facoltativo) Fornisce la velocità di caricamento della connessione: (10 o 100).	Valori:10, 100 Predefinito: 10 uplinkSpeed: 100
localInstance int	Il InstanceID del sito di deployment di OI dal file ocit.yaml. Una connessione locale collega il sito Operations Suite Infrastructure Core Rack (OIR) a Distributed Cloud direttamente utilizzando connessioni in fibra tra i rack dello stesso data center.	zones: - zoneName: kb localInstanceIDs: 1
remoteInstance [ ] int	InstanceID(s) del sito di deployment di OI dal file ocit.yaml Una connessione remota si connette a una o più località diverse utilizzando il trasporto a lungo raggio. È possibile fornire un elenco di valori remoteInstance, in modo che vengano generate configurazioni per tutti i siti OIR per connettersi alle celle Distributed Cloud specificate.	zones: - zoneName: kb remoteInstanceIDs: - 1 zones: - zoneName: kb remoteInstanceIDs: - 1 - 2 - 3

Se si tratta di una connessione locale, configura il file interconnect.yaml come segue:

zones:
  - zoneName: ah
    uplinkSpeed: 100
    localInstanceID: 1
    cellCfg: /path/to/cellcfg

Se si tratta di una connessione remota, configura il file interconnect.yaml come segue:

zones:
  - zoneName: ah
    uplinkSpeed: 100
      remoteInstanceIDs:
      - 2
    cellCfg: /path/to/cellcfg

Per le implementazioni OI multiazienda, specifica il file interconnect.yaml come segue:

zones:
  - zoneName: ah
    uplinkSpeed: 100
    localInstanceID: 1
    remoteInstanceIDs:
      - 2
    cellCfg: /path/to/cellcfg

Avviso: completa questi passaggi e utilizza i percorsi appropriati completi o i non verranno eseguiti correttamente.

19.7.3. Genera configurazioni di switch

Questi passaggi generano configurazioni di patch da applicare ai dispositivi di rete per eseguire il provisioning della connettività a Distributed Cloud.

occonfigtool generate cell config -c /path/to/interconnect.yaml -o path/to/ocit.yaml

Vengono generati i seguenti file di configurazione per ogni sito:

File di configurazione	Dispositivo	Funzione
occoresw101.incremental	occoresw101	Configurazione per applicare patch al dispositivo per la connettività all'istanza Distributed Cloud
occoresw101.acl	occoresw101	Configurazione per applicare patch agli elenchi di controllo degli accessi per l'applicazione del traffico con le reti Distributed Cloud.
occoresw102.incremental	occoresw102	Configurazione per applicare patch al dispositivo per la connettività all'istanza Distributed Cloud
occoresw102.acl	occoresw102	Configurazione per applicare patch agli elenchi di controllo degli accessi per l'applicazione del traffico con le reti Distributed Cloud.
ocsw101.incremental	ocs1w01	Configurazione per applicare patch al dispositivo per la connettività all'istanza Distributed Cloud
ocsw101.acl	ocsw101	Configurazione per applicare patch agli elenchi di controllo degli accessi per l'applicazione del traffico con le reti Distributed Cloud.
ocsw102.incremental	ocsw102	Configurazione per applicare patch al dispositivo per la connettività all'istanza Distributed Cloud
ocsw102.acl	ocsw102	Configurazione per applicare patch agli elenchi di controllo degli accessi per l'applicazione del traffico con le reti Distributed Cloud.

Nota :per le implementazioni dell'infrastruttura Operations Suite (OI) multisito, viene generata una configurazione per ogni sito menzionato nel file interconnect.yaml. Identifica i file generati per ogni sito utilizzando InstanceID. I file generati hanno un prefisso con il seguente formato: <segment_type><device_type><InstanceID><device_id>

19.7.4. Genera policy firewall

Per generare le regole firewall, occonfigtool deve accedere all'API Kubernetes per il cluster di amministrazione principale. Assicurati che la variabile di ambiente KUBECONFIG sia impostata su root-admin-kubeconfig:

export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
export OCIT_CONFIG_FILE=/path/to/ocit.yaml

Genera le regole firewall eseguendo questo comando:

occonfigtool generate fwrules -o ${OCIT_CONFIG_FILE:?}

File di configurazione	Dispositivo	Funzione
firewall-rules.base	occorefw01	Configurazione per applicare patch al dispositivo per la connettività all'istanza Distributed Cloud

19.7.5. Applica configurazioni

Utilizzando i file di output, applica la configurazione ai rispettivi dispositivi di rete utilizzando la stessa procedura del passaggio precedente per switch e firewall.

19.8. Aggiorna le risorse Distributed Cloud RoutePolicy

Distributed Cloud utilizza i criteri di route per applicare le reti autorizzate a essere pubblicizzate nella tabella di routing.

Quando aggiungiamo OI come rete esterna, dobbiamo aggiornare i RoutePolicy CR per prevedere le nuove reti.

Ciò richiede l'accesso a root-admin-cluster tramite kubectl. Assicurati che sia impostata la variabile KUBECONFIG appropriata:

export KUBECONFIG=/root/deploy/root-admin/root-admin-kubeconfig

Per confermare, procedi nel seguente modo:

kubectl get routepolicy -n gpc-system

Dovresti visualizzare un output simile al seguente:

NAME                                     AGE
customerpeering-routepolicy              19d
datacenter-routepolicy                   19d
mgmtnetworkoperationcenter-routepolicy   19d
networkoperationcenter-routepolicy       19d

Per questi passaggi, ci concentreremo su networkoperationcenter-routepolicy e mgmtnetworkoperationcenter-routepolicy.

19.8.1.1. Applicare patch alle policy di route della rete di dati

Da ocinfo.opscenter.local.txt, recupera le seguenti subnet (inclusi la rete e la lunghezza del prefisso).

Nota :per il deployment di OI multisito, ripeti questo passaggio per tutti i siti. Utilizza le subnet del file ocinfo.opscenter.local.txt dei siti elencati.

• OCCORE-SERVERS, utilizzato nell'esempio seguente come $OCCORE_SERVERS_NET
• OC-WORKSTATIONS, utilizzato nel seguente esempio come $OC_WORKSTATIONS_NET

Utilizza questi valori per modificare le norme di routing compilando le seguenti variabili:

export OCCORE_SERVERS_NET=$OCCORE_SERVERS_NET
export OC_WORKSTATIONS_NET=$OC_WORKSTATIONS_NET

Ad esempio:

export OCCORE_SERVERS_NET=172.21.0.0/24
export OC_WORKSTATIONS_NET=172.21.32.0/24

Dopo aver impostato le variabili di ambiente, esegui i seguenti comandi kubectl:

kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_SERVERS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OC_WORKSTATIONS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

Output di esempio:

routepolicy.system.private.gdc.goog/networkoperationcenter-routepolicy patched

19.8.1.2. Policy di routing di rete per la gestione delle patch

Da ocinfo.opscenter.local.txt, recupera le seguenti subnet (inclusi la rete e la lunghezza del prefisso).

Nota :per le implementazioni OI multisito, ripeti questo passaggio per tutti i siti. Utilizza le subnet dei file ocinfo.opscenter.local.txt dell'elenco dei siti.

• OCCORE-JUMPHOSTS, utilizzato nel seguente esempio come $OCCORE_JUMPHOSTS_NET
• OCCORE-ILOS, utilizzato nel seguente esempio come $OCCORE_ILOS_NET

Utilizza questi valori per modificare le norme di routing compilando le seguenti variabili:

export OCCORE_JUMPHOSTS_NET=$OCCORE_JUMPHOSTS_NET
export OCCORE_ILOS_NET=$OCCORE_ILOS_NET

Ad esempio:

export OCCORE_JUMPHOSTS_NET=172.21.2.0/27
export OCCORE_ILOS_NET=172.21.2.32/27

Dopo aver impostato le variabili di ambiente, esegui i seguenti comandi kubectl:

kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_JUMPHOSTS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_ILOS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

Output di esempio:

routepolicy.system.private.gdc.goog/mgmtnetworkoperationcenter-routepolicy patched

19.9. Convalidare la connettività di rete di OI Distributed Cloud

Importante: completa i passaggi di convalida in Stabilisci la connettività di OI Network e Distributed Cloud prima di convalidare le connessioni Distributed Cloud. Tieni presente che se le configurazioni incremental eseguite nel passaggio precedente sono già state applicate, le convalide in questo passaggio potrebbero non corrispondere esattamente.

A questo punto dell'implementazione, devono verificarsi le seguenti condizioni:

• Sia occoresw101 che occoresw102 sono configurati con i file di configurazione base, acl, incremental e incremental-acl.
• Sia ocsw101 che ocsw102 sono configurati con i file di configurazione base, acl, incremental e incremental-acl.
• occorefw101 e occoref102 sono configurati con i file di configurazione base e firewall-rules.base.
• I collegamenti uplink tra il data center e il centro operativo sono connessi e operativi.
• Gli uplink fisici tra Distributed Cloud vengono verificati.

Nota: per le implementazioni dell'infrastruttura Operations Suite (OI) multisito, i file di configurazione vengono generati e applicati per ogni sito.

Se una delle condizioni precedenti non è vera, l'output seguente potrebbe differire notevolmente a seconda dello stato attuale e probabilmente non produrrà il comportamento previsto in produzione.

19.9.1. Output previsto

I seguenti snippet mostrano l'output di un ambiente funzionante dei seguenti comandi:

• show ip bgp summary vrf all
• show ip bgp vrf all
• show ip route vrf all
• show lldp neighbors

Nota: aggiungi | no-more alla fine di ogni comando per evitare la paginazione, ad esempio show ip bgp vrf all | no-more.

Questi snippet possono fungere da confronto con un ambiente di produzione utilizzando gli stessi comandi.

19.9.2. Convalide delle chiavi

Di seguito sono riportati gli elementi chiave da cercare negli output seguenti:

• Nessuna sessione BGP è in stato Idle, Active o Closing.
• Tutte le sessioni BGP mostrano un valore State/PrxRcd maggiore di 0.
• Tutte le sessioni BGP mostrano un timer Up/Down che aumenta continuamente.
• Il prefisso externalCIDR di Distributed Cloud (che si trova in CIQ) è presente nelle tabelle di routing e BGP dei VRF GDCH-DATA, GDCH-DATA-TRANSIT, OC-WORKSTATIONS e OCCORE-SERVERS.
• oobManagementCIDRs (presente in CIQ) è presente nelle tabelle di routing e BGP dei VRF GDCH-MGMT, GDCH-MGMT-TRANSIT e HW-INFRA.

19.9.3. OCCORESW

La tabella seguente mostra l'output previsto su ogni occore switch per gli interconnessioni Distributed Cloud. Prima di questo passaggio, devi completare tutte le convalide di rete. I vicini e le route BGP discussi qui devono essere presenti insieme ai vicini e alle route BGP menzionati in precedenza. Convalida l'output su tutti gli switch.

VRF	Peer BGP	Route previste ricevute dal peer BGP	Route previste annunciate al peer BGP
GDCH-DATA-TRANSIT	AGGSW01	Indirizzo di riepilogo aggregato con subnet /19 per la cella Distributed Cloud	Prefisso OCCORE-SERVERS Prefisso OC-WORKSTATION
GDCH-DATA-TRANSIT	AGGSW02	Indirizzo di riepilogo aggregato con subnet /19 per la cella Distributed Cloud	Prefisso OCCORE-SERVERS Prefisso OC-WORKSTATION
GDCH-DATA-TRANSIT	Sessione BGP con hairpinning che utilizza OCCOREFW per OC-DATA VRF	Indirizzo di riepilogo aggregato (con subnet /19) per la cella Distributed Cloud
OC-DATA	Sessione BGP OCSW01	Indirizzo di riepilogo aggregato (con subnet /19) per la cella Distributed Cloud
OC-DATA	Sessione BGP OCSW02	Indirizzo di riepilogo aggregato (con subnet /19) per la cella Distributed Cloud
OC-DATA	Sessione BGP OCCORESW	Indirizzo di riepilogo aggregato (con subnet /19) per la cella Distributed Cloud
GDCH-MGMT-TRANSIT	MGMTAGGSW01	Indirizzi di riepilogo aggregati (con subnet /24) di tutta la rete di gestione OOB GDCH	Prefisso OCCORE-JUMPHOSTS Prefisso OCCORE-ILOS
GDCH-MGMT-TRANSIT	MGMTAGGSW02	Indirizzi di riepilogo aggregati (con subnet /24) di tutta la rete di gestione OOB di Distributed Cloud	Prefisso OCCORE-JUMPHOSTS Prefisso OCCORE-ILOS
GDCH-MGMT-TRANSIT	Sessione BGP con hairpinning che utilizza OCCOREFW per HW-INFRA VRF	Indirizzi di riepilogo aggregati (con subnet /24) di tutta la rete di gestione OOB di Distributed Cloud

19.9.4. OCSW

La tabella seguente mostra l'output previsto su ogni oc switch dopo l'esecuzione della procedura di interconnessione Distributed Cloud. Prima di questo passaggio, devi completare tutte le convalide di rete. I vicini e le route BGP discussi qui devono essere presenti insieme ai vicini e alle route BGP menzionati in precedenza. Convalida l'output su tutti gli switch.

VRF	Peer BGP	Route previste ricevute dal peer BGP
OC-DATA	Sessione BGP OCCORESW01	Indirizzo di riepilogo aggregato (con subnet /19) per la cella GDCH
OC-DATA	Sessione BGP OCCORESW02	Indirizzo di riepilogo aggregato (con subnet /19) per la cella GDCH

Lo snippet del comando di output è disponibile in Distributed Cloud validations show command.

Nota: la sezione seguente riguarda la convalida delle implementazioni multisito. Questa sezione può essere ignorata in sicurezza se la tua implementazione non è multisito.

19.9.5. Convalide del deployment di OI multisito

La sezione seguente descrive in dettaglio come convalidare i deployment multisito con più celle Distributed Cloud interconnesse. A questo punto, la topologia con due siti ha il seguente aspetto:

• Le connessioni blu mostrano il sito 1 connesso alle celle 01 e 02 di Distributed Cloud.
• Le connessioni rosse mostrano il sito 2 connesso alla cella 01 e alla cella 02 di Distributed Cloud.
• Le connessioni verdi mostrano l'interconnessione tra il sito 1 e il sito 2.

Per tutti i siti su tutti gli switch, devi completare i passaggi elencati in queste sezioni.

1. Convalide di rete.
2. Convalide multisito della rete.
3. Network Distributed Cloud Validations.

19.10. Esegui i passaggi finali della rete OI

A questo punto, tutte le configurazioni devono essere state generate e applicate a tutti i dispositivi.

Gli elenchi di controllo degli accessi alla rete si trovano ora in uno stato che consente flussi specifici previsti, ma hanno anche una regola predefinita che consente tutto il traffico.

Ora devi trasferire il deployment alle operazioni. La suite operativa varia in termini di funzione, implementazione e servizi forniti tra i clienti. Di conseguenza, ha requisiti di traffico variabili.

Una volta accettato il deployment, il team delle operazioni ha il compito di esaminare le ACL e proteggere completamente i flussi di traffico di rete.

Per eseguire queste attività vengono forniti runbook operativi.

19.11. Esegui l'upgrade dell'archiviazione di oggetti

Durante il bootstrap dell'archiviazione degli oggetti, i nodi sono stati installati con l'ultima versione secondaria supportata di StorageGRID. Tuttavia, potrebbe essere necessario aggiornare la versione di destinazione all'ultima versione della patch hotfix.

Determina la versione di StorageGRID di destinazione dai metadati della release con il seguente comando:

kubectl get releasemetadata -o jsonpath='{.items[0].spec.infraComponents.objectStorage.storageGridOSImageVersion}'

Se la versione attuale di StorageGRID non è la versione di destinazione, esegui un upgrade dell'archivio di oggetti con la versione di destinazione.

19.12. Potenziali problemi

Importante: potresti riscontrare questi problemi durante l'installazione della versione 1.9.x di Distributed Cloud.

19.12.1. La macchina virtuale di archiviazione non viene riconciliata

TLDR: la macchina virtuale di archiviazione non diventa pronta durante la creazione del cluster di amministrazione principale.

Problema: dopo aver creato il cluster di amministrazione principale, la risorsa Storage Virtual Machine non viene riconciliata e mostra un evento di avviso come:

StorageVirtualMachine Reconcile error, retrying: SVM status update failed,
error: failed to get network interface info: Get
"https://172.22.147.128/api/network/ip/interfaces?fields=%2A%2A&max_records=4096&svm.name=root-admin":
EOF

Una configurazione errata del cluster di archiviazione che impedisce l'utilizzo di SSL per motivi di sicurezza potrebbe causare questo problema.

Soluzione:

Connettiti alla porta seriale o al cluster di archiviazione utilizzando SSH ed esegui:

security ssl modify -server-enabled true -client-enabled true -vserver
CELL_ID-stge-clus-01

Dopo la connessione, la risorsa Storage Virtual Machine è in grado di eseguire la riconciliazione.

19.12.2. Il bootstrap non è riuscito durante l'installazione del certificato TLS del server firewall

Potresti riscontrare un errore TLSServerCertification durante l'esecuzione dell'attività di bootstrap del control plane dell'amministratore root descritta nel passaggio 20.

Soluzione:

Per riprovare a installare il certificato del server firewall, consulta le istruzioni elencate nel manuale di servizio IO FW-R1008. Dopo aver completato l'installazione, utilizza il comando gdcloud con il comando --start-phase per continuare il bootstrap dell'amministratore root.