Diese Seite wurde von der Cloud Translation API übersetzt.

Organisationsressourcen verwalten

Als Infrastructure Operator (IO) von Google Distributed Cloud (GDC) Air-Gapped überprüfen Sie den Systemzustand, konfigurieren Nutzer und Netzwerke und verwalten den Lebenszyklus der zugrunde liegenden Hardwaresysteme wie Compute, Speicher und Netzwerk.

Hinweise

Um dieses Dokument abzuschließen, benötigen Sie Zugriff auf die folgenden Ressourcen:

Die gcloud CLI oder die kubectl CLI
Eine Linux-Umgebung

Bitten Sie Ihren Sicherheitsadministrator, Ihnen die Rolle „Organisationsadministrator“ (organization-admin) zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Verwalten einer Organisation benötigen.

Auf Server zugreifen und sie überwachen

Auf GDC-Server zugreifen und deren Status überwachen, um sicherzustellen, dass sie sicher, auf dem neuesten Stand und funktionsfähig sind.

Weitere Informationen zum Überwachen der Server einer Organisation finden Sie auf der Seite Messwerte abfragen und ansehen.

Serverlebenszyklus verwalten

Die Serverlebenszyklusverwaltung umfasst die folgenden Funktionen:

Schalte das Gerät aus und wieder ein oder starte es neu.
Neues Image wird erstellt.
Firmware-Updates für den Baseboard Management Controller (BMC) und das Complex Programmable Logic Device (CPLD).
Betriebssystem- oder Softwareupdates.
Betriebssystemkonfigurationen wie Sicherheitseinstellungen.

Sicherheitspatches für das Basisbetriebssystem, Bundle-Upgrades für die Server-Hostsoftware und Server-Firmware-Upgrades werden regelmäßig während der Wartungsfenster durchgeführt.

Die Wartungsfenster umfassen die folgenden Aktionen:

Installieren Sie dringende Sicherheitsupdates für das Serverbetriebssystem.
Aktualisieren Sie das Hostsoftwarepaket auf einem oder mehreren Servern.
Aktualisieren Sie die Firmware auf einem oder mehreren Servern.

Arbeitslastserver hinzufügen und verwalten

Wenn Sie zusätzliche Workload-Server hinzufügen oder vorhandene Workload-Server verwalten möchten, aktualisieren Sie die benutzerdefinierte OrganizationZonalConfig-Ressource, die im iac-Repository gespeichert ist:

Liste der verfügbaren Server und Servertypen generieren:

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}'

Die Ausgabe sieht dann ungefähr so aus:

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

Achten Sie darauf, welche Server verfügbar sind, und weisen Sie nur verfügbare Server zu, wenn Sie die Arbeitslastserver Ihrer Organisation ändern.

Öffnen Sie die YAML-Datei der benutzerdefinierten Ressource OrganizationZonalConfig im Repository iac:
```
vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml
```
Ersetzen Sie Folgendes:
- IAC_REPO_PATH: der Ordnerpfad zum iac-Repository.
- ORG_NAME: der Name der Organisation.
- ZONE: der Name der Zone im Universum. Der Zonenname wird im folgenden Format abgeleitet: {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}. Beispiel: us-central1-b. Beschreibungen der Attributwerte für die Zone finden Sie im Abschnitt „Zone“ im Fragebogen zur Kundenaufnahme.

Aktualisieren Sie den Abschnitt workloadServers der YAML-Datei. Fügen Sie neue Arbeitslastserver hinzu oder verwalten Sie die Anzahl der vorhandenen Server für jeden Typ:

...
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
...

Speichern Sie den interaktiven Editor und schließen Sie ihn.
Stellen Sie die Änderungen an der YAML-Datei für die zonale Konfiguration Ihrer Organisation bereit und committen Sie sie:
```
git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
git commit
```
Übertragen Sie die Aktualisierung per Push an GitLab:
```
git -c http.sslVerify=false push
```
Warten Sie auf die Codeüberprüfung und das Zusammenführen.
Wiederholen Sie diese Schritte mit demselben Inhalt und derselben Verzeichnisstruktur für alle GitLab-Repositories aller Distributed Cloud-Zonen in der Distributed Cloud-Bereitstellung.

In der Distributed Cloud-Bereitstellung enthält jede Zone einzelne, nicht verbundene GitLab-Instanzen. Für jede globale Ressource, die in GitLab erstellt, aktualisiert oder gelöscht wird, müssen Sie genau denselben Inhalt in die GitLab-Repositories jeder Zone übertragen. Der globale Root-Abgleichs-Pod wird in der primären Distributed Cloud-Zone ausgeführt, die im Feld primary der benutzerdefinierten Ressource zoneselectionresult in der globalen API definiert ist. Der Abgleich synchronisiert Daten aus dem GitLab der primären Zone mit der globalen API.

Warnung :Sie müssen den globalen Ordner der primären Zone mit GitLab aller anderen Zonen synchronisieren. Wenn die primäre Zone ausfällt und Sie eine neue primäre Zone auswählen, können Sie versehentlich veraltete globale Ressourcen in der globalen API anwenden oder löschen.

Prüfen Sie, ob die zugewiesenen Arbeitslastserver verfügbar sind:

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}'

Wenn der Arbeitslastserver auf true festgelegt ist, ist er verfügbar. Die Ausgabe sieht etwa so aus:

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

Speicherkapazität erhöhen

Die Speichermenge, die jeder Organisation für eine Zone zur Verfügung steht, wird im Feld capacities der Ressource OrganizationZonalConfig definiert.

Wenn Sie das Kontingent dieser Speicherklassen erhöhen möchten, aktualisieren Sie die OrganizationZonalConfig-Ressource in jeder Zone.

Öffnen Sie die YAML-Datei der benutzerdefinierten Ressource OrganizationZonalConfig im Repository iac:
```
vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml
```
Ersetzen Sie Folgendes:
- IAC_REPO_PATH: der Ordnerpfad zum iac-Repository.
- ORG_NAME: der Name der Organisation.
- ZONE: der Name der Zone im Universum, z. B. us-central1-b. Weitere Informationen zu Attributwerten für Zonen finden Sie im Abschnitt Zone des Fragebogens zur Kundenaufnahme.
Aktualisieren Sie den Abschnitt capacities der YAML-Datei mit den neuen Kontingentwerten für Ihre Speichertypen. Beispiel:
```
# Several lines of code are omitted here.
spec:
  capacities:
    storage:
      file-standard: FILE_QUOTA
      block-standard: BLOCK_QUOTA
      object-standard: OBJECT_QUOTA
```
Ersetzen Sie Folgendes:
- FILE_QUOTA: Der neue Kontingentwert für die Dateispeicherung in der Zone, z. B. 10Ti.
- BLOCK_QUOTA: Der neue Kontingentwert für Blockspeicher in der Zone, z. B. 10Ti.
- OBJECT_QUOTA: Der neue Kontingentwert für den Objektspeicher in der Zone, z. B. 10Ti.
Weitere Informationen zum Definieren der Speicherkapazität in der OrganizationZonalConfig-Ressource finden Sie in der TypedResourceCapacities-Referenzdokumentation.
Speichern Sie den interaktiven Editor und schließen Sie ihn.
Stellen Sie die Änderungen an der YAML-Datei für die zonale Konfiguration Ihrer Organisation bereit und committen Sie sie:
```
git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
git commit
```
Übertragen Sie die Aktualisierung per Push an GitLab:
```
git -c http.sslVerify=false push
```
Warten Sie auf die Codeüberprüfung und das Zusammenführen.
Wiederholen Sie diese Schritte mit demselben Inhalt und derselben Verzeichnisstruktur für alle GitLab-Repositories aller GDC-Zonen in der GDC-Bereitstellung.