Google Cloud バックアップガイド
Google Cloud Storage を使用するための OpenStack Block Storage バックアップの設定
概要
1. はじめに
Red Hat OpenStack Platform director は、完全な OpenStack 環境をインストールおよび管理するためのツールセットで、主に OpenStack プロジェクトの TripleO (OpenStack-on-OpenStack) をベースとしています。director の主な目的は、手動での設定を最低限に抑えて、機能的なエンタープライズレベルの OpenStack デプロイメントを完全にオーケストレーションすることです。director は、個別の OpenStack コンポーネントの手動設定に内在する数多くの問題に対処するのに役立ちます。
director が作成して最終的に構築される OpenStack デプロイメントは、オーバークラウド と呼ばれます。オーバークラウドには、Block Storage など、エンドユーザーにサービスを提供するコンポーネントがすべて含まれます。本書は、オーバークラウドの Block Storage サービスにカスタムのバックエンドをデプロイする方法を説明します。
Red Hat OpenStack Platform は、ブロックストレージバックエンドやデータ処理などの機能向けにサードパーティーのサービス、デバイス、およびアプリケーションを複数サポートしています。今回のリリースでは、Block Storage サービスが Google Cloud をバックアップストレージサービスとして使用するように設定することができます。本リリースでは、Google Cloud の統合は テクノロジープレビュー 機能として提供しています。
テクノロジープレビュー 機能は、Red Hat では完全にサポートしていません。本ガイドで記載するデプロイメントシナリオはテスト目的でのみで使用し、実稼働環境にはデプロイすべきではありません。
テクノロジープレビュー機能に関する詳しい情報は、「対象範囲の詳細」を参照してください。
本ガイドには、オーバークラウドデプロイメント上の Block Storage サービスがボリュームを Google Cloud Storage にバックアップするように設定するテストシナリオを記載しています。このテストシナリオは、以下の要件を満たす必要があります。
- 『Red Hat OpenStack Platform 10 director のインストールと使用方法』の手順に従ってオーバークラウドをすでにデプロイ済みであること。
-
管理者特権のアカウントのユーザー名とパスワードがあること。オーバークラウドをデプロイするために作成されたのと同じアカウントを使用することができます。 『Red Hat OpenStack Platform 10 director のインストールと使用方法』では、
stackという名前のユーザーはこの目的で作成されます。 - Block Storage サービスが、コントローラーノードにインストールされていること。HA デプロイメントの場合には、全コントローラーノードにインストールされていること。
- Google Cloud Platform にアクセスできる Google アカウントがあること。このアカウントは、Block Storage サービスが Google Cloud にアクセスして、バックアップを保管するために使用します。
2. プロセスの説明
Block Storage サービスが Google Cloud をバックアップサービスとして使用するように設定する手順は、以下のステップで構成されます。
- Google アカウントのサービスアカウントの認証情報の作成およびダウンロード (「GCS 認証情報ファイルの作成とダウンロード」)。
- 必要な Block Storage の設定を定義する環境ファイルの作成 (「環境ファイルの作成」)。この環境ファイルは、前のステップで作成したサービスアカウントの認証情報も使用します。
- 作成した環境ファイルを使用したオーバークラウドの再デプロイ (「オーバークラウドの再デプロイ」)。
以下のセクションでは、これらの各手順について詳しく説明します。
3. GCS 認証情報ファイルの作成とダウンロード
Block Storage サービスがバックアップのために Google Cloud にアクセス/使用するには、Google の認証情報を必要とします。以下の手順にしたがって service account key を作成すると、これらの認証情報を Block Storage に提供することができます。
- Google アカウントを使用して、Google Developer Console (http://console.developers.google.com) にログインします。
認証情報タブをクリックします。認証情報を作成ドロップダウンリストからサービス アカウント キーを選択します。
次の画面 (
サービス アカウント キーの作成) で、サービス アカウントドロップダウンリストから Block Storage サービスが使用する必要のあるサービスアカウントを選択します。
同じ画面で、
キーのタイプのセクションからJSONを選択して、作成をクリックします。ブラウザーにより、キーがデフォルトのダウンロード先にダウンロードされます。
ダウンロードしたファイルを開いて、
project_idパラメーターの値をメモしておきます。{ "type": "service_account", "project_id": "cloud-backup-1370", .../etc/cinder/Cloud-Backup.json キーは、後ほど 「環境ファイルの作成」で使用します (具体的には、
project_idの値とファイルへの絶対パスを使用します)。キーファイルを任意のコントローラーノード上の /etc/cinder/ にコピーします。その場所から、以下のコマンドを実行して、キーファイルのユーザー、グループ、パーミッションが /etc/cinder/cinder.conf と一致するように変更します。この操作により、Block Storage サービスが確実にこのキーファイルの情報を使用することができるようになります。
# cp Cloud-Backup.json /etc/cinder/ # chown cinder:cinder /etc/cinder/Cloud-Backup.json # chmod 0600 /etc/cinder/Cloud-Backup.json
各コントローラーノードの同じ場所 (/etc/cinder/Cloud-Backup.json) にキーファイルをコピーします。以下のように
rsync -aコマンドを実行して、パーミッションと所有者の設定が保持されるようにします。# rsync -a /etc/cinder/Cloud-Backup.json root@CONTROLLERHOST:/etc/cinder/CONTROLLERHOST の箇所は、コピー先のコントローラーのホスト名に置き換えます。
4. 環境ファイルの作成
環境ファイルには、Block Storage サービスに適用する必要のある設定が記載されています。この場合には、Block Storage サービスは Google Cloud にボリュームのバックアップを保管するように設定されます。環境ファイルに関する詳しい情報は、 『Red Hat OpenStack Platform 10 director のインストールと使用方法』を参照してください。
環境ファイルでは、各設定を以下のように定義します。
入力形式
SECT/PARAM: # 1 value: CONFIG # 2
本ガイドでは、すべてのパラメーターが DEFAULT セクションで宣言されます。以下の表には、Google Cloud Storage (GCS) をバックアップサービスとして設定するのに必要な各設定についての説明をまとめています。
- Google Cloud バックアップの設定
|
PARAM |
デフォルト |
CONFIG の説明 |
|
backup_driver |
cinder.backup.drivers.swift |
Block Storage サーバーが使用する必要のあるバックアップドライバー。Google Cloud Storage には、 |
|
backup_gcs_credential_file |
「GCS 認証情報ファイルの作成とダウンロード」 のステップで作成済みのサービスアカウントのキーファイルへの絶対パス | |
|
backup_gcs_bucket |
使用するGCS バケット (またはオブジェクトストレージリポジトリー)。これはすでに存在している場合とそうでない場合があります。存在しないバケットを指定する場合、Google Cloud Storage のバックアップドライバーは、ここで指定した名前を使用してバケットを作成します。詳しくは、「Buckets」 および 「Bucket name requirements」を参照してください。 | |
|
backup_gcs_bucket_location |
US |
GCS バケットの場所。この値は、 詳しくは、「Bucket Locations」を参照してください。 |
|
backup_gcs_project_id |
使用するサービスアカウントのプロジェクト ID。「GCS 認証情報ファイルの作成とダウンロード」のステップで、サービスアカウントキーの | |
|
backup_gcs_object_size |
52428800 |
GCS バックアップオブジェクトのサイズ (バイト単位) |
|
backup_gcs_block_size |
32768 |
差分バックアップでトラッキングされる変更のサイズ (バイト単位)。この値は、 |
|
backup_gcs_user_agent |
gcscinder |
GCS API の HTTP ユーザーエージェントの文字列 |
|
backup_gcs_reader_chunk_size |
2097152 |
GCS オブジェクトは、このサイズ (バイト単位) のチャンクでダウンロードされます。 |
|
backup_gcs_writer_chunk_size |
2097152 |
GCS オブジェクトは、このサイズ (バイト単位) の複数のチャンクでアップロードされます。複数のチャンクではなく、単一のチャンクとしてファイルをアップロードするには、 |
|
backup_gcs_num_retries |
3 |
再試行回数 |
|
backup_gcs_storage_class |
NEARLINE |
GCS バケットのストレージクラス。この値は、 |
|
backup_gcs_retry_error_codes |
429 |
GCS エラーコード一覧 |
|
backup_gcs_enable_progress_timer |
True |
ボリュームのバックアップ中に Telemetry サービス ( |
Google Cloud Storage は、新規バケットを作成すると、選択したストレージクラス (backup_gcs_storage_class) に基づいて課金します。デフォルトの NEARLINE クラスは、バックアップサービスに適しています。
なお、バケットは、一旦作成したら場所やクラスを変更することはできません。詳しくは、「Managing a bucket’s storage class or location」を参照してください。
以下のサンプルには、GCS をバックアップサービスとして設定するための環境ファイルの一般的な内容を示しています。
/home/stack/templates/gcs-backup.yaml
parameter_defaults:
ControllerExtraConfig: # 1
cinder::config::cinder_config:
DEFAULT/backup_driver
value: cinder.backup.drivers.google
DEFAULT/backup_gcs_credential_file
value: /etc/cinder/Cloud-Backup.json
DEFAULT/backup_gcs_bucket
value: mycinderbucket
DEFAULT/backup_gcs_project_id
value: cloud-backup-1370
DEFAULT/backup_gcs_user_agent
value: myuseragent
- 1
ControllerExtraConfigは、全コントローラーノードに適用されるカスタムの設定を定義します。cinder::config::cinder_configクラスは、この設定が Block Storage (cinder) サービスに適用される必要のあることを意味します。このため、バックエンドの設定は最終的に、各コントローラーノードの/etc/cinder/cinder.confファイルに指定されることになります。
環境ファイルを作成した後には、「オーバークラウドの再デプロイ」でオーバークラウドに設定をデプロイする手順を参照してください。
5. オーバークラウドの再デプロイ
/home/stack/templates/ に environment file ファイルを作成したら、stack ユーザーとしてログインし、以下のコマンドを実行して設定をデプロイします。
$ openstack overcloud deploy --templates -e /home/stack/templates/gcs-backup.yaml
オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の変更がオーバークラウドに加えられないように、ここで「-e」オプションを使用して環境ファイルを再度渡します。
詳しくは、「オーバークラウドのスケーリング」 および「オーバークラウド環境の変更」を参照してください。
