アップグレード

Private Cloud Applianceのコンポーネントのアップグレードは、アプライアンス管理者の責任です。システムには、アップグレード前のアプライアンスの状態を検証し、各個々のタスクを開始し、完了するまで進行状況を追跡するワークフローとしてアップグレード手順を実行するためのフレームワークが用意されています。すべてのシステム・レベルで冗長性が組み込まれているため、アプライアンス・コンポーネントは、運用環境にサービスを停止することなくアップグレードできます。

アップグレードのソース・コンテンツ - パッケージ、アーカイブ、デプロイメント・チャートなど - ISOイメージを介して提供されます。アップグレード環境の準備中に、ISOイメージは共有ストレージにダウンロードされ、アップグレード機能自体はISOコンテンツに含まれる最新バージョンにアップグレードされます。この段階で、アプライアンスはアップグレードを適用する準備ができています。

管理者は、「サービスWeb UI」または「サービスCLI」を使用してアップグレードを実行できます。通常、フル・ラックのアップグレードは、すべてのステップを1つのワークフローに便利に統合するため実行されます。状況によっては、フェーズでのアップグレード、グループ内のコンポーネントの処理、または個々のコンポーネントのターゲット設定を行うことをお薦めします。これらのオプションも使用できます。

アップグレード計画および履歴

アップグレード環境の準備段階では、ターゲット・コンポーネント・バージョンのメタデータ・ファイルが現在のインストールと比較され、このメタデータ比較の結果が詳細なアップグレード計画に記録されます。アイテムごとに、プランには現在のバージョンとターゲットのバージョンとビルド、およびアップグレードが必要かどうかが含まれます。アイテムのアップグレードが必要な場合、プランは影響を受けるインフラストラクチャ・コンポーネント、リブートが必要かどうか、およびアップグレードにかかる時間を示します。

すべてのリブートは、アプライアンスのパフォーマンスと可用性に影響する可能性があります。最小限のリスクと最適な時間の使用のために、アップグレード計画を移入するロジックには、新しいパッケージの詳細な評価が含まれます。多くのパッケージは、リブートせずにアップグレードすることも、サービスのリブートのみを必要とすることもできます。アップグレード計画のリブート・フラグは、コンポーネントを絶対にリブートする必要がある場合にのみ設定されます。

アップグレード・プランは、すべてのアップグレード手順を所定の順序で実行するチェックリストとして機能します。アップグレード・ジョブはアップグレード・コマンドごとに開始されますが、プランでコンポーネントがすでに必要なバージョンにあることが示されている場合は、それ以上のアクションは実行されず、アップグレードはスキップされます。ただし、必要に応じて同じバージョンのアップグレードを強制できます。

アップグレード操作の進行に伴い、アップグレード・プランは現在のステータスを反映するように更新されるため、管理者は、どのコンポーネントがすでにアップグレードされているか、アップグレードが必要なかをいつでも確認できます。アップグレード・プランの各アイテムについて現行バージョンとターゲット・バージョンが同じ場合、システム全体が最新です。

アップグレード中またはアップグレード後に、管理者はジョブ・フレームワークを使用してリクエストおよびジョブのステータスを確認できます。アップグレード・コマンドは、複数のアップグレード・ジョブを含む可能性のあるワークフローをトリガーするアップグレード・リクエストに対応します。ジョブは、一連のタスクで構成されます。これらのすべての要素の詳細は、「サービスWeb UI」または「サービスCLI」を使用して取得できます。アップグレード計画ではある時点のステータスが表示されますが、ジョブ・フレームワークでは、管理者はアップグレード・アクティビティの詳細にドリルダウンしてステータスと履歴を表示できます。これにより、トラブルシューティングも簡単になります。

長期トラッキングのために、メタデータ・ファイルおよびアップグレード計画が保存され、すべてのコンポーネント・アップグレードおよびパッチに関する詳細は、アップグレード・ジョブで取得されます。アップグレード履歴機能を使用すると、管理者はアプライアンスのアップグレードおよびパッチ適用アクティビティにドリルダウンできます。アップグレード履歴には、すべてのアップグレードおよびパッチ情報が分類された方法で表示されるため、実行されたバージョン・アップグレード、それらのアップグレードごとに実行されたジョブ、およびソース(ISOアップグレードまたはULNパッチ)を確認できます。詳細には、ビルド・バージョン、前後のコンポーネント・バージョン、ジョブ完了、成功または失敗、タイムスタンプおよび期間が含まれます。

事前チェック

すべてのアップグレード操作の前に検証プロセスが表示され、システム・コンポーネントがアップグレードする適切な状態になっていることが確認されます。これらの事前チェックでは、アップグレード・メカニズムはプラットフォーム・レベルのヘルス・チェックに依存します。モニタリングのためにヘルス・チェックが継続的に実行されますが、アップグレード操作の前に特に実行する必要があります。管理者は、事前チェックを手動で実行する必要はありません。アップグレード・コマンドを入力すると、アップグレード・コードによって実行されます。単一コンポーネント・アップグレードが選択されている場合でも、すべてのチェックでアップグレードの開始を許可する必要があります。

前提条件となるソフトウェア・バージョンは、2024年1月以降のリリースで適用されます。アップグレードまたはパッチの準備中に、Upgraderサービスは、現在インストールされているアプライアンス・ソフトウェアのバージョンを新しいターゲット・バージョンに対して検証します。アプライアンスが最低限必要なバージョンを実行していない場合、ワークフローは環境を以前の状態にロールバックします。目的のターゲット・バージョンに進む前に、まず最低限必要なバージョンをインストールする必要があります。

アップグレード手順によっては、管理者が最初にプロビジョニング・ロックとメンテナンス・ロックを設定する必要があります。ロックがアクティブである間、プロビジョニング操作やその他の競合するアクティビティは発生しません。つまり、アップグレード・プロセスは潜在的な中断から保護されます。アップグレードが完了したら、メンテナンス・ロックとプロビジョニング・ロックを解放して、システムがフル・オペレーション・モードに戻る必要があります。

フル・ラック・アップグレードやすべてのコンピュート・ノードのアップグレードなど、大規模なコンポジット・ワークフローでは、ロックがプログラムで適用および解放されます。管理者は、コンポーネントを手動でロックおよびロック解除する必要はありませんが、アップグレード・ワークフローで中断の可能性を監視し、ノード・ロックやコンピュート・インスタンスの移行などで問題が発生した場合に修正処理を実行する必要があります。

フル・ラックのアップグレード

アップグレード・ワークフロー・サービス(UWS)は、アップグレード・プロセスにオーケストレーション・レイヤーを追加します。コンポーネントのアップグレードが統合されたワークフローにまとめられるため、管理者は単一のコマンドでアプライアンス全体のアップグレードを開始できます。コンポーネントの選択、順序およびタイミングのアップグレード・ロジックは、アップグレード計画によって決定されます。ワークフローは、リクエストを生成し、関連するジョブの結果をモニタリングすることによって、アップグレード計画を完了するために必要な操作を管理します。

ワークフロー・ベースのアプローチは、完全な管理クラスタをOracle Linux 8に移行するアプライアンス・ソフトウェア・バージョンで導入されています。フル・ラック・アップグレードは、2025年4月以降のすべてのリリースでPrivate Cloud Applianceをアップグレードする優先の方法です。予期しないオーケストレーションの問題または特定のコンポーネント要件の場合、Oracleは、グループまたは個別にコンポーネントをアップグレードする方法に関するガイダンスを提供します。

コンポーネントの順序は、特定のリリースのアップグレード計画によって決まります。ラック・アップグレード・ワークフローには、次のコンポーネントが含まれています:

ZFS Storage Applianceファームウェア(ストレージ・コントローラのILOMを含む)
コンピュート・ノード
管理ノード
- 3ノードのホスト・オペレーティング・システム
- MySQLクラスタ・データベース
- シークレット・サービス(EtcdおよびVaultを含む)
- Kubernetesコンテナ・オーケストレーション・パッケージ(プラットフォーム・レイヤー)
- コンテナ化されたマイクロサービス
Oracle Cloud Infrastructureイメージ
ILOM ファームウェア(すべてのノード)
スイッチ・ファームウェア(すべてのスイッチ)

コンポーネント・アップグレード

Private Cloud Applianceアップグレードはモジュラとして設計されており、運用環境でのサービス中断なしで個々のコンポーネントをアップグレードできます。 Oracleでは、フル・ラックのアップグレード・ワークフローを使用することを強くお薦めしますが、サブセットおよび個々のコンポーネントの手順は特定のシナリオで使用できます。

ZFS Storage Applianceファームウェア

このオプションを使用して、ZFS Storage Applianceのオペレーティング・ソフトウェアをアップグレードします。アクティブ/アクティブのクラスタ構成で動作する両方のコントローラは、同じプロセスの一部としてアップグレードされます。新しいILOMファームウェアが使用可能な場合は、プロセス内の両方のコントローラでもアップグレードされます。
コンピュート・ノード

このオプションを使用して、最新のOracle Linuxカーネルおよびユーザー空間パッケージと、アプライアンス固有のツールおよび最適化をインストールします。ホストIPアドレスを指定して単一ノードをアップグレードするか、アプライアンスにインストールされているすべてのコンピュート・ノードをアップグレードするワークフローを実行できます。同時アップグレードは実行できません。ノードはロックされ、1つずつアップグレードされます。
管理クラスタ

クラスタ化されたMySQLデータベースおよびシークレット・サービス(etcd/Vault)を含む、3つの管理ノードすべてで実行されているホストOSおよびサービスをアップグレードするには、このオプションを使用します。完全管理ノード・クラスタ・アップグレードでは、複数のコンポーネント・アップグレードがグローバル・ワークフローに統合されるため、すべてのジョブは事前定義された順序で実行されます。単一のコマンドで、クラスタ内の3つの管理ノードはすべて、コンポーネントごとに順次アップグレードされます。つまり、グローバル・ワークフローが次のコンポーネント・アップグレードに移行する前に、特定のコンポーネントのアップグレードが3つの管理ノードそれぞれで実行されます。
ホスト・オペレーティング・システム

このオプションを使用して、管理ノードのOracle Linuxオペレーティング・システムをアップグレードします。ホストIPアドレスを指定して単一ノードのホストOSをアップグレードしたり、3つの管理ノードすべてでホストOSを順次アップグレードするワークフローを実行したりできます。
Kubernetesクラスタ

このオプションを使用して、サービスがデプロイされるコンテナ・オーケストレーション環境であるKubernetesクラスタをアップグレードします。 Kubernetesクラスタは、すべての管理ノードおよびコンピュート・ノードで実行されます。アップグレードには、次の3つの主要な操作が含まれます:
- Kubernetesパッケージおよびすべての依存関係のアップグレード: kubeadm、kubelet、kubectlなど。
- Kubernetesコンテナ・イメージのアップグレード: kube-apiserver、kube-controller-manager、kube-proxyなど。
- 非推奨のKubernetes APIおよびサービスYAMLマニフェスト・ファイルを更新しています。
プラットフォーム・サービス

このオプションを使用して、管理ノードのKubernetesクラスタ内で実行されているコンテナ化されたサービスをアップグレードします。サービス・アップグレードのメカニズムは、パッケージ・マネージャと同等のKubernetesであるHelmに基づいています。アップグレードが必要なサービスの場合、新しいコンテナ・イメージおよびHelmデプロイメント・チャートはISOイメージを介して提供され、内部レジストリにアップロードされます。この時点までのいずれの操作も、操作環境には影響しません。

プラットフォーム・レベルでは、サービスを実行するポッドを再起動することでアップグレードがトリガーされます。新しいデプロイメント・チャートが検出され、再起動時にポッドが新しいコンテナ・イメージを取得します。問題が見つかった場合は、サービスを前の作業バージョンのイメージにロールバックできます。

ノート:

特定の状況では、オプションのJSON文字列をコマンドに追加することで、特定のプラットフォーム・サービスを個別にアップグレードできます。このオプションは、Oracleで明示的な手順が提供されないかぎり使用しないでください。
ILOMファームウェア

このオプションを使用して、アプライアンスにインストールされているコンポーネントのOracle Integrated Lights Out Manager (ILOM)ファームウェアをアップグレードします。 IPアドレスを指定して単一のILOMをアップグレードするか、すべてのアプライアンス・コンポーネントのすべてのILOMをアップグレードするワークフローを実行できます。ファームウェアが正常にアップグレードされると、ILOMが自動的にリブートされます。ただし、すべての変更を有効にするには、管理者が手動でサーバーを再起動する必要があります。
スイッチ・ファームウェア

スイッチの動作ソフトウェアをアップグレードするには、このオプションを使用します。アップグレードするスイッチ・カテゴリを指定できます: リーフ・スイッチ、スパイン・スイッチ、または管理スイッチ。アプライアンスにインストールされているすべてのスイッチをアップグレードするワークフローを実行することもできます。
Oracle-提供イメージ

このオプションを使用して、Private Cloud Applianceの最新のOracle Cloud Infrastructureイメージを追加します。不要になった既存のイメージは、手動で削除する必要があります。