機械翻訳について
  1. 概要ガイド
  2. アプライアンス管理の概要
  3. アップグレード

アップグレード

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

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

管理者は、「サービスWeb UI」または「サービスCLI」を使用してアップグレードを実行でき、2つの使用可能なオプションのいずれかを選択する必要があります: 個々のコンポーネントのアップグレードまたはフル管理ノードのクラスタのアップグレード。

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

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

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

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

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

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

事前チェック

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

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

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

単一コンポーネントのアップグレード

Private Cloud Applianceアップグレードはモジュール化するように設計されているため、システム全体ではなく個々のコンポーネントを一度にアップグレードできます。 単一コンポーネントのアップグレードでは、次のコンポーネント・オプションを使用できます:

  • ILOMファームウェア

    このオプションを使用して、アプライアンス内の特定のサーバーのOracle Integrated Lights Out Manager (ILOM)ファームウェアをアップグレードします。 ファームウェアが正常にアップグレードされると、ILOMが自動的にリブートされます。 ただし、すべての変更を有効にするには、管理者が手動でサーバーを再起動する必要があります。

  • スイッチ・ファームウェア

    スイッチの動作ソフトウェアをアップグレードするには、このオプションを使用します。 アップグレードするスイッチ・カテゴリを指定する必要があります: リーフ・スイッチ、スパイン・スイッチ、または管理スイッチ。

  • ZFS Storage Applianceファームウェア

    このオプションを使用して、ZFS Storage Applianceのオペレーティング・ソフトウェアをアップグレードします。 アクティブ/アクティブのクラスタ構成で動作する両方のコントローラは、同じプロセスの一部としてアップグレードされます。

  • ホスト・オペレーティング・システム

    このオプションを使用して、管理ノードのOracle Linuxオペレーティング・システムをアップグレードします。 選択した管理ノードでyumアップグレードをトリガーし、ISOイメージを介して移入されたyumリポジトリを使用するように構成されます。

  • クラスタMySQLデータベース

    すべての管理ノードでMySQLデータベースをアップグレードするには、このオプションを使用します。 データベースのインストールはrpmベースであるため、ISOイメージを介して移入されるyumリポジトリに依存します。 データベースのアップグレードのタイミングは重要であるため、データベースのパッケージは意図的にホスト・オペレーティング・システムのアップグレードから除外されます。 データベース・アップグレード・ワークフローは、バックアップ操作およびクラスタ状態を管理し、関連するサービスを停止および再起動します。 これにより、すべてのステップが各管理ノードで正しい順序で実行されます。

  • Kubernetesクラスタ

    このオプションを使用して、サービスがデプロイされるコンテナ・オーケストレーション環境であるKubernetesクラスタをアップグレードします。 Kubernetesクラスタは、すべての管理ノードおよびコンピュート・ノードで実行されます。アップグレードには、次の3つの主要な操作が含まれます:

    • Kubernetesパッケージおよびすべての依存関係のアップグレード: kubeadm、kubelet、kubectlなど。

    • Kubernetesコンテナ・イメージのアップグレード: kube-apiserver、kube-controller-manager、kube-proxyなど。

    • 非推奨のKubernetes APIおよびサービスYAMLマニフェスト・ファイルを更新しています。

  • シークレット・サービス

    すべての管理ノードでシークレット・サービスをアップグレードするプロセスは、2つの部分で構成されます。 これには、2つの主要なシークレット・サービス・コンポーネントのローリング・アップグレードが含まれます: etcdキー・バリュー・ストアとボールト・シークレット・マネージャ。 レジストリで利用可能な新しいイメージ・ファイルを使用して、どちらも互いに独立してアップグレードされますが、必須の順序でアップグレードされます: まずはetcd、次にVault。

  • プラットフォーム・サービス

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

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

    ノート:

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

  • コンピュート・ノード

    このオプションを使用して、コンピュート・ノードでOracle Linuxオペレーティング・システムのyumアップグレードを実行します。 アップグレードには、仮想マシン操作およびハイパーバイザ機能を最適化するためのアプライアンス固有のコードを含むovm-agentパッケージが含まれます。 コンピュート・ノードを1つずつアップグレードする必要があります。同時にアップグレード操作を行うことはできません。

完全管理ノード・クラスタのアップグレード

個々のコンポーネントのアップグレードは、主に自己完結型です。 完全な管理ノード・クラスタ・アップグレードは、これらのコンポーネント・アップグレードをグローバル・ワークフローに統合して、事前定義された順序でコンポーネント・アップグレードを実行します。 単一のコマンドで、クラスタ内の3つの管理ノードはすべて、コンポーネントごとに順次アップグレードされます。 これは、グローバル・ワークフローが次のコンポーネント・アップグレードに移動する前に、3つの管理ノードのそれぞれで特定のコンポーネントのアップグレードが実行されることを意味します。

コンポーネントがアップグレードされる順序は、依存関係のために事前定義されており、変更することはできません。 完全な管理ノード・クラスタのアップグレード中に、次のコンポーネントがアップグレードされます:

  1. 管理ノードのホスト・オペレーティング・システム

  2. クラスタ化されたMySQLデータベース

  3. シークレット・サービス(EtcdおよびVault)

  4. Kubernetesコンテナ・オーケストレーション・パッケージ

  5. プラットフォーム・レイヤー・コンテナ化されたマイクロサービス

  6. Oracle Cloud Infrastructureイメージ