19. Root-Administratorcluster-Bootstrap

Geschätzte Dauer: 7 Stunden

Eigentümer der betriebsbereiten Komponente: KUB/SERV/OBJ/FILE/PNET

Kompetenzprofil: Bereitstellungsingenieur

In dieser Anleitung wird ein Stammadministratorcluster erstellt, der als Steuerungsebene für den internen Cluster und die Infrastrukturcluster der Organisation dient.

19.1. Routingkonfiguration einrichten

Prüfen Sie, ob die statische Route während der Installation des Bootstrapper-Servers hinzugefügt wurde. Wenn die statische Route fehlt, fügen Sie dem Bootstrapper eine statische Route hinzu:

DATA_CIDR=$(kubectl get cidrclaim -n gpc-system instance-external-cidr -o jsonpath={.spec.ipv4Spec.staticCidrBlocks[0]})
DATA_GATEWAY=$(kubectl get subnetclaims -n root control-plane-subnet -o jsonpath={.status.ipv4SubnetStatus.gateway})
ip route replace ${DATA_CIDR} via ${DATA_GATEWAY}

Diese Route bietet Zugriff auf den API-Server des Administratorclusters der obersten Ebene über die Datenebenenschnittstelle auf dem Bootstrapper. Weitere Informationen zu API-Servern in GDC finden Sie unter Globale und zonale API-Server.

19.2. Root-Administratorcluster erstellen

Mit dem folgenden Befehl wird ein Administratorcluster auf Stammebene mit drei Steuerungsebenenknoten erstellt. Der Standardmandantenmodus ist der Mehrmandantenmodus.

gdcloud system admin-cluster install -v=3 \
  --tenant-mode=multi \
  --root-admin-node-count=3 \
  --generate-admin-yaml \
  --addon-manager-manifests-set harbor.postgresqlHA.enabled=true \
  --addon-manager-manifests-set harbor.productionEnvironment.enabled=true \
  --addon-manager-manifests-set storage.mode=ontap \
  --addon-manager-manifests-set gpuFeature.enabled=true \
  --addon-manager-manifests-set rootAdmin.controller.adminLBPoolSize=23 \
  --addon-manager-manifests-set rootAdmin.controller.systemLBPoolSize=60 \
  --addon-manager-manifests-set network.noInternalSubnet=false \
  --addon-manager-manifests-set minStage=FEATURE_THRESHOLD

Hinweis :Der Parameter --addon-manager-manifests-set minStage=FEATURE_THRESHOLD ist nicht erforderlich, wenn der Funktionsschwellenwert production ist. Der Wert FEATURE_THRESHOLD muss mit dem Wert übereinstimmen, der für die gesamte Bereitstellung festgelegt wurde.

Für die Erstellung des Stamm-Administratorclusters ist eine Konfigurationsdatei für die Cluster-CR erforderlich. Die Konfiguration wird standardmäßig automatisch generiert. Eine benutzerdefinierte Clusterkonfiguration ist auch möglich, indem Sie das Flag --generate-admin-yaml auf false setzen und --admin-yaml-path angeben, um auf den Zielkonfigurationspfad zu verweisen.

Nach Abschluss der Installation des Root-Administratorclusters wird die kubeconfig des Root-Administratorclusters in /root/release/root-admin/root-admin-kubeconfig gespeichert.

Hinweis :Internet Protocol Version 6 (IPv6) ist für den Stammadministratorcluster standardmäßig verfügbar, nachdem das Bootstrapping abgeschlossen ist.

Die URL der Benutzeroberfläche des Nutzeradministrators wird nach der Clusterinstallation ausgegeben. Merken Sie sich den Wert für spätere Vorgänge. Sie können sie auch mit dem folgenden Befehl abrufen:

gdcloud system admin-cluster describe

19.3. Komponenten im Administratorcluster der Stammorganisation bereitstellen

Mit dem folgenden Befehl werden operable Component Lifecycle-Vorlagen im Root-Administratorcluster bereitgestellt.

gdcloud system component deploy --kubeconfig KUBECONFIG --names=* --pivot-from=/root/.kube/config

19.4. Feature-Gates für Root-Administrator konfigurieren

Warnung :Führen Sie die Schritte in diesem Abschnitt nur aus, wenn Sie einen Schwellenwert für die Funktionsphase festgelegt haben, der nicht production ist.

Wenn Sie einen anderen Schwellenwert für die Funktionsphase als production haben, müssen Sie Ihre Feature-Gates entsprechend aktualisieren, um dem Schwellenwert zu entsprechen. Folgen Sie dabei OOPS-P0072.

19.5. Stub-Resolver im Bootstrapper konfigurieren

Verwenden Sie den folgenden Befehl, um den DNS-Stub-Resolver auf dem Bootstrapper einzurichten. Dieser Stub-Resolver ist für den Zugriff auf die Console erforderlich.

gdcloud system dns install

Diese Konfiguration sorgt dafür, dass alle Domainnamen der Organisationen vom Bootstrapper aufgelöst werden können, wie im folgenden Diagramm dargestellt:

19.6. iLo-IP-Adressen festlegen

In den folgenden Schritten werden die ILO-IP-Adressen für Administrator-Knoten auf static festgelegt.

  ADMIN_NODE=NODE NAME
  RACK=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.metadata.labels.system\.private\.gdc\.goog/rack-name}')
  ILO_IP=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.ip}')
  ILO_GATEWAY=$(kubectl --kubeconfig KUBECONFIG get subnetclaims -n root $RACK-mgmtsw01-server-bmc-subnet -o jsonpath='{.status.ipv4SubnetStatus.gateway}')
  BMC_CREDS=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.credentialsRef.name}')
  ILO_USER=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.username}' | base64 --decode)
  ILO_PASS=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.password}' | base64 --decode)

  echo Target Server: $ADMIN_NODE
  echo ILO IP: $ILO_IP
  echo ILO Gateway: $ILO_GATEWAY
  echo ILO Username: $ILO_USER
  echo ILO Password: $ILO_PASS

Prüfen Sie anhand der Informationen im Cluster, ob die oben genannten Informationen korrekt sind. Führen Sie den folgenden Befehl aus, wenn die vorherigen Informationen korrekt sind.

1. Deaktivieren Sie DHCP.

   curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"DHCPv4": {"DHCPEnabled": false}}' | jq '.'
   

   Erwartetes Ergebnis:

   MessageId: iLO.2.15.ResetRequired

2. Konfigurieren Sie die IP-Adresse und das Gateway.

   curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"IPv4Addresses":[{"Address":"'${ILO_IP}'","Gateway":"'${ILO_GATEWAY}'","SubnetMask":"255.255.255.0"}],"IPv4StaticAddresses": [{"Address": "'${ILO_IP}'", "Gateway": "'${ILO_GATEWAY}'", "SubnetMask": "255.255.255.0"}]}' | jq .
   

   Erwartetes Ergebnis:

   MessageId: Base.1.4.Success

3. iLO-Manager zurücksetzen

   curl -k -u ${ILO_USER}:${ILO_PASS}  -H "Content-Type: application/json" -H "OData-Version: 4.0" https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset --data '{"ResetType":"ForceRestart"}' -X POST | jq .
   

   Erwartetes Ergebnis:

   MessageId: iLO.2.15.ResetInProgress

4. Prüfe, ob die Ethernet-Einstellungen angewendet wurden. Wenn die Antwort nicht mehr reagiert, ist das Zurücksetzen nicht abgeschlossen. Brechen Sie den aktuellen curl-Befehl ab, warten Sie 20 Sekunden und versuchen Sie es noch einmal.

   curl --insecure -u ${ILO_USER}:${ILO_PASS} https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 -X GET | jq .
   

Prüfen Sie, ob der HTTP-Rückgabewert für jeden Schritt dem erwarteten Ergebnis entspricht.

Wiederholen Sie die vorherigen Schritte für alle Root-Administratorknoten, die im Cluster vorhanden sind.

19.7. OI-Netzwerk und Google Distributed Cloud (GDC) mit Air Gap verbinden

In diesem Abschnitt wird beschrieben, wie Sie Konfigurationsdateien für Operations Suite Infrastructure (OI) und Distributed Cloud-Netzwerke bereitstellen, um eine Verbindung herzustellen.

Für diese Schritte ist der Zugriff auf einige Distributed Cloud-Dateien sowie die Verbindung zum Root-Administratorcluster der Distributed Cloud-Instanz erforderlich, damit Laufzeitnetzwerkinformationen abgerufen werden können.

Wichtig :Wenn Sie noch nicht mit dem Distributed Cloud-Bootstrapper gearbeitet haben, benötigen Sie möglicherweise Unterstützung von einem Distributed Cloud-Deployment-Techniker, um Zugriff auf den Bootstrapper zu erhalten und den Zugriff auf die Kubernetes API des Root-Administratorclusters sicherzustellen.

19.7.1. Hinweise

In dieser Phase des Bereitstellungsprozesses muss Folgendes zutreffen:

1. Beide OIR-Switches sind verkabelt, eingeschaltet, auf die entsprechende Version aktualisiert und haben Basis- und ACL-Konfigurationen.

2. Beide OIF-Firewalls sind verkabelt, eingeschaltet, auf die entsprechende Version aktualisiert, für den FIPS-CC-Modus aktiviert und haben die Basiskonfiguration angewendet.

3. Damit die gesamte Bereitstellung der Distributed Cloud-Verbindung abgeschlossen werden kann, muss die Distributed Cloud-Instanz das Netzwerk-Bootstraping abgeschlossen und den Kind-Cluster verlassen haben und sich im Root-Admin-Cluster befinden.

Wichtig :Die Schritte, für die die cellcfg-Dateien erforderlich sind, müssen auch dann ausgeführt werden, wenn Schritt 3 noch nicht vollständig abgeschlossen ist, die cellcfg aber verfügbar ist. So können die Switches konfiguriert und für die Distributed Cloud-Verbindung vorbereitet werden. Sobald der Cluster aktiv und vollständig bereit ist, ist ein zusätzlicher Schritt erforderlich, um die Firewall-Sicherheitsrichtlinien zu generieren und anzuwenden.

19.7.2. Umgebung vorbereiten

Bereiten Sie die Umgebung für die folgenden Schritte vor, indem Sie die folgenden Informationen zusammentragen und die Umgebungsvariablen festlegen.

OI kann auf zwei Arten verbunden werden: lokal oder per Fernzugriff. Bei einer lokalen Verbindung wird OI direkt mit Distributed Cloud verbunden. Dazu werden Glasfaserverbindungen zwischen Racks im selben Rechenzentrum verwendet. Bei einer Remote-Verbindung wird über einen Long-Haul-Transport eine Verbindung zu einem anderen Standort hergestellt. Diese Spezifikation kann in der Datei interconnect.yaml angegeben werden, die zum Bereitstellen von Distributed Cloud Interconnect-Konfigurationen erforderlich ist. Diese Datei enthält alle Informationen, die zum Konfigurieren der GDC-Verbindungen erforderlich sind.

19.7.2.1. YAML-Spezifikation für Interconnect-Verbindungen

Attribut	Beschreibung	Beispiel
zones [ ] map	Informationen zur Distributed Cloud-Zelle, mit der die OI-Bereitstellung verbunden werden muss. Wenn Sie eine Verbindung zu einer Liste von Distributed Cloud-Zellen herstellen möchten, geben Sie eine Liste von zones mit Informationen zu jeder Distributed Cloud-Zelle in jeder Zone an. Zonenoptionen	Beispiel: zones: - zoneName: kb - uplinkSpeed: 10 localInstanceIDs: 2 remoteInstanceIDs: - 1 - cellCfg: path/to/cellcfg - zoneName: ah - uplinkSpeed: 100 localInstanceIDs: 3 - cellCfg: path/to/cellcfg

19.7.2.2. Zonenoptionen

Enthält Informationen zu einer Distributed Cloud-Zelle in der Datei interconnect.yaml:

Attribut	Beschreibung	Nutzung
zoneName String	Abkürzung der Distributed Cloud-Zelle, mit der die OI-Bereitstellung verbunden werden muss.	zones: - zoneName: kb
uplinkSpeed uint32	Optional: Gibt die Uplink-Geschwindigkeit der Verbindung an (10 oder 100).	Werte:10, 100 Standard: 10 uplinkSpeed: 100
localInstance int	Die InstanceID der OI-Bereitstellungswebsite aus der ocit.yaml-Datei. Über eine lokale Verbindung wird der Standort des Operations Suite Infrastructure Core Rack (OIR) direkt mit Distributed Cloud verbunden. Dazu werden Glasfaserverbindungen zwischen Racks im selben Rechenzentrum verwendet.	zones: - zoneName: kb localInstanceIDs: 1
remoteInstance [ ] int	InstanceID(s) des OI-Bereitstellungsstandorts aus der Datei ocit.yaml Bei einer Remote-Verbindung wird über Fernverkehr eine Verbindung zu einem oder mehreren anderen Standorten hergestellt. Es kann eine Liste von remoteInstance-Werten angegeben werden, sodass Konfigurationen für alle OIR-Standorte generiert werden, um eine Verbindung zu den angegebenen Distributed Cloud-Zellen herzustellen.	zones: - zoneName: kb remoteInstanceIDs: - 1 zones: - zoneName: kb remoteInstanceIDs: - 1 - 2 - 3

Wenn es sich um eine lokale Verbindung handelt, konfigurieren Sie die Datei interconnect.yaml so:

zones:
  - zoneName: ah
    uplinkSpeed: 100
    localInstanceID: 1
    cellCfg: /path/to/cellcfg

Wenn es sich um eine Remote-Verbindung handelt, konfigurieren Sie die Datei interconnect.yaml so:

zones:
  - zoneName: ah
    uplinkSpeed: 100
      remoteInstanceIDs:
      - 2
    cellCfg: /path/to/cellcfg

Geben Sie für OI-Bereitstellungen an mehreren Standorten die interconnect.yaml-Datei so an:

zones:
  - zoneName: ah
    uplinkSpeed: 100
    localInstanceID: 1
    remoteInstanceIDs:
      - 2
    cellCfg: /path/to/cellcfg

Warnung :Führen Sie diese Schritte aus und verwenden Sie die vollständigen entsprechenden Pfade, da die Befehle sonst nicht erfolgreich ausgeführt werden.

19.7.3. Switch-Konfigurationen generieren

Bei diesen Schritten werden Patchkonfigurationen generiert, die auf die Netzwerkgeräte angewendet werden, um die Verbindung zu Distributed Cloud bereitzustellen.

occonfigtool generate cell config -c /path/to/interconnect.yaml -o path/to/ocit.yaml

Dadurch werden die folgenden Konfigurationsdateien für jede Website generiert:

Konfigurationsdatei(en)	Gerät	Funktion
occoresw101.incremental	occoresw101	Konfiguration zum Patchen des Geräts für die Verbindung zur Distributed Cloud-Instanz
occoresw101.acl	occoresw101	Konfiguration zum Patchen der ACLs für die Traffic-Durchsetzung mit den Distributed Cloud-Netzwerken.
occoresw102.incremental	occoresw102	Konfiguration zum Patchen des Geräts für die Verbindung zur Distributed Cloud-Instanz
occoresw102.acl	occoresw102	Konfiguration zum Patchen der ACLs für die Traffic-Durchsetzung mit den Distributed Cloud-Netzwerken.
ocsw101.incremental	ocs1w01	Konfiguration zum Patchen des Geräts für die Verbindung zur Distributed Cloud-Instanz
ocsw101.acl	ocsw101	Konfiguration zum Patchen der ACLs für die Traffic-Durchsetzung mit den Distributed Cloud-Netzwerken.
ocsw102.incremental	ocsw102	Konfiguration zum Patchen des Geräts für die Verbindung zur Distributed Cloud-Instanz
ocsw102.acl	ocsw102	Konfiguration zum Patchen der ACLs für die Traffic-Durchsetzung mit den Distributed Cloud-Netzwerken.

Hinweis :Bei OI-Bereitstellungen (Operations Suite Infrastructure) mit mehreren Standorten wird für jeden Standort, der in der Datei interconnect.yaml angegeben ist, eine Konfiguration generiert. Ermitteln Sie anhand der InstanceID die für jede Website generierten Dateien. Die generierten Dateien haben ein Präfix im folgenden Format: <segment_type><device_type><InstanceID><device_id>

19.7.4. Firewallrichtlinien generieren

Damit die Firewallregeln generiert werden können, muss occonfigtool auf die Kubernetes API für den Root-Administratorcluster zugreifen. Prüfen Sie, ob die Umgebungsvariable KUBECONFIG auf root-admin-kubeconfig festgelegt ist:

export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
export OCIT_CONFIG_FILE=/path/to/ocit.yaml

Generieren Sie die Firewallregeln mit diesem Befehl:

occonfigtool generate fwrules -o ${OCIT_CONFIG_FILE:?}

Konfigurationsdatei(en)	Gerät	Funktion
firewall-rules.base	occorefw01	Konfiguration zum Patchen des Geräts für die Verbindung zur Distributed Cloud-Instanz

19.7.5. Konfigurationen anwenden

Wenden Sie die Konfiguration mit den Ausgabedateien auf die entsprechenden Netzwerkgeräte an. Gehen Sie dabei genauso vor wie im vorherigen Schritt für Switches und Firewalls.

19.8. Distributed Cloud-Ressourcen RoutePolicy aktualisieren

Distributed Cloud verwendet Routenrichtlinien, um zu erzwingen, welche Netzwerke in der Routingtabelle beworben werden dürfen.

Wenn wir OI als externes Netzwerk hinzufügen, müssen wir die RoutePolicy-CRs aktualisieren, damit sie die neuen Netzwerke berücksichtigen.

Dazu muss über kubectl auf root-admin-cluster zugegriffen werden. Prüfen Sie, ob die entsprechende KUBECONFIG-Variable festgelegt ist:

export KUBECONFIG=/root/deploy/root-admin/root-admin-kubeconfig

So bestätigen Sie das Problem:

kubectl get routepolicy -n gpc-system

Die folgende oder eine ähnliche Ausgabe sollte angezeigt werden:

NAME                                     AGE
customerpeering-routepolicy              19d
datacenter-routepolicy                   19d
mgmtnetworkoperationcenter-routepolicy   19d
networkoperationcenter-routepolicy       19d

Bei diesen Schritten konzentrieren wir uns auf networkoperationcenter-routepolicy und mgmtnetworkoperationcenter-routepolicy.

19.8.1.1. Patch-Datennetzwerk-Routenrichtlinien

Rufen Sie aus ocinfo.opscenter.local.txt die folgenden Subnetze ab (einschließlich Netzwerk und Präfixlänge).

Hinweis :Bei der Bereitstellung von OI an mehreren Standorten wiederholen Sie diesen Schritt für alle Standorte. Verwenden Sie die Subnetze aus der Datei ocinfo.opscenter.local.txt der aufgeführten Websites.

• OCCORE-SERVERS, im folgenden Beispiel als $OCCORE_SERVERS_NET verwendet
• OC-WORKSTATIONS, im folgenden Beispiel als $OC_WORKSTATIONS_NET verwendet

Verwenden Sie diese Werte, um die Routenrichtlinien anzupassen, indem Sie die folgenden Variablen ausfüllen:

export OCCORE_SERVERS_NET=$OCCORE_SERVERS_NET
export OC_WORKSTATIONS_NET=$OC_WORKSTATIONS_NET

Beispiel:

export OCCORE_SERVERS_NET=172.21.0.0/24
export OC_WORKSTATIONS_NET=172.21.32.0/24

Nachdem die Umgebungsvariablen festgelegt wurden, führen Sie die folgenden kubectl-Befehle aus:

kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_SERVERS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OC_WORKSTATIONS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

Beispielausgabe:

routepolicy.system.private.gdc.goog/networkoperationcenter-routepolicy patched

19.8.1.2. Netzwerkroutenrichtlinien für die Patchverwaltung

Rufen Sie aus ocinfo.opscenter.local.txt die folgenden Subnetze ab (einschließlich Netzwerk und Präfixlänge).

Hinweis :Bei OI-Bereitstellungen an mehreren Standorten wiederholen Sie diesen Schritt für alle Standorte. Verwenden Sie die Subnetze aus den ocinfo.opscenter.local.txt-Dateien der aufgeführten Websites.

• OCCORE-JUMPHOSTS, im folgenden Beispiel als $OCCORE_JUMPHOSTS_NET verwendet
• OCCORE-ILOS, im folgenden Beispiel als $OCCORE_ILOS_NET verwendet

Verwenden Sie diese Werte, um die Routenrichtlinien anzupassen, indem Sie die folgenden Variablen ausfüllen:

export OCCORE_JUMPHOSTS_NET=$OCCORE_JUMPHOSTS_NET
export OCCORE_ILOS_NET=$OCCORE_ILOS_NET

Beispiel:

export OCCORE_JUMPHOSTS_NET=172.21.2.0/27
export OCCORE_ILOS_NET=172.21.2.32/27

Nachdem die Umgebungsvariablen festgelegt wurden, führen Sie die folgenden kubectl-Befehle aus:

kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_JUMPHOSTS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_ILOS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

Beispielausgabe:

routepolicy.system.private.gdc.goog/mgmtnetworkoperationcenter-routepolicy patched

19.9. Netzwerkverbindung von OI Distributed Cloud validieren

Wichtig :Führen Sie die Validierungsschritte unter OI-Netzwerk und Distributed Cloud-Verbindung einrichten aus, bevor Sie Distributed Cloud-Verbindungen validieren. Wenn die im vorherigen Schritt vorgenommenen incremental-Konfigurationen bereits angewendet wurden, stimmen die Validierungen in diesem Schritt möglicherweise nicht genau überein.

Zu diesem Zeitpunkt der Bereitstellung muss Folgendes zutreffen:

• Sowohl occoresw101 als auch occoresw102 werden mit den Konfigurationsdateien base, acl, incremental und incremental-acl konfiguriert.
• Sowohl ocsw101 als auch ocsw102 werden mit den Konfigurationsdateien base, acl, incremental und incremental-acl konfiguriert.
• Sowohl occorefw101 als auch occoref102 werden mit den Konfigurationsdateien base und firewall-rules.base konfiguriert.
• Die Uplinks zwischen dem Rechenzentrum und dem Operations Center sind verbunden und betriebsbereit.
• Die physischen Uplinks zwischen den Distributed Cloud-Standorten werden überprüft.

Hinweis :Bei Operations Suite Infrastructure-Bereitstellungen (OI) mit mehreren Standorten werden Konfigurationsdateien für jeden Standort generiert und angewendet.

Wenn eine der oben genannten Bedingungen nicht zutrifft, kann die folgende Ausgabe je nach aktuellem Status erheblich abweichen und es ist wahrscheinlich, dass in der Produktion nicht das erwartete Verhalten auftritt.

19.9.1. Erwartete Ausgabe

Die folgenden Snippets zeigen die Ausgabe der folgenden Befehle in einer bekannten funktionierenden Umgebung:

• show ip bgp summary vrf all
• show ip bgp vrf all
• show ip route vrf all
• show lldp neighbors

Hinweis: Hängen Sie | no-more an das Ende jedes Befehls an, um die Paginierung zu verhindern, z. B. show ip bgp vrf all | no-more.

Diese Snippets können als Vergleich mit einer Produktionsumgebung mit denselben Befehlen dienen.

19.9.2. Schlüsselvalidierungen

Im Folgenden finden Sie wichtige Aspekte, die Sie in den folgenden Ausgaben beachten sollten:

• Keine BGP-Sitzungen befinden sich im Status Idle, Active oder Closing.
• Alle BGP-Sitzungen haben einen State/PrxRcd-Wert, der größer als 0 ist.
• Bei allen BGP-Sitzungen wird ein Up/Down-Timer angezeigt, der kontinuierlich ansteigt.
• Das Distributed Cloud-Präfix externalCIDR (in der CIQ) ist in den Routingtabellen und BGP-Tabellen der VRFs GDCH-DATA, GDCH-DATA-TRANSIT, OC-WORKSTATIONS und OCCORE-SERVERS vorhanden.
• Die Distributed Cloud-oobManagementCIDRs (im CIQ) ist in den Routingtabellen und BGP-Tabellen der VRFs GDCH-MGMT, GDCH-MGMT-TRANSIT und HW-INFRA vorhanden.

19.9.3. OCCORESW

In der folgenden Tabelle sehen Sie die erwartete Ausgabe für jede occore switch für die Distributed Cloud-Verbindungen. Sie müssen alle Netzwerkvalidierungen vor diesem Schritt durchführen. Die hier besprochenen BGP-Nachbarn und ‑Routen sollten zusammen mit den zuvor erwähnten BGP-Nachbarn und ‑Routen vorhanden sein. Prüfen Sie die Ausgabe auf allen Switches.

VRF	BGP-Nachbar	Erwartete Routen, die vom BGP-Nachbarn empfangen wurden	Erwartete Routen, die für den BGP-Nachbarn beworben werden
GDCH-DATA-TRANSIT	AGGSW01	Zusammenfassungsadresse mit Subnetz /19 für Distributed Cloud-Zelle zusammenfassen	OCCORE-SERVERS-Präfix Präfix OC-WORKSTATION
GDCH-DATA-TRANSIT	AGGSW02	Zusammenfassungsadresse mit Subnetz /19 für Distributed Cloud-Zelle zusammenfassen	OCCORE-SERVERS-Präfix Präfix OC-WORKSTATION
GDCH-DATA-TRANSIT	Hairpinned-BGP-Sitzung mit OCCOREFW zum OC-DATA-VRF	Zusammenfassungsadresse (mit Subnetz /19) für Distributed Cloud-Zelle
OC-DATA	OCSW01-BGP-Sitzung	Zusammenfassungsadresse (mit Subnetz /19) für Distributed Cloud-Zelle
OC-DATA	OCSW02-BGP-Sitzung	Zusammenfassungsadresse (mit Subnetz /19) für Distributed Cloud-Zelle
OC-DATA	OCCORESW-BGP-Sitzung	Zusammenfassungsadresse (mit Subnetz /19) für Distributed Cloud-Zelle
GDCH-MGMT-TRANSIT	MGMTAGGSW01	Zusammenfassungsadressen (mit Subnetz /24) des gesamten GDCH-OOB-Verwaltungsnetzwerks	OCCORE-JUMPHOSTS-Präfix OCCORE-ILOS-Präfix
GDCH-MGMT-TRANSIT	MGMTAGGSW02	Zusammenfassungsadressen (mit Subnetz /24) aller OOB-Verwaltungsnetzwerke von Distributed Cloud zusammenfassen	OCCORE-JUMPHOSTS-Präfix OCCORE-ILOS-Präfix
GDCH-MGMT-TRANSIT	HairPinned-BGP-Sitzung mit OCCOREFW zum HW-INFRA-VRF	Zusammenfassungsadressen (mit Subnetz /24) aller OOB-Verwaltungsnetzwerke von Distributed Cloud zusammenfassen

19.9.4. OCSW

In der folgenden Tabelle sehen Sie die erwartete Ausgabe auf jedem oc switch nach der Ausführung des Distributed Cloud Interconnect-Verfahrens. Sie müssen alle Netzwerkvalidierungen vor diesem Schritt durchführen. Die hier besprochenen BGP-Nachbarn und ‑Routen sollten zusammen mit den zuvor erwähnten BGP-Nachbarn und ‑Routen vorhanden sein. Prüfen Sie die Ausgabe auf allen Switches.

VRF	BGP-Nachbar	Erwartete Routen, die vom BGP-Nachbarn empfangen wurden
OC-DATA	OCCORESW01-BGP-Sitzung	Zusammenfassungsadresse (mit Subnetz /19) für GDCH-Zelle
OC-DATA	OCCORESW02-BGP-Sitzung	Zusammenfassungsadresse (mit Subnetz /19) für GDCH-Zelle

Den Ausgabebefehlsschnipsel finden Sie unter Befehl „Distributed Cloud-Validierungen anzeigen“.

Hinweis: Im folgenden Abschnitt wird die Validierung bei Bereitstellungen an mehreren Standorten behandelt. Dieser Abschnitt kann ignoriert werden, wenn Ihre Bereitstellung nicht mehrere Standorte umfasst.

19.9.5. Validierungen der OI-Bereitstellung für mehrere Websites

Im folgenden Abschnitt wird beschrieben, wie Sie Bereitstellungen mit mehreren Standorten mit mehreren miteinander verbundenen Distributed Cloud-Zellen validieren. An dieser Stelle sieht die Topologie mit zwei Standorten so aus:

• Blaue Verbindungen zeigen Standort 1, der mit Distributed Cloud-Zelle 01 und -Zelle 02 verbunden ist.
• Rote Verbindungen zeigen Standort 2, der mit Distributed Cloud-Zelle 01 und -Zelle 02 verbunden ist.
• Grüne Verbindungen zeigen die Verbindung zwischen Standort 1 und Standort 2.

Für alle Websites auf allen Switches müssen Sie die in diesen Abschnitten aufgeführten Schritte ausführen.

1. Netzwerkvalidierungen:
2. Validierungen für mehrere Websites im Netzwerk:
3. Network Distributed Cloud Validations

19.10. Letzte Schritte für das OI-Netzwerk ausführen

Zu diesem Zeitpunkt müssen alle Konfigurationen generiert und auf alle Geräte angewendet worden sein.

Die Netzwerkzugriffslisten befinden sich jetzt in einem Zustand, der bestimmte erwartete Flows zulässt, aber auch eine Standardregel enthält, die den gesamten Traffic zulässt.

Sie müssen die Bereitstellung jetzt an das Betriebsteam übergeben. Die Operational Suite variiert je nach Kunde in Bezug auf Funktion, Implementierung und bereitgestellte Dienste. Daher gelten unterschiedliche Traffic-Anforderungen.

Nachdem der Betrieb die Bereitstellung akzeptiert hat, ist es seine Aufgabe, die ACLs zu bearbeiten und die Netzwerkverkehrsflüsse vollständig zu sichern.

Für diese Aufgaben sind operative Runbooks verfügbar.

19.11. Objektspeicher aktualisieren

Während des Objekt-Speicher-Bootstraps wurden die Knoten mit der neuesten unterstützten Nebenversion von StorageGRID installiert. Die Zielversion muss jedoch möglicherweise auf die aktuelle Hotfix-Patch-Version aktualisiert werden.

Bestimmen Sie die Zielversion von StorageGRID anhand der Release-Metadaten mit dem folgenden Befehl:

kubectl get releasemetadata -o jsonpath='{.items[0].spec.infraComponents.objectStorage.storageGridOSImageVersion}'

Wenn die aktuelle Version von StorageGRID nicht der Zielversion entspricht, führen Sie ein Upgrade des Objektspeichers mit der Zielversion durch.

19.12. Mögliche Probleme

Wichtig :Diese Probleme können bei der Installation der Version 1.9.x von Distributed Cloud auftreten.

19.12.1. Storage Virtual Machine wird nicht abgeglichen

Kurzfassung: Die Storage Virtual Machine wird während der Erstellung des Root-Administratorclusters nicht bereit.

Problem: Nach dem Erstellen des Administrator-Root-Clusters wird die Storage Virtual Machine-Ressource nicht abgeglichen und es wird ein Warnereignis wie das folgende angezeigt:

StorageVirtualMachine Reconcile error, retrying: SVM status update failed,
error: failed to get network interface info: Get
"https://172.22.147.128/api/network/ip/interfaces?fields=%2A%2A&max_records=4096&svm.name=root-admin":
EOF

Dieses Problem kann durch eine Fehlkonfiguration im Speichercluster verursacht werden, die aus Sicherheitsgründen SSL verhindert.

Problemumgehung:

Stellen Sie eine Verbindung zur seriellen Konsole oder zum Speichercluster über SSH her und führen Sie Folgendes aus:

security ssl modify -server-enabled true -client-enabled true -vserver
CELL_ID-stge-clus-01

Nach der Verbindung kann die Storage Virtual Machine-Ressource abgeglichen werden.

19.12.2. Bootstrap ist bei der Installation des TLS-Serverzertifikats der Firewall fehlgeschlagen

Möglicherweise tritt ein TLSServerCertification-Fehler auf, wenn Sie die in Schritt 20 beschriebene Bootstrap-Aufgabe für die Steuerungsebene des Root-Administrators ausführen.

Problemumgehung:

Eine Anleitung zur erneuten Installation des Firewall-Serverzertifikats finden Sie im IO-Servicehandbuch FW-R1008. Nachdem Sie die Installation erfolgreich abgeschlossen haben, verwenden Sie den Befehl gdcloud mit dem Befehl --start-phase, um den Bootstrap-Vorgang für den Root-Administrator fortzusetzen.