未解決
1 Rookie
•
65 メッセージ
0
53
コンテナ事始め(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シナリオの例を想定してみました。
- 2つのK8sクラスタをActive/Passiveで運用します
- K8s #1にStatefulSetをデプロイします。PV/PVC/ストレージボリュームが作成されます
- K8sクラスタ間でストレージボリュームのレプリケーションを作成します
- レプリケートされたストレージボリュームはK8s #2で認識できないので、これをK8s #2に取り込むためにPVを作成します
- さらにK8s #2にStatefulSetをデプロイすることを想定して、PVCを事前に作成し、前のステップで作成したPVと紐づけします
- DR発動後、レプリケーションをフェイルオーバー、K8s #2にStatefulSetをデプロイします
- 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を取り上げてみたいなと思っています