1.4.3. クラスター更新時間の推定方法


同様のクラスターの履歴更新期間は、将来のクラスター更新の最適な概算を提供します。過去のデータがない場合は、更新にかかる時間の概算を計算できます。

クラスターの更新時間を見積もるには、以下の方法を使用できます。

Cluster update time = CVO target update payload deployment time + (# node update iterations x MCO node update time)

ノード更新反復は、並行して更新される 1 つ以上のノードで構成されます。コントロールプレーンノードは常に、コンピュートノードと並行して更新されます。さらに、maxUnavailable 値に基づいて、1 つ以上のコンピュートノードを並行して更新できます。

警告

OpenShift Container Platform のすべてのマシン設定プールにおける maxUnavailable のデフォルト設定は 1 です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を 3 に変更しないでください。

たとえば、更新時間を推定するために、制御プレーンノードが 3 つ、コンピュートノードが 6 つある OpenShift Container Platform クラスターを考えてみましょう。各ホストの再起動には約 5 分かかります。

注記

特定のノードの再起動にかかる時間は、大幅に異なります。クラウドインスタンスでは、再起動に約 1 - 2 分かかりますが、物理ベアメタルホストでは、再起動に 15 分以上かかる場合があります。

コントロールプレーンとコンピュートノードの両方のマシン設定プール (MCP) で maxUnavailable を 1 に設定すると、6 つのコンピュートノードすべてが各イテレーションで順番に更新されます。

Cluster update time = 60 + (6 x 5) = 90 minutes

コンピュートノード MCP の maxUnavailable2 に設定するシナリオでは、各イテレーションで 2 つのコンピュートノードが並行して更新されます。したがって、すべてのノードを更新するには合計 3 回の反復が必要です。

Cluster update time = 60 + (3 x 5) = 75 minutes
重要

maxUnavailable のデフォルト設定は、OpenShift Container Platform のすべての MCP で 1 です。コントロールプレーン MCP で maxUnavailable を変更しないことを推奨します。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る