アンダークラウドおよびコントロールプレーンノードのバックアップと復元
アンダークラウドおよびオーバークラウドコントロールプレーンノードのバックアップの作成と復元
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ)
Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。
ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)
特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。
- Multi-page HTML 形式でドキュメントを表示します。
- ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
- コメントするテキスト部分をハイライト表示します。
- Add Feedback をクリックします。
- Add Feedback フィールドにコメントを入力します。
- オプション: ドキュメントチームが問題の詳細を確認する際に使用できるメールアドレスを記入してください。
- Submit をクリックします。
第1章 アンダークラウドノードのバックアップ
アンダークラウドノードをバックアップするには、バックアップノードを設定し、アンダークラウドノードに Relax-and-Recover ツールをインストールし、バックアップイメージを作成します。バックアップは、通常の環境メンテナンスの一環として作成できます。
さらに、更新またはアップグレードを実行する前にアンダークラウドノードをバックアップする必要があります。バックアップを使用して、更新またはアップグレード時にエラーが発生した場合に、アンダークラウドノードを以前の状態に復元することができます。
1.1. サポート対象のバックアップ形式およびプロトコル
アンダークラウドおよびバックアップ/復元プロセスは、オープンソースのツールである Relax-and-Recover (ReaR) を使用してブート可能なバックアップイメージを作成し、復元します。ReaR は Bash で記述されており、複数のイメージ形式と複数の転送プロトコルをサポートします。
以下のリストで、Red Hat OpenStack Platform がサポートするバックアップフォーマットおよびプロトコルを示しています。
- ブート可能なメディア形式
- ISO
- ファイルトランスポートプロトコル
- SFTP
- NFS
1.2. バックアップノードへの NFS サーバーのインストールと設定
バックアップファイルを保存するために、新しい NFS サーバーをインストールして設定できます。バックアップノードに NFS サーバーをインストールして設定するには、インベントリーファイルを作成して SSH キーを設定して、NFS サーバーオプションを指定して openstack undercloud backup
コマンドを実行します。
- NFS サーバーまたは SFTP サーバーをインストールして設定している場合は、この手順を実行する必要はありません。バックアップするノードに ReaR を設定するときに、サーバー情報を入力します。
-
デフォルトでは、Relax and Recover (ReaR) 設定は、NFS サーバーの IP アドレスが
192.168.24.1
であることを前提としています。NFS サーバーの IP アドレスが異なる場合は、設定 ReaR コマンドにパラメーター tripleo_backup_and_restore_nfs_server を追加します。
手順
アンダークラウドノードにおいて、source コマンドでアンダークラウドの認証情報を読み込みます。
[stack@undercloud ~]$ source stackrc (undercloud) [stack@undercloud ~]$
アンダークラウドノードで、バックアップノードのインベントリーファイルを作成します。ここで、
<ip_address>
および<user>
を実際の環境の該当する値に置き換えます。(undercloud) [stack@undercloud ~]$ cat <<'EOF'> ~/nfs-inventory.yaml [BackupNode] <backup_node> ansible_host=<ip_address> ansible_user=<user> EOF
アンダークラウドノードで、以下の Ansible Playbook を作成します。ここで、
<backup_node>
をバックアップノードのホスト名に置き換えます。(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_nfs_setup.yaml # Playbook # Substitute <backup_node> with the host name of your backup node. - become: true hosts: <backup_node> name: Setup NFS server for ReaR roles: - role: backup-and-restore EOF
公開 SSH 鍵をアンダークラウドノードからバックアップノードにコピーします。
(undercloud) [stack@undercloud ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub <backup_node>
<backup_node>
をバックアップノードのパスおよび名前に置き換えます。アンダークラウドノードで以下の
ansible-playbook
コマンドを入力し、バックアップノードを設定します。(undercloud) [stack@undercloud ~]$ ansible-playbook \ -v -i ~/nfs-inventory.yaml \ --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \ --become \ --become-user root \ --tags bar_setup_nfs_server \ ~/bar_nfs_setup.yaml
1.3. アンダークラウドノードへの ReaR のインストール
アンダークラウドノードのバックアップを作成する前に、アンダークラウドに Relax and Recover (ReaR) をインストールして設定します。
前提条件
- バックアップノードに NFS または SFTP サーバーがインストールおよび設定されている。新しい NFS サーバーの作成方法は 「バックアップノードへの NFS サーバーのインストールと設定」 を参照してください。
手順
アンダークラウドノードにおいて、source コマンドでアンダークラウドの認証情報を読み込み、
tripleo-ansible-inventory
コマンドを使用して、すべてのオーバークラウドノードのホストおよび変数が含まれる静的なインベントリーファイル生成します。[stack@undercloud ~]$ source stackrc (undercloud) [stack@undercloud ~]$ tripleo-ansible-inventory \ --ansible_ssh_user heat-admin \ --static-yaml-inventory /home/stack/tripleo-inventory.yaml
カスタムのスタック名を使用する場合は、
--stack <stack_name>
オプションをtripleo-ansible-inventory
コマンドに追加します。アンダークラウドノードで、以下の Ansible Playbook を作成します。
(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_setup-undercloud.yaml # Playbook # Installing and configuring ReaR on the undercloud node - become: true hosts: undercloud name: Install ReaR roles: - role: backup-and-restore EOF
以下のいずれかのオプションを選択します。
NFS を使用する場合は、次の Ansible コマンドを入力して、アンダークラウドノードに ReaR をインストールします。
(undercloud) [stack@undercloud ~]$ ansible-playbook \ -v -i ~/tripleo-inventory.yaml \ --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \ --become \ --become-user root \ -e tripleo_backup_and_restore_server=<nfs-ip> \ --tags bar_setup_rear \ ~/bar_rear_setup-undercloud.yaml
SFTP を使用する場合は、次の Ansible コマンドを入力して、アンダークラウドノードに ReaR をインストールします。
(undercloud) [stack@undercloud ~]$ ansible-playbook \ -v -i ~/tripleo-inventory.yaml \ --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \ --become \ --become-user root \ -e tripleo_backup_and_restore_output_url=sftp://<user>:<password>@<backup_node_ip>/ \ -e tripleo_backup_and_restore_backup_url=iso:///backup/ \ --tags bar_setup_rear \ ~/bar_rear_setup-undercloud.yaml
システムで UEFI ブートローダーを使用している場合は、アンダークラウドノードで以下の手順を実施します。
以下のツールをインストールします。
$ sudo dnf install dosfstools efibootmgr
-
USING_UEFI_BOOTLOADER
パラメーターの値0
を値1
に置き換えて、/etc/rear/local.conf
にある ReaR 設定ファイルで UEFI バックアップを有効にします。
1.4. バックアップ用の Open vSwitch (OVS) インターフェイスの設定
お使いの環境で Open vSwitch (OVS) ブリッジを使用する場合は、アンダークラウドまたはコントロールプレーンノードをバックアップする前に OVS インターフェイスを手動で設定する必要があります。復元プロセスでは、この情報を使用してネットワークインターフェイスを復元します。
手順
/etc/rear/local.conf
ファイルに、以下の形式でNETWORKING_PREPARATION_COMMANDS
パラメーターを追加します。NETWORKING_PREPARATION_COMMANDS=('<command_1>' '<command_2>' ...')
<command_1>
および<command_2>
を、ネットワークインターフェイス名または IP アドレスを設定するコマンドに置き換えます。たとえば、ip link add br-ctlplane type bridge
コマンドを追加してコントロールプレーンのブリッジ名を設定するか、ip link set eth0 up
コマンドを追加してインターフェイスの名前を設定できます。ネットワーク設定に基づいて、パラメーターにさらにコマンドを追加します。
1.5. アンダークラウドノードのバックアップの作成
アンダークラウドノードのバックアップを作成するには、backup-and-restore
Ansible ロールを使用します。その後、ノードが破損したりアクセスできなくなったりした場合に備えて、バックアップを使用して、アンダークラウドノードを以前の状態に復元できます。アンダークラウドノードのバックアップには、アンダークラウドノードで実行されるデータベースのバックアップが含まれます。
前提条件
- バックアップノードに NFS または SFTP サーバーがインストールおよび設定されている。新しい NFS サーバーの作成方法は 「バックアップノードへの NFS サーバーのインストールと設定」 を参照してください。
- アンダークラウドノードに ReaR がインストールされている。詳細は、「アンダークラウドノードへの ReaR のインストール」 を参照してください。
- ネットワークインターフェイスに OVS ブリッジを使用する場合は、OVS インターフェイスを設定している。詳細は、「バックアップ用の Open vSwitch (OVS) インターフェイスの設定」 を参照してください。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 MySQL の root パスワードを取得します。
[stack@undercloud ~]$ PASSWORD=$(sudo /bin/hiera -c /etc/puppet/hiera.yaml mysql::server::root_password)
アンダークラウドノードのデータベースのバックアップを作成します。
[stack@undercloud ~]$ sudo podman exec mysql bash -c "mysqldump -uroot -p$PASSWORD --opt --all-databases" | sudo tee /root/undercloud-all-databases.sql
source コマンドでアンダークラウドの認証情報を読み込みます。
[stack@undercloud ~]$ source stackrc
アンダークラウドノードで、以下の Ansible Playbook を作成します。
(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
アンダークラウドノードのバックアップを作成するには、以下の
ansible-playbook
コマンドを入力します。(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
第2章 コントロールプレーンノードのバックアップ
コントロールプレーンノードをバックアップするには、バックアップノードを設定し、コントロールプレーンノードに Relax-and-Recover ツールをインストールし、バックアップイメージを作成します。バックアップは、通常の環境メンテナンスの一環として作成できます。
更新またはアップグレードを実行する前にコントロールプレーンノードをバックアップする必要があります。更新またはアップグレード時にエラーが発生した場合は、バックアップを使用して、コントロールプレーンノードを以前の状態に復元できます。また、バックアップは、通常の環境メンテナンスの一環として作成できます。
2.1. サポート対象のバックアップ形式およびプロトコル
アンダークラウドおよびバックアップ/復元プロセスは、オープンソースのツールである Relax-and-Recover (ReaR) を使用してブート可能なバックアップイメージを作成し、復元します。ReaR は Bash で記述されており、複数のイメージ形式と複数の転送プロトコルをサポートします。
以下のリストで、Red Hat OpenStack Platform がサポートするバックアップフォーマットおよびプロトコルを示しています。
- ブート可能なメディア形式
- ISO
- ファイルトランスポートプロトコル
- SFTP
- NFS
2.2. バックアップノードへの NFS サーバーのインストールと設定
バックアップファイルを保存するために、新しい NFS サーバーをインストールして設定できます。バックアップノードに NFS サーバーをインストールして設定するには、インベントリーファイルを作成して SSH キーを設定して、NFS サーバーオプションを指定して openstack undercloud backup
コマンドを実行します。
- NFS サーバーまたは SFTP サーバーをインストールして設定している場合は、この手順を実行する必要はありません。バックアップするノードに ReaR を設定するときに、サーバー情報を入力します。
-
デフォルトでは、Relax and Recover (ReaR) 設定は、NFS サーバーの IP アドレスが
192.168.24.1
であることを前提としています。NFS サーバーの IP アドレスが異なる場合は、設定 ReaR コマンドにパラメーター tripleo_backup_and_restore_nfs_server を追加します。
手順
アンダークラウドノードにおいて、source コマンドでアンダークラウドの認証情報を読み込みます。
[stack@undercloud ~]$ source stackrc (undercloud) [stack@undercloud ~]$
アンダークラウドノードで、バックアップノードのインベントリーファイルを作成します。ここで、
<ip_address>
および<user>
を実際の環境の該当する値に置き換えます。(undercloud) [stack@undercloud ~]$ cat <<'EOF'> ~/nfs-inventory.yaml [BackupNode] <backup_node> ansible_host=<ip_address> ansible_user=<user> EOF
アンダークラウドノードで、以下の Ansible Playbook を作成します。ここで、
<backup_node>
をバックアップノードのホスト名に置き換えます。(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_nfs_setup.yaml # Playbook # Substitute <backup_node> with the host name of your backup node. - become: true hosts: <backup_node> name: Setup NFS server for ReaR roles: - role: backup-and-restore EOF
公開 SSH 鍵をアンダークラウドノードからバックアップノードにコピーします。
(undercloud) [stack@undercloud ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub <backup_node>
<backup_node>
をバックアップノードのパスおよび名前に置き換えます。アンダークラウドノードで以下の
ansible-playbook
コマンドを入力し、バックアップノードを設定します。(undercloud) [stack@undercloud ~]$ ansible-playbook \ -v -i ~/nfs-inventory.yaml \ --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \ --become \ --become-user root \ --tags bar_setup_nfs_server \ ~/bar_nfs_setup.yaml
2.3. コントロールプレーンノードへの ReaR のインストール
コントロールプレーンノードのバックアップを作成する前に、各コントロールプレーンノードに Relax and Recover (ReaR) をインストールして設定します。
既知の問題が原因でコントローラーノードがダウンしても、オーバークラウドノードの ReaR バックアップは継続されます。ReR バックアップを実行する前に、すべてのコントローラーノードが実行されていることを確認してください。今後の Red Hat OpenStack Platform (RHOSP) リリースで修正される予定です。詳細は BZ#2077335 - Back up of the overcloud ctlplane keeps going even if one controller is unreachable を参照してください。
前提条件
- バックアップノードに NFS または SFTP サーバーがインストールおよび設定されている。新しい NFS サーバーの作成方法は 「バックアップノードへの NFS サーバーのインストールと設定」 を参照してください。
手順
アンダークラウドノードで、以下の Ansible Playbook を作成します。
(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_setup-controller.yaml # Playbook # Install and configuring ReaR on the control plane nodes - become: true hosts: Controller name: Install ReaR roles: - role: backup-and-restore EOF
注記設定可能なロールを持つコントロールプレーンノードをデプロイした場合は、ホストタイプの
Controller
をコントロールプレーン内のノードのタイプに置き換えます。たとえば、データベース、メッセージング、およびネットワーキングを別々のノードにデプロイした場合は、ControllerOpenstack,Database,Messaging,Networker
と入力します。以下のいずれかのオプションを選択します。
NFS を使用し、NFS サーバーの IP アドレスがデフォルト値の
192.168.24.1
の場合は、アンダークラウドノードで以下の Ansible コマンドを入力し、コントロールプレーンノードに ReaR をインストールします。(undercloud) [stack@undercloud ~]$ ansible-playbook \ -v -i ~/tripleo-inventory.yaml \ --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \ --become \ --become-user root \ --tags bar_setup_rear \ ~/bar_rear_setup-controller.yaml
SFTP を使用し、NFS サーバーの IP アドレスがデフォルト値の
192.168.24.1
以外の場合は、以下の Ansible コマンドを入力し、コントロールプレーンノードに ReaR をインストールします。(undercloud) [stack@undercloud ~]$ ansible-playbook \ -v -i ~/tripleo-inventory.yaml \ --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \ --become \ --become-user root \ -e tripleo_backup_and_restore_server=<nfs_ip> \ --tags bar_setup_rear \ ~/bar_rear_setup-controller.yaml
<nfs_ip>
を NFS サーバーの IP アドレスに置き換えます。SFTP を使用する場合は、次の Ansible コマンドを入力してコントロールプレーンノードに ReaR をインストールします。
(undercloud) [stack@undercloud ~]$ ansible-playbook \ -v -i ~/tripleo-inventory.yaml \ --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \ --become \ --become-user root \ -e tripleo_backup_and_restore_output_url=sftp://<user>:<password>@<backup_node_ip>/ \ -e tripleo_backup_and_restore_backup_url=iso:///backup/ \ --tags bar_setup_rear \ ~/bar_rear_setup-undercloud.yaml
システムで UEFI ブートローダーを使用している場合は、コントロールプレーンノードで以下の手順を実行します。
以下のツールをインストールします。
$ sudo dnf install dosfstools efibootmgr
-
USING_UEFI_BOOTLOADER
パラメーターの値0
を値1
に置き換えて、/etc/rear/local.conf
にある ReaR 設定ファイルで UEFI バックアップを有効にします。
2.4. バックアップ用の Open vSwitch (OVS) インターフェイスの設定
お使いの環境で Open vSwitch (OVS) ブリッジを使用する場合は、アンダークラウドまたはコントロールプレーンノードをバックアップする前に OVS インターフェイスを手動で設定する必要があります。復元プロセスでは、この情報を使用してネットワークインターフェイスを復元します。
手順
/etc/rear/local.conf
ファイルに、以下の形式でNETWORKING_PREPARATION_COMMANDS
パラメーターを追加します。NETWORKING_PREPARATION_COMMANDS=('<command_1>' '<command_2>' ...')
<command_1>
および<command_2>
を、ネットワークインターフェイス名または IP アドレスを設定するコマンドに置き換えます。たとえば、ip link add br-ctlplane type bridge
コマンドを追加してコントロールプレーンのブリッジ名を設定するか、ip link set eth0 up
コマンドを追加してインターフェイスの名前を設定できます。ネットワーク設定に基づいて、パラメーターにさらにコマンドを追加します。
2.5. コントロールプレーンノードのバックアップの作成
コントロールプレーンノードのバックアップを作成するには、backup-and-restore
Ansible ロールを使用しします。その後、ノードが破損したりアクセスできなくなったりした場合に備えて、バックアップを使用して、コントロールプレーンノードを以前の状態に復元できます。コントロールプレーンのバックアップには、コントロールプレーンノードで実行されるデータベースのバックアップが含まれます。
前提条件
- バックアップノードに NFS または SFTP サーバーがインストールおよび設定されている。新しい NFS サーバーの作成方法は 「バックアップノードへの NFS サーバーのインストールと設定」 を参照してください。
- コントロールプレーンノードに ReaR がインストールされている。詳細は、「コントロールプレーンノードへの ReaR のインストール」 を参照してください。
- ネットワークインターフェイスに OVS ブリッジを使用する場合は、OVS インターフェイスを設定している。詳細は、「バックアップ用の Open vSwitch (OVS) インターフェイスの設定」 を参照してください。
手順
各コントロールプレーンノードで、各ノードの
config-drive
パーティションをroot
ユーザーとしてバックアップします。[root@controller-x ~]$ dd if=<config_drive_partition> of=/mnt/config-drive
アンダークラウドノードで、以下の Ansible Playbook を作成します。
(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_create_restore_images-controller.yaml # Playbook # Using ReaR on the control plane nodes. - become: true hosts: ceph_mon name: Backup ceph authentication tasks: - name: Backup ceph authentication role include_role: name: backup-and-restore tasks_from: ceph_authentication tags: - bar_create_recover_image - become: true hosts: Controller name: Create the recovery images for the control plane roles: - role: backup-and-restore EOF
アンダークラウドノードで以下の
ansible-playbook
コマンドを入力し、コントロールプレーンノードのバックアップを作成します。(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-controller.yaml
2.6. cron を使用したコントロールプレーンノードバックアップのスケジューリング
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能に関する詳細は、対象範囲の詳細 を参照してください。
cron ジョブを設定し、Ansible backup-and-restore
ロールを使用して ReaR でコントロールプレーンノードのバックアップを作成することができます。/var/log/rear-cron
ディレクトリーでログを確認することができます。
前提条件
- バックアップノードに NFS または SFTP サーバーがインストールおよび設定されている。新しい NFS サーバーの作成方法は 「バックアップノードへの NFS サーバーのインストールと設定」 を参照してください。
- アンダークラウドおよびコントロールプレーンノードに ReaR がインストールされている。詳細は、「コントロールプレーンノードへの ReaR のインストール」 を参照してください。
- バックアップの保存用に、バックアップの場所に十分なディスク領域がある。
手順
アンダークラウドノードで、以下のコマンドを入力してバックアップ用のスクリプトを作成します。
[stack@undercloud ~]$ cat <<'EOF' > /home/stack/execute-rear-cron.sh #!/bin/bash OWNER="stack" TODAY=`date +%Y%m%d` FILE="/var/log/rear-cron.${TODAY}" sudo touch ${FILE} sudo chown ${OWNER}:${OWNER} ${FILE} CURRENTTIME=`date` echo "[$CURRENTTIME] rear start" >> ${FILE} source /home/stack/stackrc && /usr/bin/openstack overcloud backup 2>&1 >> ${FILE} CURRENTTIME=`date` echo "[$CURRENTTIME] rear end" >> ${FILE} EOF
/home/stack/execute-rear-cron.sh
スクリプトに実行可能な権限を設定します。[stack@undercloud ~]$ chmod 755 /home/stack/execute-rear-cron.sh
crontab -e
コマンドで crontab ファイルを編集し、任意のエディターで以下の cron ジョブを追加します。ファイルに加えた変更を保存するようにしてください。[stack@undercloud ~]# $ crontab -e #adding the following line 0 0 * * * /home/stack/execute-rear-cron.sh
/home/stack/execute-rear-cron.sh
スクリプトは、stack ユーザーにより午前 0 時に実行されるようにスケジュールされます。cron ジョブがスケジュールされていることを確認するには、以下のコマンドを入力します。
[stack@undercloud ~]$ crontab -l
コマンド出力には、スケジュールされている cron ジョブが表示されます。
0 0 * * * /home/stack/execute-rear-cron.sh
第3章 コンポーザブルロールを使用するコントロールプレーンノードのバックアップ
カスタムロールとも呼ばれるコンポーザブルロールを使用してコントロールプレーンをデプロイした場合は、コンポーザブルロール設定に基づいて各タイプのノードをキャプチャーするようにバックアッププロセスを設定します。コントロールプレーンノードをバックアップするには、バックアップノードを設定し、コントロールプレーンノードに Relax-and-Recover ツールをインストールし、バックアップイメージを作成します。
更新またはアップグレードを実行する前にコントロールプレーンノードをバックアップする必要があります。更新またはアップグレード時にエラーが発生した場合は、バックアップを使用して、コントロールプレーンノードを以前の状態に復元できます。また、バックアップは、通常の環境メンテナンスの一環として作成できます。
3.1. サポート対象のバックアップ形式およびプロトコル
アンダークラウドおよびバックアップ/復元プロセスは、オープンソースのツールである Relax-and-Recover (ReaR) を使用してブート可能なバックアップイメージを作成し、復元します。ReaR は Bash で記述されており、複数のイメージ形式と複数の転送プロトコルをサポートします。
以下のリストで、Red Hat OpenStack Platform がサポートするバックアップフォーマットおよびプロトコルを示しています。
- ブート可能なメディア形式
- ISO
- ファイルトランスポートプロトコル
- SFTP
- NFS
3.2. バックアップノードへの NFS サーバーのインストールと設定
バックアップファイルを保存するために、新しい NFS サーバーをインストールして設定できます。バックアップノードに NFS サーバーをインストールして設定するには、インベントリーファイルを作成して SSH キーを設定して、NFS サーバーオプションを指定して openstack undercloud backup
コマンドを実行します。
- NFS サーバーまたは SFTP サーバーをインストールして設定している場合は、この手順を実行する必要はありません。バックアップするノードに ReaR を設定するときに、サーバー情報を入力します。
-
デフォルトでは、Relax and Recover (ReaR) 設定は、NFS サーバーの IP アドレスが
192.168.24.1
であることを前提としています。NFS サーバーの IP アドレスが異なる場合は、設定 ReaR コマンドにパラメーター tripleo_backup_and_restore_nfs_server を追加します。
手順
アンダークラウドノードにおいて、source コマンドでアンダークラウドの認証情報を読み込みます。
[stack@undercloud ~]$ source stackrc (undercloud) [stack@undercloud ~]$
アンダークラウドノードで、バックアップノードのインベントリーファイルを作成します。ここで、
<ip_address>
および<user>
を実際の環境の該当する値に置き換えます。(undercloud) [stack@undercloud ~]$ cat <<'EOF'> ~/nfs-inventory.yaml [BackupNode] <backup_node> ansible_host=<ip_address> ansible_user=<user> EOF
アンダークラウドノードで、以下の Ansible Playbook を作成します。ここで、
<backup_node>
をバックアップノードのホスト名に置き換えます。(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_nfs_setup.yaml # Playbook # Substitute <backup_node> with the host name of your backup node. - become: true hosts: <backup_node> name: Setup NFS server for ReaR roles: - role: backup-and-restore EOF
公開 SSH 鍵をアンダークラウドノードからバックアップノードにコピーします。
(undercloud) [stack@undercloud ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub <backup_node>
<backup_node>
をバックアップノードのパスおよび名前に置き換えます。アンダークラウドノードで以下の
ansible-playbook
コマンドを入力し、バックアップノードを設定します。(undercloud) [stack@undercloud ~]$ ansible-playbook \ -v -i ~/nfs-inventory.yaml \ --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \ --become \ --become-user root \ --tags bar_setup_nfs_server \ ~/bar_nfs_setup.yaml
3.3. コントロールプレーンノードへの ReaR のインストール
コントロールプレーンノードのバックアップを作成する前に、各コントロールプレーンノードに Relax and Recover (ReaR) をインストールして設定します。
既知の問題が原因でコントローラーノードがダウンしても、オーバークラウドノードの ReaR バックアップは継続されます。ReR バックアップを実行する前に、すべてのコントローラーノードが実行されていることを確認してください。今後の Red Hat OpenStack Platform (RHOSP) リリースで修正される予定です。詳細は BZ#2077335 - Back up of the overcloud ctlplane keeps going even if one controller is unreachable を参照してください。
前提条件
- バックアップノードに NFS または SFTP サーバーがインストールおよび設定されている。新しい NFS サーバーの作成方法は 「バックアップノードへの NFS サーバーのインストールと設定」 を参照してください。
手順
アンダークラウドノードで、以下の Ansible Playbook を作成します。
(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_setup-controller.yaml # Playbook # Install and configuring ReaR on the control plane nodes - become: true hosts: Controller name: Install ReaR roles: - role: backup-and-restore EOF
注記設定可能なロールを持つコントロールプレーンノードをデプロイした場合は、ホストタイプの
Controller
をコントロールプレーン内のノードのタイプに置き換えます。たとえば、データベース、メッセージング、およびネットワーキングを別々のノードにデプロイした場合は、ControllerOpenstack,Database,Messaging,Networker
と入力します。以下のいずれかのオプションを選択します。
NFS を使用し、NFS サーバーの IP アドレスがデフォルト値の
192.168.24.1
の場合は、アンダークラウドノードで以下の Ansible コマンドを入力し、コントロールプレーンノードに ReaR をインストールします。(undercloud) [stack@undercloud ~]$ ansible-playbook \ -v -i ~/tripleo-inventory.yaml \ --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \ --become \ --become-user root \ --tags bar_setup_rear \ ~/bar_rear_setup-controller.yaml
SFTP を使用し、NFS サーバーの IP アドレスがデフォルト値の
192.168.24.1
以外の場合は、以下の Ansible コマンドを入力し、コントロールプレーンノードに ReaR をインストールします。(undercloud) [stack@undercloud ~]$ ansible-playbook \ -v -i ~/tripleo-inventory.yaml \ --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \ --become \ --become-user root \ -e tripleo_backup_and_restore_server=<nfs_ip> \ --tags bar_setup_rear \ ~/bar_rear_setup-controller.yaml
<nfs_ip>
を NFS サーバーの IP アドレスに置き換えます。SFTP を使用する場合は、次の Ansible コマンドを入力してコントロールプレーンノードに ReaR をインストールします。
(undercloud) [stack@undercloud ~]$ ansible-playbook \ -v -i ~/tripleo-inventory.yaml \ --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \ --become \ --become-user root \ -e tripleo_backup_and_restore_output_url=sftp://<user>:<password>@<backup_node_ip>/ \ -e tripleo_backup_and_restore_backup_url=iso:///backup/ \ --tags bar_setup_rear \ ~/bar_rear_setup-undercloud.yaml
システムで UEFI ブートローダーを使用している場合は、コントロールプレーンノードで以下の手順を実行します。
以下のツールをインストールします。
$ sudo dnf install dosfstools efibootmgr
-
USING_UEFI_BOOTLOADER
パラメーターの値0
を値1
に置き換えて、/etc/rear/local.conf
にある ReaR 設定ファイルで UEFI バックアップを有効にします。
3.4. バックアップ用の Open vSwitch (OVS) インターフェイスの設定
お使いの環境で Open vSwitch (OVS) ブリッジを使用する場合は、アンダークラウドまたはコントロールプレーンノードをバックアップする前に OVS インターフェイスを手動で設定する必要があります。復元プロセスでは、この情報を使用してネットワークインターフェイスを復元します。
手順
/etc/rear/local.conf
ファイルに、以下の形式でNETWORKING_PREPARATION_COMMANDS
パラメーターを追加します。NETWORKING_PREPARATION_COMMANDS=('<command_1>' '<command_2>' ...')
<command_1>
および<command_2>
を、ネットワークインターフェイス名または IP アドレスを設定するコマンドに置き換えます。たとえば、ip link add br-ctlplane type bridge
コマンドを追加してコントロールプレーンのブリッジ名を設定するか、ip link set eth0 up
コマンドを追加してインターフェイスの名前を設定できます。ネットワーク設定に基づいて、パラメーターにさらにコマンドを追加します。
3.5. コンポーザブルロールを使用するコントロールプレーンノードのバックアップの作成
コンポーザブルロールを使用するコントロールプレーンノードのバックアップを作成するには、backup-and-restore
Ansible ロールを使用します。その後、ノードが破損したりアクセスできなくなったりした場合に備えて、バックアップを使用して、コントロールプレーンノードを以前の状態に復元できます。コントロールプレーンのバックアップには、コントロールプレーンノードで実行されるデータベースのバックアップが含まれます。
前提条件
- バックアップノードに NFS または SFTP サーバーがインストールおよび設定されている。新しい NFS サーバーの作成方法は 「バックアップノードへの NFS サーバーのインストールと設定」 を参照してください。
- コントロールプレーンノードに ReaR がインストールされている。詳細は、「コントロールプレーンノードへの ReaR のインストール」 を参照してください。
- ネットワークインターフェイスに OVS ブリッジを使用する場合は、OVS インターフェイスを設定している。詳細は、「バックアップ用の Open vSwitch (OVS) インターフェイスの設定」 を参照してください。
手順
各コントローラーノードで、各ノードの
config-drive
パーティションをバックアップします。[heat-admin@controller-x ~]$ mkdir /mnt/config-drive [heat-admin@controller-x ~]$ dd if=<config_drive_partition> of=/mnt/config-drive
注記この手順は、コントローラーノードでのみ実行する必要があります。
アンダークラウドノードで、以下の Ansible Playbook を作成します。
(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_create_restore_images-controller.yaml # Playbook # Using ReaR on the Contorl-Plane - Composable Roles - become: true hosts: ControllerOpenstack,Database,Messaging,Networker name: Stop service management tasks: - include_role: name: backup-and-restore tasks_from: ../backup/tasks/service_manager_pause when: - tripleo_backup_and_restore_service_manager - become: true hosts: Database name: Database Backup tasks: - include_role: name: backup-and-restore tasks_from: ../backup/tasks/db_backup - become: true hosts: pacemaker name: Backup pacemaker configuration tasks: - include_role: name: backup-and-restore tasks_from: pacemaker_backup - become: true hosts: ControllerOpenstack,Database,Messaging,Networker name: Create recovery images with ReaR tasks: - include_role: name: backup-and-restore tasks_from: ../backup/tasks/main - become: true hosts: pacemaker name: Enabled pacemaker tasks: - name: Enable pacemaker command: pcs cluster start --all when: enabled_galera run_once: true tags: - bar_create_recover_image - become: true hosts: Database name: Restart galera tasks: - name: unPause database container command: "{{ tripleo_container_cli }} unpause {{ tripleo_backup_and_restore_mysql_container }}" when: - tripleo_container_cli is defined - not enabled_galera - tripleo_backup_and_restore_mysql_container is defined tags: - bar_create_recover_image - become: true hosts: ControllerOpenstack,Database,Messaging,Networker name: Unpause everything tasks: - name: Gather Container Service Name shell: | set -o pipefail /usr/bin/{{ tripleo_container_cli }} ps -a --filter='status=paused' --format '{{ '{{' }}.Names {{ '}}' }} ' register: container_services changed_when: container_services.stdout is defined tags: - bar_create_recover_image - name: Unpause containers for database backup. command: "{{ tripleo_container_cli }} unpause {{ item }}" with_items: "{{ container_services.stdout_lines }}" when: tripleo_container_cli is defined tags: - bar_create_recover_image
アンダークラウドノードで以下の
ansible-playbook
コマンドを入力し、コントロールプレーンノードのバックアップを作成します。重要スタックは操作しないでください。Pacemaker クラスターおよびコンテナーを停止すると、コンピュートノードへのコントロールプレーンサービスが一時的に中断します。また、ネットワーク接続、Ceph、および NFS または SFTP データプレーンサービスにも中断が発生します。この手順の最終ステップに従い、Pacemaker クラスターおよびコンテナーがサービスに戻るまで、インスタンスの作成、インスタンスの移行、要求の認証、クラスターの健全性の監視はできません。
(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-controller.yaml
3.6. cron を使用したコントロールプレーンノードバックアップのスケジューリング
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能に関する詳細は、対象範囲の詳細 を参照してください。
cron ジョブを設定し、Ansible backup-and-restore
ロールを使用して ReaR でコントロールプレーンノードのバックアップを作成することができます。/var/log/rear-cron
ディレクトリーでログを確認することができます。
前提条件
- バックアップノードに NFS または SFTP サーバーがインストールおよび設定されている。新しい NFS サーバーの作成方法は 「バックアップノードへの NFS サーバーのインストールと設定」 を参照してください。
- アンダークラウドおよびコントロールプレーンノードに ReaR がインストールされている。詳細は、「コントロールプレーンノードへの ReaR のインストール」 を参照してください。
- バックアップの保存用に、バックアップの場所に十分なディスク領域がある。
手順
アンダークラウドノードで、以下のコマンドを入力してバックアップ用のスクリプトを作成します。
[stack@undercloud ~]$ cat <<'EOF' > /home/stack/execute-rear-cron.sh #!/bin/bash OWNER="stack" TODAY=`date +%Y%m%d` FILE="/var/log/rear-cron.${TODAY}" sudo touch ${FILE} sudo chown ${OWNER}:${OWNER} ${FILE} CURRENTTIME=`date` echo "[$CURRENTTIME] rear start" >> ${FILE} source /home/stack/stackrc && /usr/bin/openstack overcloud backup 2>&1 >> ${FILE} CURRENTTIME=`date` echo "[$CURRENTTIME] rear end" >> ${FILE} EOF
/home/stack/execute-rear-cron.sh
スクリプトに実行可能な権限を設定します。[stack@undercloud ~]$ chmod 755 /home/stack/execute-rear-cron.sh
crontab -e
コマンドで crontab ファイルを編集し、任意のエディターで以下の cron ジョブを追加します。ファイルに加えた変更を保存するようにしてください。[stack@undercloud ~]# $ crontab -e #adding the following line 0 0 * * * /home/stack/execute-rear-cron.sh
/home/stack/execute-rear-cron.sh
スクリプトは、stack ユーザーにより午前 0 時に実行されるようにスケジュールされます。cron ジョブがスケジュールされていることを確認するには、以下のコマンドを入力します。
[stack@undercloud ~]$ crontab -l
コマンド出力には、スケジュールされている cron ジョブが表示されます。
0 0 * * * /home/stack/execute-rear-cron.sh
3.7. 関連情報
第4章 アンダークラウドおよびコントロールプレーンノードの復元
アンダークラウドまたはコントロールプレーンノードが破損している場合、もしくは更新またはアップグレード中にエラーが発生した場合は、コントロールプレーンノードをバックアップから以前の状態に復元できます。復元プロセスが Galera クラスターまたは共存する Ceph モニターを持つノードを自動的に復元できない場合は、これらのコンポーネントを手動で復元できます。
4.1. 復元プロセス用に同じ場所に配置された Ceph モニターを備えたコントロールプレーンを準備する
同じ場所に配置された Ceph モニターを使用してコントロールプレーンを復元する前に、Ceph モニターのバックアップファイルをノードファイルシステムにマウントするスクリプトと、ReaR がバックアップファイルを見つけるために使用する別のスクリプトを作成して、環境を準備します。
/var/lib/ceph
ディレクトリーのバックアップが作成できない場合は、Red Hat テクニカルサポートチームに連絡して ceph-mon
インデックスを再ビルドする必要があります。詳細は、Red Hat Technical Support Team を参照してください。
前提条件
- アンダークラウドノードのバックアップを作成している。詳細は、「アンダークラウドノードのバックアップの作成」 を参照してください。
- コントロールプレーンノードのバックアップを作成している。詳細は、「コントロールプレーンノードのバックアップの作成」 を参照してください。
- バックアップノードにアクセスできる。
-
NETWORKING_PREPARATION_COMMANDS
パラメーターで設定したネットワーク設定情報にアクセスできる (ネットワークインターフェイスの OVS ブリッジを使用する場合)。詳細は、「バックアップ用の Open vSwitch (OVS) インターフェイスの設定」 を参照してください。
手順
復元する各ノードで、スクリプト
/usr/share/rear/setup/default/011_backup_ceph.sh
を作成し、次のコンテンツを追加します。mount -t <file_type> <device_disk> /mnt/local cd /mnt/local [ -d "var/lib/ceph" ] && tar cvfz /tmp/ceph.tar.gz var/lib/ceph --xattrs --xattrs-include='.' --acls cd / umount <device_disk>
<file_type>
および<device_disk>
は、バックアップファイルの種類と場所に置き換えてください。通常、ファイルタイプはxfs
で、場所は/dev/vda2
です。同じノードで、スクリプト
/usr/share/rear/wrapup/default/501_restore_ceph.sh
を作成し、以下の出力を追加します。if [ -f "/tmp/ceph.tar.gz" ]; then rm -rf /mnt/local/var/lib/ceph/* tar xvC /mnt/local -f /tmp/ceph.tar.gz var/lib/ceph --xattrs --xattrs-include='.' fi
4.2. アンダークラウドノードの復元
ReaR を使用して作成したバックアップの ISO イメージを使用し、アンダークラウドノードを以前の状態に復元できます。バックアップの ISO イメージは、バックアップノードにあります。ブート可能な ISO イメージを DVD に書き込むか、Integrated Lights-Out (iLO) リモートアクセスを通じてアンダークラウドノードにダウンロードします。
前提条件
- アンダークラウドノードのバックアップを作成している。詳細は、「コントロールプレーンノードのバックアップの作成」を参照してください。
- バックアップノードにアクセスできる。
-
NETWORKING_PREPARATION_COMMANDS
パラメーターで設定したネットワーク設定情報にアクセスできる (ネットワークインターフェイスの OVS ブリッジを使用する場合)。詳細は、「バックアップ用の Open vSwitch (OVS) インターフェイスの設定」 を参照してください。
手順
- アンダークラウドノードの電源をオフにします。次のステップに進む前に、アンダークラウドノードの電源が完全にオフになっていることを確認します。
- バックアップの ISO イメージでアンダークラウドノードをブートします。
Relax-and-Recover
ブートメニューが表示されたら、Recover <undercloud_node>
を選択します。<undercloud_node>
をアンダークラウドノードの名前に置き換えます。注記システムで UEFI を使用している場合は、
Relax-and-Recover (no Secure Boot)
オプションを選択します。root
ユーザーとしてログインし、ノードを復元します。以下のメッセージが表示されます。
Welcome to Relax-and-Recover. Run "rear recover" to restore your system! RESCUE <undercloud_node>:~ # rear recover
アンダークラウドノードの復元プロセスが完了すると、コンソールに以下のメッセージが表示されます。
Finished recovering your system Exiting rear recover Running exit tasks
ノードの電源を切ります。
RESCUE <undercloud_node>:~ # poweroff
ノードをブートすると、以前の状態で再開されます。
4.3. コントロールプレーンノードの復元
更新またはアップグレード中にエラーが発生した場合は、ReaR を使用して作成したバックアップの ISO イメージを使用して、コントロールプレーンノードを以前の状態に復元できます。コントロールプレーンを復元する場合は、状態の整合性を確保するために、すべてのコントロールプレーンノードを復元する必要があります。
バックアップの ISO イメージは、バックアップノードにあります。ブート可能な ISO イメージを DVD に書き込むか、Integrated Lights-Out (iLO) リモートアクセスを通じてアンダークラウドノードにダウンロードします。
Red Hat は、Open vSwitch (OVS) およびデフォルトの Open Virtual Network (OVN) などのネイティブ SDN を使用する Red Hat OpenStack Platform のバックアップをサポートします。サードパーティーの SDN の詳細は、サードパーティーの SDN ドキュメントを参照してください。
前提条件
以下のいずれかのオプションを選択します。
- コンポーザブルロールを使用せずに、コントロールプレーンノードのバックアップを作成しました。詳細は、「コントロールプレーンノードのバックアップの作成」 を参照してください。
- コンポーザブルロールを使用するコントロールプレーンノードのバックアップを作成しました。詳細は、「コンポーザブルロールを使用するコントロールプレーンノードのバックアップの作成」 を参照してください。
- バックアップノードにアクセスできる。
-
NETWORKING_PREPARATION_COMMANDS
パラメーターで設定したネットワーク設定情報にアクセスできる (ネットワークインターフェイスの OVS ブリッジを使用する場合)。詳細は、「バックアップ用の Open vSwitch (OVS) インターフェイスの設定」 を参照してください。
手順
- 各コントロールプレーンノードの電源をオフにします。次のステップに進む前に、コントロールプレーンノードの電源が完全にオフになっていることを確認します。
- 対応するバックアップの ISO イメージで各コントロールプレーンノードをブートします。
Relax-and-Recover
ブートメニューが表示されたら、各コントロールプレーンノードでRecover <control_plane_node>
を選択します。<control_plane_node>
を対応するコントロールプレーンノードの名前に置き換えます。注記システムで UEFI を使用している場合は、
Relax-and-Recover (no Secure Boot)
オプションを選択します。それぞれのコントロールプレーンノードで
root
ユーザーとしてログインし、ノードを復元します。以下のメッセージが表示されます。
Welcome to Relax-and-Recover. Run "rear recover" to restore your system! RESCUE <control_plane_node>:~ # rear recover
コントロールプレーンノードの復元プロセスが完了すると、コンソールに以下のメッセージが表示されます。
Finished recovering your system Exiting rear recover Running exit tasks
コマンドラインコンソールが利用可能な場合は、各コントロールプレーンノードの
config-drive
パーティションを復元します。# once completed, restore the config-drive partition (which is ISO9660) RESCUE <control_plane_node>:~ $ dd if=/mnt/local/mnt/config-drive of=<config_drive_partition>
注記コンポーザブルロールを持つコントロールプレーンをデプロイした場合は、コントローラーノードでのみこの手順を実行してください。
ノードの電源を切ります。
RESCUE <control_plane_node>:~ # poweroff
- ブートシーケンスを通常のブートデバイスに設定します。ノードをブートすると、以前の状態で再開されます。
サービスが正常に実行されていることを確認するには、pacemaker のステータスを確認します。
root
ユーザーとしてコントローラーノードにログインし、以下のコマンドを入力します。# pcs status
- オーバークラウドのステータスを確認するには、OpenStack Integration Test Suite (tempest) を使用します。詳細は、Validating your OpenStack cloud with the Integration Test Suite (tempest) を参照してください。
トラブルシューティング
-
pcs status
で表示されるリソースアラームを以下のコマンドで解除します。
# pcs resource clean
-
pcs status
で表示される STONITH フェンシングの動作エラーを以下のコマンドで解除します。
# pcs resource clean # pcs stonith history cleanup
4.4. Galera クラスターの手動による復元
復元手順の一環として Galera クラスターが復元されない場合は、Galera を手動で復元する必要があります。
以下の手順では、1 つのコントローラーノードでいくつかのステップを実施する必要があります。手順の実施と同じコントローラーノードで、これらのステップを実施してください。
手順
Controller-0
で、Galera クラスターの仮想 IP を取得します。$ sudo hiera -c /etc/puppet/hiera.yaml mysql_vip
すべてのコントローラーノードで、仮想 IP を通じたデータベース接続を無効にします。
$ sudo iptables -I INPUT -p tcp --destination-port 3306 -d $MYSQL_VIP -j DROP
Controller-0
で MySQL の root パスワードを取得します。$ sudo hiera -c /etc/puppet/hiera.yaml mysql::server::root_password
Controller-0
で、Galera リソースをunmanaged
モードに設定します。$ sudo pcs resource unmanage galera-bundle
すべてのコントローラーノードで、MySQL コンテナーを停止します。
$ sudo podman container stop $(sudo podman container ls --all --format "{{.Names}}" --filter=name=galera-bundle)
すべてのコントローラーノードで、現在のディレクトリーを移動します。
$ sudo mv /var/lib/mysql /var/lib/mysql-save
すべてのコントローラーノードで、新規ディレクトリー
/var/lib/mysq
を作成します。$ sudo mkdir /var/lib/mysql $ sudo chown 42434:42434 /var/lib/mysql $ sudo chcon -t container_file_t /var/lib/mysql $ sudo chmod 0755 /var/lib/mysql $ sudo chcon -r object_r /var/lib/mysql $ sudo chcon -u system_u /var/lib/mysql
すべてのコントローラーノードで、MySQL コンテナーを起動します。
$ sudo podman container start $(sudo podman container ls --all --format "{{ .Names }}" --filter=name=galera-bundle)
すべてのコントローラーノードで、MySQL データベースを作成します。
$ sudo podman exec -i $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) bash -c "mysql_install_db --datadir=/var/lib/mysql --user=mysql --log_error=/var/log/mysql/mysql_init.log"
すべてのコントローラーノードで、データベースを起動します。
$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) bash -c "mysqld_safe --skip-networking --wsrep-on=OFF --log-error=/var/log/mysql/mysql_safe.log" &
すべてのコントローラーノードで、
.my.cnf
Galera 設定ファイルを移動します。$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) bash -c "mv /root/.my.cnf /root/.my.cnf.bck"
すべてのコントローラーノードで、Galera root パスワードをリセットします。
$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) bash -c "mysql -uroot -e'use mysql;update user set password=PASSWORD(\"$ROOTPASSWORD\")where User=\"root\";flush privileges;'"
すべてのコントローラーノード上の Galera コンテナー内で、
.my.cnf
Galera 設定ファイルを復元します。$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) bash -c "mv /root/.my.cnf.bck /root/.my.cnf"
Controller-0
で、バックアップデータベースファイルを/var/lib/MySQL
にコピーします。$ sudo cp $BACKUP_FILE /var/lib/mysql $ sudo cp $BACKUP_GRANT_FILE /var/lib/mysql
注記これらのファイルへのパスは /home/heat-admin/ です。
Controller-0
で、MySQL データベースを復元します。$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) bash -c "mysql -u root -p$ROOT_PASSWORD < \"/var/lib/mysql/$BACKUP_FILE\" " $ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) bash -c "mysql -u root -p$ROOT_PASSWORD < \"/var/lib/mysql/$BACKUP_GRANT_FILE\" "
すべてのコントローラーノードで、データベースをシャットダウンします。
$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) bash -c "mysqladmin shutdown"
Controller-0
で、ブートストラップノードを起動します。$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" --filter=name=galera-bundle) \ /usr/bin/mysqld_safe --pid-file=/var/run/mysql/mysqld.pid --socket=/var/lib/mysql/mysql.sock --datadir=/var/lib/mysql \ --log-error=/var/log/mysql/mysql_cluster.log --user=mysql --open-files-limit=16384 \ --wsrep-cluster-address=gcomm:// &
検証: Controller-0 で、クラスターのステータスを確認します。
$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) bash -c "clustercheck"
Galera cluster node is synced のメッセージが表示されるのを確認してください。表示されない場合は、ノードを再作成する必要があります。
Controller-0
で、設定からクラスターアドレスを取得します。$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) bash -c "grep wsrep_cluster_address /etc/my.cnf.d/galera.cnf" | awk '{print $3}'
残りの各コントローラーノードでデータベースを起動し、クラスターを検証します。
データベースを起動します。
$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) /usr/bin/mysqld_safe --pid-file=/var/run/mysql/mysqld.pid --socket=/var/lib/mysql/mysql.sock \ --datadir=/var/lib/mysql --log-error=/var/log/mysql/mysql_cluster.log --user=mysql --open-files-limit=16384 \ --wsrep-cluster-address=$CLUSTER_ADDRESS &
MYSQL クラスターのステータスを確認します。
$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \ --filter=name=galera-bundle) bash -c "clustercheck"
Galera cluster node is synced のメッセージが表示されるのを確認してください。表示されない場合は、ノードを再作成する必要があります。
すべてのコントローラーノードで MySQL コンテナーを停止します。
$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" --filter=name=galera-bundle) \ /usr/bin/mysqladmin -u root shutdown
すべてのコントローラーノードで以下のファイアウォールルールを削除して、仮想 IP アドレス経由のデータベース接続を許可します。
$ sudo iptables -D INPUT -p tcp --destination-port 3306 -d $MYSQL_VIP -j DROP
すべてのコントローラーノードで MySQL コンテナーを再起動します。
$ sudo podman container restart $(sudo podman container ls --all --format "{{ .Names }}" --filter=name=galera-bundle)
すべてのコントローラーノードで
clustercheck
コンテナーを再起動します。$ sudo podman container restart $(sudo podman container ls --all --format "{{ .Names }}" --filter=name=clustercheck)
Controller-0
で、Galera リソースをmanaged
モードに設定します。$ sudo pcs resource manage galera-bundle
検証
サービスが正常に実行されていることを確認するには、pacemaker のステータスを確認します。
$ sudo pcs status
- オーバークラウドのステータスを確認するには、OpenStack Integration Test Suite (tempest) を使用します。詳細は、Validating your OpenStack cloud with the Integration Test Suite (tempest) を参照してください。
特定のノードで問題が疑われる場合は、
clustercheck
でクラスターの状態を確認します。$ sudo podman exec clustercheck /usr/bin/clustercheck
4.5. アンダークラウドのノードデータベースを手動で復元する
アンダークラウドのデータベースがアンダークラウドの復元プロセスの一部として復元されない場合は、データベースを手動で復元できます。データベースを復元できるのは、以前にスタンドアロンのデータベースバックアップを作成した場合のみです。
前提条件
- アンダークラウドデータベースのバックアップを作成している。アンダークラウドデータベースのバックアップに関する詳細は、「アンダークラウドノードのバックアップの作成」 を参照してください。
手順
-
director アンダークラウドノードに
root
ユーザーとしてログインします。 すべての tripleo サービスを停止します。
[root@director ~]# systemctl stop tripleo_*
次のコマンドを入力して、サーバーでコンテナーが実行していないことを確認します。
[root@director ~]# podman ps
実行中のコンテナーがある場合は、次のコマンドを入力してコンテナーを停止します。
[root@director ~]# podman stop <container_name>
現在の
/var/lib/mysql
ディレクトリーのバックアップを作成してから、そのディレクトリーを削除します。[root@director ~]# cp -a /var/lib/mysql /var/lib/mysql_bck [root@director ~]# rm -rf /var/lib/mysql
データベースディレクトリーを再作成し、新しいディレクトリーに SELinux の属性を設定します。
[root@director ~]# mkdir /var/lib/mysql [root@director ~]# chown 42434:42434 /var/lib/mysql [root@director ~]# chmod 0755 /var/lib/mysql [root@director ~]# chcon -t container_file_t /var/lib/mysql [root@director ~]# chcon -r object_r /var/lib/mysql [root@director ~]# chcon -u system_u /var/lib/mysql
mariadb
イメージのローカルタグを作成します。<image_id>
および<undercloud.ctlplane.example.com>
を、使用している環境の値に置き換えます。[root@director ~]# podman images | grep mariadb <undercloud.ctlplane.example.com>:8787/rh-osbs/rhosp16-openstack-mariadb 16.2_20210322.1 <image_id> 3 weeks ago 718 MB
[root@director ~]# podman tag <image_id> mariadb
[root@director ~]# podman images | grep maria localhost/mariadb latest <image_id> 3 weeks ago 718 MB <undercloud.ctlplane.example.com>:8787/rh-osbs/rhosp16-openstack-mariadb 16.2_20210322.1 <image_id> 3 weeks ago 718 MB
/var/lib/mysql
ディレクトリーをコンテナーで初期化します。[root@director ~]# podman run --net=host -v /var/lib/mysql:/var/lib/mysql localhost/mariadb mysql_install_db --datadir=/var/lib/mysql --user=mysql
データベースにインポートするデータベースのバックアップファイルをコピーします。
[root@director ~]# cp /root/undercloud-all-databases.sql /var/lib/mysql
データベースサービスを開始して、データをインポートします。
[root@director ~]# podman run --net=host -dt -v /var/lib/mysql:/var/lib/mysql localhost/mariadb /usr/libexec/mysqld
データを読み込み、
max_allowed_packet
パラメーターを設定します。コンテナーにログインし、設定を行います。
[root@director ~]# podman exec -it <container_id> /bin/bash ()[mysql@5a4e429c6f40 /]$ mysql -u root -e "set global max_allowed_packet = 1073741824;" ()[mysql@5a4e429c6f40 /]$ mysql -u root < /var/lib/mysql/undercloud-all-databases.sql ()[mysql@5a4e429c6f40 /]$ mysql -u root -e 'flush privileges' ()[mysql@5a4e429c6f40 /]$ exit exit
コンテナーを停止します。
[root@director ~]# podman stop <container_id>
コンテナーが動いていないことを確認します。
[root@director ~]# podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES [root@director ~]#
すべての tripleo サービスを再起動します。
[root@director ~]# systemctl start multi-user.target