コンテナ事始め(10) KubernetesのDR運用簡素化を実現するDell CSM Replication Moduleとは？

前回の投稿（コンテナ事始め(9) 重要なコンテナアプリケーションの自動回復を実現するDell CSM Resiliency Moduleとは？）はこちらから。

こんにちは。デル・テクノロジーズでクラウド、コンテナ関連を担当している平原です。業務がバタバタして、暫く間が開いてしまいましたが、今回はKubernetesにおけるDR運用の課題を解決する「Dell CSM Replication Module」を紹介したいと思います。

KubernetesのDR対策とは？

先日、お客様とOpenShiftに関するワークショップを行った際、DR対策に関する話題が出てきました。Red Hatさんのブログ記事 (A Guide to High Availability/Disaster Recovery for Applications on OpenShift) を参考にディスカッションしたのですが、そこでDRシナリオの例を想定してみました。

1. 2つのK8sクラスタをActive/Passiveで運用します
2. K8s #1にStatefulSetをデプロイします。PV/PVC/ストレージボリュームが作成されます
3. K8sクラスタ間でストレージボリュームのレプリケーションを作成します
4. レプリケートされたストレージボリュームはK8s #2で認識できないので、これをK8s #2に取り込むためにPVを作成します
5. さらにK8s #2にStatefulSetをデプロイすることを想定して、PVCを事前に作成し、前のステップで作成したPVと紐づけします
6. DR発動後、レプリケーションをフェイルオーバー、K8s #2にStatefulSetをデプロイします
7. LBを切り替えます

非常にラフですが、こんなシナリオを考えた時に③～⑤のステップが結構面倒そうだなという認識になりました。そこで何か解決策はないものだろうかということで思い当たったのが当社のCSM Replication Moduleでした。

Dell CSM Replication Module

Dell CSIドライバとDell CSM (Container Storage Module) の関係性については、前の投稿記事で説明していますのでここでは割愛します。Dell CSM Replication ModuleはCSMの一機能であり、ミッションクリティカルなアプリケーションの高可用性アーキテクチャの実装を支援し、DR計画の重要なコンポーネントとなるものです。大まかには下記の処理を自動化します。

• サイト間のストレージレプリケーションをサポートするK8sストレージクラスにより、メインサイトのPV作成と同時にサイト間のストレージボリュームレプリケーション構成を自動化します
• サイト間でPVに関するアノテーション（≒メタ情報）を共有し、レプリケートされたストレージボリュームのPVを自動で作成。DRサイトのK8sクラスタから認識可能な状態にします
• Replication Moduleが提供するrepctl CLIとアノテーションを使用して、DRサイトのK8sクラスタの任意のネームスペースにPVに対応するPVCを容易に作成します

図らずもディスカッションで話題になったステップ省力化を実現するうえでの機能を提供するのが、Dell CSM Replication Moduleなのです。

インストール

では、実際の動きをスクリーンショットで見てみましょう。今回の構成も自宅環境を使用しているので、2つのOpenShiftクラスタとOneFS Simulatorをそれぞれ準備しました。OneFS Simulator間はSyncIQを事前に有効にしておきます。

まず、csm-replicationをgit cloneし、repctlをコンパイルします

git clone -b v1.8.0 https//github.com/dell/csm-replication.git

cd csm-replication/repctl

make build

repctlにOpenShiftクラスタを登録します

repctl cluster add -f “クラスタ#1のkubeconfig絶対パス","クラスタ#2のkubeconfig絶対パス" -n "クラスタ#1名","クラスタ#2名”

repctl cluster add -f  "/root/ocp1/auth/kubeconfig","/root/ocp2/auth/kubeconfig"-n "ocp1","ocp2”

次にレプリケーション制御用のCRDとPodを作成します。yamlファイルはgit cloneしてきた中のdeployディレクトリ中にあります

repctl create -f deploy/replicationcrds.all.yaml repctl create -f deploy/controller.yaml

作成されたCRDとPodは2つのクラスタ上のOpenShiftコンソールで確認ができます

この時点ではReplication Controller Podは正常動作していないので、repctlに登録したクラスタ情報を投入します

repctl cluster inject

2つのOpenShiftクラスタ上にサンプルのyamlファイルをカスタマイズして、ストレージクラスを作成します。サンプルは ./repctl/examples の中の powerscale_example_values.yaml です

repctl create sc --from-config powerscale_values.yaml

作成されたストレージクラスをrepctl CLIで確認します

repctl get sc

OpenShiftコンソールでも確認できます。yamlファイルを読むと上記のようにたすき掛け構成で作成されています

ここまでが下準備です。いよいよCSM Replication Moduleのインストールです。これまでのCSM Operatorを使ったインストールがうまくいかなかったので、今回はHelmインストーラを使用しました。

csi-powerscaleをgit cloneします

git clone -b v2.10.1 https//github.com/dell/csi-powerscale.git

ディレクトリ csi-powerscale に移動します

ocp1に oc login します

ネームスペースisilonを作成します

oc create namespace isilon

サンプルのsecret.yamlファイルをカスタマイズし、シークレットを作成します。サンプルは ./samples/secret の中の secret.yaml です

kubectl create secret generic isilon-creds -n isilon --from-file=config=secret.yaml

また、empty-secret.yamlファイルからもシークレットを作成します

kubectl create -f empty-secret.yaml

ディレクトリ dell-csi-helm-installer に移動します

values.yamlをダウンロードします。ここではmy-isilon-settings.yamlの名前で保存しています

my-isilon-settings.yamlをカスタマイズします。Replication Moduleを有効にするにはreplication.enabledをtrueにします

インストールスクリプトを実行します

./csi-install.sh --namespace isilon --values my-isilon-settings.yaml

ocp2にもoc loginし、同様の手順でReplication Moduleをインストールします。この時のscret.yamlは先にターゲットの情報、次にソースの情報を記述します

動作検証

では、実際にReplication Moduleの動作を見てみましょう。ocp1側に簡単なCentOS環境をStatefulSetでデプロイします

暫くするとocp1で作成された同じ名前のPVがocp2上にも現れました

OneFS Simulator上でも確認してみます。それぞれのOneFS Simulator上にPVと同じ名前のNFSエクスポートが作成され、SyncIQポリシーでレプリケーションが構成されています

repclt CLIでこの状況を確認します。同一ネームスペース上に作成されたPVはRG (Replication Group) という単位で管理されているのが分かります。ファイルオーバー操作もこのRGに対して実行します

repctl get rg

repctl get pv

ポンチ絵で表すと、この状態までがReplication Moduleによって自動で構成されたことが分かります

では、ocp2上でフェイルオーバーを実行します。レプリケーションのステータスがSYNCHRONIZEDからFAILEDOVERに変わりました

repctl --rg RG名 failover --target ターゲットocpクラスタ名

repctl --rg rg-c8618a65-e962-4796-ae80-3a7d521dcac1 failover --target ocp2

次にocp2上にocp1と同じStatefulSetをデプロイするために、デプロイ先のネームスペースに対してPVCを作成します。そうすると、ocp2-kazuhネームスペースにocp1と同じPVCが作成されたことが分かります。また、PVCとPVのマッピングも正しく維持されています

repctl create pvc --rg RG名 -t ネームスペース --clusters ターゲットocpクラスタ名

repctl create pvc --rg rg-c8618a65-e962-4796-ae80-3a7d521dcac1 -t ocp2-kazuh --clusters ocp2

これはターゲットにレプリケーションされたPVに、Replication Moduleのコントローラーが付与したアノテーション（メタ情報みたいなもの）をもとにrepctlがPVCを作成したということですね

ocp2上のocp2-kazuhネームスペースにocp1で使ったyamlファイルでStatefulSetをデプロイします。2つのPodにそれぞれPVCがマウントされ、ocp1上で書き込んだファイルが確認できました

さらにocp2上に何かファイルを書き込んでフェイルバックすると、ocp1にその状態が反映されます

repctl --rg RG名 failback --target ソースocpクラスタ名

repctl --rg rg-c8618a65-e962-4796-ae80-3a7d521dcac1 failback --target ocp1

いかがでしょうか？お客様のコンテナへの関心は以前より確実に高まっていると感じます。そうした状況を背景に永続ストレージを必須とするステートフルアプリケーションの管理をいかに簡素化するかは重要な検討事項になってくると思われます。当社のCSI/CSM Moduleがこうしたニーズに応えられるものであることをご理解いただけると幸いです。次回以降は、脱VMwareで話題にもなってきているOpenShift Virtualizationを取り上げてみたいなと思っています