Red Hat Summit5.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>
<PODNAME>- Pod の名前です。
<NAMESPACE>- プロジェクトの namespace です。
- 関連付けられた PV のファイナライザーの削除
Terminating Pod によってマウントされる永続ボリューム要求 (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.8.5. StatefulSet Pod の復旧
StatefulSet の一部である Pod には、ReadWriteOnce (RWO) ボリュームをマウントする Pod と同様の問題があります。詳細は、Kubernetes リソースの StatefulSet considerations を参照してください。
6-8 分後にアクティブなゾーンで再作成するために StatefulSet の Pod 部分を取得するには、RWO ボリュームを持つ Pod と同じ要件 (つまり、OpenShift Container Platform ノードの電源オフまたは通信が切断されている) で Pod を強制的に削除する必要があります。
