Gestire le risorse dell'organizzazione

In qualità di operatore dell'infrastruttura (IO) di Google Distributed Cloud (GDC) air-gapped, verifichi l'integrità del sistema, configuri utenti e reti e gestisci il ciclo di vita dei sistemi hardware sottostanti, come computing, spazio di archiviazione e networking.

Prima di iniziare

Per completare questo documento, devi avere accesso alle seguenti risorse:

gcloud CLI o kubectl CLI
Un ambiente Linux

Per ottenere le autorizzazioni necessarie per gestire un'organizzazione, chiedi all'amministratore della sicurezza di concederti il ruolo Amministratore dell'organizzazione (organization-admin).

Accedere ai server e monitorarli

Accedi ai server GDC e monitora i loro stati per assicurarti che siano sicuri, aggiornati e funzionanti.

Per ulteriori informazioni sul monitoraggio dei server di un'organizzazione, consulta la pagina Esegui query e visualizza le metriche.

Gestire il ciclo di vita di un server

La gestione del ciclo di vita del server include le seguenti funzionalità:

Spegni e riaccendi o riavvia.
Nuova immagine in corso…
Aggiornamenti firmware del controller di gestione della scheda madre (BMC) e del dispositivo logico programmabile complesso (CPLD).
Aggiornamenti del sistema operativo o del software.
Configurazioni del sistema operativo, ad esempio le impostazioni di sicurezza.

Le patch di sicurezza del sistema operativo di base, gli upgrade dei bundle per il software host del server e gli upgrade del firmware del server vengono eseguiti regolarmente durante i periodi di manutenzione.

Le finestre di manutenzione includono le seguenti azioni:

Installa gli aggiornamenti della sicurezza urgenti sul sistema operativo del server.
Esegui l'upgrade del pacchetto software host su uno o più server.
Esegui l'upgrade del firmware su uno o più server.

Aggiungere e gestire i server di workload

Per aggiungere altri server di workload o gestire quelli esistenti, aggiorna la risorsa personalizzata OrganizationZonalConfig archiviata nel repository iac:

Genera l'elenco dei server e dei tipi di server disponibili:

kubectl get servers -n gpc-system -o \
    jsonpath='{range .items[?(@.status.bareMetalHostStatus.provisionState=="available")]}{.metadata.name}{"\t"}{.spec.serverHardware.machineClassName}{"\t"}{.status.bareMetalHostStatus.provisionState}{"\n"}{end}'

L'output è simile al seguente:

ag-aa-bm04   o1-standard1-64-gdc-metal   available
ag-ab-bm07   o1-standard1-64-gdc-metal   available
ag-ab-bm11   o1-highmem1-96-gdc-metal    available
ag-ab-bm12   o1-highmem1-96-gdc-metal    available
ag-ab-bm13   o1-highmem1-96-gdc-metal    available
ag-ab-bm14   o1-highgpu1-48-gdc-metal    available
ag-ab-bm15   o1-highgpu1-48-gdc-metal    available
ag-ab-bm16   o1-highgpu1-48-gdc-metal    available

Prendi nota dei server disponibili e assicurati di allocare solo quelli disponibili quando modifichi i server di workload della tua organizzazione.

Apri il file YAML della risorsa personalizzata OrganizationZonalConfig nel repository iac:
```
vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml
```
Sostituisci quanto segue:
- IAC_REPO_PATH: il percorso della cartella del repository iac.
- ORG_NAME: il nome dell'organizzazione.
- ZONE: il nome della zona nell'universo. Il nome della zona viene derivato utilizzando il seguente formato: {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}. Ad esempio, us-central1-b. Consulta la sezione Zona nel questionario di acquisizione dei clienti per le descrizioni dei valori dell'attributo zona.

Aggiorna la sezione workloadServers del file YAML. Aggiungi nuovi server del carico di lavoro o gestisci il numero di server esistenti per ogni tipo:

...
workloadServers:
  o1-highmem1-40-gdc-metal: 1
  o1-standard1-64-gdc-metal: 2
  o1-highmem1-96-gdc-metal: 3
  o1-highmem1-104-gdc-metal: 4
  o1-highmem1-448-gdc-metal: 5
  o1-highgpu1-48-gdc-metal: 6
...

Salva e chiudi l'editor interattivo.
Esegui il staging e il commit delle modifiche al file YAML di configurazione zonale dell'organizzazione:
```
git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
git commit
```
Esegui il push dell'aggiornamento su GitLab:
```
git -c http.sslVerify=false push
```
Attendi la revisione del codice e l'unione.
Ripeti questi passaggi con gli stessi contenuti e la stessa struttura di directory per tutti i repository GitLab di tutte le zone Distributed Cloud nel deployment Distributed Cloud.

Nel deployment di Distributed Cloud, ogni zona contiene singole istanze GitLab disconnesse. Per ogni risorsa globale creata, aggiornata o eliminata in GitLab, devi eseguire il commit dello stesso identico contenuto nei repository GitLab di ogni zona. Il pod di riconciliazione della radice globale viene eseguito nella zona Distributed Cloud principale, definita nel campo primary della risorsa personalizzata zoneselectionresult nell'API globale. Il riconciliatore sincronizza i dati da GitLab della zona principale con l'API globale.

Avviso: devi sincronizzare la cartella globale della zona principale con GitLab di tutte le altre zone. Se la zona primaria non è più disponibile e selezioni una nuova zona primaria, potresti applicare o eliminare accidentalmente risorse globali obsolete nell'API globale.

Verifica che i server di workload che hai allocato siano disponibili per l'uso:

kubectl --kubeconfig /root/release/root-admin/root-admin-kubeconfig get servers -n gpc-system -o \
    jsonpath='{range .items[?(@.spec.nodePoolClaimRef.namespace=="org-1")]}{.metadata.name}{"\t"}{.status.provisionReady}{"\n"}{end}'

Se il server del workload è impostato su true, è disponibile. L'output è simile al seguente:

zi-aa-bm04      true
zi-aa-bm05      true
zi-aa-bm06      true

Aumentare la capacità di archiviazione

La quantità di spazio di archiviazione disponibile per ogni organizzazione per una zona è definita nel campo capacities della risorsa OrganizationZonalConfig.

Per aumentare la quota di queste classi di archiviazione, aggiorna la risorsa OrganizationZonalConfig in ogni zona.

Apri il file YAML della risorsa personalizzata OrganizationZonalConfig nel repository iac:
```
vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml
```
Sostituisci quanto segue:
- IAC_REPO_PATH: il percorso della cartella del repository iac.
- ORG_NAME: il nome dell'organizzazione.
- ZONE: il nome della zona nell'universo, ad esempio us-central1-b. Per ulteriori informazioni sui valori degli attributi di zona, consulta la sezione Zona del questionario di acquisizione dei clienti.
Aggiorna la sezione capacities del file YAML con i nuovi valori di quota per i tuoi tipi di spazio di archiviazione. Ad esempio:
```
# Several lines of code are omitted here.
spec:
  capacities:
    storage:
      file-standard: FILE_QUOTA
      block-standard: BLOCK_QUOTA
      object-standard: OBJECT_QUOTA
```
Sostituisci quanto segue:
- FILE_QUOTA: il nuovo valore della quota per l'archiviazione di file nella zona, ad esempio 10Ti.
- BLOCK_QUOTA: il nuovo valore della quota per l'archiviazione a blocchi nella zona, ad esempio 10Ti.
- OBJECT_QUOTA: il nuovo valore della quota per l'archiviazione di oggetti nella zona, ad esempio 10Ti.
Per ulteriori informazioni sulla definizione della capacità di archiviazione all'interno della risorsa OrganizationZonalConfig, consulta la documentazione di riferimento di TypedResourceCapacities.
Salva e chiudi l'editor interattivo.
Esegui il staging e il commit delle modifiche al file YAML di configurazione zonale dell'organizzazione:
```
git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
git commit
```
Esegui il push dell'aggiornamento su GitLab:
```
git -c http.sslVerify=false push
```
Attendi la revisione del codice e l'unione.
Ripeti questi passaggi con gli stessi contenuti e la stessa struttura di directory per tutti i repository GitLab di tutte le zone GDC nel deployment GDC.