コンテナ事始め(9) 重要なコンテナアプリケーション障害時の自動回復を実現！Dell CSM Resiliency Moduleとは？

前回の投稿「コンテナ事始め(8) Kubernetesワークロードの障害時のふるまい」はこちらから。

こんにちは。デル・テクノロジーズでクラウド、コンテナ関連を担当している平原です。前回はKubernetesのワークロード管理、特にStatefulSetにおける挙動と運用時の課題について説明しましたが、今回はその課題を解決する「Dell CSM Resiliency Module」を紹介したいと思います。

Dell CSM (Container Storage Module) とは？

Dell CSMの各モジュールは、Dell CSIドライバの機能を拡張するサイドカーコンテナです。サイドカーコンテナとは、その名のとおりメインのアプリケーションコンテナと同じPod内で実行されるセカンダリーコンテナで、これによってメインのコンテナをシンプルに保ちながら機能拡張、改善を図ることが可能な仕組みになっています。現在は7つのモジュールを提供しています。

• CSM Authorization：ストレージとKubernetesの管理者に、Dell CSIドライバにRBACを適用する機能を提供
• CSM Observability：Dell CSI (Container Storage Interface) ドライバで管理するボリューム/ファイル共有の容量だけでなく、帯域幅、IOPS、応答時間などのパフォーマンスも可視化。事前にパッケージ化されたGrafanaダッシュボードから、これらのメトリクスの履歴、KubernetesのPV（Persistent Volume）とバックエンドアレイのLUNまたはファイル共有間のトポロジーが確認可能
• CSM Replication：Dellストレージアレイのレプリケーション＆ディザスタリカバリ機能をKubernetesクラスタに導入し、ストレージアレイで利用可能なネイティブレプリケーション・テクノロジーを使用してボリュームグループをレプリケート、計画的および計画外のマイグレーションの際にアプリケーションを再起動する方法を提供
• CSM Resiliency：Kubernetesアプリケーション (永続ストレージを利用するアプリケーションを含む) を、様々な障害に対してより弾力的にするための自動回復機能を提供
• CSM Encryption：暗号化は、Dell CSIドライバによって作成されたボリュームに存在するユーザデータを暗号化する機能を提供
• CSM Application Mobility：Kubernetes管理者に、ステートフルなアプリケーションワークロードとアプリケーションデータを、オンプレミスまたはクラウド上の他のK8sクラスタにクローンする機能を提供 (この機能は現在Tech Previewです)
• CSM Snapshots：Kubernetes APIを拡張し、ボリュームグループのクラッシュコンシステントスナップショットをサポートします。（この機能はPowerFlexおよびPowerStoreドライバのみをサポート）

なお、対応するCSMモジュールはストレージごとに異なるのでこちらで確認ください。

リンク：Supported CSM Modules

Dell CSM Resiliency Module

CSM Resiliency Moduleについてもう少し深堀してみましょう。CSM Resiliency Moduleは “podmon” と呼ばれるサイドカーコンテナによりCSIドライバの機能を拡張し、StatefulSetにおける障害パターンをpodmonが検知することで不要なK8sリソースをクリーンアップし、Workerノード障害におけるPod再起動を自動化します。podmonは下記の障害パターンに対応しています。

• Workerノード障害
• Control Plane (Workerノード上の kubelet) 障害
• Control Planeネットワーク (Master-Workerノード間) 障害
• ストレージアクセス障害
• ドライバ障害

インストール

CSM Resiliency Moduleのインストールは簡単です。以前の投稿「コンテナ事始め(6) PowerScaleをOpenShiftのPersistent Volumeに利用する」で説明したCSIドライバインストール手順のなかで使用したCRDファイル中、対応するCSM Moduleエントリをenableにするだけです。

導入した状態はCSIドライバのみを導入した時と変わらないのですが、CSIドライバが含まれるPodの詳細（中身）を見てみると ”podmon” という文字列が見つかります。この podmon がサイドカーコンテナとしてStatefulSet障害の監視、切り分け、回復処理を行ないます。

動作検証

実際にStatedulSetのみと、CSM Resiliency Moduleを連携させたStatefulSetでの挙動の違いを見てみましょう。

まず、Podのデプロイを行います。標準のStatefulSetでのデプロイとCSM Resiliency Moduleと連携したStatefulSetでのデプロイの2パターンです。CSM Resiliency Moduleと連携させるにはオリジナルのStatefulSetのyamlファイルにある “labels:” に “podmon.dellemc.com/driver: csi-isilon” の一行を追加するだけです。

デプロイされたPodがこのラベル情報で取得できれば成功です。

では、両方のStatefulSetのPodが動いているWorkerノード (末尾 -c7t5f) をシャットダウンし、障害を再現してみます。

下図のようにCSM Resiliency Moduleと連携したStatefulSetでは自動的にPod再起動処理が行われましたが、標準のStatefulSetのほうはずっとTerminate処理のまま止まった状態になっていることが分かります。ちなみにWorkerノードVMのvNICを切断する「半死」状態も再現しましたが同様の結果となりました。

いかがでしょうか？これと同様の処理はOSSのkube-fencingという機能でも出来ないことはないのですが、調べた限りではストレージ側の処理に関与できないことから、特にRWOのPersitent Volume Claimのデタッチ処理まで自動化できず、完全なPod回復の自動化とまではいかない印象を持ちました。例えば、良く知られているコンテナアプリケーションの一つであるElasticSearchなどは処理の高速性からnfs (RWX) によるPersistent Volumeをサポートしておらず、ブロックストレージ (RWO) を使うことを求められています。当社ストレージ製品と組み合わせることで、こうしたクリティカルな要件を必要とするコンテナアプリケーションに対して、今回紹介したエンドツーエンドの自動化を提供できるのはまさにエンタープライズストレージ領域で実績のある当社ならではの価値とも言えます。

当社CSIドライバのもう一つの価値

一般的にストレージベンダー各社が提供するCSIドライバはOSSとして公開しており、ドライバ使用時におけるサポートがコミュニティレベルのサポートに留まる場合もあるようです。一方、当社のCSI Driver/CSM Moduleは導入および使用時における問題に関して当社ストレージ製品のサポート契約の中で問い合わせを行うことが可能です。こういった安心感も当社ならではと言えるかもしれません。

Dell CSM Moduleはこの他にも有用な機能があるので引き続き紹介できればと思います。