バックアップとリカバリー¶

OpenStackバックアップポリシーを作成する際、標準的なバックアップのベストプラクティスが適用できます。例えば、どの程度の頻度でバックアップを行なうかは、どのくらい早くデータロスから復旧させる必要があるかに密接に関連しています。

注釈

すべてのデータをまったく失いたくない場合、高可用性を持たせた導入に注力すべきです。 OpenStack High Availability Guide は、システム停止につながる可能性がある、単一障害点の削減に向けた提案があります。完全に規定されたドキュメントではありませんが、停止時間やデータ損失を避けるための方法や技術を提供しています。

さらにバックアップの考慮点として以下があげられます。

いくつのバックアップを持つべきか?
オフサイトにバックアップを置くべきか?
どの程度の頻度でバックアップをテストすべきか?

バックアップポリシーと同じくらい大事なことは、リカバリーポリシーです (少なくともリカバリーのテストは必要です)。

バックアップ対象¶

OpenStackは多くのコンポーネントから構成され、注意を払うべき箇所もたくさんありますが、大事なデータのバックアップは非常に単純です。

この章では、OpenStackコンポーネントを動作させるのに必要な設定ファイルとデータベースについてのバックアップ方法のみを説明します。オブジェクトストレージ内のオブジェクトや、ブロックストレージ内のデータのバックアップについては説明していません。一般的にこれらの領域はユーザー自身でバックアップを行います。

データベースのバックアップ¶

参考アーキテクチャーでは、クラウドコントローラーを MySQL サーバにしています。この MySQL サーバーは nova, glance, cinder, そして keystone のデータベースを保持しています。全てのデータベースが一か所にある場合、データベースバックアップは非常に容易となります。

# mysqldump --opt --all-databases > openstack.sql

もし、単一のデータベースのみバックアップする場合は次のように実行します。

# mysqldump --opt nova > nova.sql

ここで nova はバックアップ対象のデータベースです。

以下のようなcronジョブを一日に一度実行することで、簡単に自動化することも出来ます。

#!/bin/bash
backup_dir="/var/lib/backups/mysql"
filename="${backup_dir}/mysql-`hostname`-`eval date +%Y%m%d`.sql.gz"
# Dump the entire MySQL database
/usr/bin/mysqldump --opt --all-databases | gzip > $filename
# Delete backups older than 7 days
find $backup_dir -ctime +7 -type f -delete

このスクリプトは MySQL データベース全体をダンプし、7日間より古いバックアップを削除します。

ファイルシステムバックアップ¶

このセクションは、サービスにより整理される、定期的にバックアップすべきファイルやディレクトリーについて議論します。

Compute¶

クラウドコントローラーとコンピュートノードの /etc/nova ディレクトリーは、定期的にバックアップすべきです。

/var/log/nova については、全てのログをリモートで集中管理しているのであれば、バックアップの必要はありません。ログ集約システムの導入か、ログディレクトリのバックアップを強く推奨します

/var/lib/nova がバックアップする他の重要なディレクトリです。これの例外がコンピュートノードにある /var/lib/nova/instances サブディレクトリです。このサブディレクトリには実行中のインスタンスの KVM イメージが置かれます。このディレクトリをバックアップしたいと思うのは、すべてのインスタンスのバックアップコピーを保持する必要がある場合だけでしょう。多くの場合において、これを実行する必要がありません。ただし、クラウドごとに異なり、サービスレベルによっても異なる可能性があります。稼働中の KVM インスタンスのバックアップは、バックアップから復元したときでも、正しく起動しない可能性があることに気をつけてください。

イメージカタログと配布¶

/etc/keystone と /var/log/keystone は、対応する nova コンポーネントと同じルールに従います。

/var/lib/glance もバックアップすべきです。 /var/lib/glance/images には特段の注意が必要です。もし、ファイルベースのバックエンドを利用しており、このディレクトリがイメージの保管ディレクトリならば特にです。

このディレクトリの永続性を保証するために二つの方法があります。一つ目はRAIDアレイ上にこのディレクトリを置くことで、ディスク障害時にもこのディレクトリが利用できます。二つ目の方法はrsyncのようなツールを用いてイメージを他のサーバーに複製することです。

# rsync -az --progress /var/lib/glance/images backup-server:/var/lib/glance/images/

ユーザー管理¶

/etc/keystone と /var/log/keystone は他のコンポーネントの場合と同じルールに従います。

/var/lib/keystone は、使用されるデータは含まれていないはずですが、念のためバックアップします。

Block Storage¶

/etc/cinder と /var/log/cinder は他のコンポーネントの場合と同じルールに従います。

/var/lib/cinder もまたバックアップされるべきです。

ネットワーク¶

/etc/neutron と /var/log/neutron は他のコンポーネントの場合と同じルールに従います。

/var/lib/neutron もまたバックアップされるべきです。

Object Storage¶

/etc/swift は非常に重要ですのでバックアップが必要です。このディレクトリには、swift の設定ファイル以外に、Ring ファイルや Ring ビルダーファイルが置かれています。これらのファイルを消失した場合はクラスター上のデータにアクセスできなくなります。ベストプラクティスとしては、ビルダーファイルを全てのストレージノードに ring ファイルと共に置くことです。この方法でストレージクラスター上にバックアップコピーが分散されて保存されます。

Telemetry¶

Telemetry の設定ファイルを含む /etc/ceilometer ディレクトリーをバックアップします。

Orchestration¶

HOT テンプレートの yaml ファイル、Orchestration の設定ファイルを含む /etc/heat/ ディレクトリーをバックアップします。

バックアップのリカバリー¶

バックアップのリカバリーは単純です。始めにリカバリー対象のサービスが停止していることを確認します。例を挙げると、クラウドコントローラー上の nova の完全リカバリーを行なう場合、最初に全ての nova サービスを停止します。

# stop nova-api
# stop nova-consoleauth
# stop nova-novncproxy
# stop nova-objectstore
# stop nova-scheduler

以前にバックアップしたデータベースをインポートします。

# mysql nova < nova.sql

バックアップされた nova ディレクトリーもリストアできます。

# mv /etc/nova{,.orig}
# cp -a /path/to/backup/nova /etc/

ファイルをリストア後、サービスを起動します。

# start mysql
# for i in nova-api nova-consoleauth nova-novncproxy \
  nova-objectstore nova-scheduler
> do
> start $i
> done

他のサービスもそれぞれのディレクトリとデータベースで同じ処理となります。

概要¶

バックアップ、その後のリカバリーは、最初に学習するシステム管理の 1 つです。しかしながら、各システムは、それぞれ注意を必要とする項目が異なります。データベース、Image service、適切なファイルシステムの場所に注意することにより、リカバリーを必要とするすべてのイベントを処理できることが保証されます。

バックアップとリカバリー