Diese Seite wurde von der Cloud Translation API übersetzt.

Dynamische Erweiterung durchführen

Auf dieser Seite wird beschrieben, wie Sie Ihr System dynamisch erweitern, indem Sie mehr Speicher- und Rechenressourcen einbinden. Anleitungen sind für die folgenden Arten der Erweiterung verfügbar:

Horizontale Erweiterung des Serverracks: Der Zone wird ein neues Rack hinzugefügt. Dieses Rack enthält Rechenknoten, eine Konsole, Top-of-Rack-Switches (ToR) und Management-Switches (MGMT).
Vertikale Servererweiterung: Fügt Servererweiterungsblöcke in Racks mit leeren Erweiterungssteckplätzen ein.
Vertikale Erweiterung des Datei- und Blockspeichers: Fügt Speicherknoten in Racks mit leeren Erweiterungssteckplätzen in einem vorhandenen Speichercluster hinzu. Speicherknoten, die an denselben Speicherswitch angeschlossen sind, gehören zum selben Cluster.

Weitere Informationen zu den verschiedenen Arten der dynamischen Erweiterung finden Sie unter Dynamische Erweiterung – Übersicht.

Hinweise

Bevor Sie Änderungen an der Zone vornehmen, müssen die folgenden Voraussetzungen erfüllt sein:

Führen Sie eine Hardwareprüfung durch und bestätigen Sie sie beim OEM . Folgen Sie der Anleitung unter Rack Inspection (Rack-Prüfung).
Folgen Sie der Anleitung unter KUBECONFIG-Generierung, um die KUBECONFIG für den Administratorcluster des Steuerungsebenenknotens zu generieren. Verwenden Sie die generierte KUBECONFIG-Konfigurationsdatei für alle kubectl-Schritte in dieser Anleitung.
Prüfen Sie, ob die aktuelle Version von Google Distributed Cloud (GDC) Air Gapped im Root-Cluster mindestens Version 1.13.1 ist:
```
kubectl --kubeconfig $KUBECONFIG get org root -n gpc-system
```
Laden Sie die GDC-TAR-Datei herunter. Weitere Informationen finden Sie unter Dateien herunterladen.
Firmware für neue Geräte vorbereiten:
1. Die Paketvermittlungsgeräte in der GDC-Hardware. Weitere Informationen finden Sie unter Schalter.
2. Aktualisieren Sie den ONTAP-Datei- und ‑Blockspeicher gemäß der Anleitung unter Manuelles ONTAP-Upgrade.
Prüfen Sie mit gdcloud system doctor, ob das GDCH-System fehlerfrei funktioniert. Wenn der Befehl gdcloud system doctor nicht verfügbar ist, verwenden Sie die alternative Methode unter Netzwerkinstallation überprüfen.

Horizontale Erweiterung des Serverracks durchführen

Fügen Sie der Zone ein neues Rack hinzu, das aus Rechenknoten, der Konsole sowie ToR- und Managementswitchen besteht. Die in diesem Abschnitt beschriebenen Schritte beziehen sich auf ein einzelnes Rack. Wenn Sie mehrere Racks haben, führen Sie diese Schritte für jedes Rack aus.

Zurücksetzen

Sie müssen die folgende Ausrüstung sicher zurücksetzen:

Führen Sie einen sicheren Reset des Servers der seriellen Konsole durch. Wenden Sie sich an Google, um diese Anleitung zu erhalten, da jedes Deployment möglicherweise unterschiedliche serielle Konsolen hat.
Führen Sie einen sicheren Reset der Raritan-Stromverteilungseinheit (Power Distribution Unit, PDU) durch:
1. Schließen Sie das USB‑B-Kabel vom Systemcontroller an die Raritan-PDU an.
2. Setzen Sie die PDU in der lokalen seriellen Konsole mit dem Befehl reset factorydefaults auf die Werkseinstellungen zurück.
3. Die PDU ist jetzt auf admin/legrand festgelegt.
Führen Sie einen sicheren Reset durch, aktualisieren Sie die Firmware und setzen Sie die ToR- und MGMT-Switches auf PowerOn Auto Provisioning (POAP) zurück. Folgen Sie dazu der Anleitung unter Sicheres Löschen.
Stellen Sie eine Verbindung zu jedem Server her und führen Sie das sichere Löschen manuell durch.

Artefakte vorbereiten

So wenden Sie die erforderlichen Konfigurationsdateien und benutzerdefinierten Ressourcen an:

Generieren Sie die YAML-Datei ZonalExpansion, die Hardware-Ressource CustomResources und die Hardware-Ressource SubcomponentOverride mit dem Befehl 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
```
Ersetzen Sie FILE_PATH für jede der verwendeten Dateien. Dieser Pfad kann sich unterscheiden, wenn sich die einzelnen Dateien an unterschiedlichen Speicherorten befinden.

Mit der benutzerdefinierten Ressource ZonalExpansion werden alle hinzugefügten Objekte erfasst und der Status aller Objekte gemeldet.

Beachten Sie beim Überprüfen der YAML-Datei ZonalExpansion die folgenden Hinweise:
- Das Feld name muss aussagekräftig sein, z. B. az-ae-expansion.
- Das Feld assets muss alle neuen Geräte im neuen Erweiterungs-Rack enthalten.
Hier ist ein Beispiel für eine ZonalExpansion-Ressource:
```
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
```
Verwenden Sie Infrastruktur als Code-(IaC-)Tools, um die benutzerdefinierte ZonalExpansion-Ressource anzuwenden. Weitere Informationen finden Sie unter Infrastruktur als Code einrichten. Alternativ können Sie das IAM-R0004-Runbook verwenden und kubectl dafür nutzen.
Prüfen Sie, ob die Ressourcen ZonalExpansion und NonCompliantDeviceSet erstellt wurden:
1. Prüfen Sie den Status der ZonalExpansion-Ressource:
```
kubectl --kubeconfig $KUBECONFIG get -A zonalexpansion -o yaml
```
  Die Preflight-Prüfung sollte in dieser Phase mit dem Grund ReasonAssetsNotExisted fehlschlagen.
2. Die NonCompliantDeviceSet-Ressource muss mit dem Namen mit dem Präfix noncompliantassets- vorhanden sein.
3. Die Liste der Assets muss mit dem Feld assets in der benutzerdefinierten Ressource ZonalExpansion übereinstimmen.
Folge der Anleitung unter OLT-R0003, um die Assets zu aktualisieren.
Verbinden Sie die ToR- und MGMT-Switches im neuen Rack mit dem Aggregations-Switch im vorhandenen Rack.
Schließen Sie die Switches physisch an die Basis-Racks an.

Server-Bootstrap abschließen

Diese Phase ist größtenteils automatisiert, es sind jedoch einige Schritte erforderlich. Sie müssen den Bootstrap-Fortschritt überwachen und alle Fehlerfälle behandeln:

Der Controller startet den Bootstrap-Vorgang automatisch, sobald die Bedingung PreflightCheck=True erfüllt ist.
Prüfen Sie, ob die Bedingung NetworkBootstrapSucceed=True in der benutzerdefinierten Ressource ZonalExpansion veröffentlicht wurde. Diese Bedingung befindet sich unter ZonalExpansion.Status.PNETBootstrapStatus.
Prüfen Sie, ob die Schalter aus der Liste NonCompliantDeviceSet entfernt wurden:
```
kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A -o yaml
```
Ersetzen Sie EXPANSION_NAME durch den Namen der benutzerdefinierten Ressource für die zonale Erweiterung.

Prüfen Sie, ob sich die Schalter nicht im Feld Spec.Assets der zurückgegebenen YAML-Datei befinden. Durch diese Entfernung kann GDC die Netzwerk-ACLs aktualisieren, um andere Appliance-Bootstrap-Verfahren zu ermöglichen. Die beiden aktualisierten Netzwerk-ACLs sind quarantine-mgmt-switch-acl und quarantine-data-switch-acl.

Listen Sie alle BMC-IP-Adressen (Baseboard Management Controller) für den Server auf und prüfen Sie, ob die iLO-IP-Adressen der neuen Bare-Metal-Maschine zugewiesen sind und der Bootstrap gestartet werden kann:

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

Beispielausgabe:

 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 führt das Bootstrapping der Server parallel aus, um das sichere Löschen, die Überprüfung, die Aktualisierung der BIOS-Einstellungen und andere Bootstrap-Prozeduren durchzuführen.

Prüfen Sie, ob die Bedingung ServerBootstrapSucceeded=True in der benutzerdefinierten Ressource ZonalExpansion veröffentlicht wurde. Dieser Zustand wurde am Standort ZonalExpansion.Status.SERVBootstrapStatus festgestellt:
- Der Status des Bare-Metal-Hosts des Servers wechselt nach dem erfolgreichen Bootstrap in den Zustand Available oder Provisioned.
- Bei einem CLI-Ausführlichkeitsgrad von 4 werden Logs wie "Not all servers in the ZonalExpansion are bootstrapped" mit einer Liste der Server angezeigt, die noch nicht bereit sind.

Prüfen Sie, ob die Server jetzt aus der Liste NonCompliantDeviceSet entfernt wurden:

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

Prüfen Sie, ob die Bedingung ExpansionSucceeded=True in der benutzerdefinierten Ressource ZonalExpansion veröffentlicht wurde. Diese Bedingung befindet sich unter ZonalExpansion.Status.Conditions.

Prüfen Sie, ob die Liste NonCompliantDeviceSet gelöscht wurde:

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

Erwartete Ausgabe:

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

Vertikale Servererweiterung durchführen

Fügen Sie Racks mit leeren Erweiterungssteckplätzen durch eine vertikale Servererweiterung Servererweiterungsblöcke hinzu. Viele der Anleitungen für diese Erweiterung ähneln der horizontalen Compute-Erweiterung. So führen Sie eine vertikale Erweiterung des Serverracks durch:

Installieren Sie den Standardserverblock, der sechs Knotenkapazitäten belegt, oder den GPU-Serverblock, der drei Knotenkapazitäten belegt. Sie können pro Rack mehrere Blöcke hinzufügen. Achtung: Schließen Sie keine Kabel an die Schalter mgmtsw oder aggsw an. Weitere Informationen finden Sie unter Schalter.
Nehmen Sie keine Verkabelung vor, außer für die Stromversorgung. In diesem Schritt wird während des Hochfahrens des Servers geprüft, ob der Server bei der Ankunft nicht offline ist.

Generieren Sie die YAML-Datei ZonalExpansion und die Hardware-Ressource SubcomponentOverride mit dem Befehl 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

Ersetzen Sie FILE_PATH für jede der verwendeten Dateien. Dieser Pfad kann sich unterscheiden, wenn sich die einzelnen Dateien an unterschiedlichen Speicherorten befinden.

Beachten Sie beim Überprüfen der YAML-Datei ZonalExpansion die folgenden Hinweise:

Das Feld name muss aussagekräftig sein, z. B. az-ae-expansion.
Das Feld assets muss alle neuen Geräte im neuen Erweiterungs-Rack enthalten.

Hier ist ein Beispiel für eine ZonalExpansion-Ressource:

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

Wenden Sie die benutzerdefinierte ZonalExpansion-Ressource, die Sie gerade erstellt haben, auf den Cluster an.
Prüfen Sie, ob die Ressourcen ZonalExpansion und NonCompliantDeviceSet erstellt wurden:
1. Prüfen Sie den Status der ZonalExpansion-Ressource. Die Preflight-Prüfung sollte in dieser Phase mit dem Grund ReasonAssetsNotExisted fehlschlagen.
2. Die NonCompliantDeviceSet-Ressource muss mit dem Namen mit dem Präfix noncompliantassets- vorhanden sein.
3. Die Liste der Assets muss mit dem Feld assets in der benutzerdefinierten Ressource ZonalExpansion übereinstimmen.
Folge der Anleitung unter OLT-R0003, um die Assets zu aktualisieren.
Prüfen Sie anhand des OLT-R0001-Runbooks, ob die ACL für die Quarantäneschaltung ausgeführt wird.
Schließen Sie die Kabel für die Server an, falls dies noch nicht geschehen ist. Folgen Sie der von Hewlett Packard Enterprise (HPE) bereitgestellten Verkabelungsdatei.
Prüfen Sie, ob der Server-Bootstrapping-Prozess gestartet und erfolgreich abgeschlossen wird. Weitere Informationen finden Sie unter Server-Bootstrap abschließen.

Vertikale Datei- und Blockspeichererweiterung durchführen

Diese Anleitung enthält die Schritte, die für die Erweiterung eines vertikalen oder einzelnen Rack-Speicherknotens erforderlich sind. Die Erweiterung von Speicherknoten erfolgt, wenn neue ONTAP-Speicherknoten hinzugefügt werden, um die Speicherkapazität eines vorhandenen Racks zu erweitern. Hier finden Sie keine Verkabelungsanleitung für die neuen Speichergeräte, sondern nur die Verfahren zum Löschen, Aktualisieren und Hinzufügen neuer Speicherknoten zu einem vorhandenen Cluster.

Einrichtung für die Erweiterung des Speicherknotens durchführen

So bereiten Sie den Cluster auf die Erweiterung des Speicherknotens vor:

Folgen Sie der Anleitung unter KUBECONFIG-Generierung, um die KUBECONFIG für den Administratorcluster des Steuerungsebenenknotens zu generieren. Verwenden Sie die generierte KUBECONFIG-Konfigurationsdatei für alle kubectl-Schritte in dieser Anleitung:

Wenden Sie eine SubcomponentOverride-Ressource an, um Speicherabgleichsfunktionen während der Ersteinrichtung für die Knotenerweiterung zu deaktivieren:

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

Prüfen Sie, ob die Überschreibung funktioniert hat und die file-storage-Abstimmungsfunktionen deaktiviert wurden:
```
kubectl --kubeconfig $KUBECONFIG describe deployment file-storage -n
file-system | grep reconcilers
```
Sie sollten Folgendes sehen:
```
--enable-reconcilers=
--disable-reconcilers=*
```
Wenn dieser Status nicht angezeigt wird, warten Sie einige Minuten, bis die SubcomponentOverride-Ressource angewendet wird, und führen Sie diese Prüfung noch einmal durch. Wenn die SubcomponentOverride nach einigen Minuten noch nicht angewendet wurde, wenden Sie sich an den technischen Support von GDC.

Generieren Sie die YAML-Datei ZonalExpansion und die Hardware-Ressource SubcomponentOverride mit dem Befehl 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
```

Wenden Sie die benutzerdefinierte ZonalExpansion-Ressource, die Sie gerade erstellt haben, auf den Cluster an.
Prüfen Sie, ob die Ressourcen ZonalExpansion und NonCompliantDeviceSet erstellt wurden:
1. Prüfen Sie den Status der ZonalExpansion-Ressource. Die Preflight-Prüfung sollte in dieser Phase mit dem Grund ReasonAssetsNotExisted fehlschlagen.
2. Die NonCompliantDeviceSet-Ressource muss mit dem Namen mit dem Präfix noncompliantassets- vorhanden sein.
3. Die Liste der Assets muss mit dem Feld „assets“ in der benutzerdefinierten ZonalExpansion-Ressource übereinstimmen.
Wenden Sie die folgenden SubcomponentOverride-Ressourcen für Hardware-Assets mithilfe von IaC-Tools auf den Root-Administratorcluster an.
- file/file-storage.yaml
- inv/inv-core.yaml
Hinweis: Die generierte SubcomponentOverride enthält keine Überschreibungen, die bereits auf den Cluster angewendet wurden. Erfassen Sie die aktuellen SubcomponentOverride und fügen Sie sie den entsprechenden generierten SubcomponentOverride hinzu, damit keine Überschreibungen verloren gehen.

Prüfen Sie, ob die neuen Knoten dem Cluster hinzugefügt wurden:

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

Die neuen benutzerdefinierten Knotenressourcen sollten mit einem neueren Alterswert angezeigt werden:

  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

Verwenden Sie den Befehl describe, um Informationen zu beiden Knoten abzurufen, da sie Informationen enthalten, die für spätere Schritte benötigt werden.
```
kubectl --kubeconfig $KUBECONFIG describe storagenode NODE_NAME -n gpc-system
```
Ersetzen Sie NODE_NAME durch den Namen jedes erstellten Knotens.

Beispielausgabe:
```
NAME              MGMTIP           INTERCONNECTIP   MODEL      AGE
aj-ad-stge03-02   172.22.243.134   169.254.0.11     AFF-A400   20d
```

Vollständigen Prozess zur Erweiterung des Speicherknotens durchführen

Führen Sie die folgenden Schritte aus, um den Vorgang zum Erweitern des Speicherknotens abzuschließen:

Führen Sie ein manuelles Upgrade der neuen Speicherknoten durch. Führen Sie für jeden Knoten die Schritte unter Manuelles ONTAP-Upgrade aus und stellen Sie die Dateien über den Systemcontroller bereit.
Führen Sie eine sichere Löschung neuer Speicherknoten durch. Führen Sie für die neuen ONTAP-Knoten die Schritte unter ONTAP Reset aus, um die Knoten zurückzusetzen.
Initialisieren Sie die neuen Speicherknoten. Verwenden Sie die Informationen in den neu hinzugefügten benutzerdefinierten StorageNode-Ressourcen, die im vorherigen Schritt beschrieben wurden. Führen Sie für jeden Knoten die Schritte unter ONTAP-Appliances initialisieren aus.

Hinweis :Führen Sie den Schritt cellcfg nicht aus. Verwenden Sie stattdessen die Werte, die Sie zuvor im vorherigen Schritt erfasst haben.
Stellen Sie eine Kabelverbindung vom neuen Knoten zum aktuellen Cluster her, indem Sie der ONTAP-Einrichtung folgen.
Folgen Sie der Anleitung unter Neue Knoten einem vorhandenen Cluster hinzufügen, um die neuen Knoten dem Cluster hinzuzufügen.

Fehlerbehebung bei der dynamischen Erweiterung

Verwenden Sie die folgenden Runbooks im Servicehandbuch, um Probleme mit der dynamischen Erweiterung zu beheben:

OLT-R0001
OLT-R0002
OLT-R0003