📷

Backup and DR を使った Compute Engine の保護

Azuu D.

2023/01/05に公開

1件

Google Cloud

tech

みなさん、こんにちは。Google Cloud のカスタマーエンジニアをしている Azuu です。
Google Cloud は 2020 年末に Actifio を買収後、Actifio Go (というマーケットプレイス製品) を提供してきましたが、Google Cloud ネイティブサービスとして Backup and DR が 2022 年 10 月ついにサービスをリリースしました。今回はサービスについてよく分からない方を対象に簡単に概要を説明して、環境を立ち上げてエージェントレス、及びエージェント経由でバックアップとリカバリを行なう方法や Tips をまとめてご紹介したいと思います。

アジェンダ

Backup and DR 概要
事前準備
Backup and DR 環境のセットアップ
バックアップ計画の定義
Compute Engine のディスカバリとバックアップ計画の適用
Compute Engine のリカバリ

1. Backup and DR の概要

Backup and DR は Google Cloud 環境上で稼働する Compute Engine (GCE^[1]) や VMware Engine (GCVE) 上で稼働する VM のイメージバックアップの他にも GCE、GCVE、Bare Metal Server　(BMS) 上で稼働する様々な種類のデータベースやファイルシステムに対応しています。将来的にはオンプレミス環境で稼働している VMware 環境の保護にも対応していく予定です。

主要コンポーネント

サービスを利用する際に必ず利用するコンポーネントとして以下の 2 つがあり、これらは Backup and DR API を有効化後にデプロイしていくものです。

管理コンソール (Management Console)：ワークロードの保護と DR を管理する管理画面
- Google Cloud が管理するテナントにデプロイされ、プライベートサービス接続を使用してバックアップ対象のリソースがデプロイされている VPC と接続
- ウェブブラウザを介してアクセスし、同一プロジェクトで 1 つのみデプロイ可能
Backup and DR アプライアンス (Backup & DR Appliance)：バックアップジョブなどを実行する仮想アプライアンス
- 管理コンソールをデプロイする際に指定した自身の VPC 環境の GCE 上に仮想アプライアンスとしてデプロイ
- ユースケースに応じて、複数デプロイ可能 (リージョン毎など)

バックアップの種類

バックアップの取得方法はエージェントレスとエージェント経由の 2 種類があります。

エージェントレス：GCE (PD Snapshot API経由) 、GCVE (VMware Data Protection API経由) のネイティブ API を介したバックアップ取得
エージェント経由： GCE 、GCVE 、Bare Metal Server (BMS) 上で稼働しているデータベス (DB) 、又はファイルシステム (FS) のエージェントを介したバックアップ取得

エージェントを介したバックアップの場合、iSCSI 又は NFS を使用して下記で説明するストレージ層を対象 VM にマウントし、データのキャプチャとアクセスを行います。

バックアップ先のストレージ

バックアップのユースケースに応じて、2 種類のストレージのいずれか又は両方にてバックアップデータを保管します。例外として、エージェントレスで GCE を保護する際は、元々マネージドの機能として提供されている PD Snapshot API を使用します。そのため、PD Snapshot API を介した GCE の保護ではバックアップデータ自体は Google が管理する Cloud Storage に書き込まれ、Snapshot Pool や OnVault Pool にはバックアップに関するメタデータのみが書き込まれます。

Snapshot Pool ：Backup and DR アプライアンスのGCE インスタンスにアタッチされている永続ディスク (短期間のデータ保持のために利用)
OnVault Pool：バックアップデータの長期保管用 Cloud Storage (GCS)

リカバリの種類

エージェントレス、又はエージェント経由で取得したバックアップにアクセスする方法として以下の4種類があるのでユースケースに適したリカバリ方法を選択することができます。

Mount：データを移動させず指定した時点のデータの仮想コピーをSnapshot Pool 内で作成し、その仮想コピーを任意の VM にマウントする方法
Restore：指定した時点のデータに復元する方法
Clone：バックアップデータを元にコピー VM を作成する方法
Live Clone：DB や FS のスナップショットの仮想コピーを Snapshot Pool 内で作成後に対象 VM にマウントし、随時増分データが発生した場合にはマウントしている仮想コピーのデータを更新しながら利用する方法

その他用語の説明

バックアップ計画ではバックアップテンプレートを構成するポリシーとリソースプロファイルによって、実行するバックアップの種類や頻度とバックアップの保存場所 (使用する永続ディスクや GCS のプール) のルールを決めます。

リソースプロファイル：保護対象のアプリケーションや VM データのストレージ (Snapshot Pool や OnVault Pool) を指定するもの
バックアップテンプレート：バックアップポリシーの集合体
バックアップポリシー：データのバックアップ方法 (スナップショットやレプリケーションなど) 、バックアップの頻度や保持期間の定義

今回はGCE を 2 インスタンス用意してサービス立ち上げから以下の 2 種類のバックアップやリカバリを行なう方法を紹介します。
エージェントレス方式：GCE の PD Snapshot 取得によるイメージバックアップ
エージェント経由：GCE 上で稼働しているファイルシステムのデータバックアップ

2. 事前準備

今回は検証環境として、最終的に図 1 の構成をデプロイします。まずは予め、VPCやサブネットを準備して保護対象の GCE (CentOS) を 2 台 (demo-centos7-01 と demo-centos7-02)デプロイしておきます。2 台目のGCE (demo-centos7-02) はエージェント経由でファイルシステムの保護を行なう方法を検証するため、予め永続ディスクを追加してファイルシステムを作成しておきます。ファイルシステムの配下にはファイル形式・種類に応じて doc、pdf、junk の 3 つのディレクトリを作成してランダムでファイルを生成しておきます。
図1 検証環境の構成概要

2-1. デプロイに必要なロールや権限の付与とAPIの有効

作業を実施するユーザーアカウントがサービスをデプロイする際に必要なロール・権限について付与されているか確認します。今回はプロジェクトに対するオーナー権限を持っているので、追加で権限やロールを付与する必要がありませんが、足りていないロールがあれば IAM と管理のページから追加します。

また、Backup and DR アプライアンスをデプロイする VPC にて必要な API を有効化します。

複数 API をコマンドで有効化する場合

gcloud services enable compute.googleapis.com \ cloudresourcemanager.googleapis.com workflows.googleapis.com　\　cloudkms.googleapis.com iam.googleapis.com logging.googleapis.com

補足 : 共有 VPC を使用しているプロジェクトの場合

共有 VPC を使用するプロジェクトにおいても Backup and DR を使用することは可能です。サポートされている管理コンソールとアプライアンスの配置(アーキテクチャ)は以下となります。

管理コンソール (プライベートサービス接続先のプロジェクト)	Backup and DR アプライアンス
ホストプロジェクト	ホストプロジェクト
ホストプロジェクト	サービスプロジェクト
サービスプロジェクト	ホストプロジェクト
サービスプロジェクト	サービスプロジェクト
サービスプロジェクト	別のサービスプロジェクト

図2 管理コンソールをホストプロジェクトへアプライアンスをサービスプロジェクトにデプロイする場合
デプロイ作業を実施するユーザアカウントがそれぞれのプロジェクトで必要な IAM ロールが付与されていることをコンソールの IAM 画面で確認します。(それぞれのプロジェクトでオーナー権限が付与されていれば十分ですが権限が足りていなければ、追加します。)

ホストプロジェクトで必要な IAM ロール
管理コンソール (へのプライベートサービス接続先の)プロジェクトで必要な IAM ロール
Backup and DR アプライアンスをデプロイするプロジェクトで必要な IAM ロール
次に管理コンソールとアプライアンスを配置に応じてそれぞれのプロジェクトで以下の API を有効化します。
ホストプロジェクトで有効化する API

コマンドで有効化する場合

gcloud services enable compute.googleapis.com \ 
cloudresourcemanager.googleapis.com

アプライアンスをデプロイするプロジェクトで有効化する API

コマンドで有効化する場合

gcloud services enable compute.googleapis.com \ 
cloudresourcemanager.googleapis.com workflows.googleapis.com \ 
cloudkms.googleapis.com iam.googleapis.com logging.googleapis.com

2-2. NW設定の確認と変更

管理コンソールとプライベートサービス接続用に IP アドレスの割当を行います。始めにコンソールの VPC Network 画面にて Backup and DR アプライアンスをデプロイする VPC の「servicenetworking-googleapis-com」へのプライベートサービス接続の有無を確認します。

servicenetworking-googleapis-com へのプライベートサービス接続がある場合

既存の servicenetworking-googleapis-com へのプライベートサービス接続で割り当てている IP アドレス範囲が /23 よりも狭い場合や既に別のサービス向けに /23 のプライベートサービス接続は存在するもの既に一部の IP を使用している場合は Backup and DR で使用する IP アドレスが足りなくなります。(デプロイする際にエラーになります。）
そのため、servicenetworking-googleapis-com に対して、/20 の IP アドレス範囲をプライベートサービス接続の割当先として追加する必要があります。
※ サービスとして必要な範囲は /23 ですが、Backup and DR デプロイ時にプライベートサービス接続がない際には /20 の IP アドレス範囲の割当を行なう仕様となっていることもあり、ユーザ自身が事前にIPの割当を行なう場合は /20 の割当を推奨しています。

servicenetworking-googleapis-com へのプライベートサービス接続がない場合

設定方法は 2 通りあり、自身で指定した /20 の IP アドレス範囲を割り当てて新規にプライベートサービス接続を設定してから Backup and DR をデプロイする方法と Backup and DR をデプロイする際にサービスが自動で割り当てた IP アドレスを用いたプライベートサービス接続を利用する方法です。前者の方がプライベートサービス接続に割り当てる IP アドレス範囲が決められるのでこちらを推奨します。

ファイアウォールルールについては、Backup and DR を利用する(デプロイする)際に必要なルールが自動で追加されます。以下のユースケースに該当する場合のみ個別にファイアウォールを作成する必要があります。

ユースケース	ソース	ターゲット	ポート
共通：エージェント経由でバックアップを取得する場合	Backup and DR アプライアンス	エージェントを導入している VM	5106
NFS 経由でバックアップを取得する場合 ※(エージェント経由、又はエージェントレスでVMware 環境を保護している場合)	エージェントを導入している VM or ESXi サーバ	Backup and DR アプライアンス	111, 756, 2049, 4001, 4045

※ iSCSI 経由でバックアップを取得する場合はエージェントを導入している VM から Backup and DR アプライアンスへの通信の許可は自動で追加されるファイヤウォールルールに含まれています。

2-3. OnVault 用の GCS バケットとサービスアカウントの準備

ver 11.0.2 以降の手順
OnVault Pool 用の Cloud Storage を用意します。今回は国内のリージョン障害に対応できることを想定して、東京と大阪リージョンの Dual Region の Nearline バケットを選択しています。例えば、国内で発生する災害などを想定して、国外のリージョンでもデータを保管したい場合は Multi Regional を選択して下さい。

ver 11.0.1 までの手順

今回使用する Cloud Storage 用のサービスアカウント (今回の場合はgcbdr-operator) を作成して、 Backup and DR Cloud Storage Operator のロールを付与します。サービスアカウント作成後に JSON 形式のキーファイルを作成してダウンロードしておきます。

3. Backup and DR 環境のセットアップ

ここからは実際に Backup and DR の各コンポーネントをデプロイし、各種コンポーネントの設定を行う作業です。この章は若干 (?) 長いですが、以下の項目について説明します。
3-1. 管理コンソールと Backup and DR アプライアンスのデプロイ
3-2. 管理コンソールへ OnVault Pool の登録
3-3. 対象 VM へのエージェントインストール(DB や FS を保護する場合)
3-4. GCE バックアップを取得するサービスアカウントの作成と登録
(GCE をエージェントレスで保護する場合)
3-5. リソースプロファイルの作成 (OnVault Pool にバックアップを保管する場合)
3-6. セルフサービスポータル Actifio NOW への登録
3-7. (任意)組織・ロール・ユーザの定義

3-1. 管理コンソールと Backup and DR アプライアンスのデプロイ

始めに Backup and DR API を有効化し、管理コンソールをデプロイするリージョンと Backup and DR アプライアンスをデプロイする予定の VPC を選択します。繰り返しになりますが、管理コンソールは Google 管理のテナントにデプロイされます。現在、アジア圏では asia-east1 (台湾) か asia-southeast1 (Singapore) のどちらかを選択する必要があるので、今回は台湾リージョンを選択します。
※バックアップ自体を行う Backup and DR アプライアンスは対象 VPC サブネットが払い出されているリージョンを選択できるので、これはあくまでもウェブブラウザ経由でアクセスする管理コンソールがホストされているリソースの配置場所と捉えていただければと思います。

次に、Backup and DR アプライアンスをデプロイする対象のプロジェクトやサブネットを選択します。最後に今回デプロイする Backup and DR アプライアンスのストレージタイプについて、今回は Compute Engine の保護の検証のため “Minimal capacity persistent disk” (最小限の永続ディスクの容量となるもの) を選択します。（ここで選択しているのは Snapshot Poolの容量やディスクの種類になりますが、後から Snapshot Pool の永続ディスクを追加や拡張は可能なので検証の場合はこの選択のまま進めて大丈夫です。）最後に [Begin Installation] を押して、デプロイが完了するのを (1時間程度) 待ちます。

デプロイが完了して、以下の画面に切り替わり [LOG IN TO THE MANAGEMENT CONSOLE] 経由で管理コンソールのトップページにアクセスできることを確認します。(手順 2-1 で必要な IAM 権限の付与を行っておりますが、管理コンソールへアクセスするためにはプロジェクトレベルでこちらの権限が必要になります)

コンソールの VPC 画面から Backup and DR 向けにファイヤウォールルールが追加されていることも併せて確認します。

また、コンソールの Compute Engine 画面から Backup and DR アプライアンスに該当する backup-server-XXXXX がデプロイされていることも確認します。今回は Minimal Size Capacity を選択しているので Snapshot Pool としては 10GB のディスクがデプロイされています。 (200 GB の Primary Pool は必ずデプロイされるもので、 Backup and DR アプライアンスのシステムデータのためにあるので削除しないで下さい。)

3-2. 管理コンソールへ OnVault Pool の登録

事前準備で用意した OnVault Pool (GCS) を管理コンソールに登録します。管理コンソール上部の Manage > Storage Pools を選択して右上の [Add OnVault Pool] を選択します。事前準備で作成した Cloud Storageのバケット名 ~~とサービスアカウント名とダウンロードしたキーファイル~~を記入して [Save] を押します。(ver 11.0.1 手順までは自分自身で作成したサービスアカウントをアップロードする仕組みとなっていたため、下の画面はサービスアカウント名が ver 11.0.2 の画面で表示されるものと異なります。ver 11.0.2 以降は Backup and DR アプライアンス作成時のサービスアカウントを使用する仕組みとなっており、backup-server-XXXXX-sa@ となります。)なお、Snapshot Pool は Backup and DR アプライアンスをデプロイする際にデプロイ済みのため、登録する必要はありません。

3-3. 対象 VM へのエージェントインストール (DB や FS を保護する場合)

今回は 1 つの GCE インスタンスはエージェント経由でバックアップ取得を行うためにエージェントを導入します。バックアップ処理自体は Backup and DR アプライアンスが行うため、アプライアンス経由でエージェントをダウンロードする必要があります。エージェントを導入する際の流れは以下となります。
3-3-1. エージェントのダウンロード
3-3-2. 対象 VM へのアップロードとインストール
3-3-3. iSCSI 又は NFS の有効化

3-3-1. エージェントのダウンロード

管理コンソール上部の Manage > Appliances からデプロイした Backup and DR アプライアンスを選択後、[Configure Appliance] を押して Agent Management の画面へ遷移します。
(エージェント経由の保護がサポートされている DB や FS についてはこちらを参照下さい)

次に Agent Management の画面上部からOS (今回の場合は CentOS) に対応したエージェントをダウンロードします。

3-3-2. 対象 VM へのアップロードとインストール

ダウンロードしてきたファイルを対象 OS にアップロード後にエージェントをインストールします。インストール後に表示される Secret Key (赤枠) は後ほど使用するので保存しておきます。また、エージェントが動いていることを確認します。

インストール時のコマンド

rpm -ivh (エージェント名)

エージェントのステータス確認

systemctl status udsagent

エージェントを再起動したい場合

systemctl restart udsagent

以降、エージェントのアップグレード版が配信された場合は、同様に Backup and DR アプライアンスからダウンロードして対象 VM にインストールをしてアップグレードすることなります。(Windows OS の場合のエージェントインストールについてはこちらの手順を参照下さい)

3-3-3. iSCSI 又は NFS の有効化

エージェント経由でバックアップを取得する場合は Backup and DR アプライアンスの Snapshot Pool に iSCSI 又は NFS でアクセスしてバックアップデータを書き込むための VM 側の設定を行います。

iSCSI を使用する場合

iSCSI のパッケージをインストールします。

iSCSI パッケージがインストールされているか確認

yum list installed | grep iscsi

インストールされていない場合、iSCSI のインストール (上記で実行結果が空の場合)

yum install -y iscsi-initiator-utils

今回、エージェントを導入している VM が iSCSI イニシエータとなり、iSCSI ターゲットは Backup and DR アプライアンスの Snapshot Pool となります。通常、iSCSI ターゲットの設定はイニシエーター側で行いますが、Backup and DR では対象 VM を管理コンソール上で登録する際に Backup and DR アプライアンスがエージェントを介して設定します。そのため、最後に iSCSI のサービスを有効化しておきます。

iSCSI のサービス有効化とステータス確認

systemctl enable iscsid.service
systemctl start iscsid.service
systemctl status iscsid.service

NFS を使用する場合

NFS のパッケージをインストールします。

NFS パッケージがインストールされているか確認

 yum list installed | grep nfs

インストールされていない場合、NFS パッケージのインストール (上記で実行結果が空の場合)

 yum install nfs-utils nfs-utils-lib

rpcbind port mapper パッケージがインストールされているか確認 (上記で実行結果が空の場合)

yum list installed | grep rpcbind

インストールされていない場合、rpcbind port mapper のインストール

 yum install rpcbind

通常、クライアント側で NFS マウントの設定を行いますが、Backup and DR では対象 VM を管理コンソール上で登録する際に Backup and DR アプライアンスがエージェントを介して設定します。最後に (手順 2-2 に記載の通り) iSCSI の場合は自動で追加されるファイアウォールルールに含まれていますが、 NFS の場合は対象 VM からアプライアンスに接続できるようコンソール上でファイアウォールルールを追加します。(ルールについては手順 2-2 参照してください)

3-4. GCE バックアップを取得するサービスアカウントの作成と登録 (GCEをエージェントレスで保護する場合)

ver 11.0.2 以降の手順
クラウドコンソールの IAM & Admin > IAM の画面にて Backup and DR アプライアンスで使用しているサービスアカウントにて以下のロールが付与されていることを確認します。(付与されていない場合は、付与します。)

Backup and DR Cloud Storage Operator
Backup and DR Compute Engine Operator

ver 11.0.1 までの手順

Backup and DR で GCE のイメージバックアップを行なう場合には PD Snapshot API を介してバックアップを取得するので、その際に使用するサービスアカウントを作成する必要があります。Google Cloud のコンソールから任意の名前でサービスアカウントを作成し、Backup and DR Compute Engine Operator ロールを付与します。最後にJSON 形式のキーファイルを作成してダウンロードしておきます。

次に Backup and DR の管理コンソール上にサービスアカウントの情報を登録します。管理コンソール上部の Manage > Credentials 画面に遷移し、右上の [Add Google Credentials] を押します。ここで、認証情報の(管理コンソール上での)名称と作成したサービスアカウントのキーファイルをアップロードして登録します。ここで選択した「Default Zone」は GCE インスタンスをディスカバリする際にスキャンする対象のデフォルトゾーンの意味合いです。(実際にスキャンする際にゾーンの変更は可能です)

3-5. リソースプロファイルの作成 (OnVault Pool にバックアップを保管する場合)

次に各種バックアップで使用する Snapshot Pool や OnVault Pool などのストレージを定義するリソースのプロファイルを追加します。
補足で説明すると、Backup and DR ではバックアップの種類毎に利用できるストレージパターンは以下となります。

管理コンソールの上部 Backup Plans > Profile に遷移するとデフォルトでは上記の「1. Snapshot Pool のみ利用」に該当するリソースプロファイル 1 件「Local Profile」が用意されています。これは Backup and DR アプライアンスの Snapshot Pool 自体にバックアップデータを書き込むプロファイルです。また、手順 3-4 で GCE 保護用にサービスアカウントを登録した際にバックアップに関するメタデータを書き込む「GCE Backup_Profile」がサービス側で作成されています。
今回は更に「2. Snapshot Pool & OnVault Pool」両方を利用するリソースプロファイルを管理コンソールの UI の右上にある [Create Profile] から 1 つ作成します。
ここで SNAPSHOT POOL と ONVAULT POOL の選択肢として表示されるのは Backup and DR に登録したストレージになります。登録されているストレージを確認したい場合、管理コンソール上部の Manage > Storage Pools から確認できます。
※デプロイ時に作成された Backup and DR にマウントされている Snapshot Pool はデフォルトで act_per_pool 000 という名称がつけられます。後から Snapshot Pool の永続ディスクを追加する場合は OnVault Pool と同様 Backup and DR 内での呼び名として任意の名称をつけられます。

今回は SNAPSHOT POOL はアプライアンスの永続ディスクに該当する act_per_pool000 を選択し、ONVAULT POOL は手順 3-2 で登録した OnVault Pool を選んで [Save Profile]を押します。

3-6. セルフサービスポータル Actifio NOW への登録

最後に Backup and DR のサポートに関しては現時点 (2022 年 12 月時点では) 前段となっている Actifio で使われていた Actifio NOW を介してサポートチケットをあげる必要があります。これは Google Cloud コンソール側の Backup and DR 画面下部 Get help から LOG IN > As a new user から作成できます。他にも公式ドキュメントのこちらのページ上の Actifio NOW Account Creation Form のリンク経由で作成することが可能です。

3-7. (任意)組織・ロール・ユーザの定義

#今回の検証ではこの作業はスキップしています#
Backup and DR では同一プロジェクトでは 1つの管理コンソールを使用してバックアップやリカバリ操作を行う必要があります。Backup and DR の管理コンソール自体にアクセスできるユーザを追加したい場合、必要な権限を付与することで可能です。プロジェクト内で付与されている IAM ロールの権限に従い、初回アクセス時に管理コンソールで操作できるロールが付与されます。また、管理コンソール上で組織(ユーザのグループ)を使用することで、特定の Backup and DR アプライアンスへアクセスできるユーザを制御したい場合はこちらを設定します。

4. バックアップ計画の定義

始めに、データのバックアップ方法 (スナップショットやレプリケーションなど) 、バックアップの頻度や保持期間を定義するバックアップポリシーの集合体である、バックアップテンプレートを作成します。(バックアップテンプレートとバックアップポリシーに関する説明は 1. Backup and DR 概要の「その他用語説明」を参照)
管理コンソールの Backup Plans > Template > Create Templates から新規のバックアップテンプレートを作成 [Create Templates] を選択します。

4-1. GCE をエージェントレスで保護する場合

GCE を保護する場合、画面下部の Workload Compatibility に記載されている Snapshot Pool のみを使用したテンプレートを作成する必要があります。(Snapshot Pool 以外のバックアップポリシーが定義されていると後続の作業でバックアップジョブを適用する際にエラーになります。)
画面右側の Policies の [Add] を押して、具体的にバックアップの取得頻度や時間帯などを定義していきます。

ポリシー名 [POLICY NAME] には分かりやすい名前 (Daily Backup) をつけ、[SCHEDULING] で Windowed という決められた時間帯のバックアップを取得することとします。[ON THESE DAYS] を Everyday とし、日次バックアップとなるようにします。更に[WITHIN THIS WINDOW]を夜間 (22:00~24:00) に設定し、[RETAIN FOR] で3日間データを保持するよう定義します。
今回は例として定義した時間帯に 1 度だけバックアップを取得する設定にしていますが、[CONTIUOUS] を選択することでバックアップを定義した間隔で取得するよう設定することも可能です。(その場合、GCE は PD Snapshot API の制約に引きづられますが、最頻は 10 分に一度スナップショットが取得可能です。)

更に、[Advanced Policy Settings] から永続ディスクのスナップショットのポリシーとして Regional の大阪リージョンの GCS バケットにデータが格納されるよう設定します。デフォルトでは永続ディスクのスナップショット仕様に従ってソースの GCE が稼働しているリージョンが含まれる Multi Regional GCS にデータが保管されます。例えば、東京リージョンで稼働しているバックアップを大阪リージョンで保持したいなど社内ポリシー的に国外でデータを保管するのが NG な場合や Regional スナップショットストレージの方が Multi Regional スナップショットストレージより安価なのでコストを抑えたい場合はここを変更します。

また、今回は設定を変更しませんが、Application Consistent の部分を Crash Consistent から Application Consistent へと変更することでアプリケーション整合性のあるバックアップを取得する事が可能です。それぞれの定義については以下となります。(なお、この項目はエージェントレスバックアップの場合のみ設定が適用され、エージェン経由の DB や FS のバックアップ取得では必ず Application Consistent となります)

Crash Consistent：ストレージ内のアプリケーションデータを高速にバックアップします。ディスク上のすべてのデータが保存され、メモリ内のデータは失われます。
Application Consistent：アプリケーション整合性を担保するために Windows OS の場合は VSS、Linux OS の場合は fsfreeze の仕組みを使用して仮想マシンを静止します。これはユーザ自身が用意したスナップショット前とスナップショット後のスクリプトを活用することで実現します。
(その他 Advanced Policy で構成できる項目についてはこちらを参照して下さい)

[Update Policy] を押して、元のテンプレート画面に戻り Snapshot Policy が設定されたことを確認して、バックアップテンプレートを保存します。

4-2. DB や FS をエージェント経由で保護する場合

DB や FS を保護する場合、画面下部の Workload Compatibility に記載されているストレージを使用することが可能です。直接 OnVault Pool にバックアップをアップロードする Direct to OnVault が使用できない点だけ注意して下さい。
今回は Snapshot Pool と OnVault Pool を用いたバックアップポリシーを設定します。Snapshot Pool へのポリシーについては GCE をエージェントレスで保護する場合と同様に設定していきます。今回 [SCHEDULING] を定義した間隔でバックアップを取得する CONTINUOUS を選択して、[EVERY] で 12 時間間隔を指定します。初回のバックアップ時間 [STARTING AT] を 22:00 、[RETAIN] で2 日間データを保持する設定にしてみます。最後に [UPDATE POLICY] を押して Backup Plan の画面で設定値が反映されていることを確認します。

次に OnVault Pool のポリシー設定へ進みます。
OnVault Pool へのバックアップについても同じように設定項目となるので、[SCHEDULING] を Windowed として、[WITHIN THIS WINDOW] で 22:00-24:00 に 1 度バックアップを取得することにします。[RETAIN FOR] で 1 か月間データを保管するよう設定します。OnVault Pool は長期保管用のストレージとなりますが、目安として 30 日以上の保管の場合は Nearline Class、30 日〜 90 日程度の場合は Coldline Class のものをデプロイして利用することを推奨します。
最後に [TARGET POOL] では保管する OnVault Pool 1を選択します。この項目では OnVault Pool が 1〜4 まで選択できますが、これはリソースプロファイルで登録されている OnVault Pool の 1〜4 のどれを使用するのかという意味です。後続手順で対象 VM にバックアップ計画を設定する際、選択したリソースプロファイルにおいて OnVault Pool 1 に登録されている GCS バケットにデータを格納することを意味します。

OnVault のポリシーがアップデートされていることを確認して、[Save Template] からバックアップテンプレートを保存します。

管理コンソールのバックアップテンプレート画面で先程定義した 2 つのバックアップテンプレートが作成されていることを確認します。

5. Compute Engine のディスカバリとバックアップ計画の適用

ここからは、実際に保護したい 2 つの OS を管理コンソールに登録します。

5-1. GCEをエージェントレスで保護する場合

管理コンソール画面上部の Backup & Recover から Backup を選択し、Compute Engine のアイコンを選択します。ディスカバリする際に使用するサービスアカウントとして、登録しておいいた GCE Backup を選択し、[NEXT] を押します。

手順 3-4 で GCE のサービスアカウントを登録する際に設定したデフォルトゾーンでディスカバリされた GCE から保護する対象 (demo-centos7-01) を選択して [NEXT] を押します。

次に Action として [Apply backup plan] を選択して、GCE バックアップ用に作成したバックアップテンプレートを選択します。最後に Volume Options で全てのディスクに適用するのかブートディスクのみにするのか選びます。

[NEXT] を押して次の画面へと進み、バックアップ計画の適用を [FINSH] を押して完了します。

5-2. GCE をエージェント経由で保護する場合

管理コンソール画面上部の Manage > Hosts を選択して、対象の VM を登録します。(エージェント経由でバックアップを取得する場合、VM の中にアクセスするための認証情報を登録する必要があります)
VM 名と IP アドレスを追加し、ディスカバリを行うアプライアンスを選択します。また、Host Type は今回の場合は単体の VM なので Generic のままにします。(vCenter や ESX を登録して、まとめてディスカバリする場合はこれらを選択して下さい。) まずはホスト自体のディスカバリなので、手順 3-2 でエージェントをインストールした際に生成されたシークレットキーを貼り付けて [Add] からホストを追加します。シークレットキーを紛失してしまったり、有効期限が切れてしまった場合は対象 VM にアクセスして再度生成します。
※MariaDB、MySQL、PostgresSQL、SAP ASE などの DB をディスカバリする場合、 Application Discovery Credentials に認証情報を記入する必要があります。DB の種類に応じてユーザに付与しておくべき権限は異なるので対象 DB のディスカバリページに記載されている前提事項 (Prerequisites) を参照して下さい。

追加後に、対象 VM の Certificate Status が有効 (Valid) となっていることを確認します。
また、デフォルトでは対象 VM とアプライアンスの永続ディスク間を iSCSI 経由でアクセスする方式となっています。NFS 経由でバックアップを行う場合、Hosts の画面で対象 VM の Staging Disk Format を Block から NFS に変更してください。

問題がなければ、Backup & Recover > Backup の画面から All Apps を選択して対象 VM を選択して [Discover] へと進みます。

ディスカバリが完了すると App Manager > Applications からスキャンした OS のマウントポイントが表示されるので、ファイルシステムに該当する filedirectory を選択してバックアップジョブの適用 [Manage Backup Plan] へと進みます。

ファイルシステムの保護に適用したいバックアップテンプレートとリソースプロファイルを選択して最後に [Apply Backup Plan] を押します。

バックアップポリシーのオーバーライドを許可している場合、オーバライド内容を記入する画面が出てきます。今回は filedirectory 配下に junk フォルダだけ除外を意味する [prune path] に指定してバックアップの取得対象外としてみます。

(任意)オンデマンドでバックアップジョブの実行

最後に正しくバックアップジョブが動作することを確認するためにオンデマンドでバックアップを取得します。App Manager > Applications タブから対象VM や FS を選択して、Manage Backup Template 選択後に Policy から [Run Now] を選択します。バックアップ処理の完了後、Monitor > Jobs の画面からバックアップジョブの Status が Succeeded になっていることを確認します。

(後日)バックアップが取得出来ていることを確認

定義したバックアップ計画通りの時間帯や時間間隔でバックアップが取得出来ているか確認する方法について2通り紹介します。

ジョブの実行結果を確認する方法

管理コンソール画面の Monitor > Jobs に遷移後に画面左側の Succeeded や Failed フィルターを活用してバックアップ取得のステータスが確認出来ます。

例えば、ステータスが Failed となっているジョブがある場合、そのジョブを選択後に [View Details] を選択することでエラーメッセージを確認することができます。

[Message] の部分に表示されているのがエラーメッセージとなります。(余談ですが、この時は手順 3-3-3 で説明した、iSCSI が有効になっていなかったことが原因でした。) エラーメッセージの内容がよくわからない場合は [Error Code] の右側にある [Search Knowledge Base] を押すと、Actifio (Backup and DR の元となっている製品) のセルフサービスポータル (Actifio NOW) 上のナレッジベースに遷移します。

手順 3-6 で Actifio NOW に登録したユーザ ID とパスワードを入力して、同様のエラーコードに関する記事などを閲覧することが可能です。

バックアップ断面から確認する方法

Backup & Recover > Recover の画面から保護対象を選択すると画面では左側に日付と中央にあるアイコンがデータの断面を表しており、バックアップポリシーで定義した通りにバックアップが Snapshot Pool や OnVault Pool に書き込まれていることが確認できます。もしも、バックアップポリシーで定義した断面のデータがアイコンとして表示されていない場合、バックアップ取得が失敗していることを意味しますので 1 つ上の手順で紹介したジョブの実行結果からエラーの内容を確認して下さい。

6. Compute Engine のリカバリ

バックアップしたデータを元にリカバリを行う場合の操作は Backup & Recover > Recover へ遷移し、リカバリ対象を選択します。その後、リカバリしたいデータの断面と概要で説明したリカバリの種類としてマウントを選択します。(ここで、マウント以外のリカバリ方法を選択して、データへアクセスすることもできます。)

6-1. GCE のエージェントレスバックアップ(PD Snapshot)をマウントする場合

マウントによるリカバリを行なう際は一度永続ディスクのスナップショットを格納している Google 管理のGCS から永続ディスクとして書き出します。そして、その後新規又は既存の GCE にマウントすることでデータへのアクセスが出来ます。

新規で GCE インスタンスの作成 [MOUNT AS NEW GCE INSTANCE] を選択して、コンソールから GCE をデプロイする時と同じように必要な情報を選択・記入します。インスタンス名はプロジェクト内で一意にする必要があるので後半に「-recovery」を加えます。予め、大阪リージョンにサブネットを作成しておいて大阪リージョン側に新規の GCE にマウントしてデプロイへと進みます。

マウントジョブが完了したことを Monitor > Jobs から確認後、コンソール画面から無事にリカバリ用の VM が起動してアクセス可能なことを確認します。マウント後 (やリストア後)に必要に応じて予約利用していた元のインスタンスに紐づく静的 IP アドレスの付け替えなどを行って下さい。また、例えば上記の例のように別サブネットに GCE インスタンスをデプロイする場合はデプロイ先のサブネットで通信ができるよう FW ルールも必要に応じて追加して下さい。

6-2. FS のエージェント経由のバックアップをマウントする場合

マウントする際には実際に Snapshot Pool 内にバックアップのコピーデータを作成して、対象 VM に iSCSI や NFS 経由でデータを提示する仕組みとなってます。そのため、マウント先の VM にもエージェントが導入されていて Backup and DR でディスカバリされている必要があります。

今回はマウント先の VM として demo-centos7-02 を選択して、マウントポイントを指定します。(マウントポイントの指定がない場合は Backup and DR が作成する仕組みとなっています。また Windows OS へマウントする場合はマウントポイントではなくマウントドライブ側を指定する必要があります。)

マウントジョブが完了したことを Monitor > Jobs から確認後、対象 VM にログインすると先ほど指定したマウントポイントに　junk ディレクトリを除いたものがマウントされていることが確認できました。(junk の代わり lost+found が出来ていますが、実態としては空です。)

まとめ

今回は Compute Engine をエージェントレスの PD Snapshot API 経由で保護する方法とエージェント経由でデータの一部を保護する方法を紹介しました。エージェントの導入手順は保護する DB や FS の種類に依存せず、OS 環境に依存するものなので同様の手順でエージェントをインストールして DB のディスカバリへと進んで頂くことで DB を保護することも出来ます。
PD Snapshot API は永続ディスクの単位しか指定が出来ませんでしたが、エージェントを導入することでもきめ細やかバックアップ取得も可能なので是非ご活用いただければと思います。

脚注

正式名称は Compute Engine ですが、一般的に GCE と呼ばれることが多いので以降 GCE と呼びます。 ↩︎

Google Cloud JapanPublication

Google Cloud Japan のエンジニアを中心に情報発信をしている Publication です。Google Cloud サービスの技術情報を中心に公開しています。各記事の内容は個人の意見であり、企業を代表するものではございません。

Discussion

たまご

この記事を見て試してみましたが、（おそらくエージェントありの場合）、n1-standard-16インスタンスが起動し1時間あたり$0.88の費用が取られます。他のインスタンスが選べるのか・エージェントレスなら他の費用がかからないかどうかはわかりませんが、適当に進めて使うと1日2400円以上取られる計算になります。慣れないことはすべきではないと思い知らされました・・・。