Diese Seite wurde von der Cloud Translation API übersetzt.

Upgrade in einer Multi-Zonen-Bereitstellung durchführen

Bei einer Bereitstellung in mehreren Zonen werden die Zonen einzeln und unabhängig voneinander aktualisiert. Es gibt keine globale Orchestrierung von Upgrades über Zonen hinweg. Ein IO muss in jeder Zone ein Upgrade für die Organisation durchführen, die auf eine neue Version aktualisiert werden soll. Daher kann es sein, dass Organisationen in verschiedenen Zonen zu einem bestimmten Zeitpunkt unterschiedliche Versionen verwenden.

Gemäß der auf dieser Seite beschriebenen Upgrade-Reihenfolge müssen Sie die Stammorganisation sowie alle Mandantenorganisationen in einer Zone aktualisieren, bevor Sie mit einer anderen Zone fortfahren. Globale Ressourcen werden am Ende aktualisiert, nachdem alle Zonen aktualisiert wurden.

Auf dieser Seite wird beschrieben, wie Sie bei einem Multi-Zonen-Upgrade von Google Distributed Cloud (GDC) in einer Air-Gap-Umgebung vorgehen müssen. Dazu werden die folgenden Arten von Informationen bereitgestellt:

Erforderlicher Zugriff und Möglichkeiten, ihn zu erhalten.
Welche Tools Sie benötigen.
Schritte, die vor einem Upgrade ausgeführt werden müssen.
Wie und in welcher Reihenfolge Upgrades für verschiedene Distributed Cloud-Komponenten durchgeführt werden.

In der folgenden Liste werden die einzelnen Komponenten eines Upgrades definiert:

Zielversion: Verwenden Sie für alle Zonen dieselbe Zielversion.

Einzeln: Führen Sie das Upgrade für jeweils eine Zone durch. Bevor ein Upgrade in einer Zone ausgelöst wird, muss sichergestellt werden, dass in keiner anderen Zone ein Upgrade ausgeführt wird.

Globale Ressourcen: Kubernetes-Ressourcen, die auf dem globalen kube-apiserver bereitgestellt werden, im Gegensatz zu zonalen Ressourcen, von denen es eine Kopie pro Zone gibt. Globale Ressourcen haben einen anderen Lebenszyklus. Beachten Sie, dass sie am Ende nur einmal aktualisiert werden müssen.

Vorbereiten

Die URLs werden für den Zugriff außerhalb Ihrer Air-Gap-Umgebung bereitgestellt.

Bevor Sie mit einem Upgrade beginnen, müssen folgende Voraussetzungen erfüllt sein:

Der Pfad zur kubeconfig-Datei, die Sie durch Ausführen von gdcloud auth login für den Administrator-Stammcluster erhalten haben.

Wichtig :Sie benötigen den Pfad kubeconfig, bevor Sie fortfahren können.
Die neuen Release-Artefakte wurden heruntergeladen und sicher auf Ihren Computer übertragen. Folgen Sie der Anleitung unter Artefakte in die Container Registry übertragen.
Ein Hostcomputer zum Ausführen der manuellen Upgrades mit einer kubeconfig-Datei des Root-Administratorclusters auf dem Computer.
Alle bekannten Probleme für die Ausgangsversion werden vor dem Start des Upgrades umgangen. Achten Sie insbesondere beim Upgrade von Version 1.13.1 darauf, dass die folgenden Probleme behoben werden:
- VMs, auf denen kein Speicherplatz mehr verfügbar ist

Compliancebericht erstellen

Im Compliance-Bericht werden die Organisationen aufgeführt, die:

nicht mehr unterstützt werden
kritische Sicherheitspatches verpassen

Die Erstellung des Compliance-Berichts ist ein optionaler Schritt, für den ein authentifizierter IO mit organization-admin role erforderlich ist. Führen Sie den folgenden Befehl aus, um den Bericht zu generieren:

  gdcloud system upgrade report-compliance

Weitere Informationen zu den Vorbereitungsanforderungen finden Sie im Abschnitt Voraussetzungen.

Identity and Access Management

Bevor Sie mit einem Upgrade beginnen, müssen Sie in jeder Zone Folgendes tun:

Rufen Sie eine kubeconfig-Datei ab, indem Sie gdcloud auth login für den Root-Administratorcluster und alle Organisationsadministratorcluster ausführen.
Folgen Sie der Anleitung im Runbook für den Zugriffs- und Berechtigungseskalierungsprozess IAM-R0005, um Folgendes hinzuzufügen:
1. ClusterRoleBinding mit dem Clusteradministrator ClusterRole im Root-Administratorcluster jeder Zone
2. org-Administratorcluster, damit temporärer Administratorzugriff gewährt wird.

Globale Ressourcenupgrades in allen Zonen pausieren

Verwenden Sie die abgerufene kubeconfig-Datei, um alle globalen Ressourcenupgrades in jeder Zone zu pausieren.

# Pause upgrades to global root admin resources.
kubectl patch kubeapiserver global-root-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"LocalOnly"}}' --type=merge --kubeconfig=ROOT_ADMIN_KUBECONFIG

# Pause upgrades to global org admin resources.
kubectl patch kubeapiserver global-org-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"LocalOnly"}}' --type=merge --kubeconfig=ORG_MGMT_API_KUBECONFIG

Globale Stammorganisation aktualisieren

Die Aktualisierung der globalen Stammorganisation umfasst auf übergeordneter Ebene die folgenden Schritte:

Führen Sie ein Upgrade der Stammorganisation in allen Zonen durch. Jede Zone wird einzeln aktualisiert.

Wichtig :Beginnen Sie das Upgrade mit der primären StorageGrid-Zone und wiederholen Sie den Vorgang dann für alle anderen Zonen in der Bereitstellung. Diese Reihenfolge ist erforderlich, damit die Objektspeicherung ordnungsgemäß funktioniert.

Prüfen Sie, ob die aktuelle Zone die primäre Zone ist. Der folgende Befehl gibt in der primären Zone „true“ zurück und in nicht primären Zonen nichts.
```
kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
```
Aktualisieren Sie Komponenten, die eine zonenübergreifende Koordination erfordern.
Globale Root-Administratorressourcen aktualisieren

Prüfung vor dem Upgrade

Aktualisieren Sie die Zonen einzeln. Bevor Sie mit dem Upgrade einer Organisation in einer Zone beginnen, stellen Sie eine Verbindung zu allen anderen Zonen her und führen Sie den folgenden Befehl aus, um sicherzustellen, dass der Befehl in allen Zonen „ready“ zurückgibt. Wenn eine Zone als „Nicht bereit“ gemeldet wird, fahren Sie nicht mit dem Upgrade fort. Prüfen Sie die Organisation in dieser Zone, um das Problem zu diagnostizieren.

ORG_NAME=root

[[ $(kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get org ${ORG_NAME} -n gpc-system -ojsonpath='{.status.conditions[?(@.type=="Ready")].status}') == 'True' ]] && echo ready || echo not ready

1. Updatepaket herunterladen und kopieren

So legen Sie los:

Laden Sie ein Updatepaket auf ein Gerät mit Internetzugang herunter, um es auf ein USB-Laufwerk zu kopieren.
Kopieren Sie das Updatepaket vom USB-Laufwerk in Ihre Air-Gap-Umgebung.

Weitere Informationen finden Sie unter Dateien herunterladen zum Herunterladen von Details zu einer Distributed Cloud-Distribution und unter Download übertragen für Informationen zum tragbaren Speichergerät, das Sie zum Übertragen von Dateien in Ihre Air-Gap-Umgebung verwenden.

Entscheiden Sie gemeinsam mit Ihrem Google-Ansprechpartner, ob das Upgrade für eine von einem Partner betriebene Distributed Cloud-Bereitstellung vorgesehen ist und daher Partner-Modellrelease-Dateien verwendet werden sollten.

PARTNER_OPERATED="IS_PARTNER_OPERATED"
if [[ ${PARTNER_OPERATED:?} == "true" ]]; then
  RELEASE_SUFFIX="_partner"
  export GCS_BUCKET=private-cloud-release-partner
else
  RELEASE_SUFFIX=""
  export GCS_BUCKET=private-cloud-release
fi

Laden Sie das Updatepaket von einem Gerät mit Internetzugang auf Ihren USB-Speicher herunter. Verwenden Sie die Versions- und Digest-Details, die Sie von Ihrem Google-Ansprechpartner erhalten haben.
1. Führen Sie gcloud auth login aus, um auf den Cloud Storage-Bucket zuzugreifen.
2. Führen Sie das Skript mit --skip-unzip aus, um das Update-Paket und das Downloader-Skript in das aktuelle Verzeichnis herunterzuladen, z. B. /home/download.
```
VERSION=VERSION
DOWNLOADER=gdch-downloader-prod${RELEASE_SUFFIX}-$VERSION.sh
gcloud storage cp "gs://${GCS_BUCKET:-private-cloud-release}/$VERSION/$DOWNLOADER*" .
   PUBLIC_KEY=$(cat <<-PUBEND
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEn46iVSyFXsvuKLZ4dVOr2AqlXDnR
5cKztkpraexHDxn/ozq03EvrdkRmZkSACFfcaEFyitpraidgAx8sPjvzXQ==
-----END PUBLIC KEY-----
PUBEND
)
echo "${PUBLIC_KEY}" > "key.pub" openssl dgst -sha256 -verify "key.pub" -signature "${DOWNLOADER}.sig" ${DOWNLOADER} && chmod +x $DOWNLOADER && ./$DOWNLOADER --skip-unzip
```
3. Wenn Sie ein Upgrade mit Release-Dateien für Partnermodelle durchführen, folgen Sie der Anleitung, um die Softwarepakete für die Verteilung von Partnermodellen vorzubereiten.
  
  Hinweis :Überspringen Sie diesen Schritt, wenn Sie keine Partnermodell-Release-Dateien für das Upgrade verwenden.
Kopieren Sie sowohl das Downloader-Skript als auch das Verzeichnis gdch auf Ihren USB-Stick.
Kopieren Sie das Update von Ihrem USB-Speichermedium auf das OCIT. Speichern Sie die Dateien an einem ähnlichen Ort, z. B. /home/download/.

Definieren Sie diese Variablen im OCIT neu und extrahieren Sie das Update:

cd /root
VERSION=VERSION
DOWNLOADER=gdch-downloader-prod${RELEASE_SUFFIX}-$VERSION.sh
PUBLIC_KEY=$(cat <<-PUBEND
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEn46iVSyFXsvuKLZ4dVOr2AqlXDnR
5cKztkpraexHDxn/ozq03EvrdkRmZkSACFfcaEFyitpraidgAx8sPjvzXQ==
-----END PUBLIC KEY-----
PUBEND
)
echo "${PUBLIC_KEY}" > "key.pub" openssl dgst -sha256 -verify "key.pub" -signature "${DOWNLOADER}.sig" ${DOWNLOADER} && chmod +x $DOWNLOADER && ./$DOWNLOADER --skip-download

Der Downloader hat das Release in gdch/full-release-1.2.0-gdch.243 entpackt (z. B. /home/download/gdch/full-release-1.2.0-gdch.243). Weisen Sie dieser Variablen den vollständigen Pfad zu:
```
export ARTIFACTS_ROOT='/home/download/gdch/full-release-RELEASE_VERSION'-gdch.BUILD_NUMBER'
```

2. Artifact Registry-Upgrade konfigurieren

Für ein erfolgreiches Upgrade müssen Sie Folgendes ausführen:

Artefakte per Push in die Container Registry übertragen

Setzen Sie KUBECONFIG auf die kubeconfig-Datei für den Administratorcluster auf Stammebene.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
```

Erstellen Sie die erforderlichen ClusterRoleBindings:

kubectl create clusterrolebinding io-upgrade-admin --clusterrole=upgrade-admin-dc --user=USER_EMAIL

kubectl create clusterrolebinding io-upgrade-debugger --clusterrole=upgrade-debugger --user=USER_EMAIL

Erstellen Sie die erforderlichen RoleBindings:

kubectl create rolebinding io-system-artifact-management-secrets-admin --role=system-artifact-management-secrets-admin --user=USER_EMAIL -n anthos-creds

kubectl create rolebinding io-system-artifact-management-admin --role=system-artifact-management-admin --user=USER_EMAIL -n gpc-system

kubectl create rolebinding io-dnssuffix-viewer --role=dnssuffix-viewer --user=USER_EMAIL -n gpc-system

Erstellen Sie RoleBindings, um das OCI-Bundle zu übertragen:

kubectl create rolebinding infrastructure-operator-sar-harbor-admin --user=gdch-infra-operator-USER_EMAIL --role=sar-harbor-admin -n gpc-system

Die Ausgabe sieht so aus:

rolebinding.rbac.authorization.k8s.io/infrastructure-operator-sar-harbor-admin created

Folgen Sie der Anleitung unter Artifact Registry-Speicherplatz anpassen, um Folgendes zu tun:
1. Prüfen Sie die Speichernutzung der Artifact Registry in einem Administratorcluster und vergewissern Sie sich, dass genügend Speicherplatz für die Artefakte vorhanden ist, die Sie übertragen möchten.
2. Wenn Sie den verfügbaren Speicherplatz erhöhen müssen, folgen Sie der Anleitung unter Artifact Registry-Speicherplatz anpassen.
Docker-Konfigurationen einrichten:
```
cp ${ARTIFACTS_ROOT}/docker-credential-gdcloud /usr/bin
```
Hinweis: Achten Sie immer darauf, dass diese Binärdatei vorhanden ist, bevor Sie load-oci ausführen.

Konfigurieren Sie Docker so, dass dem Trust Store-Bundle vertraut wird.

REGISTRY=$(kubectl get harborcluster harbor -n harbor-system -o jsonpath='{.spec.externalURL}' 2>/dev/null);
if [[ -z "$REGISTRY" ]]; then echo "Harbor external URL not found" >&2; exit 1; fi;

HOST=$(echo "$REGISTRY" | sed 's#https://##');
if [[ -z "$HOST" ]]; then echo "Invalid registry URL" >&2; exit 1; fi;

DIR="/etc/docker/certs.d/$HOST"; FILE="$DIR/ca.crt"; mkdir -p "$DIR"; chmod 755 "$DIR";
if [[ ! -f "$FILE" ]]; then
   CERT=$(kubectl get secret trust-store-internal-only -n istio-system -o jsonpath='{.data.ca\.crt}' 2>/dev/null);
   if [[ -z "$CERT" ]]; then echo "Certificate secret not found" >&2;
   exit 1;
   fi;
   echo "$CERT" | base64 -d > "$FILE"; chmod 644 "$FILE";
else echo "Certificate $FILE already exists"; fi

Laden Sie die Artefakte in die Artifact Registry im Administratorcluster des Stammclusters:

export VERSION=VERSION
export KUBECONFIG=KUBECONFIG_PATH
export ARTIFACTS_ROOT=/home/download/gdch/full-release-VERSION
export PACKAGE_VALIDATION_ROOT_CERT=PACKAGE_VALIDATION_ROOT_CERT_PATH

${ARTIFACTS_ROOT}/gdcloud auth configure-docker
${ARTIFACTS_ROOT}/gdcloud system container-registry load-oci ${ARTIFACTS_ROOT}/oci --pv-root-cert-path=PACKAGE_VALIDATION_ROOT_CERT_PATH --kubeconfig=KUBECONFIG_PATH --use-ip-port=true --show-progress=false

Ersetzen Sie Folgendes:

VERSION: die Distributed Cloud-Releaseversion. Beispiel: 1.x.y-gdch.z.
KUBECONFIG_PATH: der Pfad zur kubeconfig-Datei, die Sie durch Ausführen von gdcloud auth login im Administratorcluster des Stammverzeichnisses erhalten haben.
PACKAGE_VALIDATION_ROOT_CERT_PATH: Der Pfad zum Root-Zertifikat für die Paketvalidierung. Sie müssen den Standardpfad ${ARTIFACTS_ROOT}/staging_root_ca_certificate.crt verwenden. Durch die Einbeziehung dieses Pfads werden Release-Schlüsselzertifikate validiert, die für die Paketvalidierung verwendet werden.

Wenn der Befehl erfolgreich war, sieht die Ausgabe am Ende in etwa so aus:

I0911 04:05:01.755927 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-bg4ck, starting time: 04:05:01.                                                  │·······
I0911 04:05:02.002637 3463529 monitor.go:100] [2/2] artifacts distributed and [0/0/0] inProgress/failed/stopped after 246.689693ms                                              │·······
I0911 04:05:02.002723 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-jv5p9, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.039545 3463529 monitor.go:44] Created after 36.820059ms.                                                                                                         │·······
I0911 04:05:02.039599 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-jv5p9, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.045964 3463529 monitor.go:100] [3/3] artifacts distributed and [0/0/0] inProgress/failed/stopped after 6.360571ms                                                │·······
I0911 04:05:02.045997 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-bhckh, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.077418 3463529 monitor.go:44] Created after 31.408176ms.                                                                                                         │·······
I0911 04:05:02.077464 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-bhckh, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.239086 3463529 monitor.go:100] [2/2] artifacts distributed and [0/0/0] inProgress/failed/stopped after 161.610475ms                                              │·······
I0911 04:05:02.239138 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-xvlbt, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.248366 3463529 monitor.go:44] Created after 9.220575ms.                                                                                                          │·······
I0911 04:05:02.248415 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-xvlbt, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.532191 3463529 monitor.go:100] [1/1] artifacts distributed and [0/0/0] inProgress/failed/stopped after 283.756574ms                                              │·······
I0911 04:05:02.532236 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-7k4s4, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.544529 3463529 monitor.go:44] Created after 12.282657ms.                                                                                                         │·······
I0911 04:05:02.544579 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-7k4s4, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.641252 3463529 monitor.go:100] [1/1] artifacts distributed and [0/0/0] inProgress/failed/stopped after 96.652179ms                                               │·······
I0911 04:05:02.641332 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-dpj7n, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.645509 3463529 monitor.go:44] Created after 4.169293ms.                                                                                                          │·······
I0911 04:05:02.645575 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-dpj7n, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.839587 3463529 monitor.go:100] [3/3] artifacts distributed and [0/0/0] inProgress/failed/stopped after 194.004999ms                                              │·······
I0911 04:05:02.839639 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-fn94p, starting time: 04:05:02.                                                  │·······
I0911 04:05:02.844001 3463529 monitor.go:44] Created after 4.361378ms.                                                                                                          │·······
I0911 04:05:02.844034 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-fn94p, starting time: 04:05:02.                                                  │·······
I0911 04:05:03.041615 3463529 monitor.go:100] [2/2] artifacts distributed and [0/0/0] inProgress/failed/stopped after 197.567981ms                                              │·······
I0911 04:05:03.041675 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-4cxxf, starting time: 04:05:03.                                                  │·······
I0911 04:05:03.047192 3463529 monitor.go:44] Created after 5.499407ms.                                                                                                          │·······
I0911 04:05:03.047292 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-4cxxf, starting time: 04:05:03.                                                  │·······
I0911 04:05:03.241688 3463529 monitor.go:100] [76/76] artifacts distributed and [0/0/0] inProgress/failed/stopped after 194.395913ms

Wenn Ihre Ausgabe nicht diesem Beispiel entspricht, folgen Sie dieser Anleitung, um die häufigsten Probleme zu beheben:

Wenn Ihre Ausgabe die Meldung Package validation root certificate requires upgrade! enthält, rotieren Sie das Stammzertifikat. Folgen Sie dazu der Anleitung unter Zertifikat für die Paketvalidierung rotieren.
Wenn load-oci fehlschlägt, führen Sie den Vorgang noch einmal aus. Wenn der Fehler weiterhin auftritt, sehen Sie sich die anderen Lösungen in dieser Liste an.
Wenn in der Ausgabe die Meldung Error: unable to create k8sclient: Unauthorized angezeigt wird, müssen Sie sich noch einmal authentifizieren. Wiederholen Sie den Vorbereitungsschritt, um die kubeconfig-Datei zu prüfen, oder führen Sie den Befehl ${ARTIFACTS_ROOT}/gdcloud auth login aus und wiederholen Sie den Vorgang load-oci.
Wenn in Ihrer Ausgabe die Meldung UNAUTHORIZED: unauthorized to access repository angezeigt wird, haben Sie nicht die erforderlichen Berechtigungen zum Ausführen des Befehls load-oci. Eskalieren Sie dieses Problem, um die erforderlichen Rollen zum Ausführen dieses Befehls zu erhalten, oder lassen Sie den Befehl von einem Nutzer mit den erforderlichen Rollen in Ihrem Namen ausführen.

Nur für das Upgrade mit Partnermodell-Release-Dateien: Folgen Sie der Anleitung, um die Softwarepakete für die Verteilung von Partnermodellen zu laden.
Prüfen Sie, ob sich das ReleaseMetadata-Objekt für die neue Releaseversion im Administratorcluster auf der Stammebene befindet:
```
kubectl get releasemetadata.artifact.private.gdc.goog VERSION
```
Ersetzen Sie VERSION durch die Distributed Cloud-Releaseversion. Beispiel: 1.x.y-gdch.z.

Beispielausgabe:
```
NAME             AGE
1.x.y-gdch.z     2m
```
Prüfen Sie, ob die neue Version in der Liste der verfügbaren Upgrades für die zu aktualisierende Stammorganisation aufgeführt ist:
```
ROOT_NAME=root
kubectl get organization -n gpc-system ${ROOT_NAME} -ojsonpath='{.status.availableUpgrades}{"\n"}'
```
Bei 1.x.y-gdch.z erwarten wir beispielsweise die folgende Ausgabe:
```
["1.x.y-gdch.z"]
```

Nachdem die Stammorganisation auf eine neue Version aktualisiert wurde, ist diese Version für Upgrades für eine Mandantenorganisation verfügbar.

3. Root-Organisation aktualisieren

3.1 Vor der Umstellung

Setzen Sie KUBECONFIG auf die kubeconfig-Datei für den Administratorcluster auf Stammebene.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
```

Erstellen Sie die erforderlichen ClusterRoleBindings:

kubectl create clusterrolebinding io-organization-admin --clusterrole=organization-admin --user=USER_EMAIL

Prüfen Sie, ob sich die Stammorganisation in einem fehlerfreien Zustand befindet. Dies wird durch die Antwort True angezeigt:
```
kubectl get organization -n gpc-system root \
    -ojsonpath='{.status.conditions[?(@.type=="Ready")].status}{"\n"}'
```
Beispielausgabe:
```
True
```
Folgen Sie der Anleitung im Runbook HSM-P0003, um alle HSMs neu zu starten.

3.2 Automatisierte Upgrades der Stammorganisation durchführen

Das Upgrade muss über den IaC-Prozess erfolgen. Das Upgrade wird ausgelöst, indem das Feld „version“ im entsprechenden OrganizationZonalConfig-Objekt der Organisation in der Zone aktualisiert wird.

Aktualisieren Sie die Version in der YAML-Datei OrganizationZonalConfig. Löschen Sie den Abschnitt spec.capacities.workloadServers in der Datei, falls er vorhanden ist.

ORG_NAME=root
ZONE=$(kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get controlplane cp -n mz-system -ojsonpath='{.spec.zone}')
sed -i 's/version: .*$/version: VERSION/' IAC_REPO_PATH/iac/infrastructure/global/orgs/${ORG_NAME}/${ORG_NAME}-${ZONE}.yaml

Stellen Sie die Dateiänderungen bereit und führen Sie einen Commit durch.
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

Erstellen Sie eine Zusammenführungsanfrage.

git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin ${USERNAME1}-branch

Wenn das Upgrade beginnt, wird ein OrganizationUpgrade-Objekt erstellt. Prüfen Sie, ob das Stammobjekt OrganizationUpgrade im Stamm-Administratorcluster in der Zone erstellt wurde.

kubectl get -n gpc-system organizationupgrade root -o yaml --kubeconfig ROOT_ADMIN_KUBECONFIG

Wenn OrganizationUpgrade nicht gefunden wird, folgen Sie dem Runbook IAC-R0001 zur Fehlerbehebung.

3.3 Prüfungen nach dem Upgrade

Upgrade-Ergebnisse prüfen:
1. Prüfen Sie das Objekt Organization für die Stammorganisation. Prüfen Sie, ob der Status READY True lautet:
```
kubectl -n gpc-system get organization root
```
  Beispielausgabe:
```
NAME   READY
root   True
```
2. Prüfen Sie, ob Organization.Status.Version den genauen String 1.x.y-gdch.z enthält:
```
kubectl -n gpc-system get organization root -o jsonpath='{.status.version}{"\n"}'
```
  Beispielausgabe für die Bestätigung:
```
1.13.3-gdch.5548
```

Suchen Sie in der Stammorganisation nach Fehlern bei untergeordneten Komponenten:

Suchen Sie nach den Unterkomponenten mit dem Status ReconciliationError oder Reconciling. Verweisen Sie die kubeconfig auf ROOT_ADMIN_KUBECONFIG:

export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
export CLUSTER_NAMESPACE=root
echo "Subcomponents with failures"
kubectl get subcomponent -n ${CLUSTER_NAMESPACE} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") | select(.status.featureDisabled != true) |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'
echo "Subcomponents still reconciling"
kubectl get subcomponent -n ${CLUSTER_NAMESPACE} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "Reconciling") | select(.status.featureDisabled != true) | select( "\(.status)" | contains("PreinstallPending") | not) | "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'

Bei Fehlern finden Sie in den Versionshinweisen und bekannten Problemen eine Problemumgehung. Andernfalls wenden Sie sich zur Fehlerbehebung an Distributed Cloud.

Wenn die Preflight- oder Postflight-Prüfung übersprungen wurde, entfernen Sie die Anmerkungen nach Abschluss des Upgrades:

Beispiele:

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-preflight-check-

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-postflight-check-

Upgrade der Stammorganisation in allen Zonen abschließen

Nachdem ein Upgrade in einer Zone abgeschlossen ist, sollten Sie prüfen, ob die Zone weiterhin ordnungsgemäß funktioniert, bevor Sie mit dem Upgrade der nächsten Zone fortfahren.

Wiederholen Sie die Schritte 1 bis 3 für die Stammorganisation in den restlichen Zonen. Wenn für alle Zonen ein Upgrade der Stammorganisation durchgeführt wurde, fahren Sie mit den nächsten Schritten fort.

4. Globale Ressourcen upgraden

Globale Ressourcen sollten die niedrigste Version aller Zonen haben. Starten Sie den Upgradevorgang für globale Ressourcen, indem Sie eine Verbindung zur Ankerzone herstellen und die folgenden Befehle ausführen.

# Annotate appropriate versions for all the operable components.
MAP=$(kubectl get kubeapiserver root-admin -n root -ojsonpath='{.metadata.annotations}' --kubeconfig ROOT_ADMIN_KUBECONFIG | jq -r 'to_entries | map("\(.key) \(.value)") | .[] | select(startswith("lcm.private.gdc.goog/oc-version-"))')

echo "${MAP}" | while read KV; do
   SPLIT=(${KV}); KEY=${SPLIT[0]}; VALUE=${SPLIT[1]}
   echo "Annotating global KubeAPIServer with ${KEY}: ${VALUE}"
   kubectl annotate kubeapiserver global-root-admin -n global-kube-system --overwrite ${KEY}=${VALUE} --kubeconfig ROOT_ADMIN_KUBECONFIG
done

# Trigger the global resource upgrade on global root admin.
kubectl annotate kubeapiserver global-root-admin -n global-kube-system --overwrite lcm.private.gdc.goog/paused-remote=false --kubeconfig ROOT_ADMIN_KUBECONFIG
kubectl patch kubeapiserver global-root-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"AllowAll"}}' --type=merge --kubeconfig ROOT_ADMIN_KUBECONFIG

Der Vorgang kann einige Minuten dauern. Prüfen Sie mit den folgenden Befehlen, ob die globalen Ressourcen aktualisiert wurden. Der Befehl sollte keinen Fehler melden.

# Verify that Components are all successfully rolled out on global root admin.
echo "${MAP}" | while read KV; do
   SPLIT=(${KV}); VALUE=${SPLIT[1]}; OC=$(echo ${VALUE} | cut -d- -f1)
   [[ -n ${OC} ]] || continue
   ROLLOUT=$(kubectl get componentrollout ${OC} -n global-kube-system -o json --ignore-not-found --kubeconfig ROOT_ADMIN_KUBECONFIG)
   [[ -n ${ROLLOUT} ]] || continue
   if [[ $(echo ${ROLLOUT} | jq -r '.spec.componentRef.name') != ${VALUE} ]] ; then
      echo "${OC} rollout trigger failed"; continue
   fi
   if [[ $(echo ${ROLLOUT} | jq -r '.status.allSubcomponentsReady') != 'true' ]] ; then
      echo "${OC} rollout completion failed. Use 'kubectl describe componentrollout ${OC} -n global-kube-system --kubeconfig ROOT_ADMIN_KUBECONFIG' to check for error messages."
   fi
done && echo "Global component rollout check finished."

5. Zonenübergreifende Komponentenupgrades

In einem GDC-Universum mit mehreren Zonen erfordern bestimmte bedienbare Komponenten eine Koordination zwischen den Zonen, um ihre Upgrades abzuschließen.

Die folgenden bedienbaren Komponenten werden in diesem Schritt aktualisiert.

Umfang	Bedienelemente
Infrastruktur	IAC
Infrastruktur	SIEM

Folgen Sie dem Runbook IAC-R0016, um die IAC-kompatible Komponente zu aktualisieren.

Folgen Sie dem Runbook SIEM-G0008, um die SIEM-kompatible Komponente zu aktualisieren.

6. Manuelles Upgrade für Anycast-Subnetz

Führen Sie das folgende Skript aus, um den Anycast-Subnetzen im globalen Root-API-Server die erforderlichen Labels hinzuzufügen:

#!/bin/bash

# Description:
# This script ensures that specific Subnet resources in Kubernetes have the
# correct label applied. This is necessary for anycast features to function correctly.
#
# The script is idempotent and can be run multiple times safely.
# It requires the path to a valid global root kubeconfig file as a command-line argument.

# --- Configuration ---
set -o nounset

# The names of the Subnet resources to update.
readonly SUBNET_NAMES=(
  "infra-vpc-anycast-cidr"
  "data-global-anycast-cidr"
  "admin-global-anycast-cidr"
)

# The label that will be applied to the subnets.
readonly LABEL_KEY="ipam.gdc.goog/usage"
readonly LABEL_VALUE="global-anycast-root-range"

# The Kubernetes resource type for the subnets.
readonly SUBNET_RESOURCE_TYPE="subnets"

# Timeout for kubectl commands in seconds.
readonly KUBECTL_TIMEOUT="30s"

log_error() {
  echo "[ERROR] $(date +'%Y-%m-%dT%H:%M:%S%z'): $*" >&2
}

main() {
  # --- Argument Validation ---
  if [[ $# -ne 1 ]]; then
    echo "Usage: $0 <path-to-kubeconfig-file>"
    echo "Example: $0 /root/release/root-admin/global-root-admin-kubeconfig"
    exit 1
  fi

  local KUBECONFIG_PATH="$1"

  if [[ ! -f "${KUBECONFIG_PATH}" ]]; then
      log_error "Kubeconfig file not found at: ${KUBECONFIG_PATH}"
      exit 1
  fi

  if ! command -v kubectl &> /dev/null; then
    log_error "kubectl command not found. Please ensure it is installed and in your system's PATH."
    exit 1
  fi

  if ! command -v timeout &> /dev/null; then
    log_error "timeout command not found. Please ensure 'coreutils' is installed."
    exit 1
  fi

  if ! command -v jq &> /dev/null; then
    log_error "jq command not found. Please ensure it is installed and in your system's PATH."
    exit 1
  fi

  echo "Starting Subnet labeling process using kubeconfig: ${KUBECONFIG_PATH}"

  # --- Pre-flight Check and Data Fetch ---
  echo "Verifying access and fetching all Subnet resources (timeout in ${KUBECTL_TIMEOUT})..."
  local all_subnets_json

  if ! all_subnets_json=$(timeout "${KUBECTL_TIMEOUT}" kubectl get --kubeconfig="${KUBECONFIG_PATH}" "${SUBNET_RESOURCE_TYPE}" --all-namespaces -o json 2>/dev/null); then
      log_error "Failed to list Subnet resources. The command timed out or returned an error. Please check cluster connectivity and permissions."
      exit 1
  fi

  if [[ -z "${all_subnets_json}" ]] || [[ $(jq '.items | length' <<< "${all_subnets_json}") -eq 0 ]]; then
      echo "No subnet resources found in the cluster. Exiting."
      exit 0
  fi
  echo "Access verified. Processing subnets..."

  local processed_count=0
  local found_count=0
  local subnet_regex
  subnet_regex=$(printf "|%s" "${SUBNET_NAMES[@]}")
  subnet_regex="^(${subnet_regex:1})$"

  # jq query to output: namespace  name  label_value (or null)
  echo "${all_subnets_json}" | jq -r ".items[] | [.metadata.namespace, .metadata.name, (.metadata.labels | .[\"${LABEL_KEY}\"] // \"\")] | @tsv" |
  while IFS=$'\t' read -r namespace name current_value; do
    if [[ -z "${name}" ]]; then continue; fi

    if [[ ! "${name}" =~ ${subnet_regex} ]]; then
        continue
    fi

    ((found_count++))
    echo "Found target subnet: '${name}' in namespace '${namespace}'"

    if [[ "${current_value}" == "${LABEL_VALUE}" ]]; then
        echo "  - Subnet already has the correct label. Skipping."
        ((processed_count++))
        continue
    fi

    echo "  - Applying label '${LABEL_KEY}=${LABEL_VALUE}'..."
    if ! timeout "${KUBECTL_TIMEOUT}" kubectl label --kubeconfig="${KUBECONFIG_PATH}" --namespace="${namespace}" "${SUBNET_RESOURCE_TYPE}" "${name}" "${LABEL_KEY}=${LABEL_VALUE}" --overwrite > /dev/null; then
        log_error "Failed to apply label to subnet '${name}' in namespace '${namespace}'. The command timed out or returned an error."
    else
        echo "  - Successfully labeled subnet."
        ((processed_count++))
    fi
  done

  # --- Final Summary ---
  echo "---"
  if [[ ${found_count} -eq 0 ]]; then
    echo "No target anycast subnets were found in the cluster."
  else
    echo "Finished processing. Found ${found_count} and validated ${processed_count} target subnet(s)."
  fi

  echo "Subnet labeling process completed."
}

# Execute the main function with command-line arguments.
main "$@"

Nachdem das Skript erfolgreich ausgeführt wurde, machen Sie die manuelle Anycast-Problemumgehung rückgängig, falls sie zuvor angewendet wurde.

7. Manuelles Upgrade für SyncServer

Die folgenden bedienbaren Komponenten werden in diesem Schritt aktualisiert.

Umfang	Bedienelemente
Infrastruktur	NTP

Dieses Firmware-Upgrade ist unabhängig von anderen Schritten und kann jederzeit durchgeführt werden.

Der Cluster hat nur einen SyncServer und kann daher nicht im Hochverfügbarkeitsmodus ausgeführt werden. Während des Upgrades ist der SyncServer für einen bestimmten Zeitraum nicht verfügbar. Der Cluster verwendet weiterhin seine eigenen, weniger genauen Uhren, was keine spürbaren Auswirkungen hat.

Es wird empfohlen, diesen Vorgang in einer Sitzung abzuschließen (nicht über Nacht oder am Wochenende), um Zeitabweichungen zu vermeiden.

7.1 SyncServer-Upgrade

Die folgenden Befehle sollten im Release-Verzeichnis des extrahierten Updatepakets ausgeführt werden.

So finden Sie die aktuelle Firmware für die Extraktion:

${ARTIFACTS_ROOT}/gdcloud artifacts tree ${ARTIFACTS_ROOT}/oci/ | grep syncserver | grep -v .sig$

Der Dateiname enthält die Version der Firmware.

Beispielausgabe:

│   ├── gdch-syncserver-firmware/syncserver:5.1.2

Kopieren Sie nur die Dateinamen und weisen Sie sie diesen Variablen zu:
```
export SYNCSERVER_VERSION=syncserver:5.1.2
```

Extrahieren Sie die Firmware aus dem OCI-Image:

${ARTIFACTS_ROOT}/gdcloud artifacts extract ${ARTIFACTS_ROOT}/oci syncserver_firmware --image-name=gdch-syncserver-firmware/${SYNCSERVER_VERSION:?}

Extrahieren Sie die Firmware:
```
tar -xvzf syncserver_firmware/gdch-syncserver-firmware/syncserver.tar.gz
```
Im Ausgabeverzeichnis muss eine *.dat- und eine *updater.zip-Datei vorhanden sein.
Folgen Sie dem Runbook NTP-P0002 – Auf SyncServer-Benutzeroberfläche zugreifen.
1. Gehen Sie zu Hilfe -> Über -> Softwareversion. Wenn die installierte Softwareversion gleich oder neuer als die bereitgestellte Firmware ist, muss die Firmware nicht aktualisiert werden und die nächsten Schritte können übersprungen werden.
2. Gehen Sie in der SyncServer-Benutzeroberfläche zu Admin -> Upgrade. Lade syncserver_s650_license.dat in Authorization File und syncserver_s650_updater.zip in Upgrade File hoch. Klicken Sie dann auf „Installieren“.

Globale Mandantenorganisation upgraden

Die Aktualisierung einer globalen Mandantenorganisation umfasst auf hoher Ebene die folgenden Schritte:

Führen Sie ein Upgrade der Mandantenorganisation in allen Zonen durch. Jede Zone wird einzeln aktualisiert.

Wichtig :Beginnen Sie das Upgrade mit der primären StorageGrid-Zone und wiederholen Sie den Vorgang dann für alle anderen Zonen in der Bereitstellung. Diese Reihenfolge ist erforderlich, damit die Objektspeicherung ordnungsgemäß funktioniert.

Prüfen Sie, ob die aktuelle Zone die primäre Zone ist. Der folgende Befehl gibt in der primären Zone „true“ zurück und in nicht primären Zonen nichts.
```
kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
```
Globale Ressourcen der Mandantenorganisation upgraden

Prüfung vor dem Upgrade

ORG_NAME=ORG_NAME

[[ $(kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get org ${ORG_NAME} -n gpc-system -ojsonpath='{.status.conditions[?(@.type=="Ready")].status}') == 'True' ]] && echo ready || echo not ready

Prüfen Sie, ob sich alle Cluster im Status „Wird ausgeführt“ und alle Knotenpools im Status „Bereit“ befinden. Wenn nicht, beheben Sie sie zuerst, bevor Sie mit dem Upgrade beginnen.

ORG_NAME=ORG_NAME
kubectl get nodepools -n ${ORG_NAME} --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,READY:.status.conditions[?(@.type=="Ready")].status'
# Example output
# NAMESPACE   NAME                                        READY
# org1        admin-control-plane-node-pool               True
# org1        data-plane-pool-o2-standard1-96-gdc-metal   True

kubectl get cluster -n mks-system --kubeconfig ORG_MGMT_API_KUBECONFIG
# Example output
# NAME                    STATE     K8S VERSION
# g-org1-perimeter        Running   1.30.6-gke.300
# g-org1-shared-service   Running   1.30.6-gke.300

kubectl get nodepool -A --kubeconfig ORG_INFRA_KUBECONFIG -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,READY:.status.conditions[?(@.type=="Ready")].status'
# Example output
# NAMESPACE                       NAME                                                     READY
# g-org1-perimeter-cluster        control-plane-node-pool                                  True
# g-org1-perimeter-cluster        perimeter-admin-node-pool                                True
# g-org1-perimeter-cluster        perimeter-data-node-pool                                 True
# g-org1-shared-service-cluster   control-plane-node-pool                                  True
# g-org1-shared-service-cluster   dbs-billing-system-billing-dbcluster-n2-standard-4-gdc   True
# g-org1-shared-service-cluster   shared-service-default-worker                            True

1. Mandantenorganisation aktualisieren

Bei diesem Schritt wird die Kubernetes-Version, Add-ons und betriebsbereiten Komponenten in den Clustern der Verwaltungsebene in einer Mandantenorganisation aktualisiert – org-admin-, System- und Servicecluster.

Die Gesamtdauer des Upgrades hängt von der Anzahl der Phasen ab. Das automatische Upgrade der Mandantenorganisation kann zu Unterbrechungen führen und erfordert ein Wartungsfenster.

1.1 Vorbereitung

Eine Anleitung zum Konfigurieren von Wartungsfenstern finden Sie unter Wartungsfenster für das Upgrade der Mandantenorganisation konfigurieren.

Anleitungen zum Initiieren eines Upgrades der Mandantenorganisation sind für die Verwendung von kubectl-CLI-Befehlen oder Infrastructure-as-Code-Befehlen (IaC) verfügbar. Wenn Sie die IaC-Befehle verwenden möchten, müssen Sie IaC zuerst konfigurieren:

Einrichtung von Infrastruktur als Code:
Infrastruktur als Code konfigurieren

Wenn Sie „nomos“ verwenden möchten, um den Status zu prüfen (wie in den IaC-basierten Schritten als Option angegeben), muss das „nomos“-Befehlszeilentool installiert sein. Eine Anleitung zur Installation und Verwendung von „nomos“ finden Sie unter https://cloud.google.com/anthos-config-management/docs/how-to/nomos-command auf einem Computer mit Internetzugang.

IaC

ClusterRoleBinding vor dem Start des Tenant-Organisationsupgrades mit IAC festlegen

Wechseln Sie in das Verzeichnis iac/infrastructure/zonal/zones/ZONE_NAME/{ORG}.
Wechseln Sie in das bereits erstellte IO-Verzeichnis. Wenn das Verzeichnis nicht vorhanden ist, erstellen Sie ein neues Verzeichnis.

Fügen Sie eine YAML-Datei hinzu, um dem IO die Clusterrolle io-organization-admin zuzuweisen. Beispiel:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: iac-binding-$USER-io-organization-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: io-organization-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: USER_EMAIL

Aktualisieren Sie die Datei kustomatization.yaml, um die neu erstellte Datei einzufügen. Wenn die kustomatization.yaml-Datei nicht vorhanden ist, erstellen Sie eine neue Datei:
```
kind: Kustomization
metadata:
  name: org-1-admin-kustomization
resources:
- FILE_NAME.yaml
```
Änderungen in IAC einreichen

kubectl

ClusterRoleBinding vor dem Start des Upgrades der Mandantenorganisation mit kubectl festlegen

Setzen Sie KUBECONFIG auf die kubeconfig-Datei für den Administratorcluster auf Stammebene.
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG`
```

Erstellen Sie die erforderlichen ClusterRoleBindings:

kubectl create clusterrolebinding io-organization-admin --clusterrole=organization-admin --user=USER_EMAIL`

Bevor Sie ein Upgrade von einer früheren Version von Distributed Cloud auf 1.13.x + durchführen, folgen Sie der Anleitung im Runbook BIL-R0014, um manuell eine Rechnung für die Kosten dieses Monats vom Monatsanfang bis zum Anfang des heutigen Datums zu erstellen. Die während des Upgrades der Distributed Cloud-Organisation erstellten Kostendaten gehen verloren.

1.2 Upgrade starten

Das Upgrade der Mandantenorganisation wird auch über IaC ausgelöst, indem das Feld „version“ im entsprechenden OrganizationZonalConfig-Objekt der Organisation in der Zone aktualisiert wird. Hier sind die Details:

Aktualisieren Sie die Version in der YAML-Datei OrganizationZonalConfig.

ORG_NAME=ORG_NAME
ZONE=$(kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get controlplane cp -n mz-system -ojsonpath='{.spec.zone}')
sed -i 's/version: .*$/version: VERSION/' IAC_REPO_PATH/iac/infrastructure/global/orgs/root/${ORG_NAME}-${ZONE}.yaml

Stellen Sie die Dateiänderungen bereit und führen Sie einen Commit durch.
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

Erstellen Sie eine Zusammenführungsanfrage.

git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin ${USERNAME1}-branch

Wenn das Upgrade initiiert wird, wird ein OrganizationUpgrade-Objekt erstellt. Prüfen Sie, ob das OrganizationUpgrade-Objekt im Stamm-Administratorcluster in der Zone erstellt wurde.

kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml --kubeconfig ROOT_ADMIN_KUBECONFIG

Wenn OrganizationUpgrade nicht gefunden wird, folgen Sie dem Runbook IAC-R0001 zur Fehlerbehebung.

1.3 Upgrade

Das Upgrade wird ausgeführt, wenn es einen timeWindow hat, der in das Wartungsfenster fällt, das ein Administratornutzer (auch PA genannt) angibt. So rufen Sie die geplanten timeWindow auf:

kubectl -n gpc-system get organizationupgrade ORG_NAME -o yaml

Hier sehen Sie eine typische Antwort auf den vorherigen Befehl:

apiVersion: upgrade.private.gdc.goog/v1alpha1
kind: OrganizationUpgrade
metadata:
  creationTimestamp: "2022-08-22T01:09:03Z"
  generation: 1
  name: org-1
  namespace: gpc-system
  ownerReferences:
  - apiVersion: resourcemanager.gdc.goog/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: Organization
    name: org-1
    uid: 6998cfc1-bee4-4f6d-baf2-9c0a90ef93bb
  resourceVersion: "1214182"
  uid: 1affc1df-b9ac-4343-8e61-18736781a990
spec:
  currentVersion: 1.8.0-gdch.476
  organizationRef:
    name: org-1
  targetVersion: 1.8.1-gdch.0
  timeWindow:
    end: "2022-08-28T04:00:00Z"
    start: "2022-08-28T00:00:00Z"

Im vorherigen Beispiel liegt der Zeitplan für das Upgrade auf 1.8.1-gdch.0 zwischen "2022-08-28T00:00:00Z" und "2022-08-28T04:00:00Z".

Wenn das Upgrade beginnt, wird ein OrganizationUpgrade-Objekt erstellt, das im vorherigen Beispiel für die Ausgabe als kind: OrganizationUpgrade angezeigt wird.

kind: OrganizationUpgrade

Überwachen Sie den Gesamtstatus des Upgrades mit dem entsprechenden Upgrade-Objekt, indem Sie den Befehl aus Schritt 1 mit -w anhängen. Wenn Sie beispielsweise den Upgradestatus von ORG_NAME kontinuierlich abfragen möchten, führen Sie Folgendes aus:
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml -w
```
Die Phasen des Upgrades und ihr Status können mit den folgenden Befehlen angezeigt werden:
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get -n gpc-system organizationupgrade ORG_NAME -o jsonpath='{.status.conditions}' | \
jq -r '["Stage", "Status", "Reason", "Message"], ["---", "---", "---", "---"], (.[] | [.type, .status, .reason, .message]) | @tsv' | column -ts $'\t'
```
Die Phase Succeeded bezieht sich auf den allgemeinen Upgradestatus. Die Phase Expired gibt an, dass das Upgrade über die ursprünglich geplante Zeit hinausgeht. Alle anderen Phasen beziehen sich auf die Schritte des laufenden Upgrades. Der Status True bezieht sich auf abgeschlossene Schritte und der Status Unknown auf den aktuellen Schritt des Upgrades.

Wenn eine Preflight-Prüfung fehlgeschlagen ist und Sie sicher sind, dass es sich dabei um ein falsch-positives Ergebnis handelt, können Sie die Optionen für die Preflight-Prüfung überschreiben und überspringen:
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-preflight-check=ok
```
Wenn eine Post-Check-Prüfung fehlgeschlagen ist und Sie sicher sind, dass es sich um ein falsch-positives Ergebnis handelt, können Sie die Postflight-Prüfungen überschreiben und überspringen:
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-postflight-check=ok
```
Wenn IAC zum Aktualisieren der Mandantenorganisation verwendet wurde, der Status organizationupgrade „Erfolgreich“ lautet und Organization für die Mandantenorganisation nicht den Status „Bereit“ hat, wenden Sie den folgenden Workaround an.

Fügen Sie der Organisation die folgende Anmerkung hinzu: configmanagement.gke.io/managed: disabled mit IAC. Der Status von Organization ist „Bereit“.

Das Organisationsupgrade sollte jetzt in die nächste Phase übergehen und der Status für den Dienst oder Knoten sollte „Abgeschlossen“ lauten:

Last Transition Time: 2024-08-27T22:44:09Z
  Message:             observed the following reason: [JobRunning]
  Observed Generation: 614
  Reason:              Complete
  Status:              True
  Type:                service/Node

Es kann bis zu 15 Minuten dauern, bis das Organisationsupgrade fortgesetzt wird.

1.4 Prüfungen nach dem Upgrade

Prüfen Sie das Objekt Organization für die Organisation. Die Bedingung READY muss als True angezeigt werden.
```
kubectl -n gpc-system get organization ORG_NAME
```
Beispielausgabe:
```
NAME   READY
org-1  True
```
Prüfen Sie Organization.Status.Version. Es muss der genaue String der Zielversion angezeigt werden:
```
kubectl -n gpc-system get organization ORG_NAME -o jsonpath='{.status.version}{"\n"}'
```
Beispielausgabe:
```
1.13.3-gdch.5548
```
Wichtig :Wenn Sie ein ungeplantes Update durch die Anmerkung zum Ignorieren eines Wartungsfensters ausgelöst haben, müssen Sie die Anmerkung zurücksetzen, um geplante Zeitfenster zu verwenden.

Machen Sie die Anmerkung rückgängig, um Wartungsfenster zu ignorieren:
```
kubectl annotate organization ORG_NAME -n=gpc-system  \
    "upgrade.private.gdc.goog/ignore-maintenance-window-" \
    --kubeconfig=ROOT_ADMIN_KUBECONFIG
```

Prüfen Sie in der aktualisierten Mandantenorganisation auf Fehler bei Unterkomponenten :

Suchen Sie nach den Unterkomponenten mit dem Status ReconciliationError oder Reconciling. Verweisen Sie die kubeconfig auf ORG_MGMT_API_KUBECONFIG:

export KUBECONFIG=ORG_MGMT_API_KUBECONFIG

echo "Subcomponents with failures"
kubectl get subcomponent -A -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'
echo "Subcomponents still reconciling"
kubectl get subcomponent -A -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "Reconciling") | select( "\(.status)" | contains("PreinstallPending") | not) | "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'

Informationen zu Fehlern finden Sie in den Versionshinweisen und unter Bekannte Probleme. Wenn Sie keine Problemumgehung finden, wenden Sie sich zur Fehlerbehebung an Distributed Cloud.

Wenn die Preflight- oder Postflight-Prüfung übersprungen wurde, entfernen Sie die Anmerkungen nach Abschluss des Upgrades:

Beispiele:

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-preflight-check-

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-postflight-check-

1.5 Nicht geplantes Upgrade starten

Sie können ein sofortiges Upgrade des Mandanten und der Organisation außerhalb eines maintenanceWindow auslösen, wenn Sie einen dringenden Bedarf haben, z. B. einen dringenden Sicherheits-Patch. Dies ist nur in der Mandantenorganisation erforderlich, da die Stammorganisation das Upgrade bereits sofort auslöst.

Führen Sie diesen Befehl mit dem Root-Administrator kubeconfig aus. Die benutzerdefinierte Organisationsressource, die Sie annotieren müssen, ist nur im Root-Admin-Cluster vorhanden. Sie müssen dafür kein Zeitfenster einplanen.

Patchen Sie die Organisation spec/version für die Mandantenorganisation:

export VERSION=$(kubectl get releasemetadata -ojson | jq -r '.items[] | select(.metadata.name | contains("1.13.3")) | .metadata.name')
echo $VERSION

# Example output
# 1.13.3-gdch.5548

kubectl patch -n gpc-system organization ORG_NAME --type='json' \
  -p='[{"op":"replace","path":"/spec/version","value":"'${VERSION}'"}]' \
    --kubeconfig=ROOT_ADMIN_KUBECONFIG

Starten Sie eine sofortige tenant-org upgrade, indem Sie die Annotation ignore-maintenance-window anwenden und organizationupgrade neu starten.

Hinweis :Wenn beim Upgrade ein Fehler auftritt, führen Sie denselben Befehl mehrmals aus.

Überwachen Sie den Status des Upgrades:

# kubectl -n gpc-system get organizationupgrade org-1 -o yaml

Führen Sie Prüfungen nach dem Upgrade durch.
Wenn das dringende Upgrade abgeschlossen ist, können Sie wieder die geplanten Zeitfenster verwenden:
```
kubectl annotate organization ORG_NAME -n=gpc-system  \
      "upgrade.private.gdc.goog/ignore-maintenance-window-" \
      --kubeconfig=ROOT_ADMIN_KUBECONFIG
```
Hinweis :Wenn das DNS-Upgrade fehlschlägt, finden Sie unter DNS R0006 Informationen zur Fehlerbehebung.

2. DNS-Upgrade

2.1 Weiterleitungszonen erstellen

Exportieren Sie kubeconfig für den Root-Administratorcluster:

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

Konfigurieren Sie OCIT_DOMAIN mithilfe einer Forward-Zone. Ersetzen Sie OCIT_DOMAIN durch Ihren OCIT-Domainnamen und die Endpunkte durch die OC DNS-IP-Adressen:

kubectl apply -f - <<EOF
apiVersion: network.private.gdc.goog/v1alpha1
kind: DNSZone
metadata:
  namespace: dns-system
  name: ocit-domain
spec:
  domainName: OCIT_DOMAIN
  forwardingConfig:
    # Set to OC DNS IPs (the AD domain controllers)
    endpoints:
      - 192.0.2.0
      - 192.0.2.1
    replicateToTenantOrg: true
EOF

Die Ausgabe sieht so aus:

dnszone.network.private.gdc.goog/ocit-domain created

Wenn Änderungen nicht übernommen werden, starten Sie das Deployment neu:
```
kubectl rollout restart deployment -n dns-system gpc-coredns-forwarder
```
Diese DNS-Änderung wird auf alle Cluster in GDC übertragen.

Prüfen Sie mit der Stammadministrator-kubeconfig, ob die OCIT-Domainauflösung wie vorgesehen funktioniert:

NAMESERVER=$(kubectl -n dns-system get service gpc-coredns-forwarder-udp | \
  awk '/[0-9]\./ {print $4}')
dig +short @${NAMESERVER} fs.OCIT_DOMAIN

Exportieren Sie kubeconfig für den Administratorcluster der Organisation:
```
export KUBECONFIG=/root/release/org-admin/org-admin-kubeconfig
```

Wenden Sie die kubeconfig-Datei des Organisationsadministrators an und prüfen Sie, ob die OCIT-Domainauflösung wie vorgesehen funktioniert:

NAMESERVER=$(kubectl -n dns-system get service gpc-coredns-infra-forwarder | \
  awk '/[0-9]\./ {print $4}')
dig +short @${NAMESERVER} fs.OCIT_DOMAIN

2.2 Rekursiven Resolver aktivieren

Aktivieren Sie den rekursiven Resolver im Administratorcluster der Organisation nur für v1-Organisationen. Folgen Sie dazu der Anleitung im DNS-R0027-Runbook.

Upgrade der Mandantenorganisation in allen Zonen abschließen

Nachdem ein Upgrade in einer Zone abgeschlossen ist, sollten Sie prüfen, ob die Zone weiterhin ordnungsgemäß funktioniert, bevor Sie mit dem Upgrade der nächsten Zone fortfahren.

Wiederholen Sie die Schritte 1 bis 2 für die Mandantenorganisation in den restlichen Zonen. Wenn für alle Zonen das Upgrade der Mandantenorganisation durchgeführt wurde, fahren Sie mit den nächsten Schritten fort.

3. Globale Ressourcen upgraden

# Annotate appropriate versions for all the operable components.
ORG_NAME=ORG_NAME
MAP=$(kubectl get kubeapiserver ${ORG_NAME}-admin -n ${ORG_NAME} -ojsonpath='{.metadata.annotations}' --kubeconfig ROOT_ADMIN_KUBECONFIG | jq -r 'to_entries | map("\(.key) \(.value)") | .[] | select(startswith("lcm.private.gdc.goog/oc-version-"))')

# Trigger the global resource upgrade on global org admin.
kubectl annotate kubeapiserver global-org-admin -n global-kube-system --overwrite lcm.private.gdc.goog/paused-remote=false --kubeconfig ORG_MGMT_API_KUBECONFIG
kubectl patch kubeapiserver global-org-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"AllowAll"}}' --type=merge --kubeconfig ORG_MGMT_API_KUBECONFIG

Der Vorgang kann einige Minuten dauern. Prüfen Sie mit den folgenden Befehlen, ob die globalen Ressourcen aktualisiert wurden. Der Befehl sollte keinen Fehler melden.

# Verify that Components are all successfully rolled out on global org admin.
echo "${MAP}" | while read KV; do
   SPLIT=(${KV}); VALUE=${SPLIT[1]}; OC=$(echo ${VALUE} | cut -d- -f1)
   [[ -n ${OC} ]] || continue
   ROLLOUT=$(kubectl get componentrollout ${OC} -n global-kube-system -o json --ignore-not-found --kubeconfig ORG_MGMT_API_KUBECONFIG)
   [[ -n ${ROLLOUT} ]] || continue
   if [[ $(echo ${ROLLOUT} | jq -r '.spec.componentRef.name') != ${VALUE} ]] ; then
      echo "${OC} rollout trigger failed"; continue
   fi
   if [[ $(echo ${ROLLOUT} | jq -r '.status.allSubcomponentsReady') != 'true' ]] ; then
      echo "${OC} rollout completion failed. Use 'kubectl describe componentrollout ${OC} -n global-kube-system --kubeconfig ORG_MGMT_API_KUBECONFIG' to check for error messages."
   fi
done && echo "Global component rollout check finished."

4. Tenable SC upgraden

GDCH-Doctor ausführen, um festzustellen, ob ein Upgrade erforderlich ist –

  gdcloud system doctor diagnose instance --include-ocs=vuln --root-admin-kubeconfig=${ROOT_ADMIN_CLUSTER_KUBECONFIG:?}

Wenn der tenable_sc_upgrade_readiness-Validator fehlschlägt, muss das Bild aktualisiert werden. Führen Sie dazu die folgenden Schritte aus, um Tenable SC in der OI-Services-Organisation zu aktualisieren:

Rufen Sie den Namen der virtuellen Maschine ab:

 VIRTUAL_MACHINE_NAME=$(kubectl --kubeconfig ${OI_SERVICES_ORG_INFRA_KUBECONFIG:?} get virtualmachine -n tenablesc-system -o custom-columns=NAME:.metadata.name | sort -r -k 1 | head -1)

Markieren Sie die runningState der virtuellen Maschine als Stopped:

 kubectl --kubeconfig ${OI_SERVICES_ORG_MGMT_KUBECONFIG:?} patch virtualmachines.virtualmachine.gdc.goog ${VIRTUAL_MACHINE_NAME:?} -n tenablesc-system --type merge --patch '{"spec":{"runningState":"Stopped"}}'

Deinstallieren Sie das vorhandene Helm-Diagramm für die VM:

 VIRTUAL_MACHINE_NAME=$(kubectl --kubeconfig ${OI_SERVICES_ORG_INFRA_KUBECONFIG:?} get virtualmachine -n tenablesc-system -o custom-columns=NAME:.metadata.name | sort -r -k 1 | head -1)
 kubectl --kubeconfig ${OI_SERVICES_ORG_MGMT_KUBECONFIG:?} patch virtualmachines.virtualmachine.gdc.goog ${VIRTUAL_MACHINE_NAME:?} -n tenablesc-system --type merge --patch '{"spec":{"runningState":"Stopped"}}'
 helm uninstall tenablesc-vms -n tenablesc-system --kubeconfig ${ORG_MGMT_KUBECONFIG:?}

Führen Sie eine Neuinstallation von Tenable SC gemäß Tenable.SC installieren durch.

Bereinigung nach dem Upgrade

Entfernen Sie die ClusterRoleBinding-Ressourcen, die im Abschnitt Identity and Access Management erstellt wurden.

Wartungsfenster für das Upgrade von Mandantenorganisationen konfigurieren

Wenn Sie eine Mandantenorganisation (Org) upgraden möchten, müssen Sie die richtigen Betrachter- und Administratorrollen haben, wie auf den Seiten Beschreibungen vordefinierter Rollen und Rollendefinitionen für Projekte beschrieben. Dies ist erforderlich, um sich in der kubectl-Befehlszeilenschnittstelle (Command-Line Interface, CLI) und der Console-Benutzeroberfläche (User Interface, UI) anzumelden. Wenn Sie diese nicht haben, folgen Sie der Anleitung auf der Seite Zugriff auf Projektressourcen gewähren, um sie zu gewähren oder zu beantragen.

Sie benötigen die erforderlichen Rollen, um Ihr Wartungsfenster zu konfigurieren. Prüfen Sie, ob Ihnen die folgenden vordefinierten Rollen zugewiesen sind:

Administrator für Organisationsupgrades
Betrachter für Organisationsupgrades Hinweis: Das Upgrade einer Mandantenorganisation auf eine Nebenversion, die niedriger als die Root-Organisation ist, wird nicht unterstützt.

Standardmäßig gibt es eine MaintenanceWindow für Nebenversionsupgrades und eine MaintenanceWindow für Patchupgrades. Bei Nebenversions-Upgrades wird die Funktion verbessert oder es werden Änderungen an der vorherigen Version vorgenommen, z. B. um Fehler zu beheben. Patch-Upgrades beheben bestimmte Probleme oder Sicherheitslücken. Konfigurieren Sie den Standard-Patch MaintenanceWindow, um Patch-Upgrades gemäß einem definierten Zeitplan zu starten.

Verwenden Sie zum Konfigurieren des Wartungszeitraums die CLI und kubectl-Befehle, um die Felder RRULE und TimeWindow der MaintenanceWindow-Ressourcen zu ändern. Dadurch werden Ihre Upgrades geplant. Informationen zu RRULE finden Sie unter https://pkg.go.dev/github.com/teambition/rrule-go.

Wenn Sie die kubectl-CLI-Befehle verwenden möchten, klicken Sie auf den Tab kubectl. Wenn Sie eine Anleitung für die Benutzeroberfläche sehen möchten, klicken Sie auf den Tab „Console“.

Console

Melden Sie sich in der Organisations-UI an.
Bearbeiten Sie den Zeitplan für das Wartungsfenster. Rufen Sie den Tab Wartung auf und klicken Sie auf Bearbeiten.

Wichtig :Wenn Sie ein administrativer Nutzer sind, benötigen Sie die Rolle Administrator für Organisationsupgrades, um die MaintenanceWindow zu bearbeiten, und die Rolle Betrachter für Organisationsupgrades, um geplante Upgrades anzusehen:

Abbildung 1. Wartungsfenster
Der Bildschirm Wartungsfenster bearbeiten wird geöffnet. Verwenden Sie das Fenster, um die Zeitfenster Patch und Minor neu zu konfigurieren:

Abbildung 2. Patch- und Nebenupdates neu konfigurieren

Hinweis :Das Feld Wiederholung für Nebenversion gibt die erste, zweite, dritte, vierte oder letzte Instanz des angegebenen Tages an. Wenn ein Monat nur vier Instanzen eines bestimmten Tages hat, sind der letzte und der vierte Tag gleichwertig.
Geben Sie die Patch-Version, die Startzeit und die Länge sowie den Wochentag an oder bearbeiten Sie sie.

Bearbeiten Sie die Nebenversionsnummer, Startzeit, Länge, Wiederholung und den Tag.

Abbildung 3. Neukonfiguration speichern
Klicken Sie auf Speichern, um die Änderungen zu übernehmen.
Wenn sich die gespeicherten Änderungen auf die Wiederholung auswirken, z. B. wenn Sie den Wochentag oder den Monat geändert haben, wird ein Dialogfeld angezeigt. Klicken Sie zum Bestätigen der Änderungen auf WEITER.

Abbildung 4. Klicken Sie auf „Weiter“.
Das folgende Beispiel zeigt die aktualisierten geplanten Upgrades basierend auf Ihren Konfigurationsänderungen. Beachten Sie den Link Überspringen neben jedem ausstehenden Status. Damit können Sie ein geplantes ausstehendes Upgrade überspringen.

Abbildung 5. Ansicht von Zeitplan-Upgrades mit einer Überspringen-Option für jedes

kubectl

Melden Sie sich in der kubectl-Befehlszeile an. Sie finden diese Anleitung auf dem Tab „CLI“. Prüfen Sie, ob Sie den richtigen Zugriff auf den Admin-Cluster der Organisation haben, bevor Sie fortfahren.

Sie können drei Felder in der MaintenanceWindow ändern, um die timeWindow zu konfigurieren, in der das Upgrade der Mandantenorganisation erfolgt. Die folgenden Befehle zeigen eine Änderung des Wartungsfensters für Patch-Upgrades. Die Vorgehensweise bei Nebenversionsupgrades ist ähnlich.

# 1. The first change is to the RRULE
# For patch-upgrades to happen, for example, every Thursday instead of Sunday:
kubectl patch -n gpc-system maintenancewindow patch-upgrade \
  --type='json' \
  -p='[{"op":"replace","path":"/spec/recurrence","value":"FREQ=WEEKLY;BYDAY=TH"}]'

# 2. Modify the start time of the upgrade in UTC.
export S_TIME = 2022-04-03T04:00:00Z
kubectl patch -n gpc-system maintenancewindow patch-upgrade \
  --type='json' \
  -p='[{"op":"replace","path":"/spec/timeWindow/start","value":"'${S_TIME}'"}]'

# 3. Modify the end time of the upgrade in UTC.
export E_TIME = 2022-04-03T04:00:00Z
kubectl patch -n gpc-system maintenancewindow patch-upgrade \
  --type='json' \
  -p='[{"op":"replace","path":"/spec/timeWindow/end","value":"'${E_TIME}'"}]'

Die Start- und Endzeit (/spec/timeWindow/start bzw. /spec/timeWindow/end) müssen jeweils ein Datum/Monat/Jahr haben, das in der Vergangenheit liegt. Das Zeitfenster wird anhand der von Ihnen eingegebenen Werte berechnet.

Weisen Sie mindestens die für die einzelnen Upgradetypen angegebene Mindestdauer zu. Sie können einen längeren Zeitraum zuweisen, wie in den folgenden Empfehlungen beschrieben:

Geringfügige Upgrades: Erfordern mindestens 12 Stunden in einem 32‑tägigen rollierenden Zeitfenster.
Patch-Upgrades: Erfordern mindestens 48 Stunden in einem rollierenden Zeitfenster von 32 Tagen mit einem oder mehreren Zeitblöcken. In der Konsole wird zwar ein Mindestzeitfenster von 4 Stunden angezeigt, Google empfiehlt jedoch, für jeden Zeitblock mindestens 6 Stunden einzuplanen.

Wichtig :Das Patch-Upgrade dauert möglicherweise nicht volle 6 Stunden. Google empfiehlt jedoch, diesen Zeitraum einzuplanen, um lange Patch-Prozesse zu berücksichtigen.

Manuelles Upgrade des Infrastrukturkerns der Operations Suite

Dieser Upgradeprozess gilt nur für das Upgrade von Version 1.13.x auf Version 1.14.3.

Achten Sie darauf, dass für alle verwalteten Domain- und lokalen Konten Passwörter aktiviert sind, die nicht abgelaufen sind. Bei Konten, die nicht in gutem Zustand sind, kann es bei diesem Vorgang zu Fehlern kommen.

VM-Checkpoints und Verzeichnissicherungen durchführen

VM-Prüfpunkte erstellen

Öffnen Sie auf dem Host BM01 eine PS-Konsole als Administrator.

Führen Sie den folgenden Befehl für jeden Hyper-V-Host im Cluster aus.

$servername = "<*hyperv-server-name*>"
Get-VM -CimSession $servername  | ForEach-Object {
$myargs = @{
VMName = $_.Name
SnapshotName = "Checkpoint_$($_.Name)_$(Get-Date -Format 'yyyyMMddHHmmss')"
ComputerName = $servername
}
Checkpoint-VM @myargs
}

Lassen Sie das PowerShell-Fenster für die nächsten Schritte geöffnet.

Lange Dateipfade aktivieren

  $path = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
  Set-ItemProperty -Path $path -Name 'LongPathsEnabled' -Value 1

Sichere das Laufwerk „H:\operations_center“. (Diese Aktion unterstützt das Rollback des Upgrades.)
```
  Rename-Item -Path H:\operations_center -NewName operations_center_backup
```
Sicherungskonfigurationsverzeichnisse auf CONFIG1. Diese Sicherung dient als Referenz für die Erstellung der neuen Datei „config.ps1“.
1. Stellen Sie auf dem Host BM01 über das Remote Desktop Protocol (RDP) eine Verbindung zur IP-Adresse der VM CONFIG1 her und melden Sie sich mit einem Systemadministratorkonto an. Beispiel: mstsc /v 192.168.100.99
2. Öffnen Sie eine PS-Konsole mit Als Administrator ausführen.
  - Sicherungsordner erstellen
```
mkdir c:\config1_backup
```
  - Sichere C:\dsc
```
Move-Item -Path "C:\dsc\" -Destination "C:\config1_backup"
```
  - Sicherung von C:\config
```
Move-Item -Path "C:\config\" -Destination "C:\config1_backup"
```
  - Sichern Sie C:\operations_center.
```
Move-Item -Path "C:\release\operations_center\" -Destination "C:\config1_backup"
```
  - Sicherstellen, dass lange Dateipfade aktiviert sind
```
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
Set-ItemProperty -Path $path -Name 'LongPathsEnabled' -Value 1
```

Drittanbieter-Software laden

Führen Sie die Aufgaben in der Drittanbietersoftware aus.

Vorhandene virtuelle Maschinen upgraden

Rufen Sie das Installationsverzeichnis ab.
1. Laden Sie das OIC-Komponentenpaket herunter. Folgen Sie dazu der Anleitung im Abschnitt Dateien herunterladen.
  
  Hinweis :Wenn Ihre Umgebung air-gapped ist, müssen Sie die Datei *.tar.gz auf ein USB-Laufwerk kopieren, um sie zu übertragen.
2. Extrahieren Sie auf dem Host BM01 das Verzeichnis „operations_center“ aus der heruntergeladenen Datei „prod_IT_component_bundle.tar.gz“.
  
  Hinweis :Wenn Sie tar.exe unter Windows ausführen, werden die Dateien in das aktuelle Arbeitsverzeichnis extrahiert. Kopieren Sie die Datei vor dem Extrahieren auf das H-Laufwerk.
```
Set-Location H:
tar -zxvf prod_IT_component_bundle.tar.gz
```
  Durch das Extrahieren der TAR-Datei sollte im Stammverzeichnis von H: ein Ordner release erstellt werden:
3. Verschieben Sie operations_center in das Stammverzeichnis von H:
```
Move-Item -Path H:\release\operations_center -Destination H:\
```
config.ps1 mit standortspezifischen Daten aktualisieren

Die Konfigurationsdatei config.ps1 enthält alle Informationen, die zum Erstellen und Konfigurieren der Operations Suite Infrastructure-Umgebung (OI) erforderlich sind. Um die Konfigurationsdatei zu aktualisieren, müssen Sie alle folgenden Informationen erfassen. Die Sicherung der vorhandenen Datei „config.ps1“ ist eine gute Referenz, um ein unbeabsichtigtes Überschreiben vorhandener Einstellungen zu verhindern. Wichtig: Fahren Sie erst fort, wenn config.ps1 abgeschlossen und korrekt ist.
- Die Netzwerkkonfiguration, die vom occonfigtool-Tool ausgegeben wird, insbesondere die Datei ocinfo.common.opscenter.local.txt. Die in den folgenden Schritten erwähnten Netzwerknamen, z. B. OCCORE-SERVERS, beziehen sich auf die Spalte Name in diesem Dokument.
- Der Domainname und die DNS-Server-IP-Adresse jeder GDC-Zelle, die von diesem OI verwaltet wird. Diese Daten sind in den Ausgaben des Customer Intake Questionnaire (CIQ) verfügbar.
Nehmen Sie alle Änderungen auf dem Host BM01 als Administrator vor.
Kopieren Sie den richtigen Beispielcode für die Konfiguration für den Bereitstellungstyp:
1. Kopieren Sie H:\operations_center\dsc\config.example.ps1 nach H:\operations_center\config\config.ps1.
Überprüfen und aktualisieren Sie die Werte in config.ps1 mit VSCode oder Powershell ISE.
1. Wenn OIC als Multi-Site bereitgestellt wird:
  1. Kommentare mit dem Label ### Multi-Site: suchen
  2. Führen Sie die in den gefundenen Kommentaren beschriebenen Aktionen aus.
2. Aktualisieren Sie HardwareVersion, sofern der Standardwert (3.0) nicht korrekt ist.
3. Aktualisieren Sie PrimarySiteCode, sofern der Standardwert (DC1) nicht korrekt ist.
4. Der Standortcode wird in vielen Namen verwendet. Suchen Sie nach allen Instanzen von DC1 und ersetzen Sie sie durch den richtigen Websitecode. Verwenden Sie die Suche ohne Berücksichtigung der Groß- und Kleinschreibung. Prüfen Sie jede Änderung, da einige möglicherweise nicht erforderlich sind. Wenn der Websitecode beispielsweise AB1 ist, muss der Hostname DC1-DC1 in AB1-DC1 geändert werden, nicht in AB1-AB1.
5. Aktualisieren Sie DnsDomain, wenn die Standardeinstellung nicht korrekt ist. Wenn dieser Wert geändert wird, suchen Sie in der Datei config.ps1 nach opscenter.local und ersetzen Sie alle Vorkommen. Der Standardwert ist an mehreren Stellen fest codiert.
6. Aktualisieren Sie die Objekte in DnsConditionalForwarder mit standortspezifischen Informationen. Es muss mindestens ein Weiterleitungsobjekt vorhanden sein. Unnötige Beispiele entfernen
  
  Dieser Schritt kann in WSL auf CONFIG1 ausgeführt werden, wenn die gdcloud- und kubectl-CLI installiert ist.
  
  So rufen Sie standortspezifische Informationen aus dem Administrator-Root-Cluster ab:
```
export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
kubectl get -n dns-system service gpc-coredns-external-udp \
            -o jsonpath='{.status.loadBalancer.ingress[0].ip}{"\n"}'
```
  1. Domain: Der DNS-Domainname der GDC-Zelle, z. B. dns.delegatedSubdomain in ciq.yaml.
  2. Master: Eine Liste von DNS-Server-IPs (normalerweise nur eine). Suchen Sie im cellcfg nach dem Typ DNSReservation. Wenn die GDC-Zelle bereitgestellt wird, suchen Sie im Namespace dns-system des Root-Administrationsclusters nach der EXTERNAL-IP des gpc-coredns-external-udp-Dienstes und dem FQDN der Zelle bert.sesame.street.
  3. Bei Bereitstellungen mit mehreren Standorten gibt es ein Hashtable-Objekt pro Zelle.
7. Ändern Sie nicht den Inhalt der Objekte Users, Groups und GroupPolicy.
8. Aktualisieren Sie DNSServers, sodass sie die beiden IP-Adressen enthält, die den primären und sekundären Domaincontrollern zugewiesen sind, z. B. <SITE>-DC1 und <SITE>-DC2.
9. Aktualisieren Sie NTPServers auf eine Liste der SyncServer-IP-Adressen aus den benutzerdefinierten TimeServer-Ressourcen des Root-Administrators. Sie können diese IP-Adressen mit dem folgenden Befehl abrufen:
```
kubectl get timeserver -A -o json | jq '.items[].address'
```
  Sie müssen diese IP-Adressen in NTPServers formatieren, wie im folgenden Beispiel gezeigt:
```
NtpServers = @(
  '10.251.80.2',
  '10.251.80.3',
  '10.251.80.4',
  '10.251.80.5'
)
```
10. Aktualisieren Sie bei Bedarf den Standardwert für SubnetPrefix, also 24, mit dem vom Kunden bereitgestellten Subnetzpräfixwert für das OCCORE-SERVERS-Subnetz.
11. Aktualisieren Sie den Standardwert von DefaultGateway mit dem vom Kunden bereitgestellten Standardgateway für das OCCORE-SERVERS-Subnetz.
12. Suchen Sie den Standardwert für WorkstationCider und aktualisieren Sie ihn mit dem vom Kunden angegebenen Wert für das Subnetz OC-WORKSTATIONS in IPv4-CIDR-Notation.
13. Aktualisieren Sie den Wert WorkstationAllowRemote auf $true, wenn der Kunde den Remotezugriff auf seine Arbeitsstationen zugelassen hat.
14. Suchen Sie nach dem Beispiel-Subnetzpräfix 172.21.0. und ersetzen Sie es durch das vom Kunden bereitgestellte Subnetzpräfix OCCORE-SERVERS.
15. Suchen Sie nach dem Beispiel-Subnetzpräfix 172.21.2. und ersetzen Sie es durch das vom Kunden bereitgestellte Subnetzpräfix OCCORE-JUMPHOSTS.
16. Suchen Sie das Beispiel-Subnetzpräfix 172.21.32. und ersetzen Sie es durch das vom Kunden bereitgestellte Subnetzpräfix OC-WORKSTATIONS.
17. Suchen Sie die Beispiel-Tagesbotschaft legalnoticecaption mit dem Wert Pref caption und ersetzen Sie sie durch die vom Kunden bereitgestellte Bildunterschrift.
18. Suchen Sie den Beispielwert für die Tagesbotschaft legalnoticetext von Pref text und ersetzen Sie ihn durch den vom Kunden bereitgestellten Text.
19. Prüfen Sie jedes „node“-Objekt und aktualisieren Sie es bei Bedarf.
  1. NodeName – Prüfen Sie, ob der Hostname korrekt ist. Einige Namen werden an vielen Stellen verwendet, z. B. für Domaincontroller. Wenn Sie hier einen Namen ändern, prüfen Sie, ob er auch an anderer Stelle in der Konfiguration geändert werden muss.
  2. IPv4Addr: Das muss die IP-Adresse des Hosts sein. Das letzte Oktett kann in der Regel so belassen werden. Einige davon wurden möglicherweise bei der Suche und dem Ersetzen im Netzwerk in den vorherigen Schritten aktualisiert.
  3. HyperVHost: Dieser Wert muss die IP-Adresse des Hyper-V-Servers sein, auf dem diese VM gehostet wird. Die IP-Adresse für jeden BM??-Server finden Sie im Abschnitt „Hyper-V Servers“ der Konfiguration. Ändern Sie die Hyper-V-Hostzuweisung in diesem Feld nicht, da nicht alle Hyper-V-Hosts jeden VM-Typ unterstützen. Ändern Sie nur den Hyper-V-Hostnamen in die entsprechende IP-Adresse.
20. Prüfen Sie die Details der zweiten Netzwerkschnittstelle auf allen Knoten mit Role=jumphost. Verwenden Sie für diese Schnittstelle die Subnetzdetails von OCCORE-JUMPHOSTS. Prüfen Sie:
  1. JumphostIPv4Cidr
  2. JumphostDefaultGateway
21. Aktualisieren Sie die ADFS-spezifische Stanza auf dem Knoten, auf dem Role=adfs.
  
  Warnung :Bearbeiten Sie KEINEN Teil der ADFS-Konfiguration, es sei denn, Sie werden dazu aufgefordert. Bei einem Upgrade bleibt die vorhandene ADFS-Konfiguration erhalten.
  1. Suchen Sie die Zeile Name = 'SplunkTrust' # Must be unique to the farm. Append "Trust".
  2. Ersetzen Sie die drei Vorkommen von opscenter.local nach dieser Zeile durch Ihre DNS-Domain.
22. Aktualisieren Sie die DHCP-Bereiche nach Bedarf, damit sie dem IP-Plan des Kunden entsprechen. Prüfen Sie für jeden Bereich, ob die folgenden Werte korrekt sind. Die Namen der Bereiche stimmen mit den Namen im ocinfo.common.opscenter.local.txt-Netzwerkplan überein. Verwenden Sie daher Folgendes für die Validierung:
  1. ScopeId
  2. IpStartRange
  3. IpEndRange
  4. Router
  5. SubnetMask
23. Prüfen Sie, ob die Werte mit den Werten in der gesicherten Datei „config1.ps1“ übereinstimmen.
24. Speichern Sie die Datei.

CONFIG1 – VM-Vorbereitung

Die Vorbereitung von CONFIG1 erfolgt auf BM01. Alle anderen Upgrades erfolgen, während Sie auf der CONFIG1-VM angemeldet sind.

Kopieren Sie das Verzeichnis „operations_center“ auf die CONFIG1-VM.
1. Öffnen Sie auf dem Host BM01 eine PS-Konsole als Administrator.
2. Kopieren Sie operations_center, um die für die VM CONFIG1 erforderlichen Dateien bereitzustellen.
  
  Hinweis :Copy-ConfigHostFiles.ps1 wird hier nicht verwendet, da die Umgebung betriebsbereit ist. Durch das Kopieren über SMB können Sie Stunden an Kopierzeit sparen.
```
# Change name to match your config host
$config = "DC1-CONFIG1"
# Stage files for CONFIG1 VM
Copy-Item  -Path H:\operations_center -Destination "\\$config\c$\" -Recurse -Force
```
3. Hyper-V-Zeitsynchronisierung deaktivieren
  1. Melden Sie sich als Administrator auf dem BM01-Host an.
  2. Öffnen Sie PowerShell unter Windows als Administrator und führen Sie den folgenden Befehl aus:
  Wichtig :Ersetzen Sie im nächsten Code-Snippet <var>config1_vm_name</var> durch den Namen der CONFIG1-VM, z. B. DC1-CONFIG1.
```
# Disabling Hyper-V Time Sync
Disable-VMIntegrationService -VMName `<SITE>-CONFIG1` -Name 'Time Synchronization'
```
4. CONFIG1 VM-Vorbereitung und ‑Validierung
  1. Melden Sie sich auf dem Host BM01 mit Ihrem -SA-Konto in der VM CONFIG1 an. Stellen Sie über Remote Desktop (RDP) eine Verbindung zur IP-Adresse der VM her. Beispiel: mstsc /v 192.168.100.99
  2. Öffnen Sie ein PowerShell-Fenster über das Menü „Als anderer Nutzer ausführen“, um es als Marvin-Nutzer auszuführen.
  3. Starten Sie im neuen PowerShell-Fenster eine administrative Sitzung:
```
Start -Verb runas -FilePath powershell.exe
```
    Schließen Sie das vorherige PowerShell-Fenster und lassen Sie das Administratorfenster geöffnet.
  4. Prüfen, ob das administrative PowerShell-Fenster als Marvin ausgeführt wird
```
whoami
```
  5. Stellen Sie die Dateien bereit, die vom BM01-Host bereitgestellt wurden.
```
Move-Item -Path c:\operations_center -Destination c:\release
C:\release\operations_center\dsc\Initialize-ConfigHostFiles.ps1
```
  6. Prüfen Sie, ob c:\dsc und c:\config vorhanden sind.
  7. Anmeldedaten- und Zertifikatsdateien aus der Sicherung kopieren
```
Copy-Item -Path "C:\config1_backup\config\creds\" -Destination "C:\config\creds\" -Recurse
Copy-Item -Path "C:\config1_backup\config\certs\" -Destination "C:\config\certs\" -Recurse
```
  8. MECM-Daten erstellen, die zum Kompilieren von MOFs erforderlich sind
```
C:\dsc\Build-MecmFiles.ps1
```
  9. Prüfen Sie, ob die Build-Umgebung bereit ist, indem Sie Build-Mof.ps1 ausführen. Dadurch werden MOF-Dateien für alle OI-Maschinen generiert.
```
C:\dsc\Build-Mof.ps1
```
5. Anmeldedatenvariablen einfügen
  
  Diese Variablen werden während des gesamten Upgrade-Prozesses verwendet. Geben Sie die Werte einmal im als Administrator geöffneten PowerShell-Fenster von Marvin ein.
```
. 'c:\config\config.ps1'

$da_creds = (Get-Credential -Message "Provide domain admin credentials")
$sa_creds = (Get-Credential -Message "Provide system admin credentials")

$sa_args = @{
Credential = $sa_creds
SetLcm = $true
RemoveExisting = $true
CopyModules = $true
}

$da_args = @{
Credential = $da_creds
SetLcm = $true
RemoveExisting = $true
CopyModules = $true
}
```
6. Prüfen Sie, ob DSC ausgeführt wird und die Server erreichbar sind.
```
$role = 'domain_controller'
$ca = 'ca_root'
$dcs = $config.AllNodes | Where-Object {$_.role -eq $role}
$non_dcs = $config.AllNodes | Where-Object {$_.role -ne $role -and $_.role -ne $ca -and $_.NodeName -ne "*"}

$dcs | ForEach-Object {
$session = New-CimSession -ComputerName $_.NodeName -Credential $da_creds
Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState}

$non_dcs | ForEach-Object {
Write-Output "Checking $($_.NodeName)"
$session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState | ft -AutoSize}
```
  Hinweis :Bei einigen Knoten wird möglicherweise der Status Failure angezeigt oder der Fehler The Consistency Check or Pull cmdlet is in progress ausgegeben. Das ist in Ordnung, solange der Knoten erreichbar ist.

Verbindungsprobleme beheben

Wenn New-CimSession fehlschlägt, prüfen Sie, ob der Wert von NodeName in config.ps1 korrekt ist. Prüfen Sie außerdem, ob der Server online und erreichbar ist.

Der Fehler beginnt mit Get-CimSession: WinRM cannot process the request.

Domänencontroller aktualisieren

Aktualisieren Sie den primären Domaincontroller, während Sie in CONFIG1 angemeldet sind.

Variablen einfügen, alte Gruppenrichtlinienobjekte entfernen und neue Gruppenrichtlinienobjekte verknüpfen
```
$dc2 = $dcs | Where-Object {$_.NodeName -like "*-DC2"}
$dc1 = $dcs | Where-Object {$_.NodeName -like "*-DC1"}

Invoke-Command -Computername $dc1.NodeName -Credential $da_creds -ScriptBlock {
Remove-DscConfigurationDocument -Stage Current,Pending,Previous
get-gpo -All | Where-Object { $_.DisplayName -like "OIC*" } | Remove-GPO
get-gpo -All | Where-Object { $_.DisplayName -like "SITE*" -and $_.DisplayName -notlike "*SCCM*" } | Remove-GPO
Get-Item "C:\config\domain_controller\oic_gpos"| Remove-Item -Recurse -Force
Get-Item "C:\config\domain_controller\site_gpo*"| Remove-Item -Recurse -Force
}
```
Verknüpfung von Gruppenrichtlinienobjekten aufheben Sie werden am Ende des Upgrades verknüpft.
```
$gpolinks = (Get-Content C:\dsc\data\GpoLinkMapping.yaml -Raw).Replace("LinkEnabled: 'Yes'", "LinkEnabled: 'No'")
$gpolinks | Out-File C:\dsc\data\GpoLinkMapping.yaml -Force
```
Führen Sie ein Upgrade des primären Domaincontrollers durch.
```
.\Update-RemoteHost.ps1 @da_args -ComputerName $DC1.NodeName
```
Hinweis:Copy-Item : An item with the specified name already exists.-Fehler sind während Installing PowerShell modules on host zu erwarten und können bei Knotenaktualisierungen ignoriert werden.
Warnung:Es wurde ein Problem gefunden, das sich aufgrund von Einschränkungen der Pfadlänge auf das Kopieren von Dateien auf DCs auswirkt. Wenn während „Update-RemoteHost“ ein Fehler wie a file that already exists on the target destination während Copying files for the ... role to host auftritt, führen Sie diese Befehle aus. Andernfalls fahren Sie mit dem nächsten Schritt fort.
```
New-PSDrive -Name DC1 -PsProvider FileSystem -Root "\\$($DC1.NodeName)\c$" -Credential $da_creds
Invoke-Command -ComputerName $DC1.NodeName -Credential $da_creds -Scriptblock {Remove-DscConfigurationDocument -Stage Current,Pending}
Remove-Item -Path DC1:\config\domain_controller\site_gpos -Recurse -Force
Remove-Item -Path DC1:\config\domain_controller\site_gpos_source -Recurse -Force
Copy-Item -Path C:\config\domain_controller\ -Destination DC1:\config\ -Verbose -Force -Recurse
C:\dsc\Build-Mof.ps1 -Computername $DC1.NodeName
Start-DscConfiguration -ComputerName $DC1.NodeName -Path 'c:\config\mofs' -Credential $da_creds -Verbose -Wait -Force
Remove-PsDrive -Name DC1
```
1. Zeitsynchronisierung mit dem SyncServer validieren
2. Melden Sie sich über RDP als Domainadministrator bei DC1 an.
  1. Öffnen Sie ein Powershell-Fenster als Administrator.
  2. Führen Sie den folgenden Befehl aus, um die Zeitkonfiguration zu validieren.
```
w32tm /query /status /verbose
```
Wichtig :Achten Sie darauf, dass Last Sync Error: 0 ist und Source mit einer der NtpServers-IP-Adressen übereinstimmt, die in der Anleitung NTP-Server aktualisieren konfiguriert sind.
1. Führen Sie die folgenden Befehle aus, um die Zeitsynchronisierung zu testen:
```
 # Testing time resyncronization
 w32tm /resync
```
```
 # Desired output
 Sending resync command to local computer
 The command completed successfully.
```
2. Prüfen Sie noch einmal, ob die Zeitkonfiguration korrekt ist und keine Fehler enthält.
  
  Wichtig :Achten Sie darauf, dass Last Sync Error: 0 ist und dass Time to Last Good Sync Time: aktualisiert wurde. Das sollte weniger als eine Minute dauern, wenn Sie den Befehl z. B. direkt nach der Synchronisierung ausgeführt haben.
```
 w32tm /query /status /verbose
```
  Warnung :Wenn Fehler erkannt werden oder w32tm /resync fehlschlägt, HALTEN SIE AN. Eskaliere das Problem an das OI-Engineering-Team, bevor du fortfährst, da ein hohes Risiko besteht, dass die OI-Bereitstellung blockiert wird, wenn die Zeitdienste nicht voll funktionsfähig sind.
Führen Sie ein Upgrade des zweiten Domaincontrollers durch.
1. Verwenden Sie das vorhandene PowerShell-Fenster CONFIG1, um das folgende Skript auszuführen.
```
.\Update-RemoteHost.ps1 @da_args -ComputerName $dc2.NodeName
```

Active Directory-Replikation validieren

Sobald der zweite DC betriebsbereit ist, führen Sie die folgenden Befehle auf einem der Domaincontroller aus, um die Active Directory-Replikation zu prüfen:

repadmin /replsummary

Die Ausgabe muss in etwa so aussehen:

PS C:\Users\Administrator.OpsCenter> repadmin /replsummary
Replication Summary Start Time: 2023-11-29 19:16:59

Beginning data collection for replication summary, this may take awhile:
......

Source DSA          largest delta    fails/total %%   error
OC1-DC1                   01m:49s    0 /  5    0

Destination DSA     largest delta    fails/total %%   error
OC1-DC2                   01m:49s    0 /  5    0

Upgrade von CA-ISSUING1 und CA-WEB durchführen

Verwenden Sie das vorhandene PowerShell-Terminal auf CONFIG1, um CA-ISSUING1 zu aktualisieren.

  $ca_iss = $config.AllNodes | Where-Object {$_.role -eq "ca_issuing"}
  c:\dsc\Update-RemoteHost.ps1 @sa_args -ComputerName $ca_iss.NodeName

Verwenden Sie das vorhandene PowerShell-Terminal auf CONFIG1, um CA-WEB zu aktualisieren.

  $ca_web = $config.AllNodes | Where-Object {$_.role -eq "ca_web"}
  c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $ca_web.NodeName

Upgrade validieren

  $ca_iss,$ca_web | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Upgrade von CA-ROOT1

Vorhandenes PowerShell-Terminal auf CONFIG1 verwenden

Schalte CA-ROOT1 ein.

  $ca_root = $config.AllNodes | Where-Object {$_.role -eq "ca_root"}
  $session = New-CimSession -ComputerName $ca_root.HyperVHost -Credential $sa_creds
  Start-VM -CimSession $session  -Name $ca_root.NodeName

CA-ROOT1 aktualisieren.
```
  $caroot_cred = Get-GeccoCredential -Name "$($ca_root.NodeName)\caadmin" -CredStore "c:\config\creds"
  c:\dsc\Update-RemoteHost.ps1 -Computername $ca_root.NodeName -RemoteHost $ca_root.Ipv4Addr -Credential $caroot_cred
```
Hinweis :Wenn ein Authentifizierungsfehler auftritt, melden Sie sich als caadmin auf dem Server CA-ROOT1 an. Öffnen Sie PowerShell als Administrator. Geben Sie winrm qc ein und drücken Sie die Eingabetaste. Übernehmen Sie alle Änderungen mit einem y. Melden Sie sich von CA-ROOT1 ab und versuchen Sie es noch einmal.
Wenn CA_ROOT1 nach dem vorherigen Skript nicht neu gestartet wurde, starten Sie es manuell neu.
Validieren Sie das Upgrade.
```
  $ca_root | ForEach-Object {
  $session = New-CimSession -ComputerName $_.Ipv4Addr -Credential $caroot_cred
  Get-DscConfigurationStatus -CimSession $session}
```
Wichtig: Verwenden Sie w32tm, um zu prüfen, ob die VM mit dem <SITE>-DC1-Host synchronisiert wird. Führen Sie diesen Befehl in einer administrativen Shell als lokaler Administrator auf CA-ROOT aus.

Prüfen Sie, ob die Einstellung Peer auf <SITE>-DC1.<DNSDOMAIN> und State auf Active festgelegt ist.

Fahren Sie nicht fort, wenn die Zeit nicht richtig synchronisiert wird.

  w32tm /query /peers

  #Peers: 1

  Peer: DC1-DC1.domain.local
  State: Active
  Time Remaining: 31.2997107s
  Mode: 3 (Client)
  Stratum: 1 (primary reference - syncd by radio clock)
  PeerPoll Interval: 6 (64s)
  HostPoll Interval: 6 (64s)

Schalte das CA-Root aus.

  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Stop-VM -CimSession $session  -Name $ca_root.NodeName

ADFS aktualisieren

Vorhandenes PowerShell-Terminal auf CONFIG1 verwenden

Führen Sie ein Upgrade der ADFS1-VM durch.

  $role = 'adfs'
  $adfs = $config.AllNodes | Where-Object {$_.role -eq $role}

  $adfs | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

  $adfs | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $adfs.NodeName}

1. Validate the upgrade.

  $adfs | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Jumphosts upgraden.

Vorhandenes PowerShell-Terminal auf CONFIG1 verwenden

Erstellen Sie ein Array von Jumphosts.

  $role = 'jumphost'
  $jumps = $config.AllNodes | Where-Object {$_.role -eq $role}

Führen Sie ein Upgrade der Jumphosts durch.

  $jumps | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}

Validieren Sie das Upgrade.

  $jumps | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Dateiserver aktualisieren

Vorhandenes PowerShell-Terminal auf CONFIG1 verwenden

Erstellen Sie ein Array mit den Fileservern.

  $role = 'file'
  $files = $config.AllNodes | Where-Object {$_.role -eq $role}

Führen Sie ein Upgrade der Fileserver durch.

  $files | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}

Validieren Sie das Upgrade.

  $files | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Aktualisieren Sie DHCP-Server.

Vorhandenes PowerShell-Terminal auf CONFIG1 verwenden

DHCP1 aktualisieren.

  $role = 'dhcp_primary'
  $dhcp1 = $config.AllNodes | Where-Object {$_.role -eq $role}
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $dhcp1.NodeName

Validieren Sie das Upgrade.

  $dhcp1 | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

DHCP2 aktualisieren

  $role = 'dhcp_failover'
  $dhcp2 = $config.AllNodes | Where-Object {$_.role -eq $role}
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $dhcp2.NodeName

Validieren Sie das Upgrade.

  $dhcp2 | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Userlock-Server aktualisieren

Vorhandenes PowerShell-Terminal auf CONFIG1 verwenden

Erstellen Sie ein PowerShell-Array mit den Userlock-Servern.

  $role = 'userlock_primary'
  $ulock1 = $config.AllNodes | Where-Object {$_.role -eq $role}
  $role = 'userlock_backup'
  $ulock2 = $config.AllNodes | Where-Object {$_.role -eq $role}

Entfernen Sie Markierungsdateien aus der vorherigen Einrichtung.

  Invoke-Command -ComputerName $ulock1.NodeName -Credential $sa_creds -Scriptblock { Remove-item "c:\config\userlock_primary\ServiceImpersonation.log" }
  Invoke-Command -ComputerName $ulock2.NodeName -Credential $sa_creds -Scriptblock { Remove-item "c:\config\userlock_backup\ServiceImpersonation.log" }

Primären Userlock-Server aktualisieren

  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $ulock1.NodeName

Userlock-Sicherungsserver aktualisieren.

  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $ulock2.NodeName

Bestätigen Sie die Upgrades.

  $ulock1,$ulock2 | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Nessus-Server aktualisieren.

Vorhandenes PowerShell-Terminal auf CONFIG1 verwenden

Erstellen Sie ein PowerShell-Array mit den Nessus-Servern.

  $role = 'nessus_'
  $nessus = $config.AllNodes | Where-Object {$_.role -match $role}

Aktualisieren Sie die Nessus-Server.

  $nessus | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $_.NodeName}

Validieren Sie das Upgrade.

  $nessus | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Führen Sie ein Upgrade der Hyper-V-Server durch.

Vorhandenes PowerShell-Terminal auf CONFIG1 verwenden

Erstellen Sie ein PowerShell-Array mit den Hyper-V-Servern.

  $role = 'hyper_v'
  $hyper = $config.AllNodes | Where-Object {$_.role -eq $role}

Führen Sie ein Upgrade der Hyper-V-Server durch.
```
  $hyper | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}
```
Warnung :Wenn BM01 neu gestartet wird, wird auch CONFIG1 neu gestartet. Sobald verfügbar, melden Sie sich an, öffnen Sie PowerShell als Marvin und führen Sie eine Rechteausweitung durch. Führen Sie dann Schritt Config1 prep 1.e. aus, um Variablen neu zu laden. Starten Sie das Hyper-V-Upgrade noch einmal.

Validieren Sie das Upgrade.

  $hyper | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Toolboxen aktualisieren

Vorhandenes PowerShell-Terminal auf CONFIG1 verwenden

Erstellen Sie ein PowerShell-Array mit den Toolbox-Servern.

  $role = 'toolbox'
  $tools = $config.AllNodes | Where-Object {$_.role -eq $role}

Zusätzliches Laufwerk auf dem Server „TOOLBOX1“ erstellen

  $tools | ForEach-Object {
     if ($_.ExtraDiskSize) {
     Invoke-Command -ComputerName $_.HyperVHost -Credential $sa_creds -ScriptBlock {
        $additional_disk_path = Join-Path -Path $using:_.ExtraDiskFolder -ChildPath "$($using:_.NodeName)-2.vhdx"
        New-VHD -Path $additional_disk_path -Dynamic -SizeBytes $using:_.ExtraDiskSize
        Add-VMHardDiskDrive -VMName $using:_.NodeName -Path $additional_disk_path
        Get-VMHardDiskDrive -VMName $using:_.NodeName | select VMName,ControllerLocation,Path
     }}}

Prüfen Sie, ob in der Ausgabe zwei Laufwerke angezeigt werden, die der VM zugewiesen sind. Beispiel:

  VMName       ControllerLocation Path
  ------       ------------------ ----
  DC1-TOOLBOX1                  0 H:\Hyper-V\Virtual Hard Disks\DC1-TOOLBOX1.vhdx
  DC1-TOOLBOX1                  1 Z:\Hyper-V\Virtual Hard Disks\DC1-TOOLBOX1-2.vhdx

Aktualisieren Sie die Toolbox-Server.

  $tools | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $_.NodeName}

Validieren Sie das Upgrade.

  $tools | ForEach-Object {
  $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
  Get-DscConfigurationStatus -CimSession $session}

Verwenden Sie das vorhandene PowerShell-Terminal auf `CONFIG1`, um das Upgrade zu validieren.

Prüfen Sie, ob DSC fehlerfrei ausgeführt wird.

   $role = 'domain_controller'
   $ca = 'ca_root'
   $dcs = $config.AllNodes | Where-Object {$_.role -eq $role}
   $non_dcs = $config.AllNodes | Where-Object {$_.role -ne $role -and $_.role -ne $ca -and $_.NodeName -ne "*"}

   $dcs | ForEach-Object {
   $session = New-CimSession -ComputerName $_.NodeName -Credential $da_creds
   Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState}

   $non_dcs | ForEach-Object {
   Write-Output "Checking $($_.NodeName)"
   $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
   Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState | ft -AutoSize}

Upgrade von Splunk-VMs durchführen

Richten Sie im PowerShell-Fenster auf CONFIG1 die DSC-Konfiguration ein und führen Sie sie aus:

Geben Sie den Websitecode ein. Beispiel: "DC1"

 $sitecode = Read-Host "Enter your site code"
 Set-Location c:\dsc

Heavy Forwarder konfigurieren:

 $myargs = @{
 Computername = "$sitecode-HEAVYFWD"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Indexer 1 konfigurieren:

 $myargs = @{
 Computername = "$sitecode-INDEXER1"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Indexierungs-Plug-in 2 konfigurieren:

 $myargs = @{
 Computername = "$sitecode-INDEXER2"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Indexer 3 konfigurieren:

 $myargs = @{
 Computername = "$sitecode-INDEXER3"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Managerkonto konfigurieren:

 $myargs = @{
 Computername = "$sitecode-SPLUNKMGR"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Suchkopf konfigurieren:

 $myargs = @{
 Computername = "$sitecode-SEARCHHEAD"
 Credential = $sa_creds
 SetLcm = $true
 RemoveExisting = $true
 }
 .\Update-RemoteHost.ps1 @myargs

Führen Sie im PowerShell-Fenster auf CONFIG1 folgende Schritte aus:

  $servers = @()
  $config.AllNodes | Where-Object {$_.role -match "splunk_"} | Foreach { $servers += $_.NodeName }
  Invoke-Command -ComputerName $servers -Credential $sa_creds -ScriptBlock {Restart-Service -Name 'Splunkd'} -ErrorAction Continue

Folgen Sie SIEM-G0006, um den globalen Pass4SymmKey festzulegen, und SIEM-G0007, um jede Zone in OIC an Splunk anzuhängen.

CONFIG1-Host aktualisieren

Führen Sie im PowerShell-Fenster auf CONFIG1 folgende Schritte aus:

Start-DscConfiguration -ComputerName $env:COMPUTERNAME -Path c:\config\mofs -Verbose -Wait -Force

Wenn der Computer neu gestartet wird, melden Sie sich wieder an und starten Sie PowerShell noch einmal als Marvin. Erhöhen Sie dann die Berechtigungen auf Administrator. Füllen Sie die für die nächsten Abschnitte erforderlichen Variablen aus.
```
Set-Location c:\dsc
. c:\config\config.ps1
$da_creds = (Get-Credential -Message "Provide domain admin credentials")
$sa_creds = (Get-Credential -Message "Provide system admin credentials")
```

Microsoft Configuration Manager (MCM)

Da das Publisher-Verwaltungstool keine aktualisierbare Komponente ist, besteht die einzige Möglichkeit darin, die vorhandenen MCM-Hosts zu löschen und das Publisher-Verwaltungstool neu bereitzustellen.

Prüfen Sie, ob die aktuelle MCM-Software gemäß IT-T0023 aktualisiert wurde.
Das Verfahren für die erneute Bereitstellung wird in IT-R0019 beschrieben.

VM-Prüfpunkte entfernen

Sobald die Upgrades abgeschlossen sind, sollten die Checkpoints entfernt werden. Prüfpunkte können im Laufe der Zeit zu einer übermäßigen Festplattennutzung führen. Behalten Sie sie nur bei, wenn aufgrund eines fehlgeschlagenen Upgrades eine Wiederherstellung auf einen Prüfpunkt erforderlich ist.

Vorhandenes PowerShell-Terminal auf CONFIG1 verwenden

VM-Checkpoints entfernen

  $config.AllNodes | Where-Object {$_.Role -eq "hyper_v"} | Foreach-Object {
  Invoke-Command -ComputerName $_.NodeName -Credential $sa_creds -Scriptblock {
    Get-VM | Get-VMSnapshot | Where-Object {$_.Name -like "Checkpoint_*"} | Remove-VMSnapshot -Verbose
  }}

Gruppenrichtlinienobjekte für die Domain wieder aktivieren

Vorhandenes PowerShell-Terminal auf CONFIG1 verwenden

Konfiguration der Domänencontrollerrolle ändern, um Links in verwalteten GPOs zu aktivieren

  $gpolinks = (Get-Content C:\dsc\data\GpoLinkMapping.yaml -Raw).Replace("LinkEnabled: 'No'", "LinkEnabled: 'Yes'")
  $gpolinks | Out-File C:\dsc\data\GpoLinkMapping.yaml -Force

Aktualisieren Sie den Domaincontroller mit der Rolle „ObjectOwner“:

  c:\dsc\Update-RemoteHost.ps1 -Computername $config.AllNodes.DomainConfig.ObjectOwner -Credential $da_creds

Google-Team kontaktieren

Auf der Seite Support anfordern finden Sie eine Anleitung dazu, wie Sie sich an Google wenden können, um weitere Unterstützung zu erhalten.

Upgrade in einer Multi-Zonen-Bereitstellung durchführen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Vorbereiten

Compliancebericht erstellen

Identity and Access Management

Globale Ressourcenupgrades in allen Zonen pausieren

Globale Stammorganisation aktualisieren

Prüfung vor dem Upgrade

1. Updatepaket herunterladen und kopieren

2. Artifact Registry-Upgrade konfigurieren

Artefakte per Push in die Container Registry übertragen

3. Root-Organisation aktualisieren

3.1 Vor der Umstellung

3.2 Automatisierte Upgrades der Stammorganisation durchführen

3.3 Prüfungen nach dem Upgrade

Upgrade der Stammorganisation in allen Zonen abschließen

4. Globale Ressourcen upgraden

5. Zonenübergreifende Komponentenupgrades

6. Manuelles Upgrade für Anycast-Subnetz

7. Manuelles Upgrade für SyncServer

7.1 SyncServer-Upgrade

Globale Mandantenorganisation upgraden

Prüfung vor dem Upgrade

1. Mandantenorganisation aktualisieren

1.1 Vorbereitung

IaC

kubectl

1.2 Upgrade starten

1.3 Upgrade

1.4 Prüfungen nach dem Upgrade

1.5 Nicht geplantes Upgrade starten

2. DNS-Upgrade

2.1 Weiterleitungszonen erstellen

2.2 Rekursiven Resolver aktivieren

Upgrade der Mandantenorganisation in allen Zonen abschließen

3. Globale Ressourcen upgraden

4. Tenable SC upgraden

Bereinigung nach dem Upgrade

Wartungsfenster für das Upgrade von Mandantenorganisationen konfigurieren

Console

kubectl

Manuelles Upgrade des Infrastrukturkerns der Operations Suite

VM-Checkpoints und Verzeichnissicherungen durchführen

Drittanbieter-Software laden

Vorhandene virtuelle Maschinen upgraden

CONFIG1 – VM-Vorbereitung

Verbindungsprobleme beheben

Domänencontroller aktualisieren

Upgrade von CA-ISSUING1 und CA-WEB durchführen

Upgrade von CA-ROOT1

ADFS aktualisieren

Jumphosts upgraden.

Dateiserver aktualisieren

Aktualisieren Sie DHCP-Server.

Userlock-Server aktualisieren

Nessus-Server aktualisieren.

Führen Sie ein Upgrade der Hyper-V-Server durch.

Toolboxen aktualisieren

Verwenden Sie das vorhandene PowerShell-Terminal auf CONFIG1, um das Upgrade zu validieren.

Upgrade von Splunk-VMs durchführen

CONFIG1-Host aktualisieren

Microsoft Configuration Manager (MCM)

VM-Prüfpunkte entfernen

Gruppenrichtlinienobjekte für die Domain wieder aktivieren

Google-Team kontaktieren

Upgrade in einer Multi-Zonen-Bereitstellung durchführen

Verwenden Sie das vorhandene PowerShell-Terminal auf `CONFIG1`, um das Upgrade zu validieren.