5.4. クラスター更新時間の概算


同様のクラスターの履歴更新期間は、将来のクラスター更新の最適な概算を提供します。ただし、履歴データが利用できない場合は、次の規則を使用してクラスターの更新時間を概算することができます。

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

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

例えば、更新時間を概算するには、3 つのコントロールプレーンノードと 6 つのコンピュートノードを持つ OpenShift Container Platform クラスターがあり、各ホストの再起動に約 5 分かかるとします。

注記

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

シナリオ 1:

コントロールプレーンとコンピュートノードの Machine Config Pool (MCP) の両方で maxUnavailable1 に設定すると、6 つのコンピュートノードすべてが反復ごとに次々と更新されます。

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

シナリオ 2

コンピュートノード 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 をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

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

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

会社概要

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

© 2024 Red Hat, Inc.