Questa pagina è stata tradotta dall'API Cloud Translation.

Eseguire un'espansione dinamica

Questa pagina descrive il processo di espansione dinamica del sistema mediante l'incorporazione di ulteriori risorse di archiviazione e di calcolo. Vengono fornite istruzioni per i seguenti tipi di espansione:

Espansione orizzontale del rack del server: aggiunge un nuovo rack alla zona. Questo rack include nodi di calcolo, una console, switch Top-of-Rack (ToR) e switch di gestione (MGMT).
Espansione verticale del server: aggiunge blocchi di espansione del server ai rack che hanno slot di espansione vuoti.
Espansione verticale dell&archiviazione a blocchi di file e blocchi: aggiunge nodi di archiviazione a rack con slot di espansione vuoti in un cluster di archiviazione esistente. I nodi di archiviazione collegati allo stesso switch di archiviazione fanno parte dello stesso cluster.

Per ulteriori informazioni sui diversi tipi di espansione dinamica, consulta la Panoramica dell'espansione dinamica.

Prima di iniziare

Prima di apportare modifiche alla zona, devi disporre di quanto segue:

Esegui un'ispezione hardware e firma con l'OEM . Segui le istruzioni riportate in Ispezione del rack.
Segui la generazione di KUBECONFIG per generare KUBECONFIG per il cluster di amministrazione del nodo del control plane. Utilizza il file di configurazione KUBECONFIG generato per tutti i passaggi di kubectl in questa guida.
Verifica che la versione attuale di Google Distributed Cloud (GDC) con air gap sul cluster root sia almeno la versione 1.13.1:
```
kubectl --kubeconfig $KUBECONFIG get org root -n gpc-system
```
Scarica il file tar GDC. Per ulteriori informazioni, vedi Scaricare file.
Prepara il firmware dei nuovi elettrodomestici:
1. I dispositivi di commutazione dei pacchetti nell'hardware GDC. Per saperne di più, vedi Opzioni.
2. Aggiorna l'archiviazione di file e a blocchi ONTAP seguendo le istruzioni riportate in Upgrade manuale di ONTAP.
Verifica che il sistema GDCH sia integro utilizzando gdcloud system doctor. Se il comando gdcloud system doctor non è disponibile, utilizza il metodo alternativo in Verifica dell'installazione di rete.

Esegui l'espansione orizzontale del rack del server

Aggiungi una nuova rack composta da nodi di calcolo, dalla console e dagli switch ToR e di gestione alla zona tramite un'espansione orizzontale del rack server. I passaggi descritti in questa sezione si riferiscono a un singolo rack. Se hai più rack, applica questi passaggi a ciascuno.

Eseguire operazioni di ripristino

Devi ripristinare in modo sicuro le seguenti apparecchiature:

Esegui un server della console seriale di ripristino sicuro. Contatta Google per queste istruzioni, poiché ogni deployment potrebbe avere console seriali diverse.
Esegui un ripristino sicuro dell'unità di distribuzione dell'alimentazione (PDU) Raritan:
1. Collega il cavo USB-B alla PDU Raritan dal controller di sistema.
2. Nella console seriale locale, ripristina le impostazioni di fabbrica predefinite della PDU utilizzando il comando: reset factorydefaults.
3. L'unità di distribuzione dell'alimentazione è ora impostata su admin/legrand.
Esegui un ripristino sicuro, aggiorna il firmware e ripristina gli switch ToR e MGMT su PowerOn Auto Provisioning (POAP) seguendo le istruzioni riportate in Cancellazione sicura.
Connettiti a ogni server ed esegui la cancellazione sicura manualmente.

Preparare gli artefatti

Segui questi passaggi per applicare i file di configurazione e le risorse personalizzate necessari:

Genera il file YAML ZonalExpansion, l'hardware CustomResources e le risorse hardware SubcomponentOverride utilizzando il comando gdcloud system assets add:

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af

Sostituisci FILE_PATH per ciascuno dei file utilizzati. Tieni presente che questo percorso potrebbe essere diverso se ogni file si trova in una posizione diversa.

La risorsa personalizzata ZonalExpansion tiene traccia di tutti gli oggetti aggiunti e ne segnala lo stato.

Segui queste indicazioni quando esamini il file YAML ZonalExpansion:

Il campo name deve essere descrittivo, ad esempio az-ae-expansion.
Il campo assets deve includere tutti i nuovi elettrodomestici nel nuovo rack di espansione.

Ecco un esempio di risorsa ZonalExpansion:

apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01

Utilizza gli strumenti Infrastructure as Code (IaC) per applicare la risorsa personalizzata ZonalExpansion. Per ulteriori informazioni, vedi Configurazione di Infrastructure as Code. In alternativa, segui il runbook IAM-R0004 e utilizza kubectl per farlo.
Verifica che siano state create le risorse ZonalExpansion e NonCompliantDeviceSet:
1. Controlla lo stato della risorsa ZonalExpansion:
```
kubectl --kubeconfig $KUBECONFIG get -A zonalexpansion -o yaml
```
  In questa fase, il controllo preflight dovrebbe non riuscire con il motivo: ReasonAssetsNotExisted.
2. La risorsa NonCompliantDeviceSet deve esistere con il nome preceduto dal prefisso noncompliantassets-.
3. L'elenco degli asset deve corrispondere al campo assets nella risorsa personalizzata ZonalExpansion.
Segui le istruzioni riportate in OLT-R0003 per aggiornare gli asset.
Collega gli switch ToR e MGMT nel nuovo rack allo switch di aggregazione nel rack esistente.
Collega fisicamente gli interruttori ai rack di base.

Completa il bootstrap del server

Questa fase è per lo più automatizzata, ma sono necessari alcuni passaggi. Devi monitorare l'avanzamento del bootstrap e gestire eventuali casi di errore:

Il controller avvia automaticamente la procedura di bootstrap una volta soddisfatta la condizione PreflightCheck=True.
Verifica che la condizione NetworkBootstrapSucceed=True sia pubblicata nella risorsa personalizzata ZonalExpansion. Questa condizione si trova nella posizione ZonalExpansion.Status.PNETBootstrapStatus.
Verifica che gli interruttori siano stati rimossi dall'elenco NonCompliantDeviceSet:
```
kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A -o yaml
```
Sostituisci EXPANSION_NAME con il nome della risorsa personalizzata di espansione zonale.

Verifica che gli switch non si trovino nel campo Spec.Assets del file YAML restituito. Questa rimozione consente a GDC di aggiornare le ACL di rete per consentire altre procedure di bootstrap dell'appliance. I due elenchi di controllo degli accessi alla rete aggiornati sono quarantine-mgmt-switch-acl e quarantine-data-switch-acl.

Elenca tutti gli indirizzi IP del Baseboard Management Controller (BMC) per il server e verifica che gli indirizzi IP iLO siano assegnati alla nuova macchina bare metal e che il bootstrap possa iniziare:

kubectl --kubeconfig $KUBECONFIG get servers -n gpc-system -o=custom-columns=SERVER:.metadata.name,BMC_IP:.spec.bmc.ip

Output di esempio:

 SERVER       BMC_IP
 yz-aa-bm01   10.128.136.2
 yz-aa-bm02   10.128.136.3
 yz-aa-bm03   10.128.136.4
 yz-ab-bm01   10.128.136.66
 yz-ab-bm02   10.128.136.67
 yz-ab-bm03   10.128.136.68
 yz-ac-bm01   10.128.136.130
 yz-ac-bm02   10.128.136.131
 yz-ac-bm03   10.128.136.132
 yz-ac-bm04   10.128.136.133
 yz-ac-bm05   10.128.136.134
 yz-ac-bm06   10.128.136.135
 yz-ac-bm07   10.128.136.136
 yz-ac-bm08   10.128.136.137
 yz-ac-bm09   10.128.136.138
 yz-ac-bm10   10.128.136.139
 yz-ac-bm11   10.128.136.140
 yz-ac-bm12   10.128.136.141
 yz-ac-bm13   10.128.136.142
 yz-ac-bm14   10.128.136.143
 yz-ac-bm15   10.128.136.144
 yz-ac-bm16   10.128.136.145
 yz-ac-bm17   10.128.136.146
 yz-ac-bm18   10.128.136.147

GDC esegue il bootstrap dei server in parallelo per eseguire la cancellazione sicura, la verifica, l'aggiornamento dell'impostazione del BIOS e altre procedure di bootstrap.

Verifica che la condizione ServerBootstrapSucceeded=True sia pubblicata nella risorsa personalizzata ZonalExpansion. Questa condizione si trova nella posizione ZonalExpansion.Status.SERVBootstrapStatus:
- Lo stato dell'host bare metal del server diventa Available o Provisioned dopo l'avvio riuscito.
- A un livello di verbosità della CLI pari a quattro, vengono visualizzati log come "Not all servers in the ZonalExpansion are bootstrapped" con un elenco di server non ancora pronti.

Verifica che i server siano stati rimossi dall'elenco NonCompliantDeviceSet:

kubectl --kubeconfig $KUBECONFIG get noncompliantdevicesets -n gpc-system "noncompliantassets-EXPANSION_NAME" -o yaml

Controlla che la condizione ExpansionSucceeded=True sia pubblicata nella risorsa personalizzata ZonalExpansion. Questa condizione si trova nella posizione ZonalExpansion.Status.Conditions.

Verifica che l'elenco NonCompliantDeviceSet sia stato eliminato:

kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A

Output previsto:

`Error from server (NotFound): noncompliantdevicesets.system.private.gdc.goog "noncompliantassets-EXPANSION_NAME" not found`

Esegui l'espansione verticale del server

Aggiungi blocchi di espansione del server nei rack che hanno slot di espansione vuoti tramite un'espansione verticale del server. Molte delle istruzioni per questa espansione sono simili all'espansione orizzontale del calcolo. Segui questi passaggi per eseguire un'espansione verticale del rack del server:

Installa fisicamente il blocco server standard che occupa sei nodi di capacità o il blocco server GPU che consuma tre nodi di capacità. Puoi aggiungere più blocchi per rack. Avviso: non collegare i cavi agli switch mgmtsw o aggsw. Per saperne di più, vedi Opzioni.
Non eseguire alcun cablaggio, ad eccezione dell'alimentatore. Questo passaggio consente al processo di accensione del server di verificare che il server non sia offline all'arrivo.

Genera il file YAML ZonalExpansion e la risorsa hardware SubcomponentOverride utilizzando il comando gdcloud system assets add:

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af

Sostituisci FILE_PATH per ciascuno dei file utilizzati. Tieni presente che questo percorso potrebbe essere diverso se ogni file si trova in una posizione diversa.

Segui queste indicazioni quando esamini il file YAML ZonalExpansion:

Il campo name deve essere descrittivo, ad esempio az-ae-expansion.
Il campo assets deve includere tutti i nuovi elettrodomestici nel nuovo rack di espansione.

Ecco un esempio di risorsa ZonalExpansion:

apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01

Applica la risorsa personalizzata ZonalExpansion che hai appena creato al cluster.
Verifica che siano state create le risorse ZonalExpansion e NonCompliantDeviceSet:
1. Controlla lo stato della risorsa ZonalExpansion. In questa fase, il controllo preflight dovrebbe non riuscire con il motivo: ReasonAssetsNotExisted.
2. La risorsa NonCompliantDeviceSet deve esistere con il nome preceduto dal prefisso noncompliantassets-.
3. L'elenco degli asset deve corrispondere al campo assets nella risorsa personalizzata ZonalExpansion.
Segui le istruzioni riportate in OLT-R0003 per aggiornare gli asset.
Verifica che l'ACL di commutazione della quarantena sia in esecuzione seguendo il runbook OLT-R0001.
Collega i cavi per i server, se non è già stato fatto. Segui il file di cablaggio fornito da Hewlett Packard Enterprise (HPE).
Verifica che la procedura di bootstrap del server venga avviata e completata correttamente. Per saperne di più, vedi Bootstrap completo del server.

Esegui l'espansione verticale dell'archiviazione di file e blocchi

Queste istruzioni includono i passaggi necessari per eseguire un'espansione verticale o di un singolo rack del nodo di archiviazione. L'espansione dei nodi di archiviazione viene eseguita quando vengono aggiunti nuovi nodi di archiviazione ONTAP per espandere le funzionalità di archiviazione di un rack esistente. Le istruzioni di cablaggio per i nuovi dispositivi di archiviazione non sono fornite qui, ma solo le procedure per cancellare, eseguire l'upgrade e aggiungere nuovi nodi di archiviazione a un cluster esistente.

Esegui la configurazione per l'espansione del nodo di archiviazione

Per preparare il cluster per l'espansione del nodo di archiviazione:

Segui la generazione di KUBECONFIG per generare KUBECONFIG per il cluster di amministrazione del nodo del control plane. Utilizza il file di configurazione KUBECONFIG generato per tutti i passaggi kubectl di questa guida:

Applica una risorsa SubcomponentOverride per disattivare i riconciliatori dello spazio di archiviazione durante l'esecuzione della configurazione iniziale per l'espansione dei nodi:

kubectl --kubeconfig $KUBECONFIG apply -f - <<EOF
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
    name: file-storage-sub-override
    namespace: root
spec:
    subComponentRef: "file-storage"
    backend:
        operableParameters:
            controller:
                enableReconcilers: ""
                disableReconcilers: "*"
EOF

Verifica che l'override abbia funzionato e che i riconciliatori file-storage siano stati disattivati:
```
kubectl --kubeconfig $KUBECONFIG describe deployment file-storage -n
file-system | grep reconcilers
```
Devi visualizzare quanto segue:
```
--enable-reconcilers=
--disable-reconcilers=*
```
Se non vedi questo stato, attendi alcuni minuti per consentire l'applicazione della risorsa SubcomponentOverride ed esegui di nuovo questo controllo. Se SubcomponentOverride non è ancora stato applicato dopo un paio di minuti, contatta l'assistenza tecnica di GDC.

Genera il file YAML ZonalExpansion e la risorsa hardware SubcomponentOverride utilizzando il comando gdcloud system assets add:

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af
```
Replace FILE_PATH for each of the files used. Note, this path might be different if each file is in a different location.

Use the following guidance when reviewing the `ZonalExpansion` YAML file:

The `name` field must be descriptive, such as aj-ad-expansion.
The `assets` field must include all new appliances in the new expansion rack.
Here is an example of a `ZonalExpansion` resource:

```sh
apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
name: file
namespace: gpc-system
spec:
assets:
- kind: StorageNode
    name: aj-ad-stge03-01
- kind: StorageNode
    name: aj-ad-stge03-02
```

Applica la risorsa personalizzata ZonalExpansion che hai appena creato al cluster.
Verifica che siano state create le risorse ZonalExpansion e NonCompliantDeviceSet:
1. Controlla lo stato della risorsa ZonalExpansion. In questa fase, il controllo preflight dovrebbe non riuscire con il motivo: ReasonAssetsNotExisted.
2. La risorsa NonCompliantDeviceSet deve esistere con il nome preceduto dal prefisso noncompliantassets-.
3. L'elenco degli asset deve corrispondere al campo degli asset nella risorsa personalizzata ZonalExpansion.
Applica le seguenti risorse SubcomponentOverride per gli asset hardware al cluster di amministrazione principale utilizzando gli strumenti IaC.
- file/file-storage.yaml
- inv/inv-core.yaml
Nota: il SubcomponentOverride generato non include eventuali override già applicati al cluster. Acquisisci gli attuali SubcomponentOverride e aggiungili ai rispettivi SubcomponentOverride generati per assicurarti che non vengano persi override.

Conferma che i nuovi nodi siano stati aggiunti al cluster:

kubectl --kubeconfig $KUBECONFIG get storagenodes -n gpc-system

Dovresti vedere le nuove risorse personalizzate del nodo aggiunte con un valore di età più recente:

  NAME              MGMTIP           INTERCONNECTIP   MODEL      AGE
  aj-ad-stge01-01   172.22.243.129   169.254.0.1      AFF-A250   37d
  aj-ad-stge01-02   172.22.243.130   169.254.0.3      AFF-A250   37d
  aj-ad-stge03-01   172.22.243.133   169.254.0.9      AFF-A400   20d
  aj-ad-stge03-02   172.22.243.134   169.254.0.11     AFF-A400   20d

Utilizza il comando describe per ottenere informazioni su entrambi i nodi, poiché contengono informazioni necessarie per i passaggi successivi.

kubectl --kubeconfig $KUBECONFIG describe storagenode NODE_NAME -n gpc-system

Sostituisci NODE_NAME con il nome di ogni nodo creato.