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

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

検証環境

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

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にアクセスできるように設定しています。
さらに、今回はPVCを含めたバックアップ・リカバリの動作を確認したいため、以下のようにStorageClassを利用してNginxのPodにNFSの領域を提供しています。(今回はNFS用のStorageClassを作成するために「NFS subdir external provisioner」を利用しています。) NginxのPodをデプロイする際にパス/usr/share/nginx/htmlにNFSの領域がマウントされるように設定しています。
NFSサーバー側の状態も見ておきましょう。 ディレクトリ「nginx-test-nginx-...」に「index.html」を格納しており、このディレクトリがPod「nginx-test」にマウントされています。
以上の設定により、Kubernetesクラスタ外部からWebブラウザで<WorkerNode_IPアドレス>:30001にアクセスするとこの「index.html」のデータが表示されるという仕組みになっています。

　

事前準備

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

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

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

本項の作業はバックアップ対象のKubernetesクラスタ上で行います。 またご紹介するコマンドは一例です。 まずは以下のコマンドを実行しServiceAccount「cohesity」を作成します。
　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
このコマンド実行によって得られた文字列は、KubernetesクラスタをCohesityにソース登録する際に利用します。

(2) Dockerイメージの準備

「入門編」でレジストリが必要になるということをご説明しましたが、まずはその理由を確認しておきましょう。 理由はKubernetesクラスタをCohesityにソース登録する際の挙動にあります。 ソース登録するとKubernetesクラスタがどのような構成になるかを見てみましょう。
KubernetesクラスタをCohesityにソース登録すると、当該Kubernetesクラスタ上に「cohesity-<CohesityのクラスタID>」というNamespaceが作成され、VeleroのPodが1台、DataMoverのPodが各Workerノード上に1台ずつデプロイされます。(これらの処理は自動で行われます。) CohesityでKubernetes環境をバックアップする時にはVeleroとDataMoverが併用されます。「DataMover」のPodはCohesityが提供するイメージを元に作成されますので、レジストリを利用してKubernetesクラスタがDataMoverのイメージを利用できるようにしておく必要があります。

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

② docker loadコマンドでtarファイルをDockerイメージとして展開します。 その後でdocker imagesコマンドを実行すると、この環境ではイメージID「92a252e78aaa」が付与されたことが確認できます。
③ 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コマンドでレジストリにアップロードします。

これでレジストリが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) ソース登録

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

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

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

バックアップの実行

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

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

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

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

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

リカバリの実行

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

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

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

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

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

Kubernetesクラスタの状態を確認してみましょう。 KubernetesクラスタにはNamespace「nginx-test」が存在する状態になっています。このNamespace内のPodやSVC、PVCなども復旧されています。

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

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

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

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

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

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

　

　

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

　

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