はじめに
前回の記事ではAstra Control Service(以下、ACS)にEKS上にデプロイしたWordPressアプリケーションを登録しました。
今回はそのアプリケーションに対してスナップショットならびにバックアップの取得を行なっていきます。
- Astra Control Service(ACS)の導入
- Astra Control Service(ACS)の使い方
- アプリケーションの登録
- アプリケーションのスナップショット&バックアップ ←イマココ
- アプリケーションのリストア&クローニング
前回までのおさらい
前回記事でEKSクラスタ上にWordPressをデプロイし、テスト用データとしてブログ記事を投稿しました。
このブログ記事などのアプリケーションデータはCSIドライバーであるAstra Tridentを介して、バックエンドストレージであるAmazon FSx for NetApp ONTAPに格納されています。
またACS上ではEKSクラスタならびにアプリケーションの登録が完了し、データ保護を行う準備が整っています。
スナップショットとバックアップの違い
実際に機能を使う前にACSにおけるスナップショットとバックアップの違いをまとめておきます。
比較項目 | スナップショット | バックアップ |
---|---|---|
保護されるデータ | アプリ構成情報 + PV内のデータ | アプリ構成情報 + PV内のデータ |
取得にかかる時間 | 短い | (スナップショットと比較すると)長い |
データ格納先 | クラスタローカル | 外部のS3ストレージ |
リストア先 | 同一k8sクラスタ内の別のnamespace | 同一k8sクラスタ内の別のnamespace または 別のk8sクラスタ |
PV削除時の復旧可否 | 不可 | 可 |
ポイントになりそうなのはバックアップ対象のPV自体が破損または削除されてしまった場合にはスナップショットからの復旧はできないという点でしょうか。
DRやクラスタ間のアプリケーション移行などのユースケースではバックアップを選択する必要があります。
スナップショット&バックアップしてみた
ここからが本題です。
アプリケーションのオンデマンドスナップショット
まずはACSにログインし、Applicationsメニューから前回登録したアプリケーションの管理画面を開きます。
Data protectionのタブからCreate snapshotをクリックします。
指定する必要があるパラメータは取得するスナップショットの名前だけでした(今回はデフォルト値)
スナップショットが取得できるとこんな感じです。スナップショット作成開始から完了まで数十秒くらいでした。
スナップショット機能の仕様について少し掘り下げると、PVのデータのバックアップにはk8sのvolumeSnapshotの仕組みが使われています。
上記でお伝えした「元PVが削除されるとデータ復旧できない」というのはこの仕様によるものですね。
ちなみにvolumeSnapshot作成時に使用しているvolumeSnapshotClassですが、こちらは私自ら作成したものではなくACSにクラスタを登録した時点で自動作成されていたものです。
CSIスナップショッターとしてAstra Trident(csi.trident.netapp.io)が指定されています。
試しにk8sクラスタの中身を覗いてみます。
# スナップショット機能によって作成されたvolumeSnapshotの一覧を確認
$ kubectl get volumesnapshot -n prod
NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT RESTORESIZE SNAPSHOTCLASS SNAPSHOTCONTENT CREATIONTIME AGE
pvc-2bc478fc-9bea-4374-bc18-506810c579aa-snap-18d88514-12fc-4667-9123-f92ab1819292 true my-release-wordpress 202512Ki astra-netapp-csi-trident-netapp-io-vsc snapcontent-fe7d0de8-1465-4bab-b24a-597ddcc01bdd 4m10s 4m10s
pvc-4c2ea6b2-1f97-42fd-b342-3100db04907c-snap-18d88514-12fc-4667-9123-f92ab1819292 true data-my-release-mariadb-0 38316Ki astra-netapp-csi-trident-netapp-io-vsc snapcontent-87efbb36-d61b-4baf-a281-d2c7347a44b8 4m10s 4m10s
# ACSが自動作成したvolumeSnapshotClassの中身を確認
$ kubectl get volumesnapshotclass astra-netapp-csi-trident-netapp-io-vsc -o yaml
apiVersion: snapshot.storage.k8s.io/v1
deletionPolicy: Delete
driver: csi.trident.netapp.io
kind: VolumeSnapshotClass
metadata:
creationTimestamp: "2022-10-11T13:43:01Z"
generation: 1
labels:
app.netapp.io/managed-by: astra.netapp.io
name: astra-netapp-csi-trident-netapp-io-vsc
resourceVersion: "47518"
uid: 7a7ee9ec-baa3-4779-ad86-0329dc2f76cb
なおアプリの構成情報データ(Deployment,Secretなど)の格納先についてはACSのサービス側に保管されています。
アプリケーションのオンデマンドバックアップ
次にバックアップ機能を使ってみたいと思います。
スナップショット同様、アプリの管理画面を開きます。
Data protectionのタブから画面右端のBackupsを選択した上で、Create backupをクリックします。
バックアップの名称以外に、いくつかオプションが選択できます。
Back up from an existing snapshotにチェックを付けると、現在のアプリケーションの状態でなく過去に取得したスナップショットをもとにバックアップを作成することができます。
またBackup Destinationではバックアップデータを保管するS3バケットが選択できます。
前回は説明を省きましたが、バックアップデータ格納用のS3バケットはACSが自動作成するもの以外にも既存のバケットをACSに登録して使うことできます
Nextをクリックすると最終確認画面が表示されますので、問題が無ければBack upをクリックします。
バックアップ機能ではS3バケットへ実データのコピーが行われるため、処理時間はデータ量に依存します。
今回は約180MB分のバックアップデータでしたが、数分くらいで処理完了しました。
アプリケーションの保護ポリシーの作成
ここまでは任意の時点でスナップショットやバックアップを作成する方法を試してきましたが、ACSではスケジュールベースでこれらの機能を定期実行することもできます。
具体的にはどれぐらいの周期でバックアップ作成し、どれぐらいの世代数を保管するかという保護ポリシーを作成することでこれを実現します。
Data protectionのタブからConfifure protection policyをクリックします。
バックアップ/スナップショットの周期は以下の粒度で設定できます。
- Hourly: 毎時0分/10分/20分/30分/40分/50分のいずれかを選択して指定
- Daily: 毎日のバックアップ時刻(UTC)を分単位で指定
- Weekly: 曜日(複数指定可)とバックアップ時刻(UTC/分単位)を組み合わせて指定
- Monthly: 日付(複数指定可)とバックアップ時刻(UTC/分単位)を組み合わせて指定
また保管するデータの世代数はスナップショット/バックアップそれぞれに異なる値を設定できます。
保管できる世代数の上限値はバックアップの方が多くなっています。
- スナップショット: 32世代まで
- バックアップ: 1000世代まで
今回は以下の様に保護ポリシーを設定してみました。
- スナップショットを毎時0分に取得し、1日分(=24世代)保管
- バックアップを毎日0:00に取得し、1週間分(=7世代)保管
Configureをクリックして保護ポリシーを作成するとアプリのApplication ProtectionがFully protectedのステータスに遷移しました。
Fully protectedになる条件は以下の様になっています。
- 直近でバックアップ(≠スナップショット)が取得されていること
- 保護ポリシーが作成されていること
これでスナップショット&バックアップは完了です。
まとめ&次回予告
今回の記事ではACSの中核の機能とも言えるアプリケーションのバックアップとリストアを検証してみました。
スナップショットはアプリの更新前後などの日常的なバックアップとしてのユースケースで使えそうですね。
一方でバックアップ機能はDRやアプリのクラスタ間移行などのユースケースで有効そうです。
次回記事では今回取得したバックアップデータをリストアしてみたいと思います。
次回記事 -> EKS上のステートフルアプリケーションをまるごとバックアップ・リストアしてみた【④リストア&クローニング篇】