Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

5.8. OpenShift Data Foundation ストレッチクラスターのリカバリー

ストレッチクラスターの障害復旧のソリューションでは、完全または部分的なサイトの停止に直面しても回復性を提供することを考えると、アプリケーションとそのストレージのさまざまな復旧方法を理解することが重要です。

アプリケーションがどのように設計されているかによって、アクティブゾーンで再び利用できるようになるまでの時間が決まります。

サイトの停止に応じて、アプリケーションとそのストレージの復旧方法は異なります。復旧時間は、アプリケーションのアーキテクチャーによって異なります。復旧のさまざまな方法は以下のとおりです。

5.8.1. ゾーンの障害について
リンクのコピー

このセクションでは、ゾーン障害は、ゾーン内のすべての OpenShift Container Platform、マスターノード、およびワーカーノードが 2 番目のデータゾーンのリソース (たとえば、電源がオフになっているノード) と通信しなくなった障害と見なされます。データゾーン間の通信がまだ部分的に機能している (断続的にアップまたはダウンしている) 場合、回復を成功させるには、クラスター、ストレージ、およびネットワーク管理者がデータゾーン間の通信パスを切断する必要があります。

重要

サンプルアプリケーションをインストールする場合は、OpenShift Container Platform ノード (OpenShift Data Foundation デバイスを使用するノード) の電源をオフにし、file-uploader アプリケーションが利用可能であることを検証するためにデータゾーンの失敗をテストし、新しいファイルをアップロードします。

5.8.2. RWX ストレージのあるゾーン対応の HA アプリケーションの復旧
リンクのコピー

topologyKey: topology.kubernetes.io/zone を使用してデプロイされ、データゾーンごとに 1 つ以上のレプリカがスケジュールされており、共有ストレージ (ReadWriteMany (RWX) CephFS ボリューム) を使用しているアプリケーションは、障害のあったゾーンで数分後に自身で中断し、新しい Pod が起動し、ゾーンが復元されるまで Pending の状態で停止します。

このタイプのアプリケーションの例は、ゾーン対応サンプルアプリケーションのインストール セクションを参照してください。

重要

ゾーンのリカバリー中に、CephFS ボリュームのマウント中にアプリケーション Pod がアクセス許可拒否エラーにより CrashLoopBackOff (CLBO) 状態になった場合は、Pod がスケジュールされているノードを再起動します。しばらく待ってから、Pod が再び実行されているかどうかを確認します。

5.8.3. RWX ストレージを使用する HA アプリケーションの復旧
リンクのコピー

topologyKey: kubernetes.io/hostname を使用している、またはトポロジー設定をまったく使用していないアプリケーションは、同じゾーンにあるすべてのアプリケーションレプリカに対する保護がありません。

注記

これは、Pod 仕様の podAntiAffinity および topologyKey: kubernetes.io/hostname でも発生する可能性があります。これは、この非アフィニティールールがホストベースであり、ゾーンベースではないためです。

これが発生し、すべてのレプリカが障害のあるゾーンにある場合、ReadWriteMany (RWX) ストレージを使用するアプリケーションはアクティブゾーンで回復するのに 6-8 分の時間がかかります。この一時停止は、障害が発生したゾーンの OpenShift Container Platform ノードが NotReady(60 秒) になり、デフォルトの Pod エビクションタイムアウトが期限切れ (300 秒) になるためです。

5.8.4. RWO ストレージを使用したアプリケーションの復旧
リンクのコピー

ReadWriteOnce (RWO) ストレージを使用するアプリケーションには、この Kubernetes の問題 で説明されている既知の動作があります。この問題のため、データゾーンに障害が発生した場合は、RWO ボリュームをマウントしているそのゾーンのアプリケーション Pod(例: cephrbd ベースのボリューム) は 6〜8 分後に Terminating ステータスのままになり、手動の介入なしではアクティブゾーンに再作成されません。

ステータスが NotReady の OpenShift Container Platform ノードを確認します。ノードが OpenShift コントロールプレーンと通信できない問題が生じる可能性があります。ただし、ノードは永続ボリューム (PV) に対して I/O 操作を実行している可能性があります。

2 つの Pod が同じ RWO ボリュームに同時に書き込む場合は、データ破損のリスクが発生します。NotReady ノードのプロセスが終了するか、終了するまでブロックされていることを確認します。

ソリューションの例:

  • 帯域外管理システムを使用してノードの電源をオフにし、確認を行うことは、プロセスを確実に終了させる例です。

  • 障害が発生したサイトのノードによってストレージとの通信に使用されるネットワークルートを無効します。

    注記

    障害のあるゾーンまたはノードにサービスを復元する前に、PV が指定されたすべての Pod が正常に終了していることを確認します。

Terminating Pod がアクティブなゾーンで再作成されるようにするには、Pod を強制的に削除するか、関連付けられた PV でファイナライザーを削除します。これら 2 つのアクションのいずれかが完了すると、アプリケーション Pod がアクティブゾーンで再作成され、その RWO ストレージが正常にマウントされます。

Pod を強制的に削除

強制削除は、Pod が終了したという kubelet からの確認を待ちません。 

$ oc delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>
Copy to Clipboard Toggle word wrap
<PODNAME>
Pod の名前です。
<NAMESPACE>
プロジェクトの namespace です。
関連付けられた PV のファイナライザーの削除

Terminating Pod によってマウントされる永続ボリューム要求 (PVC) に関連付けられた PV を見つけ、oc patch コマンドを使用してファイナライザーを削除します。 

$ oc patch -n openshift-storage pv/<PV_NAME> -p '{"metadata":{"finalizers":[]}}' --type=merge
Copy to Clipboard Toggle word wrap
<PV_NAME>

Pod の名前です。

関連付けられた PV を見つける簡単な方法として、Terminating Pod を記述することができます。複数割り当ての警告が表示される場合は、PV 名が警告に含まれるはずです (例: pvc-0595a8d2-683f-443b-aee0-6e547f5f5a7c)。 

$ oc describe pod <PODNAME> --namespace <NAMESPACE>
Copy to Clipboard Toggle word wrap
<PODNAME>
Pod の名前です。
<NAMESPACE>

プロジェクトの namespace です。

出力例: 

[...]
Events:
  Type     Reason                  Age   From                     Message
  ----     ------                  ----  ----                     -------
  Normal   Scheduled               4m5s  default-scheduler        Successfully assigned openshift-storage/noobaa-db-pg-0 to perf1-mz8bt-worker-d2hdm
  Warning  FailedAttachVolume      4m5s  attachdetach-controller  Multi-Attach error for volume "pvc-0595a8d2-683f-443b-aee0-6e547f5f5a7c" Volume is already exclusively attached to one node and can't be attached to another
Copy to Clipboard Toggle word wrap

5.8.5. StatefulSet Pod の復旧
リンクのコピー

ステートフルセットの一部である Pod には、ReadWriteOnce (RWO) ボリュームをマウントする Pod と同様の問題があります。詳細は、Kubernetes リソースの StatefulSet considerations を参照してください。

6-8 分後にアクティブなゾーンで再作成するために StatefulSet の Pod 部分を取得するには、RWO ボリュームを持つ Pod と同じ要件 (つまり、OpenShift Container Platform ノードの電源オフまたは通信が切断されている) で Pod を強制的に削除する必要があります。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

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

会社概要

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

Theme

© 2025 Red Hat