このページは Cloud Translation API によって翻訳されました。

マルチゾーンデプロイでアップグレードを実行する

マルチゾーンデプロイでは、ゾーンは 1 つずつアップグレードされ、互いに独立しています。ゾーン間のアップグレードのグローバルオーケストレーションはありません。IO は、新しいバージョンにアップグレードする組織のすべてのゾーンでアップグレードを実行する必要があります。そのため、異なるゾーンの組織は、特定の時点で異なるバージョンを使用している可能性があります。

このページで説明するアップグレード順序は、別のゾーンに移動する前に、1 つのゾーンのルート組織とすべてのテナント組織をアップグレードするものです。グローバルリソースは、すべてのゾーンがアップグレードされた後に最後にアップグレードされます。

このページでは、次の種類の情報を提供して、マルチゾーンの Google Distributed Cloud（GDC）エアギャップアップグレードを進める手順について説明します。

必要なアクセス権とその取得方法。
必要なツール。
アップグレードを行う前に必要な手順。
さまざまな Distributed Cloud コンポーネントのアップグレードをどのような順序で実行するか。

次のリストでは、アップグレードの各コンポーネントを定義します。

ターゲットバージョン: すべてのゾーンで同じターゲットバージョンを使用します。

一度に 1 つ: 一度に 1 つのゾーンをアップグレードします。1 つのゾーンでアップグレードがトリガーされる前に、他のゾーンでアップグレードが実行されていないことを確認します。

グローバルリソース: ゾーンごとに 1 つのコピーがあるゾーンリソースとは異なり、グローバル kube-apiserver にデプロイされた Kubernetes リソースとして定義されます。グローバルリソースは異なるライフサイクルに従います。アップグレードは最後に 1 回だけ行う必要があります。

準備

これらの URL は、エアギャップ環境外からアクセスするために提供されています。

アップグレードを開始する前に、次のことを確認してください。

ルート管理クラスタに対して gdcloud auth login を実行して取得した kubeconfig ファイルのパス。

重要: 続行するには、kubeconfig パスが必要です。
新しいリリースアーティファクトがダウンロードされ、マシンに安全に転送されている。アーティファクトをコンテナレジストリに push するの手順に沿って操作します。
手動アップグレードを実行するためのホストマシン。マシンにはルート管理クラスタの kubeconfig ファイルがあります。
アップグレードを開始する前に、アップグレード元のバージョンの既知の問題を回避します。特に 1.13.1 からアップグレードする場合は、次の問題が解決されていることを確認してください。
- デバイスに空き容量がない VM

コンプライアンスレポートを生成する

コンプライアンスレポートには、次の組織が一覧表示されます。

サポートが終了している
重大なセキュリティパッチを適用し忘れる

コンプライアンスレポートの生成は省略可能な手順であり、organization-admin role を持つ認証済みの IO が必要です。レポートを生成するには、次のコマンドを実行します。

  gdcloud system upgrade report-compliance

準備要件の詳細については、前提条件のセクションをご覧ください。

Identity and Access Management

アップグレードを開始する前に、各ゾーンで次の操作を行います。

ルート管理クラスタとすべての組織管理クラスタに対して gdcloud auth login を実行して、kubeconfig ファイルを取得します。
アクセスと権限昇格のプロセス IAM-R0005 ランブックの手順に沿って、以下を追加します。
1. ClusterRoleBinding: 各ゾーンのルート管理クラスタの cluster-admin ClusterRole
2. 組織の管理クラスタ。一時的な管理者アクセス権を取得します。

すべてのゾーンでグローバルリソースのアップグレードを一時停止する

取得した kubeconfig ファイルを使用して、各ゾーンのすべてのグローバルリソースのアップグレードを一時停止します。

# 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

グローバルルート組織をアップグレードする

グローバルルート組織のアップグレードの概要は次のとおりです。

すべてのゾーンでルート組織をアップグレードします。各ゾーンは個別にアップグレードされます。

重要: StorageGrid プライマリゾーンからアップグレードを開始し、デプロイ内の他のすべてのゾーンで繰り返します。この順序は、オブジェクトストレージが正しく機能するために必要です。
現在のゾーンがプライマリゾーンかどうかを確認します。次のコマンドは、プライマリゾーンでは「true」を返し、プライマリ以外のゾーンでは何も返しません。
```
kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
```
クロスゾーン調整が必要なコンポーネントをアップグレードします。
グローバルルート管理者リソースをアップグレードします。

アップグレード前のチェック

ゾーンを一度に 1 つずつアップグレードします。1 つのゾーンで組織のアップグレードを開始する前に、他のすべてのゾーンに接続し、次のコマンドを実行して、すべてのゾーンでコマンドが ready を返すことを確認します。いずれかのゾーンが準備完了でないと報告された場合は、アップグレードに進まないでください。そのゾーンの組織を確認して、問題を診断します。

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. 更新パッケージをダウンロードしてコピーする

手順は次のとおりです。

インターネットにアクセスできるデバイスにアップデートパッケージをダウンロードして、USB ドライブにコピーします。
更新パッケージを USB ドライブからエアギャップ環境にコピーします。

詳細については、Distributed Cloud ディストリビューションの詳細をダウンロードするファイルのダウンロードと、ファイルをエアギャップ環境に転送するために使用するポータブルストレージデバイスに関する情報については、転送のダウンロードをご覧ください。

Google の担当者と協力して、アップグレードがパートナーが運用する Distributed Cloud デプロイ用であるかどうかを判断し、パートナーモデルリリースファイルを使用する必要があるかどうかを判断します。
```
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
```
インターネットにアクセスできるマシンから USB ドライブにアップデートパッケージをダウンロードします。Google の担当者（POC）から提供されたバージョンとダイジェストの詳細を使用します。
1. gcloud auth login を実行して Cloud Storage バケットにアクセスします。
2. --skip-unzip を使用してスクリプトを実行し、更新パッケージとダウンローダスクリプトを現在のディレクトリ（/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. パートナーモデルリリースファイルを使用してアップグレードする場合は、手順に沿って、パートナーモデル配布用のソフトウェアパッケージを準備します。
  
  注: アップグレードにパートナーモデルリリースファイルを使用しない場合は、この手順をスキップします。
ダウンローダースクリプトと gdch ディレクトリの両方を USB ドライブにコピーします。
USB ドライブから OCIT に更新をコピーします。ファイルを /home/download/ などの同様の場所に配置します。

OCIT でこれらの変数を再定義し、更新を抽出します。

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

ダウンローダーは、リリースを gdch/full-release-1.2.0-gdch.243（例: /home/download/gdch/full-release-1.2.0-gdch.243）に解凍します。この変数をフルパスに割り当てます。
```
export ARTIFACTS_ROOT='/home/download/gdch/full-release-RELEASE_VERSION'-gdch.BUILD_NUMBER'
```

2. Artifact Registry のアップグレードを構成する

アップグレードを正常に実行するには、次の操作を行う必要があります。

アーティファクトをコンテナレジストリに push する

KUBECONFIG をルート管理クラスタの kubeconfig ファイルに設定します。
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
```

必要な 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

必要な 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

OCI バンドルを push するために必要な RoleBindings を作成します。

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

出力は次のようになります。

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

Artifact Registry ストレージのサイズを変更するの手順に沿って、次の操作を行います。
1. 管理クラスタの Artifact Registry のストレージ使用量を確認し、push するアーティファクトに十分な容量があることを確認します。
2. 使用可能な容量を増やす必要がある場合は、Artifact Registry ストレージのサイズを変更するの手順に沿って操作します。
Docker 構成を設定します。
```
cp ${ARTIFACTS_ROOT}/docker-credential-gdcloud /usr/bin
```
注: load-oci を実行する前に、このバイナリが配置されていることを常に確認してください。

トラストストアバンドルを信頼するように Docker を構成します。

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

アーティファクトをルート管理クラスタのアーティファクトレジストリに読み込みます。

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

次のように置き換えます。

VERSION: Distributed Cloud のリリースバージョン。例: 1.x.y-gdch.z
KUBECONFIG_PATH: ルート管理クラスタで gdcloud auth login を実行して取得した kubeconfig ファイルのパス。
PACKAGE_VALIDATION_ROOT_CERT_PATH: パッケージ検証ルート証明書のパス。デフォルトのパス ${ARTIFACTS_ROOT}/staging_root_ca_certificate.crt を使用する必要があります。このパスを含めることで、パッケージの検証で使用されるリリースキー証明書が検証されます。

コマンドが成功すると、出力は次の例のようになります。

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

出力がこの例と異なる場合は、次の手順に沿って一般的な問題を解決します。

出力に Package validation root certificate requires upgrade! というメッセージが含まれている場合は、パッケージ検証証明書をローテーションするの手順に沿ってルート証明書をローテーションします。
load-oci が失敗した場合は、オペレーションを再度実行します。エラーが解決しない場合は、このリストに記載されている他の解決策をご確認ください。
出力に Error: unable to create k8sclient: Unauthorized というメッセージが含まれている場合は、再度認証する必要があります。準備手順を繰り返して kubeconfig ファイルを確認するか、コマンド ${ARTIFACTS_ROOT}/gdcloud auth login を実行して load-oci オペレーションを再試行します。
出力に UNAUTHORIZED: unauthorized to access repository というメッセージが含まれている場合は、load-oci コマンドを実行するために必要な権限がありません。このコマンドを実行するために必要なロールを取得するには、この問題をエスカレーションするか、必要なロールを持つユーザーにこのコマンドの実行を依頼してください。

パートナーモデルリリースファイルのみを使用したアップグレードの場合は、手順に沿って、パートナーモデルの配布用のソフトウェアパッケージを読み込みます。
新しいリリースバージョンの ReleaseMetadata オブジェクトがルート管理クラスタにあることを確認します。
```
kubectl get releasemetadata.artifact.private.gdc.goog VERSION
```
VERSION は、Distributed Cloud のリリースバージョンに置き換えます。例: 1.x.y-gdch.z

出力例:
```
NAME             AGE
1.x.y-gdch.z     2m
```
アップグレードするルート組織で使用可能なアップグレードのリストに新しいバージョンが表示されていることを確認します。
```
ROOT_NAME=root
kubectl get organization -n gpc-system ${ROOT_NAME} -ojsonpath='{.status.availableUpgrades}{"\n"}'
```
たとえば、1.x.y-gdch.z の場合、次の出力が想定されます。
```
["1.x.y-gdch.z"]
```

ルート組織が新しいバージョンにアップグレードされると、そのバージョンがテナント組織のアップグレードに利用できるようになります。

3. ルート組織をアップグレードする

3.1. アップグレード前

KUBECONFIG をルート管理クラスタの kubeconfig ファイルに設定します。
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
```

必要な ClusterRoleBindings を作成します。

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

レスポンス True で示されるように、ルート組織が正常な状態であることを確認します。

kubectl get organization -n gpc-system root \
    -ojsonpath='{.status.conditions[?(@.type=="Ready")].status}{"\n"}'

出力例:

True

ランブック HSM-P0003 の手順に沿って、すべての HSM を再起動します。

3.2. ルート組織の自動アップグレードを実行する

アップグレードは IaC プロセスを経る必要があります。アップグレードは、ゾーン内の組織の対応する OrganizationZonalConfig オブジェクトのバージョンフィールドを更新することでトリガーされます。

OrganizationZonalConfig YAML ファイルのバージョンを更新します。ファイルに spec.capacities.workloadServers セクションがある場合は削除します。

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

ファイルの変更をステージングして commit します。
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

マージリクエストを作成します。

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

アップグレードが開始されると、OrganizationUpgrade オブジェクトが作成されます。ルート OrganizationUpgrade オブジェクトがゾーンのルート管理クラスタに作成されたことを確認します。

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

OrganizationUpgrade が見つからない場合は、IAC-R0001 ランブックに沿ってトラブルシューティングを行います。

3.3. アップグレード後のチェック

アップグレードの結果を確認します。
1. ルート組織の Organization オブジェクトを確認します。ステータス条件 READY が True であることを確認します。
```
kubectl -n gpc-system get organization root
```
  出力例:
```
NAME   READY
root   True
```
2. Organization.Status.Version に 1.x.y-gdch.z という文字列が表示されていることを確認します。
```
kubectl -n gpc-system get organization root -o jsonpath='{.status.version}{"\n"}'
```
  検証の出力例:
```
1.13.3-gdch.5548
```

ルート組織でサブコンポーネントの障害を確認します。

ReconciliationError または Reconciling ステータスを示すサブコンポーネントを確認します。kubeconfig を 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)"'

エラーについては、リリースノートと既知の問題で回避策を確認してください。回避策がない場合は、Distributed Cloud にお問い合わせください。

プリフライトチェックまたはポストフライトチェックがスキップされた場合は、アップグレードの完了後にアノテーションを削除します。

例:

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 つのゾーンでアップグレードが完了したら、次のゾーンのアップグレードに進む前に、そのゾーンが引き続き正常に機能していることを確認することをおすすめします。

残りのゾーンのルート組織に対して、手順 1 ～ 3 を繰り返します。すべてのゾーンでルート組織がアップグレードされたら、次の手順に進みます。

4. グローバルリソースをアップグレードする

グローバルリソースは、すべてのゾーンの最も低いバージョンにする必要があります。アンカーゾーンに接続して次のコマンドを実行し、グローバルリソースのアップグレードプロセスを開始します。

# 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

この処理には数分かかる場合があります。次のコマンドを実行して、グローバルリソースのアップグレードが完了したことを確認します。コマンドからエラーが報告されないようにします。

# 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. ゾーン間のコンポーネントアップグレード

GDC マルチゾーンユニバースでは、特定の操作可能なコンポーネントでアップグレードを完了するためにゾーン間の調整が必要です。

この手順では、次の操作可能なコンポーネントがアップグレードされます。

範囲	操作可能なコンポーネント
インフラストラクチャ	IAC
インフラストラクチャ	SIEM

IAC 操作可能なコンポーネントをアップグレードするには、ランブック IAC-R0016 に従います。

SIEM 操作可能コンポーネントをアップグレードするには、ランブック SIEM-G0008 に従います。

6. エニーキャストサブネットの手動アップグレード

次のスクリプトを実行して、グローバルルート API サーバーのエニーキャストサブネットに必要なラベルを追加します。

#!/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 "$@"

スクリプトが正常に実行されたら、回避策が以前に適用されている場合は、手動エニーキャストの回避策を元に戻します。

7. SyncServer の手動アップグレード

この手順では、次の操作可能なコンポーネントがアップグレードされます。

範囲	操作可能なコンポーネント
インフラストラクチャ	NTP

このファームウェアアップグレードは他のステップに依存しておらず、いつでも実行できます。

クラスタには SyncServer が 1 つしかないため、高可用性モードで動作できません。アップグレード中は、SyncServer が一定期間使用できなくなります。クラスタは、精度が低い独自のクロックを使用して時間を維持し続けますが、目立った影響はありません。

時間のずれを防ぐため、このプロセスは一度に完了することをおすすめします（一晩または週末に放置しない）。

7.1. SyncServer のアップグレードプロセス

次のコマンドは、抽出したアップデートパッケージのリリースディレクトリから実行する必要があります。

抽出する最新のファームウェアを見つけます。

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

ファイル名にはファームウェアのバージョンが含まれています。

出力例:

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

ファイル名のみをコピーして、次の変数に割り当てます。
```
export SYNCSERVER_VERSION=syncserver:5.1.2
```

OCI イメージからファームウェアを抽出します。

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

ファームウェアを抽出します。
```
tar -xvzf syncserver_firmware/gdch-syncserver-firmware/syncserver.tar.gz
```
出力ディレクトリに 1 つの *.dat ファイルと 1 つの *updater.zip ファイルが表示されます。
ランブック NTP-P0002 - SyncServer UI にアクセスします。
1. [Help] -> [About] -> [Software Version] に移動します。インストールされているソフトウェアが提供されたファームウェアと同じかそれ以降の場合、ファームウェアを更新する必要はないため、次の手順をスキップできます。
2. SyncServer UI で [Admin] -> [Upgrade] に移動します。Authorization File の syncserver_s650_license.dat と Upgrade File の syncserver_s650_updater.zip をアップロードします。[インストール] をクリックします。

グローバルテナント組織をアップグレードする

グローバルテナント組織のアップグレードには、次の手順が含まれます。

すべてのゾーンでテナント組織をアップグレードします。各ゾーンは個別にアップグレードされます。

重要: StorageGrid プライマリゾーンからアップグレードを開始し、デプロイ内の他のすべてのゾーンで繰り返します。この順序は、オブジェクトストレージが正しく機能するために必要です。
現在のゾーンがプライマリゾーンかどうかを確認します。次のコマンドは、プライマリゾーンでは「true」を返し、プライマリ以外のゾーンでは何も返しません。
```
kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
```
グローバルテナント組織のリソースをアップグレードします。

アップグレード前のチェック

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

すべてのクラスタが実行状態にあり、すべてのノードプールが準備完了状態にあることを確認します。問題がある場合は、アップグレードを開始する前に修正してください。

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. テナント組織をアップグレードする

この手順では、テナント組織（org-admin、システム、サービスクラスタ）の管理プレーンクラスタで、Kubernetes のバージョン、アドオン、操作可能なコンポーネントをアップグレードします。

アップグレードの全体的な所要時間は、アップグレードのステージ数によって異なります。テナント組織の自動アップグレードは中断を伴う可能性があり、メンテナンスの時間枠が必要です。

1.1. 準備

メンテナンスの時間枠を構成するには、テナント組織のアップグレードのメンテナンスの時間枠を構成するをご覧ください。

テナント組織のアップグレードを開始する手順は、kubectl CLI コマンドまたは Infrastructure as Code（IaC）コマンドを使用する場合に提供されます。IaC コマンドを使用するには、まず IaC を構成します。

Infrastructure as Code の設定。
Infrastructure as Code を構成する。

IaC ベースの手順でオプションとして参照されているステータスを確認するために nomos を使用するには、nomos コマンドラインツールがインストールされている必要があります。nomos のインストールと使用方法については、インターネットに接続しているパソコンから https://cloud.google.com/anthos-config-management/docs/how-to/nomos-command にアクセスしてください。

IaC

IAC を使用してテナント組織のアップグレードを開始する前に clusterrolebinding を設定する

iac/infrastructure/zonal/zones/ZONE_NAME/{ORG} ディレクトリに移動します。
すでに作成されている IO ディレクトリに移動します。ディレクトリが存在しない場合は、新しいディレクトリを作成します。

io-organization-admin クラスタロールを IO に割り当てる YAML ファイルを追加します。次に例を示します。

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

kustomatization.yaml を更新して、作成した新しいファイルを含めます。kustomatization.yaml が存在しない場合は、新しいファイルを作成します。
```
kind: Kustomization
metadata:
  name: org-1-admin-kustomization
resources:
- FILE_NAME.yaml
```
IAC で変更を送信する

kubectl

kubectl を使用してテナント組織のアップグレードを開始する前に clusterrolebinding を設定する

KUBECONFIG をルート管理クラスタの kubeconfig ファイルに設定します。
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG`
```

必要な ClusterRoleBindings を作成します。

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

以前のバージョンの Distributed Cloud から 1.13.x 以降にアップグレードする前に、ランブック BIL-R0014 の手順に沿って、今月の初めから今日の日付の初めまでの今月の費用の請求書を手動で生成します。Distributed Cloud 組織のアップグレードプロセスで作成された費用データは失われます。

1.2. アップグレードを開始する

テナント組織のアップグレードは、ゾーン内の組織の対応する OrganizationZonalConfig オブジェクトのバージョンフィールドを更新することで、IaC を介してトリガーすることもできます。詳細は次のとおりです。

OrganizationZonalConfig YAML ファイルのバージョンを更新します。

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

ファイルの変更をステージングして commit します。
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

マージリクエストを作成します。

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

アップグレードが開始されると、OrganizationUpgrade オブジェクトが作成されます。OrganizationUpgrade オブジェクトがゾーンのルート管理クラスタに作成されたことを確認します。

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

OrganizationUpgrade が見つからない場合は、IAC-R0001 ランブックに沿ってトラブルシューティングを行います。

1.3. アップグレード

アップグレードは、管理者ユーザー（PA とも呼ばれます）が指定したメンテナンスの時間枠内の timeWindow がある場合に実行されます。スケジュールされた timeWindow を表示します。

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

上記のコマンドに対する一般的なレスポンスは次のとおりです。

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"

上記の例では、1.8.1-gdch.0 へのアップグレードのスケジュールは "2022-08-28T00:00:00Z" と "2022-08-28T04:00:00Z" の間です。

アップグレードが開始されると、OrganizationUpgrade オブジェクトが作成されます。これは、前述の出力例では kind: OrganizationUpgrade として示されています。

kind: OrganizationUpgrade

対応するアップグレードオブジェクトを使用して、アップグレードの全体的なステータスをモニタリングします。これを行うには、ステップ 1 のコマンドに -w を追加します。たとえば、ORG_NAME のアップグレードステータスを継続的にクエリするには、次のコマンドを実行します。
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml -w
```
アップグレードのステージとそのステータスは、次の方法で確認できます。
```
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'
```
Succeeded ステージは、アップグレードの全体的なステータスを指します。Expired ステージは、アップグレードが元のスケジュール時間を過ぎたことを示すために使用されます。他のすべてのステージは、進行中のアップグレードの手順を指します。ステータス True は完了したステップを指し、ステータス Unknown はアップグレードの現在のステップを指します。

プリフライトチェックが失敗し、このプリフライトチェックの失敗が誤検出であると確信している場合は、プリフライトチェックオプションをオーバーライドしてスキップします。
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-preflight-check=ok
```
ポストチェックが失敗し、その失敗が誤検出であると確信している場合は、ポストフライトチェックをオーバーライドしてスキップします。
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl annotate -n gpc-system organization ORG_NAME \
    upgrade.private.gdc.goog/skip-postflight-check=ok
```
IAC を使用してテナント組織をアップグレードし、organizationupgrade ステータスが「成功」と表示され、テナント組織の Organization が「準備完了」状態でない場合は、次の回避策を適用します。

IAC を使用して、このアノテーション configmanagement.gke.io/managed: disabled を組織に追加します。モニター Organization のステータスが Ready 状態であることを確認します。
組織のアップグレードが次のステージに進み、サービスまたはノードのステータスが完了になります。
```
Last Transition Time: 2024-08-27T22:44:09Z
  Message:             observed the following reason: [JobRunning]
  Observed Generation: 614
  Reason:              Complete
  Status:              True
  Type:                service/Node
```
組織のアップグレードが再開されるまでに 15 分ほどかかることがあります。

1.4. アップグレード後のチェック

組織の Organization オブジェクトを確認します。条件 READY は True と表示される必要があります。
```
kubectl -n gpc-system get organization ORG_NAME
```
出力例:
```
NAME   READY
org-1  True
```
Organization.Status.Version を確認します。ターゲットバージョンの正確な文字列を表示する必要があります。
```
kubectl -n gpc-system get organization ORG_NAME -o jsonpath='{.status.version}{"\n"}'
```
出力例:
```
1.13.3-gdch.5548
```
重要: メンテナンスの時間枠を無視するアノテーションを使用して予定外の更新をトリガーした場合は、予定された時間枠を使用するように元に戻す必要があります。
アノテーションを元に戻して、メンテナンスの時間枠を無視します。
```
kubectl annotate organization ORG_NAME -n=gpc-system  \
    "upgrade.private.gdc.goog/ignore-maintenance-window-" \
    --kubeconfig=ROOT_ADMIN_KUBECONFIG
```

アップグレードされたテナント組織でサブコンポーネントの障害を確認します。

ReconciliationError または Reconciling ステータスを示すサブコンポーネントを確認します。kubeconfig を 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)"'

エラーについては、リリースノートと既知の問題で回避策を確認してください。回避策がない場合は、Distributed Cloud にお問い合わせください。

プリフライトチェックまたはポストフライトチェックがスキップされた場合は、アップグレードの完了後にアノテーションを削除します。

例:

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. 予定外のアップグレードを開始する

緊急のセキュリティパッチの要件など、緊急のニーズがある場合は、maintenanceWindow の外部でテナント組織のアップグレードを即時にトリガーします。ルート組織ではアップグレードが瞬時にトリガーされるため、これはテナント組織でのみ必要です。

このコマンドは、ルート管理者 kubeconfig を使用して実行します。アノテーションを付ける必要がある組織のカスタムリソースは、ルート管理クラスタにのみ存在します。このプロセスの時間枠はスケジュールしません。

テナント組織の組織 spec/version にパッチを適用します。

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

ignore-maintenance-window アノテーションを適用して organizationupgrade を再起動し、瞬時の tenant-org upgrade を開始します。

注: アップグレードでエラーが発生した場合は、同じコマンドを複数回適用します。
アップグレードのステータスをモニタリングします。
```
# kubectl -n gpc-system get organizationupgrade org-1 -o yaml
```
アップグレード後のチェックを実施します。
緊急アップグレードが完了したら、スケジュールされた時間枠の使用に戻ります。
```
kubectl annotate organization ORG_NAME -n=gpc-system  \
      "upgrade.private.gdc.goog/ignore-maintenance-window-" \
      --kubeconfig=ROOT_ADMIN_KUBECONFIG
```
注: DNS のアップグレードが失敗した場合は、DNS R0006 を参照して問題を解決してください。

2. DNS のアップグレード

2.1 転送ゾーンを作成する

ルート管理クラスタの kubeconfig をエクスポートします。
```
export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
```

転送ゾーンを使用して OCIT_DOMAIN を構成します。OCIT_DOMAIN は OCIT ドメイン名に置き換え、エンドポイントは OC DNS IP アドレスに置き換えます。

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

出力は次の例のようになります。

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

変更が適用されない場合は、デプロイを再起動します。
```
kubectl rollout restart deployment -n dns-system gpc-coredns-forwarder
```
この DNS 変更は、GDC 内のすべてのクラスタに伝播されます。

ルート管理者 kubeconfig を使用して、OCIT ドメイン解決が意図したとおりに機能していることを確認します。

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

組織の管理クラスタの kubeconfig をエクスポートします。
```
export KUBECONFIG=/root/release/org-admin/org-admin-kubeconfig
```

組織管理者の kubeconfig を適用し、OCIT ドメイン解決が意図したとおりに機能していることを検証します。

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

2.2 再帰リゾルバを有効にする

DNS-R0027 ランブックの手順に沿って、v1 組織の組織管理クラスタでのみ、再帰リゾルバを有効にします。

すべてのゾーンでテナント組織のアップグレードを完了する

残りのゾーンのテナント組織に対して、手順 1 ～ 2 を繰り返します。すべてのゾーンでテナント組織がアップグレードされたら、次の手順に進みます。

3. グローバルリソースをアップグレードする

# 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

# 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 をアップグレードする

GDCH doctor を実行して、アップグレードが必要かどうかを確認します。

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

tenable_sc_upgrade_readiness バリデータが失敗してイメージのアップグレードが必要になった場合は、次の手順に沿って OI サービス組織で Tenable SC をアップグレードします。

仮想マシン名を取得します。

 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)

仮想マシンの runningState を 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"}}'

VM の既存の Helm チャートをアンインストールします。

 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:?}

Tenable.SC をインストールするに沿って Tenable SC の新規設定を行います。

アップグレード後のクリーンアップ

[Identity and Access Management] セクションで作成した ClusterRoleBinding リソースを削除します。

テナント組織のアップグレードのメンテナンスの時間枠を構成する

テナント組織（組織）をアップグレードするには、kubectl コマンドラインインターフェース（CLI）とコンソールユーザーインターフェース（UI）にログインするために、事前定義ロールの説明とプロジェクトのロール定義のページに記載されているように、適切な閲覧者ロールと管理者ロールが割り当てられていることを確認します。権限がない場合は、プロジェクトリソースへのアクセス権を付与するの手順に沿って、権限を付与するか、権限の付与をリクエストします。

メンテナンスの時間枠を構成するには、必要なロールが必要です。次の事前定義ロールが割り当てられていることを確認します。

組織のアップグレード管理者
組織のアップグレードビューア注: テナント組織をルート組織よりも低いマイナーバージョンにアップグレードすることはできません。

デフォルトでは、マイナーアップグレード用に 1 つの MaintenanceWindow があり、パッチアップグレード用に 1 つの MaintenanceWindow があります。マイナーアップグレードでは、関数が強化されたり、以前のリビジョンから変更が加えられたりします。これは、バグの修正などのパッケージアップグレードです。パッチアップグレードは、特定の問題や脆弱性に対処します。デフォルトのパッチ MaintenanceWindow を構成して、定義されたスケジュールに従ってパッチのアップグレードを開始します。

メンテナンスの時間枠を構成するには、CLI と kubectl コマンドを使用して、MaintenanceWindow リソースの RRULE フィールドと TimeWindow フィールドを変更します。これにより、アップグレードのスケジュールが設定されます。RRULE について詳しくは、https://pkg.go.dev/github.com/teambition/rrule-go をご覧ください。

kubectl CLI コマンドを使用するには、[kubectl] タブをクリックします。UI ベースの手順を表示するには、[コンソール] タブをクリックします。

コンソール

組織 UI にログインします。
メンテナンスの時間枠のスケジュールを編集します。[メンテナンス] タブに移動し、[編集] をクリックします。

重要: 管理ユーザーの場合は、MaintenanceWindow を編集するには 組織アップグレード管理者ロール、スケジュールされたアップグレードを表示するには組織アップグレード閲覧者ロールが必要です。

図 1: メンテナンス時間枠
[メンテナンスの時間枠を編集] 画面が開きます。このウィンドウを使用して、パッチとマイナーのタイムウィンドウを再構成します。

図 2. パッチとマイナーアップデートを再構成する

注: [マイナーバージョン] の [繰り返し] フィールドは、指定した曜日の 1 回目、2 回目、3 回目、4 回目、または最後のインスタンスを示します。特定の曜日が 4 回しかない月の場合、最後と 4 回目は同じです。
[パッチバージョン]、[開始時間]、[長さ]、曜日を指定または編集します。

[マイナーバージョン]、[開始時刻]、[長さ]、[繰り返し]、[曜日] を編集します。

図 3. 再構成を保存する
[保存] をクリックして変更を適用します。
保存した変更が定期的な予定に影響する場合（曜日や月を変更した場合など）、ダイアログが表示されます。変更を確定するには、[続行] をクリックします。

図 4. [続行] をクリックします。
次の例は、構成の変更に基づいて更新されたスケジュール設定されたアップグレードを示しています。保留中のステータスの横に [スキップ] リンクが表示されます。これを使用して、スケジュールされた保留中のアップグレードをスキップします。

図 5. スケジュールされたアップグレードのビュー。各
のスキップオプションが表示されています

kubectl

kubectl CLI にログインします。これらの手順は、[CLI] タブにあります。続行する前に、組織管理クラスタに対する適切なアクセス権があることを確認してください。

MaintenanceWindow の 3 つのフィールドを変更して、テナント組織のアップグレードが行われる timeWindow を構成できます。次のコマンドは、パッチアップグレードのメンテナンスの時間枠の変更を示しています。マイナーアップグレードの変更も同様です。

# 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}'"}]'

開始時刻と終了時刻（それぞれ /spec/timeWindow/start と /spec/timeWindow/end）には、過去に発生した日付/月/年が含まれている必要があります。時間枠は、入力した値に基づいて計算されます。

アップグレードタイプごとに示されている最小期間を少なくとも割り当てます。次の推奨事項に記載されているように、より長い期間を割り当てることができます。

マイナーアップグレード: 32 日間のローリングウィンドウ内で少なくとも 12 時間必要です。
パッチアップグレード: 32 日間のローリングウィンドウ内で 48 時間以上（1 つ以上の時間ブロック）が必要です。コンソールには 4 時間以上の時間枠を指定するように表示されますが、各時間ブロックに 6 時間以上割り当てることをおすすめします。

重要: パッチのアップグレードに 6 時間かからない場合もありますが、長いパッチプロセスを考慮して、この時間枠の割り当てをおすすめします。

Operations Suite Infrastructure Core の手動アップグレード

このアップグレードプロセスは、バージョン 1.13.x から 1.14.3 へのアップグレードにのみ適用されます。

管理対象のドメインアカウントとローカルアカウントがすべて有効になっており、パスワードの有効期限が切れていないことを確認します。アカウントの状態が良好でない場合、このプロセスでエラーが発生する可能性があります。

VM チェックポイントとディレクトリバックアップを実行する

VM チェックポイントを実行します。
1. BM01 ホストで、管理者として PS コンソールを開きます。
2. クラスタ内の各 Hyper-V ホストに対して次のコマンドを実行します。
```
$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
}
```
  次の手順で使用するため、PowerShell ウィンドウは開いたままにしておきます。

長いファイルパスを有効にする

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

H:\operations_center ドライブをバックアップします。（この操作では、アップグレードのロールバックがサポートされます）。
```
  Rename-Item -Path H:\operations_center -NewName operations_center_backup
```
CONFIG1 のバックアップ構成ディレクトリ。（このバックアップは、新しい config.ps1 構成を構築する際の参照として使用されます）。
1. BM01 ホストで、リモートデスクトッププロトコル（RDP）を使用して CONFIG1 VM の IP アドレスに接続し、システム管理者アカウントでサインオンします。例: mstsc /v 192.168.100.99
2. [管理者として実行] を使用して PS コンソールを開きます。
  - バックアップフォルダを作成する
```
mkdir c:\config1_backup
```
  - Backup C:\dsc
```
Move-Item -Path "C:\dsc\" -Destination "C:\config1_backup"
```
  - C:\config をバックアップする
```
Move-Item -Path "C:\config\" -Destination "C:\config1_backup"
```
  - C:\operations_center をバックアップする
```
Move-Item -Path "C:\release\operations_center\" -Destination "C:\config1_backup"
```
  - 長いファイルパスが有効になっていることを確認する
```
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
Set-ItemProperty -Path $path -Name 'LongPathsEnabled' -Value 1
```

サードパーティソフトウェアを読み込む

サードパーティソフトウェアでタスクを実行します。

既存の仮想マシンをアップグレードする

インストールディレクトリを取得します。
1. ファイルのダウンロードセクションの手順に沿って、OIC コンポーネントバンドルをダウンロードします。
  
  注: 環境がエアギャップされている場合は、*.tar.gz ファイルを USB ドライブにコピーして転送する必要があります。
2. BM01 ホストで、ダウンロードした prod_IT_component_bundle.tar.gz から operations_center ディレクトリを抽出します。
  
  注: Windows で tar.exe を実行すると、現在の作業ディレクトリに抽出されます。解凍する前にファイルを H ドライブにコピーします。
```
Set-Location H:
tar -zxvf prod_IT_component_bundle.tar.gz
```
  TAR ファイルを解凍すると、H: のルートに release フォルダが作成されます。
3. operations_center を H: のルートに移動します。
```
Move-Item -Path H:\release\operations_center -Destination H:\
```
サイト固有のデータで config.ps1 を更新する

config.ps1 構成ファイルには、Operations Suite Infrastructure（OI）環境のビルドと構成に必要なすべての情報が含まれています。構成ファイルを更新するには、次の情報をすべて収集する必要があります。既存の config.ps1 のバックアップは、既存の設定が誤って上書きされるのを防ぐための参考資料として役立ちます。重要: config.ps1 が完了し、正しいことを確認するまで、続行しないでください。
- occonfigtool ツールのネットワーク構成出力（特に ocinfo.common.opscenter.local.txt ファイル）。以降の手順で参照するネットワーク名（OCCORE-SERVERS など）は、そのドキュメントの Name 列を参照しています。
- この OI が管理するすべての GDC セルのドメイン名と DNS サーバーの IP アドレス。このデータは、お客様情報アンケート（CIQ）の出力で確認できます。
BM01 ホストで Administrator としてすべての変更を行います。
デプロイタイプに適した構成例のコードをコピーします。
1. H:\operations_center\dsc\config.example.ps1 を H:\operations_center\config\config.ps1 にコピーします。
VSCode または PowerShell ISE を使用して、config.ps1 の値を検証して更新します。
1. OIC がマルチサイトとしてデプロイされている場合:
  1. ### Multi-Site: のラベルが付いたコメントを探す
  2. 見つかったコメントに記載されているアクションを実行します。
2. デフォルト（3.0）が正しい場合を除き、HardwareVersion を更新します。
3. デフォルト（DC1）が正しい場合を除き、PrimarySiteCode を更新します。
4. サイトコードは多くの名前で使用されます。DC1 のすべてのインスタンスを検索し、正しいサイトコードに置き換えます。大文字と小文字を区別しない検索を使用します。各変更を確認します。一部の変更は必要ない場合があります。たとえば、サイトコードが AB1 の場合、ホスト名 DC1-DC1 は AB1-AB1 ではなく AB1-DC1 に変更する必要があります。
5. デフォルトが正しくない場合は、DnsDomain を更新します。この値が変更された場合は、config.ps1 ファイル全体で opscenter.local を検索して置換します。このデフォルトは、複数の場所でハードコードされています。
6. DnsConditionalForwarder のオブジェクトをサイト固有の情報で更新します。転送オブジェクトが少なくとも 1 つ必要です。不要な例を削除します。
  
  この手順は、gdcloud と kubectl CLI がインストールされている場合、CONFIG1 の WSL で実行できます。
  
  ルート管理クラスタからサイト固有の情報を pull するには、次のコマンドを使用します。
```
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 - GDC セルの DNS ドメイン名（ciq.yaml の dns.delegatedSubdomain など）。
  2. Master - DNS サーバーの IP のリスト（通常は 1 つのみ）。cellcfg で DNSReservation 型を探します。GDC セルがデプロイされている場合は、ルート管理クラスタの dns-system Namespace で gpc-coredns-external-udp サービスの EXTERNAL-IP とセルの FQDN bert.sesame.street を確認します。
  3. マルチサイトデプロイでは、セルごとに 1 つのハッシュテーブルオブジェクトがあります。
7. Users、Groups、GroupPolicy オブジェクトの内容は変更しないでください。
8. DNSServers を更新して、プライマリドメインコントローラとセカンダリドメインコントローラ（<SITE>-DC1 や <SITE>-DC2 など）に割り当てられた 2 つの IP アドレスを含めます。
9. NTPServers を、root-admin TimeServer カスタムリソースの SyncServer IP アドレスのリストに更新します。この IP アドレスのセットは、次のコマンドで取得できます。
```
kubectl get timeserver -A -o json | jq '.items[].address'
```
  次の例に示すように、これらの IP アドレスを NTPServers でフォーマットする必要があります。
```
NtpServers = @(
  '10.251.80.2',
  '10.251.80.3',
  '10.251.80.4',
  '10.251.80.5'
)
```
10. 必要に応じて、SubnetPrefix のデフォルト値（24）を、お客様が提供した OCCORE-SERVERS サブネットのサブネット接頭辞値で更新します。
11. OCCORE-SERVERS サブネットの顧客提供のデフォルトゲートウェイを使用して、DefaultGateway のデフォルト値を更新します。
12. WorkstationCider のデフォルト値を見つけて、IPv4 CIDR 表記の OC-WORKSTATIONS サブネットについてお客様から提供された値で更新します。
13. お客様がワークステーションへのリモートアクセスを許可することを選択した場合は、WorkstationAllowRemote の値を $true に更新します。
14. サンプルサブネットプレフィックス 172.21.0. を、お客様が提供した OCCORE-SERVERS サブネットプレフィックスに置き換えます。
15. 172.21.2. のサブネットプレフィックスの例を、お客様から提供された OCCORE-JUMPHOSTS サブネットプレフィックスに置き換えます。
16. サブネットの接頭辞の例である 172.21.32. を、お客様が提供した OC-WORKSTATIONS サブネットの接頭辞に置き換えます。
17. Pref caption の legalnoticecaption 値の「今日のメッセージ」の例を検索して、お客様から提供されたキャプションに置き換えます。
18. Pref text の legalnoticetext の値の「今日のメッセージ」の例を検索して、お客様から提供されたテキストに置き換えます。
19. 各「ノード」オブジェクトを検証し、必要に応じて更新します。
  1. NodeName - ホスト名が正しいことを確認します。一部の名前は、ドメインコントローラなど、多くの場所で使用されます。ここで名前を変更する場合は、構成の他の場所でも変更する必要があるかどうかを確認してください。
  2. IPv4Addr - ホストの IP アドレスである必要があります。通常、最後のオクテットはそのままにしておいて構いません。一部は、前の手順で行ったネットワークの検索と置換で更新されている可能性があります。
  3. HyperVHost - この値は、この VM をホストする Hyper-V サーバーの IP アドレスである必要があります。各 BM?? サーバーの IP アドレスは、構成の [Hyper-V Servers] セクションで確認できます。このフィールドの Hyper-V ホストの割り当ては変更しないでください。すべての Hyper-V ホストがすべての VM タイプをサポートできるわけではありません。Hyper-V ホスト名を対応する IP アドレスに変更するだけです。
20. Role=jumphost を使用して、すべてのノードで 2 番目のネットワークインターフェースの詳細を検証します。このインターフェースには、OCCORE-JUMPHOSTS サブネットの詳細を使用します。確認:
  1. JumphostIPv4Cidr
  2. JumphostDefaultGateway
21. Role=adfs のノードで ADFS 固有のスタンザを更新します。
  
  警告: 指示がない限り、ADFS 構成のどの部分も編集しないでください。アップグレード中、既存の ADFS 構成は維持されます。
  1. Name = 'SplunkTrust' # Must be unique to the farm. Append "Trust" という行を探します。
  2. この行の後の 3 つの opscenter.local を DNS ドメインに置き換えます。
22. 必要に応じて、お客様の IP プランに合わせて DHCP スコープを更新します。各スコープについて、次の値が正しいことを確認します。スコープの名前は ocinfo.common.opscenter.local.txt ネットワークプランで使用されている名前と一致するため、検証では次のものを使用します。
  1. ScopeId
  2. IpStartRange
  3. IpEndRange
  4. Router
  5. SubnetMask
23. 値がバックアップされた config1.ps1 の値と一致することを確認します。
24. ファイルを必ず保存してください。

CONFIG1 VM の準備

CONFIG1 の準備は BM01 で行われます。その他のアップグレードはすべて、CONFIG1 VM にログインした状態で行われます。

operations_center ディレクトリを CONFIG1 VM にコピーする
1. BM01 ホストで、管理者として PS コンソールを開きます。
2. operations_center をコピーして、CONFIG1 仮想マシン（VM）に必要なファイルをステージングします。
  
  注: ここでは、環境が運用中のため、Copy-ConfigHostFiles.ps1 は使用されません。SMB コピーにより、コピー時間を数時間短縮できます。
```
# 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 の時刻同期を無効にする
  1. 管理者として BM01 ホストにログインします。
  2. Windows で PowerShell を管理者として開き、次のコマンドを実行します。
  重要: 次のコードスニペットで、<var>config1_vm_name</var> を CONFIG1 VM の名前に置き換えます（例: DC1-CONFIG1）。
```
# Disabling Hyper-V Time Sync
Disable-VMIntegrationService -VMName `<SITE>-CONFIG1` -Name 'Time Synchronization'
```
4. CONFIG1 VM の準備と検証
  1. BM01 ホストから、-SA アカウントで CONFIG1 VM にログインします。リモートデスクトップ（RDP）を使用して VM の IP アドレスに接続します。例: mstsc /v 192.168.100.99
  2. [別のユーザーとして実行] メニューを使用して PowerShell ウィンドウを開き、Marvin ユーザーとして実行します。
  3. 新しい PowerShell ウィンドウで、管理セッションを開始します。
```
Start -Verb runas -FilePath powershell.exe
```
    前の PowerShell ウィンドウを閉じ、管理者ウィンドウを開いたままにします。
  4. 管理 PowerShell ウィンドウが Marvin として実行されていることを確認する
```
whoami
```
  5. BM01 ホストからステージングされたファイルをレイアウトします。
```
Move-Item -Path c:\operations_center -Destination c:\release
C:\release\operations_center\dsc\Initialize-ConfigHostFiles.ps1
```
  6. c:\dsc と c:\config が存在することを確認します。
  7. バックアップから認証情報ファイルと証明書ファイルをコピーする
```
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. MOF のコンパイルに必要な MECM データを構築する
```
C:\dsc\Build-MecmFiles.ps1
```
  9. Build-Mof.ps1 を実行して、ビルド環境の準備ができていることを検証します。これにより、すべての OI マシンの MOF ファイルが生成されます。
```
C:\dsc\Build-Mof.ps1
```
5. 認証情報変数を入力する
  
  これらの変数は、アップグレードプロセス全体で使用されます。管理者として開いた Marvin Powershell ウィンドウで、一度だけ入力します。
```
. '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. DSC が実行中で、サーバーにアクセスできることを確認します。
```
$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}
```
  注: 一部のノードでステータスが Failure になったり、エラー The Consistency Check or Pull cmdlet is in progress が発生したりすることがあります。ノードに到達可能であれば問題ありません。

接続に関する問題のトラブルシューティングを行います。

New-CimSession が失敗した場合は、config.ps1 で NodeName の値が正しいことを確認します。また、サーバーがオンラインで到達可能であることを確認します。

エラーは Get-CimSession: WinRM cannot process the request で始まります。

ドメインコントローラをアップグレードする

CONFIG1 にログインした状態で、プライマリドメインコントローラをアップグレードします。

変数を入力し、古い GPO を削除して、新しい GPO をリンクします。
```
$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
}
```
グループポリシーオブジェクトのリンクを解除します。アップグレードの最後にリンクされます。
```
$gpolinks = (Get-Content C:\dsc\data\GpoLinkMapping.yaml -Raw).Replace("LinkEnabled: 'Yes'", "LinkEnabled: 'No'")
$gpolinks | Out-File C:\dsc\data\GpoLinkMapping.yaml -Force
```
プライマリドメインコントローラをアップグレードします。
```
.\Update-RemoteHost.ps1 @da_args -ComputerName $DC1.NodeName
```
注: Installing PowerShell modules on host 中に Copy-Item : An item with the specified name already exists. エラーが発生することがありますが、ノードの更新では無視しても問題ありません。
警告: パスの長さの制限により、DC へのファイルのコピーに影響する問題が確認されています。Copying files for the ... role to host の実行中に a file that already exists on the target destination などのエラーが Update-RemoteHost で発生した場合は、次のコマンドを実行します。それ以外の場合は、次の手順に進みます。
```
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. SyncServer で時刻同期を検証する
2. ドメイン管理者として RDP を使用して DC1 にログインします。
  1. Powershell ウィンドウを管理者として開きます。
  2. 次のコマンドを実行して、時間構成を検証します。
```
w32tm /query /status /verbose
```
重要: Last Sync Error: が 0 であり、Source が NTP サーバーの更新の手順で構成された NtpServers IP アドレスのいずれかと一致していることを確認します。
1. 次のコマンドを実行して、時刻の再同期をテストします。
```
 # Testing time resyncronization
 w32tm /resync
```
```
 # Desired output
 Sending resync command to local computer
 The command completed successfully.
```
2. 時間構成が正しく、エラーがないことを再確認します。
  
  重要: Last Sync Error: が 0 であり、Time to Last Good Sync Time: が更新されていることを確認します（同期直後に実行した場合は 1 分以内です）。
```
 w32tm /query /status /verbose
```
  警告: エラーが検出された場合、または w32tm /resync が失敗した場合は、停止します。時間サービスが完全に機能していないと OI のデプロイがブロックされるリスクが高いため、続行する前に OI エンジニアリングにエスカレーションします。
2 番目のドメインコントローラをアップグレードします。
1. 既存の CONFIG1 PowerShell ウィンドウを使用して、次のスクリプトを実行します。
```
.\Update-RemoteHost.ps1 @da_args -ComputerName $dc2.NodeName
```

Active Directory レプリケーションを検証します。

2 番目の DC が起動して動作したら、ドメインコントローラのいずれかから次のコマンドを実行して、Active Directory レプリケーションを検証します。

repadmin /replsummary

出力は次のようになります。

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

CA-ISSUING1 と CA-WEB をアップグレードする

CONFIG1 の既存の PowerShell ターミナルを使用して、CA-ISSUING1 をアップグレードします。

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

CONFIG1 の既存の PowerShell ターミナルを使用して、CA-WEB をアップグレードします。

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

アップグレードを検証する

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

CA-ROOT1 をアップグレードする

CONFIG1 の既存の PowerShell ターミナルを使用する

CA-ROOT1 の電源をオンにします。

  $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 を更新します。
```
  $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
```
注: 認証エラーが発生した場合は、caadmin として CA-ROOT1 サーバーにログインします。管理者として PowerShell を開きます。「winrm qc」と入力して Enter キーを押します。y を使用して変更を承認します。CA-ROOT1 からログオフして、再試行します。
前のスクリプトの後に CA_ROOT1 が再起動しなかった場合は、手動で再起動します。
アップグレードを検証します。
```
  $ca_root | ForEach-Object {
  $session = New-CimSession -ComputerName $_.Ipv4Addr -Credential $caroot_cred
  Get-DscConfigurationStatus -CimSession $session}
```
重要: w32tm を使用して、VM が <SITE>-DC1 ホストに同期していることを確認します。CA-ROOT のローカル管理者として、管理シェルで次のコマンドを実行します。

Peer の設定が <SITE>-DC1.<DNSDOMAIN> で、State が Active であることを確認します。

時間が正しく同期されていない場合は、続行しないでください。

  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)

CA-Root の電源を切ります。

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

ADFS をアップグレードする

CONFIG1 の既存の PowerShell ターミナルを使用する

ADFS1 VM をアップグレードします。

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

ジャンプホストをアップグレードします。

CONFIG1 の既存の PowerShell ターミナルを使用する

ジャンプホストの配列を作成します。

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

ジャンプホストをアップグレードします。

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

アップグレードを検証します。

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

ファイルサーバーをアップグレードします。

CONFIG1 の既存の PowerShell ターミナルを使用する

Fileserver を含む配列を作成します。

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

ファイルサーバーをアップグレードします。

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

アップグレードを検証します。

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

DHCP サーバーをアップグレードします。

CONFIG1 の既存の PowerShell ターミナルを使用する

DHCP1 をアップグレードします。

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

アップグレードを検証します。

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

DHCP2 をアップグレードします。

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

アップグレードを検証します。

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

Userlock サーバーをアップグレードします。

CONFIG1 の既存の PowerShell ターミナルを使用する

Userlock サーバーを含む PowerShell 配列を作成します。

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

以前のセットアップからマーカーファイルを削除します。

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

プライマリ Userlock サーバーをアップグレードします。

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

バックアップ Userlock サーバーをアップグレードします。

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

アップグレードを検証します。

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

Nessus サーバーをアップグレードします。

CONFIG1 の既存の PowerShell ターミナルを使用する

Nessus サーバーを含む PowerShell 配列を作成します。

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

Nessus サーバーをアップグレードします。

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

アップグレードを検証します。

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

Hyper-V サーバーをアップグレードします。

CONFIG1 の既存の PowerShell ターミナルを使用する

Hyper-V サーバーを含む PowerShell 配列を作成します。

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

Hyper-V サーバーをアップグレードします。
```
  $hyper | ForEach-Object {
  c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}
```
警告: BM01 の再起動が発生すると、CONFIG1 が再起動します。利用可能になったら、ログインして Marvin として PowerShell を開き、昇格してから、ステップ Config1 の準備 1.e. を実行して変数を再読み込みします。Hyper-V のアップグレードを再度開始します。

アップグレードを検証します。

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

ツールボックスをアップグレードする

CONFIG1 の既存の PowerShell ターミナルを使用する

Toolbox サーバーを含む PowerShell 配列を作成します。

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

TOOLBOX1 サーバーに追加のドライブを作成する

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

出力に VM に割り当てられた 2 つのディスクが表示されていることを確認します。例:

  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

Toolbox サーバーをアップグレードします。

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

アップグレードを検証します。

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

`CONFIG1` の既存の PowerShell ターミナルを使用して、アップグレードを検証します。

DSC がエラーなく実行されていることを確認します。

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

Splunk VM をアップグレードする

CONFIG1 の Powershell ウィンドウで、DSC 構成を設定して実行します。

サイトコードを入力します。例: "DC1"

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

ヘビーフォワーダーを構成します。

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

インデクサー 1 を構成します。

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

インデクサー 2 を構成します。

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

インデクサー 3 を構成します。

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

マネージャーを構成します。

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

検索ヘッドを構成します。

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

CONFIG1 の PowerShell ウィンドウで、次の操作を行います。

  $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

SIEM-G0006 に沿ってグローバル Pass4SymmKey を設定し、SIEM-G0007 に沿って各ゾーンを OIC の Splunk に接続します。

CONFIG1 ホストをアップグレードする

CONFIG1 の PowerShell ウィンドウで、次の操作を行います。

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

パソコンが再起動した場合は、再度ログインして Marvin として PowerShell を起動し、管理者権限に昇格します。次のセクションに必要な変数を入力します。
```
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）

MCM はアップグレード可能なコンポーネントではないため、既存の MCM ホストを破棄して MCM を再デプロイするしかありません。

IT-T0023 に従って、現在の MCM ソフトウェアがハイドレートされていることを確認します。
再デプロイの手順については、IT-R0019 を参照してください。

VM チェックポイントを削除する

アップグレードが完了したら、チェックポイントを削除する必要があります。チェックポイントは、時間の経過とともにディスク使用率が過剰になる可能性があります。アップグレードの失敗によりチェックポイントへの復元が必要な場合にのみ保持します。

CONFIG1 の既存の PowerShell ターミナルを使用します。

VM チェックポイントを削除します。

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

ドメインのグループポリシーオブジェクトを再度有効にする

CONFIG1 の既存の PowerShell ターミナルを使用する

ドメインコントローラのロール構成を変更して、管理対象 GPO のリンクを有効にする

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

ObjectOwner ロールを使用してドメインコントローラを更新します。

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

Google チームへのお問い合わせ

Google にお問い合わせいただく手順については、サポートをリクエストするページをご覧ください。

マルチゾーン デプロイでアップグレードを実行する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

準備

コンプライアンス レポートを生成する

Identity and Access Management

すべてのゾーンでグローバル リソースのアップグレードを一時停止する

グローバル ルート組織をアップグレードする

アップグレード前のチェック

1. 更新パッケージをダウンロードしてコピーする

2. Artifact Registry のアップグレードを構成する

アーティファクトをコンテナ レジストリに push する

3. ルート組織をアップグレードする

3.1. アップグレード前

3.2. ルート組織の自動アップグレードを実行する

3.3. アップグレード後のチェック

すべてのゾーンでルート組織のアップグレードを完了する

4. グローバル リソースをアップグレードする

5. ゾーン間のコンポーネント アップグレード

6. エニーキャスト サブネットの手動アップグレード

7. SyncServer の手動アップグレード

7.1. SyncServer のアップグレード プロセス

グローバル テナント組織をアップグレードする

アップグレード前のチェック

1. テナント組織をアップグレードする

1.1. 準備

IaC

kubectl

1.2. アップグレードを開始する

1.3. アップグレード

1.4. アップグレード後のチェック

1.5. 予定外のアップグレードを開始する

2. DNS のアップグレード

2.1 転送ゾーンを作成する

2.2 再帰リゾルバを有効にする

すべてのゾーンでテナント組織のアップグレードを完了する

3. グローバル リソースをアップグレードする

4. Tenable SC をアップグレードする

アップグレード後のクリーンアップ

テナント組織のアップグレードのメンテナンスの時間枠を構成する

コンソール

kubectl

Operations Suite Infrastructure Core の手動アップグレード

VM チェックポイントとディレクトリ バックアップを実行する

サードパーティ ソフトウェアを読み込む

既存の仮想マシンをアップグレードする

CONFIG1 VM の準備

接続に関する問題のトラブルシューティングを行います。

ドメイン コントローラをアップグレードする

CA-ISSUING1 と CA-WEB をアップグレードする

CA-ROOT1 をアップグレードする

ADFS をアップグレードする

ジャンプホストをアップグレードします。

ファイル サーバーをアップグレードします。

DHCP サーバーをアップグレードします。

Userlock サーバーをアップグレードします。

Nessus サーバーをアップグレードします。

Hyper-V サーバーをアップグレードします。

ツールボックスをアップグレードする

CONFIG1 の既存の PowerShell ターミナルを使用して、アップグレードを検証します。

Splunk VM をアップグレードする

CONFIG1 ホストをアップグレードする

Microsoft Configuration Manager（MCM）

VM チェックポイントを削除する

ドメインのグループ ポリシー オブジェクトを再度有効にする

Google チームへのお問い合わせ

マルチゾーンデプロイでアップグレードを実行する

コンプライアンスレポートを生成する

すべてのゾーンでグローバルリソースのアップグレードを一時停止する

グローバルルート組織をアップグレードする

アーティファクトをコンテナレジストリに push する

4. グローバルリソースをアップグレードする

5. ゾーン間のコンポーネントアップグレード

6. エニーキャストサブネットの手動アップグレード

7.1. SyncServer のアップグレードプロセス

グローバルテナント組織をアップグレードする

3. グローバルリソースをアップグレードする

VM チェックポイントとディレクトリバックアップを実行する

サードパーティソフトウェアを読み込む

ドメインコントローラをアップグレードする

ファイルサーバーをアップグレードします。

`CONFIG1` の既存の PowerShell ターミナルを使用して、アップグレードを検証します。

ドメインのグループポリシーオブジェクトを再度有効にする