みなさんこんにちは。 Portworxの機能を連載形式でご紹介しております。

-------------------------------------------------------------------------------------------
　入門編　コンテナ環境と「データ」を考える
　第1回　PX-Storeによるボリュームの提供(初級編)
　第2回　PX-Storeによるボリュームの提供(応用編)
　第3回　ボリュームのスナップショット
-------------------------------------------------------------------------------------------

連載第1回～第2回ではPortworx (PX-Store)におけるディスクやボリュームの扱い方を中心に機能をご紹介いたしました。今回(第3回)はPortworxのボリュームに対するスナップショットについてご紹介したいと思います。

Portworxにおけるスナップショット作成の手法

本ブログ記事ではKubernetesにおける永続ボリュームのスナップショットに焦点を当ててご説明いたします。 (非Kubernetes環境の場合はPXCLIによりスナップショットを作成することが可能です。)

Kubernetesの永続ボリュームに対してスナップショットを作成するにあたっては、後述のSTORKを利用する方法と、PVCのAnnotationを利用する方法があります。メーカードキュメントに記載の通り、推奨されているのは前者のSTORKを利用する方法です。 従って本ブログ記事ではSTORKを利用したスナップショットの作成についてご紹介いたします。

なお、メーカードキュメントにはスナップショットの保管先や作成方法に関する名称が複数記載されています。 ここで内容を整理しておきましょう。

ローカルスナップショット (Local Snapshot)
あるボリュームのスナップショットをPortworxクラスターのStorage Poolに(=ローカルに)保存します。

クラウドスナップショット (Cloud SnapshotまたはCloudsnap)
あるボリュームのスナップショットをAzure BlobやAWS(Amazon S3)などのクラウドにアップロードし保管します。保管先としてS3互換ストレージを選択することも可能です。
3DSnap
アプリケーション整合性を保ってスナップショットを作成する手法です。プリルール・ポストルールを指定することにより、スナップショット作成前にアプリケーションを静止し、スナップショット作成後にI/Oを再開することが可能です。

スナップショットグループ (Snapshot GroupまたはGroup Snapshot)
アプリケーションで複数のボリュームを利用しているような場合に、スナップショットを同時に取得する際はスナップショットグループを利用します。

本ブログ記事はPortworxの基礎をご紹介するものですので、今回は単一ボリュームに対する「ローカル」スナップショットの作成・復元をご紹介したいと思います。

なお本ブログ記事ではPortworx Enterpriseを利用した際の動作をご紹介しております。Portworx Essentialsをご利用の場合はボリュームあたりのスナップショット数に制限がございます。詳細につきましてはメーカーサイトをご参照ください。

ストレージスケジューラ「STORK」

連載第2回で簡単にSTORKをご紹介しましたが、STORKはスナップショット作成にも関わりますのでここで改めておさらいを兼ねて触れておきたいと思います。

STORKはSTorage Operator Runtime for Kubernetesの略で、オープンソースのストレージスケジューラです。 STORKによってPodをデータと同じノードに配置することができI/O効率が上がるといったことが期待できます。 さらにSTORKを利用することでKubernetesからPortworxボリュームのスナップショットを作成したり復元したりすることもできます。

PodのスケジューラとしてSTORKを利用したい場合にはマニフェストで明示的に指定します。 以下はDeploymentの例です。 spec.template.spec.schedulerNameで"stork"を指定しています。

なお、STORKの操作のためにコマンドラインツール"storkctl"が提供されています。Kubernetes Masterノード上で"storkctl --help"コマンドを実行すると用法を確認することができます。

もし使用しているノードにstorkctlが存在していない場合はこちらの" Storkctl"に記載の手順に沿ってインストールすることが可能です。

検証環境

利用する環境はこれまでのブログ記事で扱ったものと同様です。4台のUbuntu 20.04.4LTS仮想マシンで構成したKubernetesクラスター(Kubernetes 1.22, Docker 19.3.11)上に構成しています。Kubernetesクラスターには3つのWorkerノードがあり、その空きディスクでPortworxクラスター(Portworx Enterprise 2.11)を構成しています。(このPortworxクラスターはPX-Centralを利用して構成されており、STORKが既にインストールされている状態です。)
この環境で以下のStorageClassを作成しており、PX-Store上にPVを動的に作成できるようにしています。

さらに動作確認のために下図のようなリソースを用意しました。 Namespace "snapshot-test"内でNginxのPodが稼働しており、WebサイトのコンテンツをPVに格納しています。
WebブラウザでこちらのServiceにアクセスすると以下のコンテンツが表示されるようになっています。

ローカルスナップショットの作成 (オンデマンド)

まずは手動で(オンデマンドで)ボリュームのスナップショットを作成してみます。 ここでは以下のマニフェストを用意し"kubectl apply"しました。 spec.persistentVolumeClaimNameでスナップショットを作成する対象のPVCを指定しています。

これでスナップショットが作成されます。 スナップショットの確認のため"storkctl get snap"コマンドを実行します。 コマンド実行結果からスナップショット作成元のPVCやスナップショットを作成した日時も確認可能です。
なお、スナップショット(VolumeSnapshot)を作成すると自動的に"VolumeSnapshotData"というオブジェクトが作成されます。
"kubectl describe volumesnapshotdata"コマンドにより、スナップショットのより詳細な内容を確認することが可能です。 Status.Conditions.Messageにスナップショット作成が成功したと記載されています。
　

スナップショットからのボリューム復元 (in-placeリストア)

作成したスナップショットからボリュームを復元してみます。ここでは元のPVCに対してボリュームを復元する"in-place"リストアを実行します。 (スナップショットをin-placeで復元する場合、そのPVCを利用するPodはSTORKをスケジューラとして利用している必要がある点にご留意ください。)
動作確認のためPVに格納していたWebサイトのコンテンツを削除します。
これによりServiceにアクセスすると403エラーが表示されるようになりました。

ボリューム復元のために"VolumeSnapshotRestore"を作成します。 ここでは以下のマニフェストを用意し"kubectl apply"しました。
ボリューム復元が成功したかどうかは"storkctl get volumesnapshotrestore"コマンドで確認することができます。以下が実行例です。STATUSが"Successful"になっていることが分かります。 なお、in-placeでスナップショットをリストアした場合、そのPVCを利用するPodは再作成されます。
再度WebブラウザでServiceにアクセスすると元のコンテンツが閲覧できるようになっています。 ボリュームを復元できたことが確認できました。

スナップショットからの復元手順についてはメーカーサイトにも記載がございますので、併せてご参照ください。

　

スナップショット作成のスケジューリング

ここまで扱ったスナップショットはオンデマンドで作成されたものでした。 オンデマンドではなく定期的に自動でスナップショットを作成することも可能です。 ここからはスケジュールに基づいてスナップショットを作成する方法をご紹介いたします。 なお、本機能を利用する場合はSTORKが必要です。

スケジュール指定とスナップショット作成

スナップショットの作成をスケジューリングするには"SchedulePolicy"を利用します。SchedulePolicyでは一定間隔毎あるいは日次 / 週次 / 月次といったスナップショット作成タイミング、保持するスナップショット数を指定します。(設定可能なフィールドや値についてはこちらをご参照ください。) 時刻を指定する場合はUTCでの動作になりますので、スナップショットを作成したい時間からマイナス9時間します。

ここでは毎日AM11:30(日本時間20:30)にスナップショットを作成するためのSchedulePolicy "pol-day1130am"を作成しました。 "policy"で毎日AM11:30にスナップショットを作成するよう指定しています。 さらに"retain"で何回分のスナップショットを保持するかを指定することが可能です。 ここでは3回分保持する設定としています。
作成したSchedulePolicyを確認する際にはkubectlを利用することもできますが、"storkctl get schedulepolicy"コマンドを利用するとスナップショット取得タイミングの設定も併せて確認することが可能です。 以下がコマンド実行例ですが、今回作成した"pol-day1130am"以外にもSchedulePolicyが存在していることが分かります。 こちらはPortworxにデフォルトで存在しているSchedulePolicyです。

次に、作成したSchedulePolicyをボリュームかStorageClassと関連付ける必要があります。ここではSchedulePolicyをボリュームと関連付けてみたいと思います。SchedulePolicyをボリュームと関連付けるには"VolumeSnapshotSchedule"を作成します。
ここでは以下のようにVolumeSnapshotScheduleを作成しました。 spec.template.spec.persistentVolumeClaimNameでSchedulePolicyを適用するPVCを指定しています。(その他のパラメータに関する詳細はメーカーサイトをご参照ください。)

"storkctl get volumesnapshotschedule"コマンドを実行すると、作成したVolumeSnapshotScheduleを確認することができます。(kubectlで確認することもできますが、storkctlを利用すると設定内容も併せて確認できるようになっています。)
これで指定したタイミングでスナップショットが作成されるようになりました。

なお、スケジュールに基づいてスナップショットを作成する手順についてはメーカーサイトにも記載がございますので併せてご参照ください。

作成されたスナップショットの確認

今回はSchedulePolicyで日次 / retain: 3と指定していました。 3日後にスナップショットの作成状況を確認してみます。  "storkctl get snap"コマンドを実行すると3回分のスナップショットが確認でき、VolumeSnapshotDataも作成されています。
さらにここから数日おいてスナップショットを確認すると以下のようになっています。 11月4日～6日のスナップショットがあり、11月1日～3日のスナップショットはなくなっています。 SchedulePolicyでretain: 3と指定していましたので、古いスナップショットは破棄されたようです。
　

スナップショットからのボリューム復元 (新しいPVCへ復元)

先程、スナップショットから復元する際にin-placeリストアと呼ばれる手法を利用しました。元のPVCだけではなく、新しいPVCに復元することも可能です。今回はスケジュールに基づいて作成されたスナップショット(11月5日に作成されたもの)から新しいPVCに復元してみたいと思います。

操作のイメージは下図の通りです。
スナップショット作成元と異なるPVCにスナップショットを復元する場合にはPVC自体を新たに作成します。ここでは以下のようなPVCを作成しました。スナップショットを作成した元のPVCはStorageClass "portworx-sc"を利用していましたが、今回は"stork-snapshot-sc"を指定しています。こちらはSTORKをインストールすると作成されるStorageClassで、スナップショットからPVCを作成する際に利用するものです。

新しいPVCが作成され、PVも自動的に作成されています。
"kubectl describe pvc"コマンドを実行すると、"Events"にプロビジョンに成功した旨のイベントが記録されています。

まとめ

今回はローカルスナップショットをピックアップし、オンデマンド / スケジュールによるスナップショット作成と復元の方法をご紹介しました。 kubectlで一元的にスナップショットを管理できることがお分かり頂けたのではないかと思います。

Portworxに限らずスナップショットはデータの破損や紛失から復旧するのに大変便利な方法です。 しかしながらご留意頂きたい点としてPortworxのスナップショットで保護できるのはあくまでボリュームのみです。 さらに今回ご紹介したローカルスナップショットはボリューム上の全てのデータが複製されている訳ではありません。(メーカーサイトにも記載がございますようにRedirect-on-Writeによるものです。) このため万が一の事態に備えたバックアップならびに復旧の方法については別途検討する必要があります。 Portworxはバックアップの機能をPX-Backupとして提供していますので、こちらも別の機会にご紹介できればと思います。

　

　

※ 本ブログにおける記載はPortworx Enterprise 2.11の情報に基づいています。 異なるバージョンにおけるサポート範囲 / 仕様変更等についてはメーカードキュメントをご確認ください。
※ 本ブログは弊社にて把握、確認された内容を基に作成したものであり、お客さま環境での動作や製品機能の仕様について担保・保証するものではありません。サービスや製品の仕様ならびに動作に関しては、予告なく改変される場合があります。
※ 一部オブジェクトのマニフェストを変更しコマンド実行結果を更新しました。(2022/11)