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

手動で更新

自動アップグレードが失敗した場合は、次の手動アップグレードの手順を使用できます。

1. PANW の手動アップグレード

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

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

このアップグレードでは、外部接続のトラフィックの中断は最小限に抑えられ、ダウンタイムは約 1 分です。このようなアップグレードは手動で行われます。PANW は高可用性（HA）モードで動作します。

1.1. 定義

Palo Alto ファイアウォールソフトウェアのバージョンは X.Y.Z の形式で表示されます。

ソフトウェアバージョン	形式
FEATURE リリース	X.Y
BASE メンテナンスリリース	X.Y.0
特定の機能リリースの最新のメンテナンスリリース	X.Y.Z: Z は、将来のリリース X.Y の最後のメンテナンスリリースです。

1.2. アップグレード手順

1.2.1. パスのアップグレード

続行する前に、ニーズに合致するケース（ケース 1、ケース 2、ケース 3）を特定してください。

ケース 1: X.Y が対象のリリースです。
ケース 2: X.Y が対象リリースではない場合。
ケース 3: ファイアウォールバージョンが X.Y で、X.Y は X の最後の FEATURE リリースです。

ケース 1、ケース 2、ケース 3 の説明は、それぞれに対応するアップグレードパスを示しています。

ケース	説明と対応
ケース 1	X.Y は、アップグレードするリリースです（ターゲットリリースではありません）。
		X.Y の対象となるメンテナンスリリース X.Y(Z2) をダウンロードしてインストールします。
ケース 2	X.Y がアップグレードするリリース（ターゲットリリース）ではない。
		X.Y の最新のメンテナンスリリース X.Y.Z1 をダウンロードしてインストールします。
		ベースメンテナンスリリース X.(Y+1).0 をダウンロードします。 X.(Y+1) が対象の機能リリースの場合、 X.(Y+1) の対象となるメンテナンスリリース X(Y+1).Z2 をダウンロードしてインストールします。 X.(Y+1) が対象の FEATURE リリースでない場合、ケース 2 を繰り返して、ケース 1 を適用します。 X.(Y+1) が X の最後の機能リリースである場合は、ケース 3 に進みます。
ケース 3	ファイアウォールバージョンは X.Y です。ここで、X.Y は X の最後の機能リリースです。
		ベースメンテナンスリリース（X+1）.0.0 をダウンロードします。ケース 1 に戻ります。

ここに記載されている内容に加えて、アップグレードパスについては、https://www.paloaltonetworks.com/ を参照してください。

1.2.2. アップグレードの設定

Distributed Cloud は 2 つのファイアウォールを使用します。アップグレードを開始する前に、両方のファイアウォールが同じバージョンであることを確認します。一致していない場合は、両方を次のターゲットバージョンにアップグレードする前に、バージョンを一致させるために必要なアップグレードを行います。アップグレードを実行するたびに、この操作を行います。

両方のファイアウォールが正しく機能していることを確認します。
1. ダッシュボードで、高可用性（HA）が緑色であることを確認します。
2. ネットワークにダウンリンクがないことを確認します。
両方のファイアウォールの構成をバックアップします。
[Device] > [High Availability] に移動します。
[デバイス] ページの先頭付近にある [Operational Commands] タブを見つけてクリックします。
1. ナビゲーションパネルで [高可用性] を見つけてクリックします。
2. [高可用性のためにローカルデバイスを一時停止] オプションが表示されたら、クリックします。
図 1: HA を一時停止する
ローカルファイアウォールの返された状態が suspended と表示されていることを確認します。

図 2. ファイアウォールが一時停止されていることを確認する
ファイアウォールをアップグレードします。
suspended 状態から復元する: [Make local device available for high availability] をクリックします。

図 3. HA を利用可能にする

最初の手順に戻り、アップグレードパスに沿って 2 番目のファイアウォールに対してプロセスを繰り返します。

1.3. アップグレード手順の詳細の例

現在の PAN-OS バージョンを確認します。
```
show system info | match sw-version
```
PAN-OS が対象のソフトウェアバージョンでない場合は、デバイスをアップグレードします。
提供されているパス固有のアップグレード手順に沿って操作します。
パスを確認するには、続行する前に、ローカルコンピュータから paloaltonetworks.com ウェブサイト（https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-upgrade/upgrade-pan-os/upgrade-the-firewall-pan-os/determine-the-upgrade-path.html）でアップグレードパスを確認します。
デバイスが登録され、ライセンスが付与されていることを確認します。
抽出する最新のファームウェアを見つけます。
```
gdcloud artifacts tree ${ARTIFACTS_ROOT}/oci | grep "gdch-firewall"
```
ファイル名にはビルドバージョンが含まれています。出力例:
```
│   │   └── gdch-firewall/os:1.10.0-gdch.1426
```
上記の例では、ビルドバージョンは 1.10.0-gdch.1426 と表示されます。
ファイル名をコピーして、ファームウェアを抽出します。次に例を示します。
1. ファイル名として「gdch-firewall/os:1.10.0-gdch.1426」をコピーします。この値を使用して、次のコマンドの FIRMWARE_FILENAME を置き換えます。
```
export FW_FIRMWARE_TAR_FILENAME=FIRMWARE_FILENAME
```
2. OCI イメージからファームウェアを抽出します。
```
gdcloud artifacts extract ${ARTIFACTS_ROOT}/oci firmware \
    --image-name=${FW_FIRMWARE_TAR_FILENAME:?}
```
  FW_FIRMWARE_TAR_FILENAME は、ファイアウォールファームウェアの tar ファイルのファイル名に置き換えます。
3. ファームウェアを抽出します。
```
tar -xvf firmware/gdch-firewall/os.tar.gz
```
アップグレード OS ファイルを収集し、ファイアウォールデバイスにアップロードしてアップグレードを開始します。

Console

ファイアウォールとローカルコンピュータとの IP 接続を確立し、ユーザーインターフェース（UI）に移動します。
ソフトウェアをファイアウォールにアップロードするには、[Device] > [Software] を選択し、ページの下部にある [Upload] をクリックします。

図 4. ソフトウェアアップデートをアップロードする
ソフトウェアをアップロードすると、表に利用可能と表示され、インストールするためのアクションが表示されます。
https://support.paloaltonetworks.com/Updates/DynamicUpdates の [アプリ] カテゴリ（プルダウンメニュー）から、最新の動的更新をダウンロードします。
[アップロード] をクリックして、動的更新をファイアウォールにアップロードします。この手順は 1 回だけ行う必要がある場合があります。
ファイルからアップロードされたものをインストールします。[Install From File] をクリックします。

図 5. [Install From File] を選択します。
図 6 で「ACTION」という単語で始まる列を見つけます。その列で、[インストール] を選択してソフトウェアをインストールします。ファイアウォールが再起動します。

図 6: インストール機能を示す [アクション] 列
[ダッシュボード] ページに移動して、[全般情報] ペインを表示します。[ソフトウェアバージョン] を見つけて、関連付けられている値が元のバージョン値から変更されていることを確認します。これにより、バージョンの変更が検証されます。

図 7. ソフトウェアバージョンに変化が表示される
アップグレードパスに基づいて、必要に応じてこれらの手順を繰り返します。

kubectl

インターネットにアクセスできない場合は、次のコマンドラインの手順に沿って PAN-OS をアップグレードします。

ファームウェアを SCP します。

scp import software from ubuntu@<host>:/home/ubuntu/gdcloud_v8/images/PanOS_5200-XX.XX.XX

必要なシステムソフトウェアのインストールバージョンをリクエストします。
```
request system software install version XX.XX.XX
```
これにより、次のステップで使用するジョブ ID が生成されます。出力メッセージの例を次に示します。
```
Software install job enqueued with jobid 2. Run 'show jobs id 2' to monitor its
status. Please reboot the device after the installation is done.
```
ジョブのステータスをモニタリングします。
```
show jobs id 2
```
インストール後に PAN-OS を再起動します。
```
request restart system
```
エラーが発生していないにもかかわらず PAN-OS を更新できない場合は、PAN-OS のライセンスを取得し、動的更新で更新します。ライセンスキーが cell.yaml ファイルまたはディレクトリにあることを確認します。構成を確認するをご覧ください。
動的アップデートをインストールするには、PAN ポータルまたはドライブの場所で最新バージョンの動的アップデートを見つけます。

ファイアウォールのコンテンツを SCP します。

# scp import content from
ubuntu@<host_ip>::/home/ubuntu/gdcloud_v8/images/panupv2-all-contents-8580-7429

コンテンツをインストールします。

request content upgrade install  skip-content-validity-check yes file panupv2-all-contents-8580-7429

PAN-OS をホストマシンにアップロードします。
1. ノートパソコンを、ホストマシンと同じラックにある管理スイッチに接続します。
2. 管理ネットワーク vlan97 からノートパソコンに IP アドレスを割り当てます。
3. ノートパソコンからホストマシンに PAN-OS を SCP します。
```
scp ~/Downloads/Pan* ubuntu@10.251.243.79:~
Warning: Permanently added '10.251.243.79' (ED25519) to the list of known hosts.
ubuntu@10.251.243.79's password:
```

2 HSM の自動アップグレードをトリガーする

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

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

HSM のアップグレードでは、HSMUpgradeRequest を作成し、アップグレードリクエストのステータスを定期的に確認する必要があります。

1 つ以上の CTMClusterUpgradeRequests が自動的に生成され、アップグレードパスの各 HSMCluster を次のファームウェアバージョンにアップグレードして、ターゲットファームウェアバージョンに到達します。HSM のアップグレードは、約 2 時間かかる中断のないアップグレードです。

このアップグレードのダウンタイムの長さは、統合によって異なります。複数のアドレスで構成された HSM は、中断することなくローリングアップデートを行うことができます。

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

HSMUpgradeRequest カスタムリソースを作成します。hsmupgrade.yaml を作成し、CurrentGDCHVersion と TargetGDCHVersion を含めます。

カスタムリソースの例:

apiVersion: "upgrade.private.gdc.goog/v1alpha1"
kind: HSMUpgradeRequest
metadata:
   name:  HSM_UPGRADE_REQUEST_NAME
   namespace: gpc-system
spec:
   currentGDCHVersion: "1.10.X-gdch-xxx"
   targetGDCHVersion: "1.11.y-gdch.yyyy"

新しいカスタムリソースを適用します。

kubectl --kubeconfig=${KUBECONFIG:?} apply -f hsmupgrade.yaml

作成された HSMUpgradeRequest リソースと CTMClusterUpgradeRequest リソースの Status を確認して、HSM のアップグレードをモニタリングします。

kubectl --kubeconfig=${KUBECONFIG:?} describe HSMUpgradeRequest HSM_UPGRADE_REQUEST_NAME -n gpc-system

完了した HSMUpgradeRequest の Status 出力の例:

Status:
Conditions:
 Last Transition Time:  2023-08-03T18:20:50Z
 Message:
 Observed Generation:   1
 Reason:                PullFirmwareImages
 Status:                True
 Type:                  FirmwareImagesPulled
 Last Transition Time:  2023-08-03T18:20:50Z
 Message:               CTM upgrade request to version:2_12_0 is in progress
 Observed Generation:   1
 Reason:                CTMClusterUpgradeInProgress
 Status:                True
 Type:                  InProgress
 Last Transition Time:  2023-08-03T18:41:54Z
 Message:               CTM upgrade request to target version:2_12_0 completed
 Observed Generation:   1
 Reason:                AllCTMClusterUpgradeRequestsCompleted
 Status:                True
 Type:                  AllComplete

kubectl --kubeconfig=${KUBECONFIG:?} get ctmclusterupgraderequests -n gpc-system

kubectl --kubeconfig=${KUBECONFIG:?} describe ctmclusterupgraderequests CTM_CLUSTER_UPGRADE_REQUEST_NAME -n gpc-system

完了した CTMClusterUpgradeRequest の Status 出力の例:

Status:
Conditions:
 Last Transition Time:  2023-09-11T18:08:25Z
 Message:               CTM pre upgrade checks succeed. The system is eligible to upgrade.
 Observed Generation:   1
 Reason:                CTMPreUpgradeChecksReady
 Status:                True
 Type:                  PreUpgradeCheckCompleted
 Last Transition Time:  2023-09-11T18:18:31Z
 Message:               HSM backup completed. The system is ready to upgrade.
 Observed Generation:   2
 Reason:                HSMBackupCompleted
 Status:                True
 Type:                  BackupCompleted
 Last Transition Time:  2023-09-11T18:18:31Z
 Message:               Starting HSM upgrades for cluster.
 Observed Generation:   2
 Reason:                hsmclusterClusterUpgradeInProgress
 Status:                True
 Type:                  ClusterUpgradeInProgress
 Last Transition Time:  2023-09-11T19:46:22Z
 Message:
 Observed Generation:   2
 Reason:                ReconcileCompleted
 Status:                True
 Type:                  AllComplete

3. ONTAP の手動アップグレード

既存のストレージクラスタがあるシステムで手動アップグレードを実行する場合は、次の手順に沿ってアップグレードを実行します。

12.4.1 取得方法 1 または 12.4.2 取得方法 2 のいずれかの方法で OS アップグレードイメージを取得します。これらのステップシーケンス番号は、1 つだけを使用するため、同じ番号になります。

3.1. - 取得方法 1

このメソッドを使用して、gdch.tar.gz からアップグレード可能なパッケージを取得します。

ホストマシンでリリースバンドルにアクセスできる場合は、Harbor レジストリからイメージを取得します。
```
# Download the upgrade OS package
OCI_PATH=$ARTIFACTS_ROOT/oci
gdcloud artifacts extract $OCI_PATH storage --image-name=gpc-system-storage/storage:9.13.1P1

tar -xvzf storage/gpc-system-storage/storage.tar.gz
```
抽出に失敗した場合は、次のコマンドで適切なアーカイブを探します。 sh gdcloud artifacts extract $OCI_PATH tree | grep storage
storage/9.13.1P1.tar でファイルを見つけます。
アップグレード OS ファイルを収集して、アップグレードを開始するためにストレージサイトにアップロードします。または、ONTAP がまだインストールされていない場合は、ブートストラッパーでこれらのファイルを提供し、ノードにイメージをプルさせます。

3.2. - 取得方法 2

root-admin-cluster がすでに稼働している場合は、GDC Artifact Registry からアップグレードイメージを直接取得できます。

Artifact Registry からイメージを取得します。

https://gpc-istio-ingressgateway-IP/artifacts/serve/base64url encoding of the artifact reference

アップグレードファイルをダウンロードします。

IMAGE_BASE64_URL=$(echo "gpc-system-storage/storage:ontap" | base64)

# The OS file is located at:
https://gpc-istio-ingressgateway-IP/artifacts/serve/IMAGE_BASE64_URL

アーティファクト参照は gpc-system-storage/storage:ontap. です。

https://gpc-istio-ingressgateway-IP/artifacts/serve/IMAGE_BASE64_URL で指定された URL にアクセスし、OS パッケージをローカルにダウンロードします。
アップグレード OS ファイルを収集し、ストレージサイトにアップロードしてアップグレードを開始します。

3.3. ONTAP に画像をアップロードする

ONTAP 管理 URL を開き、[概要] ページを見つけます。
[ONTAP Update] ボタンをクリックします。

図 8: [ONTAP Update] ボタン
[+ 画像を追加] をクリックし、取得方法 1 または取得方法 2 で収集した画像をアップロードします。

図 9: [+Add Image] ボタン

3.4. ONTAP アップグレードのプリフライトチェック

画像をアップロードしたら、[アップグレード] をクリックしてプリフライトチェックを開始します。次の画像のように、「警告付きで更新」という警告メッセージが表示されます。

図 10. 警告付きでアップグレードボタン

警告メッセージが表示された場合は、次の操作を行います。

対応が必要なアクションアイテムが表示されていないことを確認します。アップグレードに影響する可能性のあるものがリストされていないことを確認します。
次のプリフライトチェックを実行します。
- クラスタが正常で、ストレージフェイルオーバーが構成されたノードが正常であることを確認します。
- ストレージシステムでアラートが報告されていないことを確認します。
- アップグレードウィンドウで CPU とディスクの使用率が 50% 未満であることを確認します。
- ストレージシステムで実行中のジョブがないことを確認します。
  たとえば、ボリュームジョブと集計ジョブは実行中であるか、実行待ちのキューに入っている可能性があります。完了するまで待ちます。
- DNS が起動していることを確認します（構成されている場合）。
- すべてのネットワークインターフェースがホームノードにあることを確認します。そうでない場合は、ホームノードに移動するように戻します。
- SnapMirror が構成されている場合は、アップグレード時に一時停止されていることを確認します。
- すべての手順で、ストレージシステムのアップグレードに関する推奨事項に従います。

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

ルート管理クラスタ内で Kubernetes API オブジェクトを作成し、kubectl CLI を使用してルート管理クラスタに適用します。

apiVersion: upgrade.storage.private.gdc.goog/v1alpha1
kind: FileStorageUpgradeRequest
metadata:
 name: test
 namespace: gpc-system
spec:
 fileStorageUpgradeMode: Manual
 storageClusterRef:
   name: $StorageClusterName
   namespace: gpc-system
 targetVersion: 9.10.1

[警告付きで更新] をクリックします。

図 11. 警告付きで更新ボタン

3.6. 空白のシステムでアップグレードする

なんらかの理由で ONTAP ストレージがリセットされ、まだクラスタがない場合は、ノードを 1 つずつ更新する必要があります。手順は次のとおりです。

ONTAP ソフトウェアの最新バージョンをダウンロードします。ファイル名の命名規則は、9.13.1P1_ONTAP_image.tgz のようになります。
ONTAP イメージファイルをホストするディレクトリを作成します。
```
mkdir files
mv 9.13.1P1_ONTAP_image.tgz files
```

python3 を使用してブートストラッパーでイメージをホストします。

# create a webserver with python
python3 -m http.server -d files
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

system node reboot CLI を使用してノードを再起動します。

Ctrl+C キーを押して、ブートサイクルを中断します。ブートメニューが表示されたら、オプション 7: [Install new software first] を選択します。ブートメニューは次のようになります。

> system node reboot

Warning: Are you sure you want to reboot node "ag-ad-stge02-02"?
{y|n}: y

# interrupt the boot cycle using Ctrl-C

*******************************
*                             *
* Press Ctrl-C for Boot Menu. *
*                             *
*******************************
^CBoot Menu will be available.

Please choose one of the following:

(1)  Normal Boot.
(2)  Boot without /etc/rc.
(3)  Change password.
(4)  Clean configuration and initialize all disks.
(5)  Maintenance mode boot.
(6)  Update flash from backup config.
(7)  Install new software first.
(8)  Reboot node.
(9)  Configure Advanced Drive Partitioning.
(10) Set Onboard Key Manager recovery secrets.
(11) Configure node for external key management.
Selection (1-11)? 7

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

This procedure is not supported for Non-Disruptive Upgrade on an HA pair.
The software will be installed to the alternate image, from which the node is
not currently running. Do you want to continue? {y|n} y

In order to download the package, a temporary network interface needs to be
configured.

Select the network port you want to use for the download (for example, 'e0a')

e0M インターフェースで IP アドレスを構成します。その後、ノードを再起動します。

Select the network port you want to use for the download (for example, 'e0a')
> e0M

The node needs to reboot for this setting to take effect.  Reboot now? {y|n}
(selecting yes will return you automatically to this install wizard) y

Rebooting...

## Configure the mgmt interface (e0M)

In order to download the package, a temporary network interface needs to be
configured.

Enter the IP address for port e0M: 172.22.115.131
Enter the netmask for port e0M: 255.255.255.0
Enter IP address of default gateway: 172.22.115.1

What is the URL for the package? http://172.22.112.67:8000/files/9.13.1P1_ONTAP_image.tgz
What is the user name on "172.22.112.67", if any?

version CLI を使用して、現在のソフトウェアバージョンを確認します。出力は次のようになります。
```
> version
NetApp Release 9.13.1P1: Tue Jul 25 10:19:28 UTC 2023
```
3.7. バックアップエージェント LIF の MTU を更新する

バックアップと復元システムは ONTAP の LIF を使用します。MTU は最大値の 9,000 より小さくする必要があります。これはバックアップエージェントによって行われます。ONTAP が実行され、正常な状態になったら、バックアップエージェント LIF の最大伝送単位（MTU）サイズを小さくします。

net port broadcast-domain modify -broadcast-domain backup-agent-network -mtu 8000

次のコマンドを実行して、成功したことを確認できます。

net port broadcast-domain show -broadcast-domain backup-agent-network

新しい MTU 値 8000 が表示されます。

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

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

4.1 バックアップを実行する

Operation Center の設定手順に記載されている手順に沿って、VM のバックアップを行います。
H:\operations_center ドライブをバックアップします。（この操作では、アップグレードのロールバックがサポートされます）。
CONFIG1 で C:\dsc、C:\operations_center\、C:\config\ をバックアップします。（このバックアップは、新しい config.ps1 構成を構築する際の参照として使用します）。

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

インストールディレクトリを取得します。
1. ファイルのダウンロードセクションの手順に沿って、OIC コンポーネントバンドルをダウンロードします。
  
  注: 環境がエアギャップされている場合は、*.tar.gz ファイルを USB ドライブにコピーして転送する必要があります。
2. ダウンロードした prod_IT_component_bundle.tar.gz から operations_center ディレクトリを抽出します。
```
tar -zxvf prod_IT_component_bundle.tar.gz ./release/operations_center
```
3. H:\operations_center は、前の手順で抽出したディレクトリに置き換えます。
サイト固有のデータで 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. OIC が最初に単一サイトとしてデプロイされている場合は、H:\operations_center\dsc\config.single-site-example.ps1 を H:\operations_center\config\config.ps1 にコピーします。
2. OIC が最初にマルチサイトとしてデプロイされている場合は、H:\operations_center\dsc\config.multi-site-example.ps1 を H:\operations_center\config\config.ps1 にコピーします。
PowerShell ISE を使用して、config.ps1 の値を検証して更新します。
1. デフォルト（3.0）が正しい場合を除き、HardwareVersion を更新します。
2. デフォルト（DC1）が正しい場合を除き、PrimarySiteCode を更新します。
3. サイトコードは多くの名前で使用されます。DC1 のすべてのインスタンスを検索して、正しいサイトコードに置き換えます。大文字と小文字を区別しない検索を使用します。各変更を確認します。一部の変更は必要ない場合があります。たとえば、サイトコードが AB1 の場合、ホスト名 DC1-DC1 は AB1-AB1 ではなく AB1-DC1 に変更する必要があります。
4. デフォルトが正しくない場合は、DnsDomain を更新します。この値が変更された場合は、config.ps1 ファイル全体で opscenter.local を検索して置換します。このデフォルトは、複数の場所でハードコードされています。
5. DnsConditionalForwarder のオブジェクトをサイト固有の情報で更新します。転送オブジェクトが少なくとも 1 つ必要です。不要な例を削除します。
  
  ルート管理クラスタからサイト固有の情報を pull するには、次のコマンドを使用します。
```
export KUBECONFIG=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 つのハッシュテーブルオブジェクトがあります。
6. Users、Groups、GroupPolicy オブジェクトの内容は変更しないでください。
7. DNSServers を更新して、プライマリドメインコントローラとセカンダリドメインコントローラ（<SITE>-DC1 や <SITE>-DC2 など）に割り当てられた 2 つの IP アドレスを含めます。
8. 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'
)
```
9. 必要に応じて、SubnetPrefix のデフォルト値（24）を、お客様が提供した OCCORE-SERVERS サブネットのサブネット接頭辞値で更新します。
10. OCCORE-SERVERS サブネットの顧客指定のデフォルトゲートウェイを使用して、DefaultGateway のデフォルト値を更新します。
11. WorkstationCider のデフォルト値を見つけて、IPv4 CIDR 表記で OC-WORKSTATIONS サブネット用に顧客が提供した値に更新します。
12. サンプルサブネットプレフィックス 172.21.0. を、お客様から提供された OCCORE-SERVERS サブネットプレフィックスに置き換えます。
13. 172.21.2. のサブネットプレフィックスの例を、お客様から提供された OCCORE-JUMPHOSTS サブネットプレフィックスに置き換えます。
14. サブネットの接頭辞の例 172.21.32. を、お客様が提供した OC-WORKSTATIONS サブネットの接頭辞に置き換えます。
15. Pref caption の legalnoticecaption 値の「今日のメッセージ」の例を検索して、お客様から提供されたキャプションに置き換えます。
16. Pref text の legalnoticetext の値の「今日のメッセージ」の例を検索して、お客様から提供されたテキストに置き換えます。
17. 各「ノード」オブジェクトを検証し、必要に応じて更新します。
  1. NodeName - ホスト名が正しいことを確認します。一部の名前は、ドメインコントローラなど、多くの場所で使用されます。ここで名前を変更する場合は、構成の他の場所でも変更が必要かどうかを確認してください。
  2. IPv4Addr - ホストの IP アドレスである必要があります。通常、最後のオクテットはそのままにしておいて構いません。一部は、前の手順で行ったネットワークの検索と置換で更新されている可能性があります。
  3. HyperVHost - この値は、この VM をホストする Hyper-V サーバーの IP アドレスである必要があります。各 BM?? サーバーの IP アドレスは、構成の [Hyper-V Servers] セクションで確認できます。このフィールドの Hyper-V ホストの割り当ては変更しないでください。すべての Hyper-V ホストがすべての VM タイプをサポートできるわけではありません。Hyper-V ホスト名を対応する IP アドレスに変更するだけです。
18. splunk_indexer を含むノードのすべてのスタンザを更新して、大きなセカンダリディスクを含めます。各スタンザには次の行を含める必要があります。
```
ExtraDiskSize   = 5120GB # No quotes -- PowerShell converts this to an integer.
ExtraDiskFolder = 'H:\Hyper-V\Virtual Hard Disks'
```
19. Role=jumphost を使用して、すべてのノードで 2 番目のネットワークインターフェースの詳細を検証します。このインターフェースには、OCCORE-JUMPHOSTS サブネットの詳細を使用します。確認:
  1. JumphostIPv4Cidr
  2. JumphostDefaultGateway
20. Role=adfs のノードで ADFS 固有のスタンザを更新します。
  1. bert.sesame.street と GDCH.sesame.street のすべてのインスタンスを、構成の DnsConditionalForwarder セクションのスタンザのいずれかから正しい Domain 値に置き換えます。
  2. Bert（大文字と小文字を区別しない）という単語を、ADFS を使用するように構成されている GDC セルの短い識別子に置き換えます。
21. 必要に応じて、お客様の IP プランに合わせて DHCP スコープを更新します。各スコープで、次の値が正しいことを確認します。スコープの名前は ocinfo.common.opscenter.local.txt ネットワークプランで使用されている名前と一致するため、検証では次のものを使用します。
  1. ScopeId
  2. IpStartRange
  3. IpEndRange
  4. Router
  5. SubnetMask
22. 値がバックアップされた config1.ps1 の値と一致することを確認します。
23. ファイルを必ず保存してください。
CONFIG1 VM のアップグレード

CONFIG1 のアップグレードは、初期インストールとの整合性を保つために BM01 で実行されます。他のすべてのアップグレードは、アップグレード後に CONIFIG1 から実行されます。
1. operations_center ディレクトリを CONFIG1 VM にコピーする
2. BM01 ホストで、管理者として PS コンソールを開きます。
3. Copy-ConfigHostFiles.ps1 スクリプトを実行して、CONFIG1 仮想マシン（VM）に必要なファイルをステージングします。
```
# CD to the script's directory
cd H:\operations_center\dsc
```
```
# Staging files for CONFIG1 VM
.\Copy-ConfigHostFiles.ps1 `<SITE>-CONFIG1`
```
4. 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'
```
5. CONFIG1 更新スクリプトを実行する
```
.\Update-RemoteHost.ps1 -ComputerName DC1-CONFIG1 -Credentials $domain_admin_creds -SetLcm -RemoveExisting
```
6. スクリプトを実行すると、CONFIG1 VM が再起動します。
7. CONFIG1 VM の検証
  1. BM01 ホストで、リモートデスクトップ（RDP）を使用して CONFIG1 VM の IP に接続し、Marvin としてログインします。例: mstsc /v 192.168.100.99
  2. Marvin ユーザーとして、[管理者として実行] を使用して PS コンソールを開きます。
  3. Build-Mof.ps1 を実行して、ビルド環境の準備ができていることを検証します。これにより、すべての OI マシン用の Managed Object Format（MOF）ファイルが生成されます。
```
# Running Build-MOf.ps1
cd C:\dsc
./Build-Mof.ps1
```
  注: ターゲットマシンがまだ構築されていないため、証明書が見つからないという警告が複数表示されるのは正常です。
  注: 認証情報の生成に関するメッセージが複数表示されます。
CA-ISSUING と CA-WEB をアップグレードする

重要: 常に <SITE>-CA-WEB1 の前に <SITE>-CA-ISSUING1 をアップグレードしてください。
1. CONFIG1 で、Marvin として次のスクリプトを実行して、CA-ISSUING VM を構成します。 powershell $la_creds = Get-Credential -Message "Provide local admin credentials for CA- VMs" ./Update-RemoteHost.ps1 -ComputerName <SITE>-CA-ISSUING1 -Credentials $la_creds -SetLcm -RemoveExisting
2. CONFIG1 で、Marvin として次のスクリプトを実行して、CA-WEB1 サーバーを構成します。
```
$la_creds = Get-Credential -Message "Provide local admin credentials for CA- VMs"
.\Update-RemoteHost.ps1 -ComputerName <SITE>-CA-WEB1 -Credential $la_creds SetLcm -RemoveExisting
```
CA_ROOT をアップグレードする
1. CA-ROOT1 の電源を入れます。
  1. 管理者として BM01 ホストにログインします。
  2. Windows で PowerShell を管理者として開き、次のコマンドを実行します。
```
Start-VM -Name <SITE>-CA-ROOT1
```
2. CONFIG1 VM から、CA-ROOT1 VM を初期化します。
```
.\Update-RemoteHost.ps1  -ComputerName <SITE>-CA-ROOT1 -Credential $la_creds SetLcm -RemoveExisting
```
3. 前のスクリプトの実行後に CA_ROOT VM が再起動しなかった場合は、手動で再起動します。
4. 重要: w32tm を使用して、VM が <SITE>-DC1 ホストに同期していることを確認します。このコマンドは、CA-ROOT のローカル管理者として管理シェルで実行します。Peer の設定が <SITE>-DC1.<DNSDOMAIN> で、State が Active であることを確認します。時間が正しく同期されていない場合は、続行しないでください。
```
w32tm /query /peers

#Peers: 1

Peer: DC2-DC1.hq.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)
```
DHCP VM をアップグレードする
1. marvin ユーザーとして CONFIG1 で、DHCP VM をアップグレードします。最初に DHCP2、次に DHCP1 を使用します。
  - DHCP2 を構成します。
```
.\Update-RemoteHost.ps1 -ComputerName <SITE>-DHCP2 -Credential $da_creds SetLCM -RemoveExisting
```
  - DHCP1 を構成する
```
.\Update-RemoteHost.ps1 -ComputerName <SITE>-DHCP1 -Credential $da_creds SetLCM -RemoveExisting
```
ドメインコントローラをアップグレードする
1. CONFIG1 で marvin ユーザーとして、プライマリドメインコントローラをアップグレードします。
```
.\Update-RemoteHost.ps1 -ComputerName <SITE>-DC1 -Credential $da_creds SetLCM -RemoveExisting
```
1. SyncServer で時刻同期を検証する
  1. ドメイン管理者として <SITE>-DC1 に RDP で接続します。
  2. Powershell ウィンドウを管理者として開きます。
  3. 次のコマンドを実行して、時間構成を検証します。
    
    重要: Last Sync Error: が 0 であり、Source が NTP サーバーを更新するの手順で構成された NtpServers IP アドレスのいずれかと一致していることを確認します。
```
# Checking time status
w32tm /query /status /verbose
```
  4. 次のコマンドを実行して、時刻の再同期をテストします。
```
# Testing time resyncronization
w32tm /resync
```
```
# Desired output
Sending resync command to local computer
The command completed successfully.
```
  5. 時間構成が正しく、エラーがないことを再確認します。
  重要: Last Sync Error: が 0 であり、Time to Last Good SYnc Time: が更新されていることを確認します（同期直後に実行した場合は 1 分以内です）。
```
  # Checking time status
  w32tm /query /status /verbose
```
  警告: エラーが検出された場合、または w32tm /resync が失敗した場合は、停止します。時間サービスが完全に機能していないと OI のデプロイがブロックされるリスクが高いため、続行する前に OI エンジニアリングにエスカレーションします。
2. BM02 で 2 番目の DC VM（<SITE>-DC2）をアップグレードする
  1. marvin ローカル管理者アカウントで CONFIG1 にログインします。
  2. 管理者として PowerShell ターミナルを開き、次のスクリプトを実行します。
```
cd c:\dsc

.\Update-RemoteHost.ps1 -ComputerName <SITE>-DC2 -Credential $da_creds -SetLCM -RemoveExisting
```
  1. サーバーが再起動します。15 分間待つか、AD レプリケーションが完了するまで待ちます。
  2. AD レプリケーションを検証する
  3. 2 番目の DC が起動して動作したら、ドメインコントローラのいずれかから次のコマンドを実行して、Active Directory レプリケーションを検証します。
```
repadmin /replsummary
```
  1. #validate-ad-replication の手順に沿って結果を検証します。
  警告: repadmin /replsummary の出力に errors または fails がある場合は、停止します。時間サービスが完全に機能していないと OI のデプロイがブロックされるリスクが高いため、続行する前に OI エンジニアリングにエスカレーションします。

Microsoft Config Manager VM をアップグレードする

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

.\Update-RemoteHost.ps1 -ComputerName <SITE>-MCMDB1 -Credential $da_creds -SetLCM -RemoveExisting

.\Update-RemoteHost.ps1 -ComputerName <SITE>-MCM1 -Credential $da_creds -SetLCM -RemoveExisting

.\Update-RemoteHost.ps1 -ComputerName <SITE>-MCM2 -Credential $da_creds -SetLCM -RemoveExisting

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

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

 .\Update-RemoteHost.ps1 -ComputerName <SITE>-splunk-heavyfwd -Credential $da_creds -SetLCM -RemoveExisting

 .\Update-RemoteHost.ps1 -ComputerName <SITE>-splunk-indexer -Credential $da_creds -SetLCM -RemoveExisting

 .\Update-RemoteHost.ps1 -ComputerName <SITE>-splunk-manager -Credential $da_creds -SetLCM -RemoveExisting

 .\Update-RemoteHost.ps1 -ComputerName <SITE>-splunk-searchhead -Credential $da_creds -SetLCM -RemoveExisting

 .\Update-RemoteHost.ps1 -ComputerName <SITE>-universal -Credential $da_creds -SetLCM -RemoveExisting

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

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

 .\Update-RemoteHost.ps1 -ComputerName <SITE>-NESSUS1 -Credential $da_creds -SetLCM -RemoveExisting

 .\Update-RemoteHost.ps1 -ComputerName <SITE>-NESSUS2 -Credential $da_creds -SetLCM -RemoveExisting

手動で更新 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

1. PANW の手動アップグレード

1.1. 定義

1.2. アップグレード手順

1.2.1. パスのアップグレード

1.2.2. アップグレードの設定

1.3. アップグレード手順の詳細の例

Console

kubectl

2 HSM の自動アップグレードをトリガーする

3. ONTAP の手動アップグレード

3.1. - 取得方法 1

3.2. - 取得方法 2

3.3. ONTAP に画像をアップロードする

3.4. ONTAP アップグレードのプリフライト チェック

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

3.6. 空白のシステムでアップグレードする

3.7. バックアップ エージェント LIF の MTU を更新する

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

4.1 バックアップを実行する

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

手動で更新

3.4. ONTAP アップグレードのプリフライトチェック

3.7. バックアップエージェント LIF の MTU を更新する