OpenStackを担当しているソリューションアーキテクトの輿水です。
Red Hat OpenStack Platform 13から16.1へのアップグレード手順の中で、アップグレード前に既存環境のバックアップを取得することをお願いしているので、今回はバックアップ方法に触れたいと思います。バックアップ手順に関して、ロングライフリリースであるRHOSP 13と16では、Director（undercloud）のバックアップ・リストアに関するドキュメントに加えて、underclodおよびovercloudのControl Planeのバックアップ・リストアに関するドキュメントが公開されています。
Red Hat OpenStack Platform 13のバックアップとリストア
バックアップ対象となるのはOpenStack Director（ undercloud ）及びOpenStack Control Plane（ Controller Node ）です。Compute Nodeは含まれません。バックアップツールとしてBashで書かれたオープンソースの災害復旧ソリューション Relax and Recover（ReaR）を使用します。ReaRではISO／USB／eSATA／PXEといった様々なブートメディア用フォーマットがサポートされていますが、本手順ではISOブートフォーマットを使用し、ブートイメージの転送にはNFSを使用します。
バックアップの流れ
バックアップ（NFS）サーバの準備
- NFSサーバーのインストールとNFSサービスに必要なポートをファイアーウォールで開放する
- バックアップサーバに任意のバックアップディレクトリを作成
- バックアップディレクトリをundercloudおよび各Controller Nodeに対してexport
undercloudと各Controller Nodeでの事前準備
- Relax and Recover (ReaR) パッケージおよびISOイメージを生成するためのパッケージをインストール
- バックアップディレクトリを作成
- バックアップサーバのバックアップディレクトリをmount
- ReaR設定ファイルを作成
undercloudのバックアップ
- 各Controller Nodeのバックアップ
undercloudのバックアップ
undercloudでReaRコマンドを実行します。この操作によってバックアップサーバのバックアップディレクトリにundercloudのISOイメージが作成されます。この間、OpenStackサービスに影響は発生しません。
Controller Nodeのバックアップ
Control Planeのバックアップを実施するためにはPacemekrおよび各Controller Nodeで稼働しているすべてのコンテナを停止する必要があります。この間にデータベースのバックアップも実施します。Pacemakerとコンテナを停止している間は、Computeに対するControl Planeサービスが停止するため、インスタンスの作成やイ移行などのOpenStackの操作を行うことはできません。
はじめにController Nodeのいずれかでmysqlコマンドでデータベースのバックアップを作成します。次にPacemaker停止のコマンドを実行します。Pacemakerが停止したことを確認した後に、各Controller Nodeでコンテナを停止します。コンテナ停止後、ReaRコマンドを実行します。これにより各Controller NodeのISOイメージがバックアップサーバに作成されます。
ISOイメージが生成されたら、Controller NodeのいずれかでPacemekr起動を行い、各Controller Nodeでコンテナを起動します。Pacemakerとコンテナが起動すれば、OpenStackの操作が可能になります。
リストア手順
ブート可能なISOイメージを読み込み、リストアが必要なノードをブートします。Relax-and-Recover ブートメニューが表示されるので、対象となるノード名を確認してリストアを行ってください。リストア後はノードの電源をオフにして、通常のブートデバイスで起動することを確認してください。
▽Red Hat OpenStack Platform 13 バックアップとリストアの公開ドキュメント access.redhat.com
Red Hat OpenStack Platform 16のバックアップとリストア
RHOSP 16の場合でも、 ReaRを使ってバックアップする処理は同様ですが、RHOSP 13では各サーバで手動でコマンドを実行していた処理を、RHOSP 16ではAnsibleを利用して実行するようになっています。backup-and-restoreのRoleは既に準備されており、環境固有の値を示すyamlファイルを作成しそれを指定することで一連の処理を行うことができます。Ansible Playbookの実行はundercloudで行います。RHOSP 13の手順では各サーバにログインし、手動でmysqlコマンドやpcsコマンドを実行していましたがRHOSP 16ではそのようなコマンドを意識する必要はありません。
（例）undercloudのバックアップ取得
(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_create_restore_images-undercloud.yaml # Playbook # Using ReaR on the undercloud node. - become: true hosts: undercloud name: Create the recovery images for the undercloud roles: - role: backup-and-restore EOF
.
(undercloud) [stack@undercloud ~]$ ansible-playbook \
-v -i ~/tripleo-inventory.yaml \
--extra="ansible_ssh_common_args=-o StrictHostKeyChecking=no" \
--become \
--become-user root \
--tags bar_create_recover_image \
~/bar_rear_create_restore_images-undercloud.yaml
バックアップのコマンドは煩雑かつクリティカルなものも多いので、自動化されていると便利です。準備されてるplaybookの内容はGitで見ることができるので興味があれば参照してください。
▽Red Hat OpenStack Platform 16.1 バックアップとリストアの公開ドキュメント access.redhat.com
以上、Red Hat OpenStack Platformのバックアップについてでした。今後はOpenStack環境の維持・運用について記事を出してゆきたいと思ってます。
