Recovering a Metro-DR stretch cluster
Red Hat OpenShift Data Foundation での大規模な障害からアプリケーションとそのストレージを復旧する方法に関する説明
概要
前書き
大規模な障害復旧のストレッチクラスターでは、完全または部分的なサイトの停止に直面しても回復性を提供することを考えると、アプリケーションとそのストレージのさまざまな復旧方法を理解することが重要です。
アプリケーションがどのように設計されているかによって、アクティブゾーンで再び利用できるようになるまでの時間が決まります。
サイトの停止に応じて、アプリケーションとそのストレージの復旧方法は異なります。復旧時間は、アプリケーションのアーキテクチャーによって異なります。復旧のさまざまな方法は以下のとおりです。
第1章 ゾーンの障害について
このセクションでは、ゾーン障害は、ゾーン内のすべての OpenShift Container Platform、マスターノード、およびワーカーノードが 2 番目のデータゾーンのリソース (たとえば、電源がオフになっているノード) と通信しなくなった障害と見なされます。データゾーン間の通信がまだ部分的に機能している (断続的にアップまたはダウンしている) 場合、回復を成功させるには、クラスター、ストレージ、およびネットワーク管理者がデータゾーン間の通信パスを切断する必要があります。
第2章 RWX ストレージのあるゾーン対応の HA アプリケーションの復旧
topologyKey: topology.kubernetes.io/zoneでデプロイされ、各データゾーンで 1 つ以上のレプリカがスケジュールされ、共有ストレージ (つまり ReadWriteMany (RWX) CephFS ボリューム) を使用しているアプリケーションは、新しい接続に対して 30〜60 秒以内にアクティブゾーンで回復します。ルーター Pod が失敗したデータゾーンでオフラインになると、HAProxy が接続を更新する短い一時停止です。
このタイプのアプリケーションの例は、Install Zone Aware Sample Application セクションを参照してください。
サンプルアプリケーションをインストールする場合は、OpenShift Container Platform ノード (OpenShift Data Foundation デバイスを使用するノード) の電源をオフにし、file-uploader アプリケーションが利用可能であることを検証するためにデータゾーンの失敗をテストし、新しいファイルをアップロードします。
第3章 RWX ストレージを使用する HA アプリケーションの復旧
topologyKey: kubernetes.io/hostname を使用している、またはトポロジー設定をまったく使用していないアプリケーションは、同じゾーンにあるすべてのアプリケーションレプリカに対する保護がありません。
これは、Pod 仕様の podAntiAffinity および topologyKey: kubernetes.io/hostname でも発生する可能性があります。これは、この非アフィニティールールがホストベースであり、ゾーンベースではないためです。
これが発生し、すべてのレプリカが障害のあるゾーンにある場合、ReadWriteMany (RWX) ストレージを使用するアプリケーションはアクティブゾーンで回復するのに 6-8 分の時間がかかります。この一時停止は、障害が発生したゾーンの OpenShift Container Platform ノードが NotReady(60 秒) になり、デフォルトの Pod エビクションタイムアウトが期限切れ (300 秒) になるためです。
第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>
<PODNAME>- Pod の名前です。
<NAMESPACE>- プロジェクトの namespace です。
- 関連付けられた PV のファイナライザーの削除
Terminating Pod によってマウントされる Persistent Volume Claim (PVC) に関連付けられた PV を見つけ、
oc patchコマンドを使用してファイナライザーを削除します。$ oc patch -n openshift-storage pv/<PV_NAME> -p '{"metadata":{"finalizers":[]}}' --type=merge<PV_NAME>Pod の名前です。
関連付けられた PV を見つける簡単な方法として、Terminating Pod を記述することができます。複数割り当ての警告が表示される場合は、PV 名が警告に含まれるはずです (例:
pvc-0595a8d2-683f-443b-aee0-6e547f5f5a7c)。$ oc describe pod <PODNAME> --namespace <NAMESPACE>
<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
第5章 StatefulSet Pod の復旧
ステートフルセットの一部である Pod には、ReadWriteOnce (RWO) ボリュームをマウントする Pod と同様の問題があります。詳細は、Kubernetes リソース StatefulSet の考慮事項 で参照されます。
6-8 分後にアクティブなゾーンで再作成するために StatefulSet の Pod 部分を取得するには、RWO ボリュームを持つ Pod と同じ要件 (つまり、OpenShift Container Platform ノードの電源オフまたは通信が切断されている) で Pod を強制的に削除する必要があります。
