SB C&Sの最新技術情報 発信サイト

C&S ENGINEER VOICE

CohesityでKubernetes環境をバックアップ 実践編

データマネジメント
2021.10.05

こんにちは。SB C&S 中原です。

前回、こちらの記事(入門編)Kubernetes環境を保護することの重要さや、Kubernetesの基礎的なコンポーネントについてご紹介しました。 今回はCohesityでバックアップを取得するための準備、ならびにバックアップ・リカバリの実行について解説したいと思います。

検証環境

検証を行った環境は下図の通りです。 今回はオンプレミスに環境を用意しました。
chsty-env.png

Cohesity C4500: 4ノードでクラスタリングしています。バージョンは6.6.0b_p1(patch:p5)です。

Kubernetesクラスタ: Masterノード1台、Workerノード2台の計3台でクラスタリングしています。 クラスタ上に「nginx-test」というNamespaceを作成し、NginxのPodをデプロイしてあります。 今回はこちらをバックアップ・リカバリの対象としたいと思います。

レジストリ: オンプレミス上にプライベートレジストリを用意しました。 Kubernetesクラスタとは別のUbuntuホストを用意し、Docker上で「DockerRegistry2.0」を稼働させています。

なおNginxのPodはKubernetesクラスタ上に存在していますので、動作確認のためクラスタ外部からPodへの接続ができるようにしてあります。 ここではその手段としてService(SVC)の「NodePort」を利用しており、<WorkerノードのIPアドレス>:30001でNginxにアクセスできるように設定しています。
chsty-nginx-svc.png
さらに、今回はPVCを含めたバックアップ・リカバリの動作を確認したいため、以下のようにStorageClassを利用してNginxのPodにNFSの領域を提供しています。(今回はNFS用のStorageClassを作成するために「NFS subdir external provisioner」を利用しています。) NginxのPodをデプロイする際にパス/usr/share/nginx/htmlにNFSの領域がマウントされるように設定しています。
chsty-env3.png

NFSサーバー側の状態も見ておきましょう。 ディレクトリ「nginx-test-nginx-...」に「index.html」を格納しており、このディレクトリがPod「nginx-test」にマウントされています。
chsty-nginx-nfs.png以上の設定により、Kubernetesクラスタ外部からWebブラウザで<WorkerNode_IPアドレス>:30001にアクセスするとこの「index.html」のデータが表示されるという仕組みになっています。
chsty-nginx-index_mod.png

 

事前準備

KubernetesクラスタをCohesityにソース(Source)として登録する前に、前述のコンポーネントそれぞれで事前準備を行う必要があります。

(1) ServiceAccountの作成、ベアラートークンの確認

CohesityによりKubernetesクラスタを保護するためには、CohesityKubernetesクラスタ上のリソースにアクセスできるようにしておく必要があります。そこでKubernetes側でServiceAccountと呼ばれるユーザーを作成し、それに紐づくベアラー(Bearer)トークンを確認します。

本項の作業はバックアップ対象のKubernetesクラスタ上で行います。 またご紹介するコマンドは一例です。 まずは以下のコマンドを実行しServiceAccountcohesity」を作成します。
 kubectl create serviceaccount cohesity -n default

作成したServiceAccountにロール「cluster-admin」を割り当てます。 このロールはクラスタ内およびすべてのNamespace内のリソースを制御できるというものです。
 kubectl create clusterrolebinding cohesity-admin --clusterrole=cluster-admin --serviceaccount=default:cohesity

前述のkubectl create serviceaccountコマンドを実行することで、当該のServiceAccount に紐づくSecret(資格情報)が作成されます。 このSecretからベアラートークンを確認します。
 kubectl describe secrets -n default cohesity-token | grep token: | awk '{print $2}' | head -1
chsty-barertoken.png
このコマンド実行によって得られた文字列は、KubernetesクラスタをCohesityにソース登録する際に利用します。

(2) Dockerイメージの準備

入門編」でレジストリが必要になるということをご説明しましたが、まずはその理由を確認しておきましょう。 理由はKubernetesクラスタをCohesityにソース登録する際の挙動にあります。 ソース登録するとKubernetesクラスタがどのような構成になるかを見てみましょう。
chsty-env2.png

KubernetesクラスタをCohesityにソース登録すると、当該Kubernetesクラスタ上に「cohesity-<CohesityのクラスタID>」というNamespaceが作成され、VeleroPod1台、DataMoverPodが各Workerノード上に1台ずつデプロイされます。(これらの処理は自動で行われます。) CohesityKubernetes環境をバックアップする時にはVeleroDataMoverが併用されます。「DataMover」のPodはCohesityが提供するイメージを元に作成されますので、レジストリを利用してKubernetesクラスタがDataMoverのイメージを利用できるようにしておく必要があります。

レジストリにDataMoverのイメージを登録する作業の流れとしては以下の通りです。
chsty-regImage.png① DataMoverはCohesity Support Portaltarファイルとして提供されています。 これをダウンロードしてdockerコマンドを利用できる環境にコピーします。(ここではレジストリにイメージを登録するだけですので、操作する環境はバックアップ対象のKubernetesクラスタでなくても構いません。KubernetesではなくDockerのみが稼働するホストでも構いません。もちろん、バックアップ対象のKubernetesクラスタ上で操作しても問題ありません。)

② docker loadコマンドでtarファイルをDockerイメージとして展開します。 その後でdocker imagesコマンドを実行すると、この環境ではイメージID「92a252e78aaa」が付与されたことが確認できます。
chsty-dockercmd1.png③ docker image tagコマンドでイメージID「92a252e78aaa」に対してタグを付与します。 今回利用するレジストリの名称は「u-reg.cohesity.local」です。 またイメージ名は「cohesity-datamover」、タグは「6.6.0x-latest」("x"は利用しているバージョンに合わせて変更します。今回は6.6.0bを利用しているため「6.6.0b-latest」とします。) にする必要があります。

④ タグ付けしたイメージをdocker pushコマンドでレジストリにアップロードします。
chsty-dockercmd2.png

これでレジストリがDataMoverのイメージを提供できるようになりました。2回目の「docker images」コマンドの結果に「u-reg.cohesity.local/cohesity-datamover」とあります。 これをCohesityが利用します。

なお、Veleroに関してはパブリックに公開されているイメージを利用しますので、Veleroのイメージを自身のレジストリに登録しておく必要はありません。

(3) Cohesityの機能有効化

CohesityによるKubernetes保護機能はリリースされてから日が浅く、バージョン6.6.0時点では「TechPreview」として扱われています。 このためデフォルトでは機能が有効化されておらず、Cohesityサポートに問い合わせを行った上で機能を有効化する必要があります。 この際、以下の情報が必要になりますので準備しておきましょう。

DataMoverイメージの在り処: 手順(2)で準備したものです。本検証では「u-reg.cohesity.local/cohesity-datamover」です。

Cohesityのadminユーザー: Cohesityのユーザーには自動でS3アクセスキー/シークレットアクセスキーが割り当てられます。これを利用してSecretを作成し、Cohesityに登録します。

(4) ソース登録

CohesityKubernetesクラスタをソース登録します。 CohesityのGUIで「ソース」を開き「登録」をクリックして「Kubernetesクラスタ」を選択します。
1.c_source_mod.png

Kubernetesクラスタのホスト名またはIPアドレス、事前準備(1)で確認したベアラートークンを入力して「登録」をクリックします。
2.c_source.png

ソースが登録できたことを確認します。
3.c_source.png前述の通り、ソース登録が完了すると自動的にKubernetesクラスタにNamespaceが作成されPodがデプロイされます。 "kubectl get namespace"コマンドを実行すると、Namespacecohesity-<CohesityのクラスタID>」が作成されていることが確認できます。
4.c_source_ns.png"kubectl get pods"コマンドを実行してこのNamespace内のPodを確認してみましょう。 「cohesity-dm-*」という名称のものがCohesity DataMoverPodです。 各Workerノードにひとつずつデプロイされています。 また「velero-*」という名称のものがVeleroPodです。 こちらはKubernetesクラスタに対してひとつデプロイされます。
5.c_source_po.png

バックアップの実行

事前準備ができましたので、バックアップを取得してみましょう。 Cohesityでは保護対象がKubernetesであってもGUIが変わることはありません。 また保護対象やポリシーを指定して保護グループを作成するという点では、物理マシンや仮想マシンのバックアップと同様ですので、直感的に操作ができるようになっています。

保護グループを作成するためにCohesityGUIで「データ保護」>「保護」を開き、「保護」>Kubernetesクラスタ」をクリックします。
c_k8s_pg1.png

ソースとして先程登録したKubernetesクラスタを指定すると、当該クラスタ内のNamespaceが一覧表示されます。 今回は「検証環境」の章でご説明した「nginx-test」にチェックを入れ、「選択範囲の保存」をクリックします。
c_k8s_pg2.png

保護グループ名「K8s-nginx」を入力し、ポリシーを指定して「保護」をクリックします。
c_k8s_pg3.png

デフォルトでは即時バックアップが実行されますので、完了まで待機します。 以下のように「ステータス」に緑のチェックアイコンが表示されれば完了です。
c_k8s_pg4.png 

リカバリの実行

今回は検証ですので、動作確認のためにNamespacenginx-test」ならびにNFSサーバー側のデータを削除してからリカバリを行います。
c_k8s_r0-p1.pngなお、Namespaceが削除されるとその中のPVCも削除されます。「NFS subdir external provisioner」の仕様によりPVCが削除されるとディレクトリ名の先頭に"archived-"が付与されるため、これをrmコマンドで削除しています。
c_k8s_r0-p2.png

これにより(当然のことではありますが)Nginxにアクセスすることはできなくなります。
c_k8s_r0-p3.pngここからCohesityによるリカバリを実行します。 CohesityのGUIで「データ保護」>「回復」を開き、「回復」>「Kubernetesクラスタ」をクリックします。
c_k8s_r0.png

「名前空間で検索」欄に任意の文字列を入力し、リカバリ対象を検索します。 ここでは「*」を入力しています。 検索結果からリカバリ対象の「nginx-test」にチェックを入れ「続行」をクリックします。
c_k8s_r1.png

「新規Kubernetesの名前空間の復元」画面でリカバリ対象のオブジェクト等を確認し、「回復」をクリックします。 今回は元の場所に元のNamespaceでリカバリしますので、「設定」はデフォルトのままにしています。
c_k8s_r2.png

リカバリが実行されますので、完了まで待機します。 「ステータス」が「成功」になれば完了です。
c_k8s_r3.png

Kubernetesクラスタの状態を確認してみましょう。 KubernetesクラスタにはNamespacenginx-test」が存在する状態になっています。このNamespace内のPodSVCPVCなども復旧されています。
c_k8s_r4.png

NFSサーバー側の状態も見てみましょう。ディレクトリ「nginx-test-nginx-...」が作成されており、その中に「index.html」が復旧されていることが確認できます。
c_k8s_r5.png

これにより、Webブラウザで<WorkerNode_IPアドレス>:30001にアクセスすると「index.html」のデータが再び表示されるようになりました。
c_k8s_r6.png 

以上、2回にわたりCohesityによるKubernetesの保護について解説いたしました。

Kubernetesのそもそものテクノロジが複雑なため前置きが少し長くなってしまいましたが、事前準備さえ済んでしまえばバックアップ・リカバリ自体はこれまでのCohesityの使用感と変わることなく実行できることがお分かり頂けたのではないでしょうか。 また、GUIが日本語なので操作がしやすいと思います。

Kubernetes自体にはデータ保護の機能はありませんので、Kubernetesを導入する場合にはそのデータをどう保護するかを検討する必要があります。 しかしながらKubernetes環境の保護のためだけにバックアップシステムを導入するのは荷が重いと思われる方も多いかもしれません。 Cohesityでしたら物理マシンも仮想マシンもKubernetes環境も同一のGUIで保護することが可能です。 内部的にVeleroを利用してはいますが、ユーザーがVeleroを直接操作する必要がない、つまりVeleroの操作方法を覚える必要がないというのも嬉しいポイントですね。

本ブログをきっかけにKubernetesの保護についてご検討頂けましたら幸いです。

 

 

※ サービスや製品の仕様ならびに動作に関しては、予告なく改変される場合があります。
※ バックアップ・リカバリの所要時間、データ削減率等は環境によって異なります。
※ 本ブログにおけるCohesityに関する記載はバージョン6.6.0bの情報に基づいています。 後継バージョンにおけるサポート範囲 / 仕様変更等についてはメーカードキュメントをご確認ください。

 

Cohesity社ウェブサイト: https://www.cohesity.com/ja/

これまでに投稿したCohesity関連のブログ一覧はこちら

著者紹介

SB C&S株式会社
技術統括部 第1技術部 2課
中原 佳澄