director のアンダークラウドのバックアップとリストア
director のアンダークラウドのバックアップとリストア
概要
第1章 アンダークラウドのバックアップ
本ガイドでは、Red Hat OpenStack Platform director で使用するアンダークラウドのバックアップ方法を説明します。アンダークラウドとは、通常 OpenStack 環境のデプロイメントおよび管理に使用する単一の物理ノードのことを指します (ただし、仮想マシンで director を実行する、2 ノードタイプの Pacemaker クラスターを使用した高可用性オプションも存在します)。
1.1. バックアップに関する留意事項
データ損失やシステムのダウンタイムを最小限に抑えるため、強力なバックアップおよびリカバリーポリシーを策定します。バックアップストラテジーを決定するにあたっては、以下の質問事項への回答を明確にしておく必要があります。
- データ損失からどの程度迅速に復旧する必要がありますか。データ損失が一切許容されない場合には、デプロイメントストラテジーとして、バックアップの使用に加えて、高可用性に焦点を当てるべきです。物理バックアップメディアを取得する際にかかる時間 (例: オフサイトの場所を利用している場合はそのサイトからのメディア) やリストアの操作に利用可能なテープドライブがいくつあるかを考慮する必要があります。
- 保管が必要なバックアップの数はいくつですか。データの保管年数に影響を与える法的かつ規制上の要件を考慮する必要があります。
- バックアップはオフサイトに保管する必要がありますか。バックアップメディアをオフサイトに保管すると、物理的な場所に降りかかる災害のリスクを軽減するのに役立ちます。
- バックアップをテストする頻度はどの程度ですか。強固なバックアップストラテジーには、バックアップデータを定期的にリストアするテストが含まれます。これは、正しいデータが依然としてバックアップされており、バックアップやリストアプロセス中にデータの破損が発生していないことを検証するのに役立ちます。これらのテストは、実際の災害復旧の条件下で実行することを想定すべきです。
- バックアップの対象は何ですか。以下の項では、コンポーネントのデータベースとファイルシステムのバックアップのほか、バックアップの復旧についても説明します。
1.2. アンダークラウドノードの高可用性
Red Hat は、アンダークラウドノードの高可用性 (HA) オプションに特定の要件を規定していないので、希望に応じて自由に検討することができます。たとえば、Red Hat Virtualization (RHV) 内の高可用性の仮想マシンとしてアンダークラウドノードを実行する構成を検討してください。また、必要なサービスを HA で提供する Pacemaker をインストールした物理ノードを使用することも検討することができます。
アンダークラウドノードの高可用性について検討する場合は、お使いの環境に最も有効であると判断したソリューションのドキュメントやグッドプラクティスを参照してください。
1.3. コンテナー化されたアンダークラウドのバックアップ
完全なアンダークラウドのバックアップには、以下のデータベースおよびファイルが含まれます。
- アンダークラウドノード上のすべての MariaDB データベース
- データベースを正確にリストアできるようにするためのアンダークラウド上の MariaDB 設定ファイル
-
設定データ:
/etc
-
ログデータ:
/var/log
-
イメージデータ:
/var/lib/glance
-
証明書生成データ (SSL を使用している場合):
/var/lib/certmonger
-
コンテナーイメージデータ:
/var/lib/containers
および/var/lib/image-serve
-
swift の全データ:
/srv/node
-
stack ユーザーのホームディレクトリー内の全データ:
/home/stack
バックアッププロセスを実行する前に、アンダークラウドの利用可能なディスク容量が十分であることを確認します。アーカイブファイルは 3.5 GB 以上であることを想定します。
手順
-
アンダークラウドに
root
ユーザーとしてログインします。 パスワードを取得します。
[root@director ~]# /bin/hiera -c /etc/puppet/hiera.yaml mysql::server::root_password
バックアップを実行します。
[root@director ~]# podman exec mysql bash -c "mysqldump -uroot -pPASSWORD --opt --all-databases" > /root/undercloud-all-databases.sql
データベースの root 設定ファイルをコピーします。
[root@director ~]# cp /var/lib/config-data/puppet-generated/mysql/root/.my.cnf ~/.
データベースのバックアップと設定ファイルをアーカイブします。
[root@director ~]# cd /backup [root@director backup]# tar --xattrs --xattrs-include='*.*' --ignore-failed-read -cf \ undercloud-backup-`date +%F`.tar \ /root/undercloud-all-databases.sql \ /etc \ /var/log \ /var/lib/glance \ /var/lib/certmonger \ /var/lib/containers \ /var/lib/image-serve \ /var/lib/config-data \ /srv/node \ /root \ /home/stack
-
--ignore-failed-read
オプションを指定すると、アンダークラウドに適用されないディレクトリーはスキップされます。 -
--xattrs
オプションには、Object Storage (swift) のメタデータを保管するのに必要な拡張属性が含まれます。
これにより、
undercloud-backup-<date>.tar.gz
という名前のファイルが作成されます。ここで、<date>
はシステムの日付けです。このtar
ファイルをセキュアな場所にコピーします。-
1.4. 作成完了したバックアップの検証
リストアプロセスを実行/検証することでバックアッププロセスが正常に完了したことを検証できます。バックアップからのリストアの詳しい情報は、次の項を参照してください。
パート I. アンダークラウドのリストア
本項では、Red Hat OpenStack Platform director で使用するアンダークラウドのリストア方法を説明します。
このプロセスでは、OpenStack Platform director のバックアップのデータをアンダークラウドの新規インストールにリストアする手順を説明します。これにより、復元されたアンダークラウドでは最新のパッケージが使用されます。
第2章 コンテナー化されたアンダークラウドの復元
以下の復元プロセスは、アンダークラウドノードでエラーが発生して、回復不可能な状態であることを前提としています。この手順では、新規インストール環境でデータベースおよびクリティカルなファイルシステムの復元を行う必要があります。以下が前提条件です。
- Red Hat Enterprise Linux 8 の最新版を再インストール済みであること
- ハードウェアレイアウトが同じであること
- マシンのホスト名とアンダークラウドの設定が同じであること
-
バックアップアーカイブが
root
ディレクトリーにコピー済みであること
手順
-
お使いのアンダークラウドに
root
ユーザーとしてログインします。 コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。
[root@director ~]# subscription-manager register
Red Hat OpenStack Platform のエンタイトルメントをアタッチします。
[root@director ~]# subscription-manager attach --pool=Valid-Pool-Number-123456
デフォルトのリポジトリーをすべて無効にしてから、必要な Red Hat Enterprise Linux リポジトリーを有効にします。
[root@director ~]# subscription-manager repos --disable=* [root@director ~]# subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms --enable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=openstack-16-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms
システムで更新を実行して、ベースシステムパッケージを最新の状態にします。
[root@director ~]# dnf update -y [root@director ~]# reboot
アンダークラウドの時刻が同期されていることを確認します。以下に例を示します。
[root@director ~]# dnf install -y chrony [root@director ~]# systemctl start chronyd [root@director ~]# systemctl enable chronyd
-
アンダークラウドのバックアップアーカイブをアンダークラウドの
root
ディレクトリーにコピーします。これ以降のステップでは、ファイル名にundercloud-backup-$TIMESTAMP.tar
を使用しています。ここで、$TIMESTAMP はアーカイブのタイムスタンプの Bash 変数です。 データベースサーバーとクライアントツールをインストールします。
[root@director ~]# dnf install -y mariadb mariadb-server
データベースを起動します。
[root@director ~]# systemctl start mariadb
データベースのバックアップのサイズに対応するように、許可されるパケット数を増やします。
[root@director ~]# mysql -uroot -e"set global max_allowed_packet = 1073741824;"
アーカイブからデータベースおよびデータベース設定を抽出します。
[root@director ~]# tar -xvC / -f undercloud-backup-$TIMESTAMP.tar var/lib/config-data/mysql/etc/my.cnf.d/galera.cnf [root@director ~]# tar -xvC / -f undercloud-backup-$TIMESTAMP.tar root/undercloud-all-databases.sql
データベースのバックアップをリストアします。
[root@director ~]# mysql -u root < /root/undercloud-all-databases.sql
root 設定ファイルの一時バージョンを抽出します。
[root@director ~]# tar -xvf undercloud-backup-$TIMESTAMP.tar root/.my.cnf
データベースの古い root パスワードを取得します。
[root@director ~]# OLDPASSWORD=$(sudo cat root/.my.cnf | grep -m1 password | cut -d'=' -f2 | tr -d "'")
データベースの root パスワードをリセットします。
[root@director ~]# mysqladmin -u root password "$OLDPASSWORD"
一時保管場所から root 設定ファイルをコピーします。
[root@director ~]# mv root/.my.cnf . [root@director ~]# rmdir root
古いユーザー権限の一覧を取得します。
[root@director ~]# mysql -e 'select host, user, password from mysql.user;'
リストされた各ホストの古いユーザー権限を削除します。以下に例を示します。
[root@director ~]# HOST="192.0.2.1" [root@director ~]# USERS=$(mysql -Nse "select user from mysql.user WHERE user != \"root\" and host = \"$HOST\";" | uniq | xargs) [root@director ~]# for USER in $USERS ; do mysql -e "drop user \"$USER\"@\"$HOST\"" || true ;done [root@director ~]# mysql -e 'flush privileges'
ホスト IP および任意のホスト ("
%
") からアクセスするすべてのユーザーに対して、この手順を実施します。
HOST パラメーターの IP アドレスは、コントロールプレーン内のアンダークラウドの IP アドレスです。
データベースを停止します。
[root@director ~]# systemctl stop mariadb
stack
ユーザーを作成します。[root@director ~]# useradd stack
ユーザーのパスワードを設定します。
[root@director ~]# passwd stack
sudo
を使用する場合にパスワードを要求されないようにします。[root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack [root@director ~]# chmod 0440 /etc/sudoers.d/stack
stack
ユーザーのホームディレクトリーをリストアします。# tar -xvC / -f undercloud-backup-$TIMESTAMP.tar home/stack
python3-policycoreutils
パッケージをインストールします。[root@director ~]# dnf -y install python3-policycoreutils
glance
データを復元します。[root@director ~]# tar --xattrs -xvC / -f undercloud-backup-$TIMESTAMP.tar var/lib/glance
swift
データを復元します。[root@director ~]# tar --xattrs -xvC / -f undercloud-backup-$TIMESTAMP.tar srv/node
アンダークラウドで SSL を使用している場合には、CA 証明書をリフレッシュします。
[root@director ~]# tar -xvC / -f undercloud-backup-$TIMESTAMP.tar etc/pki/instack-certs/undercloud.pem [root@director ~]# tar -xvC / -f undercloud-backup-$TIMESTAMP.tar etc/pki/ca-trust/source/anchors/* [root@director ~]# restorecon -R /etc/pki [root@director ~]# semanage fcontext -a -t etc_t "/etc/pki/instack-certs(/.*)?" [root@director ~]# restorecon -R /etc/pki/instack-certs [root@director ~]# update-ca-trust extract
stack
ユーザーに切り替えます。[root@director ~]# su - stack [stack@director ~]$
python3-tripleoclient
パッケージをインストールします。$ sudo dnf install -y python3-tripleoclient ceph-ansible
アンダークラウドのインストールコマンドを実行します。このコマンドは、
stack
ユーザーのホームディレクトリーから実行するようにしてください。[stack@director ~]$ openstack undercloud install
インストールが完了すると、アンダークラウドは、オーバークラウドへの接続を自動的にリストアします。ノードは、保留中のタスクに対して、OpenStack Orchestration (heat) のポーリングを続けます。
第3章 オーバークラウドノード用イメージのリストア
新しいオーバークラウドノードのプロビジョニング用に、director には最新のディスクイメージが必要です。以下の手順に従って、これらのイメージをリストアします。
手順
source コマンドで
stackrc
ファイルを読み込み、director のコマンドラインツールを有効にします。[stack@director ~]$ source ~/stackrc
rhosp-director-images
およびrhosp-director-images-ipa
パッケージをインストールします。(undercloud) [stack@director ~]$ sudo dnf install rhosp-director-images rhosp-director-images-ipa
イメージのアーカイブを、
stack
ユーザーのホーム下のimages
ディレクトリー (/home/stack/images
) に展開します。(undercloud) [stack@director ~]$ cd ~/images (undercloud) [stack@director images]$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-16.0.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.0.0.tar; do tar -xvf $i; done
これらのイメージを director にインポートします。
(undercloud) [stack@director images]$ cd ~/images (undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/
新しいイメージを使用するように、環境内のノードを設定します。
(undercloud) [stack@director images]$ for NODE in $(openstack baremetal node list -c UUID -f value) ; do openstack overcloud node configure $NODE ; done
第4章 完了したリストアの検証
以下のコマンドを使用して、新しくリストアした環境のヘルスチェックを実行します。
4.1. Identity サービス (Keystone) の動作の確認
このステップでは、ユーザーの一覧をクエリーで取得して、Identity サービスの動作を検証します。
# source stackrc # openstack user list
コントローラーから実行する場合は、このコマンドの出力には、この環境で作成されたユーザーの一覧が含まれているはずです。このアクションでは、keystone が実行中でユーザーの要求を正常に認証していることが分かります。以下に例を示します。
# openstack user list +----------------------------------+------------+---------+----------------------+ | id | name | enabled | email | +----------------------------------+------------+---------+----------------------+ | 9e47bb53bb40453094e32eccce996828 | admin | True | root@localhost | | 9fe2466f88cc4fa0ba69e59b47898829 | ceilometer | True | ceilometer@localhost | | 7a40d944e55d422fa4e85daf47e47c42 | cinder | True | cinder@localhost | | 3d2ed97538064f258f67c98d1912132e | demo | True | | | 756e73a5115d4e9a947d8aadc6f5ac22 | glance | True | glance@localhost | | f0d1fcee8f9b4da39556b78b72fdafb1 | neutron | True | neutron@localhost | | e9025f3faeee4d6bb7a057523576ea19 | nova | True | nova@localhost | | 65c60b1278a0498980b2dc46c7dcf4b7 | swift | True | swift@localhost | +----------------------------------+------------+---------+----------------------+