15. Objektspeicher-Bootstrap

Geschätzte Dauer: 7 Stunden

Eigentümer der bedienbaren Komponente: OBJ

Kompetenzprofil: Bereitstellungsingenieur

Hinweis :Nicht alle Konfigurationen von Google Distributed Cloud (GDC) Air-Gapped werden mit einem StorageGRID-System geliefert. Eine Distributed Cloud-Instanz mit StorageGRID hat ein Rack, das StorageGRID-Geräte mit Modellnummern enthält, die mit SG beginnen. AFF ONTAP-Geräte werden in diesem Abschnitt nicht behandelt.

15.1. Netzwerkanforderungen

Das folgende Bild zeigt ein Verkabelungsdiagramm für SG1000 und SG6060 zum Konfigurieren der GRID-, Admin- und Client-Netzwerke:

15.1.1. Admin-Knoten SG1000

Sie müssen mindestens zwei Administratorknoten in SG1000 haben.

Für jeden Administratorknoten benötigen Sie insgesamt vier IP-Adressen, eine Adresse in jeder der folgenden Kategorien:

• BMC-Netzwerk.
• Administratorennetzwerk.
• Clientnetzwerk
• Grid Network

Sie benötigen drei Subnetze für Folgendes:

• Administratorennetzwerk.
• BMC-Netzwerk.

Das Clientnetzwerk und das Grid-Netzwerk sowie jedes Subnetz müssen eine Subnetzmaske von maximal 30 Bit haben.

15.1.2. Speicherknoten SG6060 und SG6000

Für die Modelle SG6060 und SG6000 sind mindestens drei Speicherknoten erforderlich.

Für jeden Speicherknoten benötigen Sie insgesamt fünf IP-Adressen, eine für jede der folgenden Komponenten:

• BMC-Netzwerk(mgmt).
• Admin Network(mgmt)
• Grid Network
• Storage Controller Network (mgmt) Hinweis: Das Storage Controller-Netzwerk muss zwei IP-Adressen haben.

Sie benötigen zwei Subnetze für jede der folgenden Optionen:

• BMC-Netzwerk.
• Administratorennetzwerk.
• Storage Controller Network
• Grid Network

In der folgenden Tabelle ist die Anzahl der IP-Adressen für die Administrator- und Speicherknoten aufgeführt:

Anzahl der benötigten IPs	Administratornetzwerk	Clientnetzwerk	Grid Network
Admin-Knoten	2	1	1
Speicherknoten	4	0	1

Sie benötigen die folgenden drei Subnetze:

• Administratorennetzwerk.
• Clientnetzwerk
• Grid Network

Jedes Subnetz muss eine Subnetzmaske von maximal 30 Bit haben.

15.1.3. Netzwerkdetails

15.1.3.1. Netzwerk der Distributed Cloud-Steuerungsebene:

Das Out-of-Band-Verwaltungsnetzwerk (OOB) von Distributed Cloud enthält das BMC-Netzwerk (Baseboard Management Controller) für den Objektspeicher und das Administratornetzwerk. Das Netzwerk stellt eine Verbindung zu mgmtsw her.

Sie benötigen die OOB-BMC-IP-Adresse für Folgendes:

• SG1000
• SG6000

Sie benötigen die OOB-Verwaltungs-IP-Adresse für Folgendes:

• SG1000
• SG6000
• SG6060

15.1.3.2. Distributed Cloud-Datenebenennetzwerk

Das Netzwerk der Datenebene besteht aus dem externen Objekt StorageGRID (SG1000), der Client-LIF und dem Clientnetzwerk in NetApp.

Hinweis :Wenn Sie das noch nicht getan haben, folgen Sie dem Hinweis unter cellconfig erstellen, um die generierten cellconfig-Dateien in einer einzigen Datei zusammenzufassen.

• Führen Sie die folgenden Schritte aus, um die SubnetClaim auf den einzelnen Geräten zu ermitteln:

  • S3 API-Endpunkt:
  1. Suchen Sie in der Datei cellconfig nach external-objectstorage-client-lif-subnet.
  2. Suchen Sie nach dem entsprechenden SubnetClaim, in dem die zugewiesene CIDR-/Gateway-IP-Adresse angegeben ist.

  • SG1000-Grid-Netzwerkgeräte-Endpunkte:

    1. Suchen Sie in der Datei cellconfig nach objectstorage-admin-nodes-lif-subnet.
    2. Suchen Sie nach dem entsprechenden SubnetClaim, in dem die zugewiesene CIDR-/Gateway-IP-Adresse angegeben ist.

• SG6060-Grid-Netzwerkgeräte-Endpunkte:

  1. Suchen Sie in der Datei cellconfig nach objectstorage-storage-nodes-lif-subnet.
  2. Suchen Sie nach dem entsprechenden SubnetClaim, in dem die zugewiesene CIDR-/Gateway-IP-Adresse angegeben ist.

15.2. Vorbereitung

15.2.1. Informationen erfassen

Geschätzte Dauer: 5–10 Minuten

Bevor Sie mit diesem Abschnitt fortfahren, müssen Sie sicherstellen, dass das Netzwerk-Bootstrap und die Konfiguration der Distributed Cloud-Instanz abgeschlossen sind und der Operator Zugriff auf die genaueste oder neueste verfügbare cellconfig-Datei oder auf den Bootstrap hat.

15.2.1.1. Informationen zu Speicherhardwaregeräten erfassen

Die Distributed Cloud-Instanzen folgen einer festen Namenskonvention, um Hardwaregeräte in Racks zu identifizieren. Insbesondere für die folgenden Objektspeichergeräte:

• Administratorknoten(SG1000): <cell>-<rack>-objsadm[node-number]. Beispiel: af-ae-objsadm01 steht für einen Administrator-Knoten.
• Storage Compute Controller-Knoten (SG6000-CN): <cell>-<rack>-objs[node-number]. Beispiel: af-ae-objs01
• Storage-Controller-Shelf(E2860): <cell>-<rack>-objs[node-number]-s1. Beispiel: af-ae-objs01-s1
• Storage-Knoten-Controller(SG6060): <cell>-<rack>-objs[node-number]-s1-[controller number]. Beispiel: af-ae-objs01-s1-01 und af-ae-objs01-s1-02

15.2.1.2. Netzwerkinformationen der Verwaltungsebene erfassen

Während des Netzwerk-Bootstrapping und der Konfiguration muss der Betreiber ein Subnetz für die Verwaltungsebene erstellen. Das Objektspeichersystem benötigt während des Bootstrapping-Prozesses die folgenden Informationen:

1. Verwaltungssubnetz
2. IP-Adresse des Verwaltungs-Gateways.
3. 16 IP-Adressen im Verwaltungs-Subnetz reserviert, zwei IP-Adressen für jeden Admin-Knoten und vier IP-Adressen für jeden Speicherknoten.

Suchen Sie die IP-Adresse des Management-Gateways im SubnetClaim <cell>-<rack>-mgmtsw01-objs-os-subnet. <cell> und <rack> sind dieselben wie in Schritt „Informationen zu Speicherhardwaregeräten erfassen“ angegeben, z. B. af-ae-mgmtsw01-objs-os-subnet.

kubectl get subnetclaim -n root <cell>-<rack>-mgmtsw01-objs-os-subnet -o jsonpath='{.status.ipv4SubnetStatus.reservedIpRanges[?(.type == "GatewayReservation")].ipRange.startIPAddress}'

Speichern Sie den Wert des Befehls in MANAGEMENT_SWITCH_GATEWAY.

15.2.1.3. Netzwerkinformationen der Datenebene erfassen

Bevor Sie fortfahren, müssen Sie dafür sorgen, dass Sie während des Netzwerk-Bootstrapping und der Konfiguration drei Subnetze für das Objektspeichersystem bereitgestellt haben.

Prüfen Sie, ob die folgenden Subnetze vorhanden sind:

• objectstorage-admin-nodes-lif-subnet
• objectstorage-storage-nodes-lif-subnet
• external-objectstorage-client-lif-subnet

Führen Sie den folgenden Befehl mit den Namen der SubnetClaim aus:

kubectl -n root get SubnetClaim SUBNET_CLAIM_NAME

Die folgende Ausgabe wird angezeigt:

NAME                                    CIDRCLAIM                             OVERLAY-NETWORK   IPV4-CIDR     IPV6-CIDR   VLAN   READY   VLANREADY
objectstorage-admin-nodes-lif-subnet   objectstorage-admin-nodes-lif-cidr   ObjectStorage     10.7.7.0/24                  7      True    True

Prüfen Sie, ob die folgenden Felder vorhanden sind:

1. VLAN
2. READY: True
3. VLANREADY: True

15.2.1.4. Abhängigkeitsinformationen erfassen

Das Objektspeichersystem basiert auf den folgenden Hauptdiensten und der Infrastruktur in Distributed Cloud:

• NTP
• Hardwaresicherheitsmodule (HSM)
• DNS

15.2.1.5. Felder mit „TO-BE-FILLED“ aktualisieren

Prüfen Sie die Datei obj-cellobj.yaml auf TO-BE-FILLED-Werte und aktualisieren Sie sie.

Führen Sie den folgenden Befehl aus, um sicherzustellen, dass der Wert nicht in der YAML-Datei vorhanden ist:

cat OBJ_CELLOBJ_YAML_PATH | grep "TO-BE-FILLED"

15.2.2. Konfigurationsverwaltungsnetzwerk über lokale Verbindung

Geschätzter Zeitaufwand: 30–45 Minuten

In diesem Unterabschnitt wird das Verwaltungsnetzwerk für jeden StorageGRID-Appliance-Knoten eingerichtet. Sobald das Verwaltungsnetzwerk konfiguriert ist, wird über die IP-Adresse im Verwaltungsnetzwerk auf StorageGRID-Knoten vom Bootstrapper aus zugegriffen.

Gehen Sie bei allen ObjectStorage-Geräten so vor:

• af-ae-objsadm01
• af-ae-objsadm02
• af-ae-objs01
• af-ae-objs02
• af-ae-objs03

Um die StorageGRID-Geräte zu booten, stellen Sie mit einem Crash Cart über den Admin-Netzwerkport 6 eine Verbindung zu jedem Gerät her, einschließlich zwei Admin-Knoten und drei Speicherknoten, und rufen Sie https://169.254.0.1:8443 auf, um die Admin-IP-Adressen im Verwaltungsnetzwerk einzurichten.

1. Verbinden Sie einen Crash Cart mit einem Ethernetkabel direkt mit dem RJ‑45-Port ganz rechts auf der Services-Appliance. Die folgenden Diagramme zeigen Port 6 für Administrator- und Speicherknoten als Beispiel:

   

   

2. Öffnen Sie einen Webbrowser auf dem Crash Cart.

3. Rufen Sie auf jedem Computer https://169.254.0.1:8443 auf.

   Hinweis :Wenn Sie nicht auf die Startseite zugreifen können, ändern Sie die Subnetzmaske des Crash-Carts in 255.255.255.0 und versuchen Sie es noch einmal. Wenn Sie immer noch nicht über eine Link-Local-Verbindung darauf zugreifen können, konfigurieren Sie die Crash-Cart-IP-Adresse als 169.254.0.2 und versuchen Sie es noch einmal.

4. Klicken Sie in der Menüleiste des StorageGRID Appliance Installer auf Netzwerk konfigurieren > Link-Konfiguration. Prüfen Sie, ob das Administratornetzwerk aktiviert ist.

   

5. Wenn Sie die IP-Adresse für das Administratornetzwerk konfigurieren möchten, wählen Sie Netzwerk konfigurieren > IP-Konfiguration aus.

6. Scrollen Sie nach unten zum Abschnitt Admin Network (Administratorennetzwerk) und wählen Sie unter IP Assignment (IP-Zuweisung) die Option Static (Statisch) aus. Geben Sie dann die entsprechenden Verwaltungs-IP-Adressen, managementIP, für den Knoten ein. Die Verwaltungs-IP für jeden Knoten finden Sie in der Datei obj-cellobj.yaml. Beispiel:

   • ObjectStorageAdminNode (SG1000):

     apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
     kind: ObjectStorageAdminNode
     metadata:
       creationTimestamp: null
       name: af-ae-objsadm01
     spec:
       network:
         bmcIP: 10.251.188.11/24
         clientIP: 10.251.113.2/28
         dataIP: 10.1.0.66/26
         managementIP: 10.251.188.10/24
       siteName: objectstorage-site
     

   • ObjectStorageStorageNode (SG6000):

     apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
     kind: ObjectStorageStorageNode
     metadata:
       creationTimestamp: null
       name: af-ae-objs01
     spec:
       network:
         bmcIP: 10.251.243.34/24
         controllerAManagementIP: 10.251.243.35/24
         controllerBManagementIP: 10.251.243.36/24
         dataIP: 10.1.0.132/26
         managementIP: 10.251.243.33/24
       siteName: objectstorage-site
     

   Hinweis: Konfigurieren Sie die Netzwerkeinstellungen nur für das Administratornetzwerk. Sie müssen keine anderen IP-Adressen konfigurieren.

   Legen Sie das Gateway auf MANAGEMENT_SWITCH_GATEWAY fest.

   Das folgende Beispielbild zeigt die Konfiguration für af-ae-objs01 mit der Verwaltungs-IP-Adresse, die in der Datei obj-cellobj.yaml zugewiesen ist:

   

7. Klicken Sie auf Speichern und prüfen Sie, ob die IP-Adresse aktualisiert wird.

8. Pingen Sie die Verwaltungs-IP-Adresse vom Bootstrapper aus an, um sicherzustellen, dass sie erreichbar ist.

   1. Pingen Sie die Verwaltungs-IP-Adresse vom Bootstrapper an, um sicherzustellen, dass sie erreichbar ist.
   2. Sobald alle Knoten eine IP-Adresse im Verwaltungsnetzwerk haben, rufen Sie die GUI für die Installation von StorageGRID-Knoten über die Verwaltungs-IP-Adresse auf.

Fehlerbehebung:

Wenn ein Knoten nicht angepingt werden kann:

1. Rufen Sie die StorageGRID-Knoteninstallations-UI aus dem vorherigen Schritt 3 auf und prüfen Sie, ob in einem Dialogbanner Fehler angezeigt werden. Versuchen Sie, die Fehler zu beheben. Wenden Sie sich bei Bedarf an Techniker.
2. Rufen Sie Netzwerk konfigurieren > IP-Konfiguration auf. Prüfen Sie, ob der richtige Abschnitt „Admin Network“ mit der richtigen statischen IP-Adresse und dem richtigen Gateway konfiguriert ist. Manchmal wird die Konfiguration des Verwaltungsnetzwerks nach der Bestätigung nicht vollständig auf dem StorageGRID-Knoten registriert.
3. Wiederholen Sie die Schritte 5 bis 8 und prüfen Sie das Netzwerk des Administrator-Knotens.

Der Zugriff auf die GUI für die Installation von StorageGRID-Knoten auf jedem Knoten ist erforderlich, um die Installation des Objektspeichersystems fortzusetzen.

15.2.3. StorageGRID aktualisieren

Geschätzte Zeit: 1–1,5 Stunden

Wichtig :Sie müssen die Versionsprüfung auf jedem Compute-Knoten für den Objektspeicher durchführen. Dazu gehören die Admin-Knoten (SG1000) und die Storage-Knoten (SG6060).

Hinweis :Sie müssen ein Downgrade auf die angegebene Installationsversion durchführen, wenn die aktuelle StorageGRID-Version höher als die angegebene Version ist.

Prüfen Sie vor dem Upgrade von StorageGRID die StorageGRID-Softwareversion. Rufen Sie Erweitert > StorageGRID-Software hochladen auf. Die aktuelle StorageGRID-Version wird angezeigt.

Prüfen Sie die mitgelieferte StorageGRID-Installationsversion:

gdcloud artifacts tree oci | grep object-storage/os

Die Beispielausgabe sieht etwa so aus:

│   │   │       └── gpc-system-object-storage/os:11.8.0
    ├── gpc-system-object-storage/os:sha256-d4cb75f91f43a92cb580db98faae12e87ec49d2b27c7db8a056d6411ac3b6044.sig

Die Version wird im Artefakt getaggt, in diesem Beispiel als 11.8.0:

Speichern Sie den Wert der Version in SG_INSTALL_VERSION.

Prüfen Sie die mitgelieferte StorageGRID-Firmwareversion:

gdcloud artifacts tree oci | grep object-storage/firmware

Die Beispielausgabe sieht etwa so aus:

│   │   │       ├── gpc-system-object-storage/firmware:3.8.1
    ├── gpc-system-object-storage/firmware:sha256-20a664504c342b5f14188114fad7a1e7d40abc042690bb0f776aa67cecff52e1.sig

Die Version wird im Artefakt getaggt, in diesem Beispiel als 3.8.1:

Speichern Sie den Wert der Version in SG_FIRMWARE_VERSION.

Wenn die Version auf dem Knoten nicht SG_INSTALL_VERSION ist, fahren Sie mit den nächsten Schritten fort, um die StorageGRID-Installationsversion zu aktualisieren oder ein Downgrade durchzuführen. Wenn die aktuelle Version SG_INSTALL_VERSION ist, fahren Sie mit dem Abschnitt SANtricity aktualisieren fort.

15.2.3.1. Firmware aktualisieren

Führen Sie diese Schritte für alle StorageGRID-Knoten aus:

• af-ae-objsadm01
• af-ae-objsadm02
• af-ae-objs01
• af-ae-objs02
• af-ae-objs03

1. Firmware-Image aus dem Bundle abrufen:

   gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/firmware:SG_FIRMWARE_VERSION
   
   tar -xvzf storage/gpc-system-object-storage/firmware.tar.gz
   

   Die Datei ist in storagegrid_firmware_install/ verfügbar.

2. Rufen Sie auf dem StorageGRID-Knoten das StorageGRID Appliance Installer auf. Wählen Sie Erweitert > Firmware aktualisieren aus. Laden Sie das Firmware-Image storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2 und die Prüfsumme storagegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1 für die ausgewählte Firmwareversion hoch. Nach dem Hochladen beginnt StorageGRID automatisch mit der Validierung der Dateien. Die Validierung dauert in der Regel etwa fünf bis zehn Minuten.

   

3. Wenn zwei grüne Häkchen angezeigt werden, klicken Sie auf Upgrade Inactive Partition (Inaktive Partition aktualisieren).

   

   Nachdem Sie die Meldung Successfully updated the firmware on the inactive partition erhalten haben, prüfen Sie im Bereich Aktuelle Firmware, ob die inaktive Partition tatsächlich die richtige Version ist.

   Klicken Sie zweimal auf Reboot (Neu starten) und Swap Partitions (Partitionen tauschen).

   Hinweis :Während des Neustarts und des Tauschs kann die Verbindung zum Knoten vorübergehend unterbrochen werden. Dieser Vorgang dauert etwa 20 bis 30 Minuten. Wenn die Verbindung zum Knoten nicht unterbrochen wird, müssen Sie möglicherweise zweimal auf Neu starten und Partitionen tauschen klicken, damit die Anfrage durchgeht.

4. Wiederholen Sie nach dem Neustart des Knotens die Schritte 1 und 2, um die Firmware der anderen Partition zu aktualisieren. Die aktive Partition ist die ausgewählte Version, während die inaktive Partition die ältere Version enthält.

   

15.2.3.2. StorageGRID-Software aktualisieren

Sobald das Upgrade der Firmware auf allen Knoten auf die richtige Version abgeschlossen ist, führen Sie ein Upgrade der Software auf die ausgewählte Version auf den beiden Administrator-Knoten durch. Die Speicherknoten müssen nicht aktualisiert werden, da sie die Software auf den Administratorknoten nachbilden und abrufen.

Folgen Sie dieser Anleitung auf den Admin-Knoten für SG1000:

• af-ae-objsadm01
• af-ae-objsadm02

1. Rufen Sie das Installations-Image aus dem Bundle ab:

   gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/os:SG_INSTALL_VERSION
   
   tar -xvzf storage/gpc-system-object-storage/os.tar.gz
   

   Die Dateien sind in storagegrid_os_install/ verfügbar.

2. Gehen Sie zu Advanced -> Upload StorageGRID Software (Erweitert -> StorageGRID-Software hochladen). Klicken Sie auf Entfernen, um die aktuelle Software zu entfernen, und laden Sie das neue Softwarepaket storagegrid_SG_INSTALL_VERSION_webscale_os_image.deb und die entsprechende Prüfsumme storagegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5 wie dargestellt hoch:

   

3. Prüfen Sie nach dem Hochladen der Software, ob die Software für den Knoten auf die ausgewählte Version aktualisiert wurde:

   

15.2.4. SANtricity aktualisieren

Geschätzte Zeit: 1–1,5 Stunden

Wichtig :Sie müssen die Versionsprüfung für jedes SANtricity-Objektspeichergerät durchführen.

Prüfen Sie vor dem Upgrade von SANtricity die SANtricity-Softwareversion. Rufen Sie die SANtricity-Benutzeroberfläche auf und klicken Sie auf Support > UPGRADE CENTER > Begin Upgrade (Support > UPGRADE CENTER > Upgrade starten). Die aktuelle SANtricity-Version wird angezeigt.

Prüfen Sie die mitgelieferte SANtricity-Installationsversion:

gdcloud artifacts tree oci | grep object-storage/santricity

Die Beispielausgabe sieht etwa so aus:

│   │   │       └── gpc-system-object-storage/santricity:11.70.5R1
    ├── gpc-system-object-storage/santricity:sha256-b145edeb8b24cac420862e7ef09224009aa51da6c6508f5a113753cc07db6ec5.sig

Die Version wird im Artefakt getaggt, in diesem Beispiel als 11.70.5R1.

Speichern Sie den Wert der Version in SANTRICITY_OS_VERSION.

Wenn die SANtricity-Version niedriger als SANTRICITY_OS_VERSION ist, fahren Sie mit den nächsten Schritten fort, um die SANtricity OS-Version zu aktualisieren. Fahren Sie andernfalls mit der Installation fort.

Wichtig :Wenn Ihre aktuelle Version älter als 11.70.5R1 und Ihre Zielversion neuer als 11.70.5R1 ist, müssen Sie zuerst ein Upgrade auf diese Version durchführen.

15.2.4.1. SANtricity OS upgraden

Folgen Sie dieser Anleitung in der SANtricity-Benutzeroberfläche für jeden Speicherknoten:

1. Rufen Sie das Installations-Image aus dem Bundle ab:

   gdcloud artifacts extract oci santricity \
       --image-name=gpc-system-object-storage/santricity:SANTRICITY_OS_VERSION
   
   tar -xvzf santricity/gpc-system-object-storage/santricity.tar.gz
   

   Die Upgradedatei ist in santricity/SANTRICITY_OS_VERSION/ verfügbar.

2. Klicken Sie auf Support > UPGRADE CENTER (Support > UPGRADE CENTER). Klicken Sie unter SANtricity OS Software upgrade (SANtricity OS-Software-Upgrade) auf Begin Upgrade (Upgrade starten). Wählen Sie die SANtricity OS-Softwaredatei aus, indem Sie auf Durchsuchen klicken. Laden Sie das neue Softwarepaket RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlp wie gezeigt hoch:

   

3. Klicken Sie auf Starten und bestätigen Sie, dass Sie den Vorgang ausführen möchten.

4. Prüfen Sie nach Abschluss des Upgrades, ob die Version aktualisiert wurde:

   

15.3. Installation

15.3.1. Secrets erstellen

Geschätzter Zeitaufwand: 15–30 Minuten

Verwenden Sie das Verzeichnis cellcfg, um Werte zum Erstellen von Secrets abzurufen:

1. Rufen Sie die Namen der objectstoragestoragenodes ab:

   $ CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
   $ sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' CELLCFG_PATH/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
   

   Beispielausgabe:

   # CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
   # sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' ./cellcfg/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
   ah-ac-objs01
   ah-ac-objs02
   ah-ac-objs03
   

2. Rufen Sie die BMC-IP-Adresse für den Speicherknoten ab:

   echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /bmcIP/p" $CELL_ID-obj-cellobj.yaml | grep bmcIP | awk '{print $2}' | cut -d'/' -f1):8443
   

3. Melden Sie sich über den Link in der Ausgabe des vorherigen Befehls im SANtricity System Manager an. Wenn Sie das Passwort noch nicht festgelegt haben, erstellen Sie ein Passwort und melden Sie sich an:

   

   1. Wenn das SANtricity-Passwort verloren gegangen ist, setzen Sie es über die serielle Konsole von StorageGRID E2860 zurück. Für die Verbindung zum seriellen Port des E2860-Festplatten-Arrays sind die Terminaleinstellungen 115200 8N1.

4. Konfigurieren Sie die NTP-Serveradressen im SANtricity System Manager für beide Controller:

   

   1. NTP-Serveradressen abrufen

       kubectl get ntpserver -n ntp-system -o custom-columns=NAME:.metadata.name,MANAGEMENT-IP:.status.managementIP
       ```
      

   2. Wählen Sie im SANtricity System Manager Hardware aus.

   3. Wenn auf der Grafik die Laufwerke zu sehen sind, klicken Sie auf Rückseite des Regals anzeigen. Die Grafik ändert sich und zeigt die Controller anstelle der Laufwerke.

   4. Klicken Sie auf den Controller, den Sie konfigurieren möchten. Das Kontextmenü des Controllers wird angezeigt.

   5. Wählen Sie NTP-Server konfigurieren aus. Das Dialogfeld „NTP-Server (Network Time Protocol) konfigurieren“ wird geöffnet.

   6. Wählen Sie I want to enable NTP on Controller (A or B) (Ich möchte NTP auf Controller (A oder B) aktivieren) aus. Im Dialogfeld werden zusätzliche Auswahlmöglichkeiten angezeigt.

   7. Wählen Sie NTP-Serveradressen manuell angeben aus. Geben Sie die primäre NTP-Serveradresse mit einer der IP-Adressen ein, die vom vorherigen Befehl abgerufen wurden.

   8. Klicken Sie auf Speichern.

5. Aktualisieren Sie die Secrets, die SANtricity-Anmeldedaten für jeden der Speicherknoten in der Datei „cell.yaml“ enthalten. Wenn die Secrets nicht vorhanden sind, fügen Sie sie anhand dieser Vorlage hinzu:

   apiVersion: v1
   kind: Secret
   metadata:
     creationTimestamp: null
     name: <STORAGE_NODE_NAME>-santricity
     namespace: gpc-system
   stringData:
     password: 'PASSWORD'
     username: 'admin'
   type: Opaque
   

6. Erstellen Sie die Secrets für jeden der im vorherigen Schritt aufgeführten Speicherknoten:

   kubectl create secret generic \
      --namespace=gpc-system STORAGE_NODE_NAME-santricity \
      --from-literal=username=admin \
      --from-literal=password=PASSWORD
   

Validierung:

1. Führen Sie den folgenden Befehl für jeden im vorherigen Schritt aufgeführten Speicherknoten aus. Der im vorherigen Schritt festgelegte Santricity-Nutzername wird ausgegeben. Administrator bestätigen:

   kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.username}' | base64 -d; echo
   

2. Führen Sie den folgenden Befehl für jeden im vorherigen Schritt aufgeführten Speicherknoten aus. Das Santricity-Passwort wird ausgegeben:

   kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.password}' | base64 -d; echo
   

3. Führen Sie den folgenden Befehl aus, um die URL der Santricity Management-Benutzeroberfläche abzurufen. Melden Sie sich mit dem Nutzernamen und Passwort bei Santricity an:

   echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /controllerAManagementIP/p" $CELL_ID-obj-cellobj.yaml | grep controllerAManagementIP | awk '{print $2}' | cut -d'/' -f1):8443
   

Fehlerbehebung:

Wenn die Secrets beim Ausführen von Validierungsschritt 1 oder 2 nicht gefunden werden, führen Sie Schritt kubectl create secret noch einmal aus.

Wenn Sie sich nicht in der Santricity Management-Benutzeroberfläche anmelden können:

1. Setzen Sie die Administratoranmeldedaten über die serielle Konsole von StorageGRID E2860 zurück.
2. Führen Sie alle vorherigen Schritte mit Ausnahme des letzten aus.

3. Löschen Sie das vorhandene Santricity-Secret jedes Knotens:

   kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricity
   

4. Führen Sie den letzten Schritt aus, um das Santricity-Secret neu zu erstellen.

15.3.2. Bootstrap Object Storage

Der Bootstrapping-Prozess für Object Storage unterscheidet sich zwischen der ersten Zone und den beitretenden Zonen. Sehen Sie sich den entsprechenden Abschnitt an, der auf Ihre spezielle Situation zutrifft.

WICHTIG: Prüfen Sie, ob das globale API-Bootstrapping für die Ankerzone abgeschlossen ist, bevor Sie fortfahren.

15.3.2.1. Objektspeicher in der ersten Zone booten

Führen Sie den folgenden Befehl aus, um den Objektspeicher zu booten:

gdcloud system objectstorage install --config /CELLCFG_PATH  --first-zone --enable-objectstorage-hsm -v 5

Hinweis:Lassen Sie das Flag --enable-objectstorage-hsm weg, wenn die Umgebung nicht mit HSM gebootstrapped wird.

Hinweis:Wenn Sie eine frühere Umgebung manuell booten, kann es zu einem Fehler kommen, wenn Sie eine CertificateSigningRequest an Kubernetes senden, die CertificateSigningRequest entfernen und versuchen, sie noch einmal zu senden. Beheben Sie das Problem, indem Sie die Zertifikate aus dem HSM rotieren. Folgen Sie zum Rotieren der Zertifikate der Anleitung in HSM Toil 0012 im Abschnitt „KMIP-Zertifikate rotieren“.

15.3.2.2. Objektspeicher in der Beitrittszone booten

Fehlerbehebung:

1. Wenn bei den Google Cloud CLI-Befehlen ein Zeitüberschreitungsfehler auftritt oder Fehler zurückgegeben werden, beheben Sie die zurückgegebenen Probleme.
2. Weitere Informationen zum Fehler finden Sie im gpc-system/obj-infra-cluster-cm-backend-controller-Pod für die Anmeldung.

15.3.2.3. Objektspeicher in der Beitrittszone booten

Geschätzter Zeitaufwand: 30–60 Minuten

Das Bootstrapping von Object Storage in einer beitretenden Zone erfordert eine Koordination zwischen den Object Storage-Abstimmungsfunktionen in der Ankerzone und der beitretenden Zone. Da während des Bootstrappings kein gesicherter und kontrollierter Kommunikationskanal zwischen zwei Zonen für Abgleichsfunktionen vorhanden ist, muss die E/A die gesicherte Kommunikation für Object Storage-Abgleichsfunktionen zwischen zwei Zonen manuell ermöglichen.

1. Weisen Sie sich selbst die vordefinierte Rolle Cluster Admin im zonalen Root-Administratorcluster und im globalen Cluster in der Ankerzone zu. Weitere Informationen finden Sie im IAM-Runbook.

Alternativ können Sie diese beiden Rollenbindungen in der Ankerzone anwenden:

In der globalen API:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: mz-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: mz-bootstrap-global-backend-controllers-role
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: [e-mail]

Im Administratorcluster des Stammverzeichnisses:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: cluster-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: cluster-admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: [e-mail]

1. Führen Sie den Befehl in der Ankerzone aus, um die DNS-Server-IP zu erhalten, und notieren Sie sie für die spätere Verwendung: sh kubectl --kubeconfig /ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH get service gpc-coredns-external-udp -n dns-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

2. Richten Sie den DNS-Stub-Resolver der Beitrittszone so ein, dass er mit der Ankerzone verknüpft wird:

   1. systemd-resolved deaktivieren und beenden sh systemctl disable systemd-resolved.service --now

   2. Löschen Sie die Datei „resolv.conf“, falls sie vorhanden ist. sh rm -f /etc/resolv.conf

   3. Schreiben Sie die DNS-Server-IP der Ankerzone in die resolv.conf der Beitrittszone. sh vim /etc/resolv.conf Beispiel für den Inhalt der Datei „/etc/resolv.conf“: sh nameserver 10.200.40.0

3. Erstellen Sie die YAML-Datei TokenRequest in der Joining-Zone.

   gdcloud system multi-zone create-token-request --zone JOINING_ZONE_NAME --client-type obj-join --cluster kind --namespace gpc-system --output-file TOKEN_REQUEST_YAML_PATH
   

   Ersetzen Sie JOINING_ZONE_NAME durch den Zonennamen aus dem Customer Intake Questionnaire (siehe Hinweis am Ende des Abschnitts).

4. Übertragen Sie die TokenRequest-YAML-Datei in die Ankerzone.

   scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATH
   

5. Wenden Sie die TokenRequest-YAML-Datei auf den globalen Root-Admin-Cluster in der Ankerzone an.

   kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATH
   

6. Erstellen Sie eine Token-YAML-Datei in der Ankerzone.

   gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace gpc-system --output-file TOKEN_YAML_PATH
   

7. Übertragen Sie die Token-YAML-Datei in die Zone, der Sie beitreten möchten.

   scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATH
   

8. Wenden Sie die Token-YAML auf den KIND-Cluster in der Beitrittszone an.

   kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATH
   

9. Erstellen Sie die YAML-Datei „ObjectStorageBootstrap“ in der Ankerzone.

   gdcloud system objectstorage create-bootstrap --output-file  OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
   

10. Übertragen Sie die ObjectStorageBootstrap-YAML-Datei in die Zone, die hinzugefügt wird.

    scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    

11. Wenden Sie die YAML-Datei „ObjectStorageBootstrap“ auf den KIND-Cluster in der Beitrittszone an.

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    

12. Objektspeicher in der beitretenden Zone booten.

    gdcloud system objectstorage install --config /CELLCFG_PATH  --add-zone --enable-objectstorage-hsm -v 5
    

    Hinweis :Lassen Sie das Flag --enable-objectstorage-hsm weg, wenn die Umgebung nicht mit HSM gebootstrapped wird.

Hinweis :Wenn Sie eine frühere Umgebung manuell booten, kann es zu einem Fehler kommen, wenn Sie eine CertificateSigningRequest an Kubernetes senden, die CertificateSigningRequest entfernen und versuchen, sie noch einmal zu senden. Beheben Sie das Problem, indem Sie die Zertifikate aus dem HSM rotieren. Folgen Sie zum Rotieren der Anleitung in HSM Toil 0012 im Abschnitt „KMIP-Zertifikate rotieren“.

Hinweis :Es wird erwartet, dass sich objectstorageadminnode, objectstoragestoragenode und objectstoragesite im KIND-Cluster nicht im Status „Bereit“ befinden.