手順

1. アンダークラウドに root ユーザーとしてログインします。

2. データベースをバックアップします。

   # mysqldump --opt --all-databases > /root/undercloud-all-databases.sql

3. データベースのバックアップと設定ファイルをアーカイブします。

   # sudo tar --xattrs --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/docker \
       /var/lib/registry \
       /srv/node \
       /root \
       /home/stack

   これで、undercloud-backup-<date>.tar.gz という名前のファイルが作成されます。<date> はシステムの日付です。この tar ファイルをセキュアな場所にコピーします。

手順

1. データベースのバックアップを実行します。

   1. コントロールノードにログインします。オーバークラウドには、アンダークラウドからアクセスできます。

      $ ssh heat-admin@192.0.2.100

   2. root ユーザーに変更します。

      $ sudo -i

   3. バックアップを保管するための一時ディレクトリーを作成します。

      # mkdir -p /var/tmp/mysql_backup/

   4. データベースのパスワードを取得して、MYSQLDBPASS の環境変数に保存します。このパスワードは、/etc/puppet/hieradata/service_configs.json ファイルの mysql::server::root_password 変数に保管されています。以下のコマンドを使用してパスワードを保管します。

      # MYSQLDBPASS=$(sudo hiera mysql::server::root_password)

   5. データベースをバックアップします。

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "select distinct table_schema from information_schema.tables where engine='innodb' and table_schema != 'mysql';" | xargs mysqldump -uroot -p$MYSQLDBPASS --single-transaction --databases > /var/tmp/mysql_backup/openstack_databases-`date +%F`-`date +%T`.sql

      このコマンドにより、/var/tmp/mysql_backup/openstack_databases-<date>.sql という名前のデータベースバックアップがダンプされます。<date> はシステムの日付と時刻です。このデータベースダンプを安全な場所にコピーします。

   6. ユーザーおよびパーミッションに関する全情報をバックアップします。

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "SELECT CONCAT('\"SHOW GRANTS FOR ''',user,'''@''',host,''';\"') FROM mysql.user where (length(user) > 0 and user NOT LIKE 'root')" | xargs -n1 mysql -uroot -p$MYSQLDBPASS -s -N -e | sed 's/$/;/' > /var/tmp/mysql_backup/openstack_databases_grants-`date +%F`-`date +%T`.sql

      このコマンドにより、/var/tmp/mysql_backup/openstack_databases_grants-<date>.sql という名前のデータベースバックアップがダンプされます。<date> はシステムの日付と時刻です。このデータベースダンプを安全な場所にコピーします。

2. OpenStack Telemetry データベースをバックアップします。

   1. 任意のコントローラーに接続して、MongoDB のプライマリーインスタンスの IP を取得します。

      # MONGOIP=$(sudo hiera mongodb::server::bind_ip)

   2. バックアップを作成します。

      # mkdir -p /var/tmp/mongo_backup/
      # mongodump --oplog --host $MONGOIP --out /var/tmp/mongo_backup/

   3. /var/tmp/mongo_backup/ 内のデータベースダンプを安全な場所にコピーします。

3. Redis クラスターをバックアップします。

   1. HAProxy から Redis のエンドポイントを取得します。

      # REDISIP=$(sudo hiera redis_vip)

   2. Redis クラスターのマスターパスワードを取得します。

      # REDISPASS=$(sudo hiera redis::masterauth)

   3. Redis クラスターの接続をチェックします。

      # redis-cli -a $REDISPASS -h $REDISIP ping

   4. Redis データベースをダンプします。

      # redis-cli -a $REDISPASS -h $REDISIP bgsave

      このコマンドにより、データベースのバックアップがデフォルトの /var/lib/redis/ ディレクトリーに保管されます。このデータベースダンプを安全な場所にコピーします。

4. 各コントローラーノードのファイルシステムをバックアップします。

   1. バックアップ用のディレクトリーを作成します。

      # mkdir -p /var/tmp/filesystem_backup/

   2. 以下の tar コマンドを実行します。

      # tar --ignore-failed-read --xattrs \
          -zcvf /var/tmp/filesystem_backup/`hostname`-filesystem-`date '+%Y-%m-%d-%H-%M-%S'`.tar \
          /etc \
          /srv/node \
          /var/log \
          /var/lib/nova \
          --exclude /var/lib/nova/instances \
          /var/lib/glance \
          /var/lib/keystone \
          /var/lib/cinder \
          /var/lib/heat \
          /var/lib/heat-config \
          /var/lib/heat-cfntools \
          /var/lib/rabbitmq \
          /var/lib/neutron \
          /var/lib/haproxy \
          /var/lib/openvswitch \
          /var/lib/redis \
          /usr/libexec/os-apply-config \
          /home/heat-admin

      --ignore-failed-read オプションを使用すると、見つからないディレクトリーは無視されます。これは、特定のサービスが使用されていない場合や、独自のカスタムロール上に分離されている場合に役立ちます。

5. 作成された tar ファイルを安全な場所にコピーします。

手順

1. この post-install.yaml のサンプルファイルの内容を既存の post-install.yaml ファイルのいずれかに追加します。

2. カスタムの環境ファイル (例: network-environment.yaml) で、vhost ユーザーソケットディレクトリーを変更します。

   parameter_defaults:
     NeutronVhostuserSocketDir: "/var/lib/vhost_sockets"

3. openstack overcloud deploy コマンドに ovs-dpdk-permissions.yaml ファイルを追加して、qemu グループの設定値を OVS-DPDK 向けに hugetlbfs に設定します。

    -e environments/ovs-dpdk-permissions.yaml

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. 主要な OpenStack Platform サービスを停止します。

   $ sudo systemctl stop 'openstack-*' 'neutron-*' httpd

   注記

   これにより、アンダークラウドで短時間のダウンタイムが生じます。アンダークラウドのアップグレード中もオーバークラウドは引き続き機能します。

3. python-tripleoclient パッケージと依存関係を更新し、マイナーバージョンの更新向けの最新のスクリプトを使用できるようにします。

   $ sudo yum update -y python-tripleoclient

4. openstack undercloud upgrade コマンドを実行します。

   $ openstack undercloud upgrade

5. コマンドの実行が完了するまで待ちます。

6. アンダークラウドを再起動して、オペレーティングシステムのカーネルとその他のシステムパッケージを更新します。

   $ sudo reboot

7. ノードが起動するまで待ちます。
8. アンダークラウドに stack ユーザーとしてログインします。

手順

1. yum ログをチェックして、新規イメージのアーカイブが利用可能かどうかを確認します。

   $ sudo grep "rhosp-director-images" /var/log/yum.log

2. 新規アーカイブが利用可能な場合には、現在のイメージを新規イメージに置き換えてください。新しいイメージをインストールするには、最初に stack ユーザーの images ディレクトリー (/home/stack/images) から既存のイメージを削除します。

   $ rm -rf ~/images/*

3. アーカイブを展開します。

   $ cd ~/images
   $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-10.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-10.0.tar; do tar -xvf $i; done

4. 最新のイメージを director にインポートして、ノードがこれらの新規イメージを使用するように設定します。

   $ cd ~
   $ openstack overcloud image upload --update-existing --image-path /home/stack/images/
   $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f csv --quote none | sed "1d" | paste -s -d " ")

5. 新規イメージがあるかどうかをチェックして、イメージ更新の最終処理を行います。

   $ openstack image list
   $ ls -l /httpboot

   director は古いイメージを保持して、それらが更新された時のタイムスタンプを使用して名前を変更します。必要がなくなったイメージは削除してください。

手順

1. 元の openstack overcloud deploy コマンドに --update-plan-only オプションを追加して、現在のプランを更新します。以下に例を示します。

   $ openstack overcloud deploy --update-plan-only \
     --templates  \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
     -e /home/stack/templates/network-environment.yaml \
     -e /home/stack/templates/storage-environment.yaml \
     -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml \
     [-e <environment_file>|...]

   --update-plan-only のオプションを指定すると、director に保管されているオーバークラウドのプランのみが更新されます。-e オプションを使用して、オーバークラウドと関連のある環境ファイルとその更新パスを追加します。後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。以下の一覧は、環境ファイルの順序の例です

   • Heat テンプレートコレクションの初期化ファイル (environments/network-isolation.yaml) を含むネットワーク分離ファイルと、次にカスタムの NIC 設定ファイル
   • 外部のロードバランシングの環境ファイル
   • ストレージの環境ファイル
   • Red Hat CDN または Satellite 登録用の環境ファイル
   • その他のカスタム環境ファイル

2. openstack overcloud update コマンドを使用して、全ノードでパッケージの更新を実行します。以下に例を示します。

   $ openstack overcloud update stack -i overcloud

   -i のオプションを指定すると、各ノードは対話モードで更新されます。更新プロセスによりノードの更新が完了すると、スクリプトにより、確認のためのブレークポイントが提供されます。 -i オプションを使用しなかった場合には、最初のブレークポイントで更新が一時停止されたままとなるため、-i オプションの指定は必須です。

   注記

   全ノードで並行して更新を実行すると問題が発生する可能性があります。たとえば、パッケージの更新には、サービスの再起動が必要となる場合があり、その操作によって他のノードが中断される可能性があります。そのため、このプロセスでは、一連のブレークポイントを設けて、ノードごとに更新します。1 つのノードでパッケージの更新が完了すると、更新プロセスは次のノードに移ります。

3. 更新のプロセスが開始します。このプロセス中に、director は IN_PROGRESS のステータスを報告して、ブレークポイントを通過するように定期的に要求します。以下に例を示します。

   not_started: [u'overcloud-controller-0', u'overcloud-controller-1', u'overcloud-controller-2']
   on_breakpoint: [u'overcloud-compute-0']
   Breakpoint reached, continue? Regexp or Enter=proceed, no=cancel update, C-c=quit interactive mode:

   Enter を押すと、on_breakpoint 一覧の最後のノードからブレークポイントを通過します。これで、そのノードの更新が開始します。また、ノード名を入力して特定のノードでブレークポイントを通過したり、複数のノードで一度にブレークポイントを通過するための Python ベースの正規表現を入力することも可能です。ただし、複数のコントローラーノードで同時にブレークポイントを通過することはお勧めしません。全ノードが更新を完了するまで、このプロセスを継続します。

4. 更新が完了すると、コマンドにより COMPLETE のステータスが報告されます。

   ...
   IN_PROGRESS
   IN_PROGRESS
   IN_PROGRESS
   COMPLETE
   update finished with status COMPLETE

5. コントローラーノードにフェンシングを設定している場合には、更新プロセスによってその設定が無効になる場合があります。更新プロセスの完了時には、コントローラーノードの 1 つで以下のコマンドを実行してフェンシングを再度有効にします。

   $ sudo pcs property set stonith-enabled=true

手順

1. ノードを選択してログインします。

2. ノードを再起動します。

   [heat-admin@overcloud-controller-0 ~]$ sudo reboot

3. ノードが起動するまで待ちます。

4. ノードにログインしてサービスをチェックします。以下に例を示します。

   1. ノードが Pacemaker サービスを使用している場合には、ノードがクラスターに再度参加したかどうかを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo pcs status

   2. ノードが Systemd サービスを使用している場合には、全サービスが有効化されているかどうかを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status

手順

1. Ceph MON またはコントローラーノードにログインして、Ceph Storage クラスターのリバランスを一時的に無効にします。

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

2. 再起動する最初の Ceph Storage ノードを選択して、ログインします。

3. ノードを再起動します。

   $ sudo reboot

4. ノードが起動するまで待ちます。

5. ノードにログインして、クラスターのステータスを確認します。

   $ sudo ceph -s

   pgmap により、すべての pgs が正常な状態 (active+clean) として報告されることを確認します。

6. ノードからログアウトして、次のノードを再起動し、ステータスを確認します。全 Ceph Storage ノードが再起動されるまで、このプロセスを繰り返します。

7. 完了したら、Ceph MON またはコントローラーノードにログインして、クラスターのリバランスを再度有効にします。

   $ sudo ceph osd unset noout
   $ sudo ceph osd unset norebalance

8. 最終のステータスチェックを実行して、クラスターが HEALTH_OK を報告していることを確認します。

   $ sudo ceph status

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. 全コンピュートノードとその UUID を一覧表示します。

   $ source ~/stackrc
   (undercloud) $ openstack server list --name compute

   再起動するコンピュートノードのUUID を特定します。

3. アンダークラウドから、コンピュートノードを選択し、そのノードを無効にします。

   $ source ~/overcloudrc
   (overcloud) $ openstack compute service list
   (overcloud) $ openstack compute service set [hostname] nova-compute --disable

4. コンピュートノード上の全インスタンスを一覧表示します。

   (overcloud) $ openstack server list --host [hostname] --all-projects

5. 以下のコマンドの 1 つを使用して、インスタンスを移行します。

   1. 選択した特定のホストにインスタンスを移行します。

      (overcloud) $ openstack server migrate [instance-id] --live [target-host]--wait

   2. nova-scheduler により対象のホストが自動的に選択されるようにします。

      (overcloud) $ nova live-migration [instance-id]

   3. 一度にすべてのインスタンスのライブマイグレーションを行います。

      $ nova host-evacuate-live [hostname]

      注記

      nova コマンドで非推奨の警告が表示される可能性がありますが、安全に無視することができます。

6. 移行が完了するまで待ちます。

7. 正常に移行したことを確認します。

   (overcloud) $ openstack server list --host [hostname] --all-projects

8. 選択したコンピュートノードのインスタンスがなくなるまで、移行を続けます。

9. コンピュートノードのログインしてリブートします。

   [heat-admin@overcloud-compute-0 ~]$ sudo reboot

10. ノードが起動するまで待ちます。

11. コンピュートノードを再度有効化します。

    $ source ~/overcloudrc
    (overcloud) $ openstack compute service set [hostname] nova-compute --enable

12. コンピュートノードが有効化されているかどうかを確認します。

    (overcloud) $ openstack compute service list

手順

1. ノードにログインします。

2. yum を実行して、システムパッケージを確認します。

   $ sudo yum list qemu-img-rhev qemu-kvm-common-rhev qemu-kvm-rhev qemu-kvm-tools-rhev openvswitch

3. ovs-vsctl を実行して、現在実行中のバージョンを確認します。

   $ sudo ovs-vsctl --version

手順

1. アンダークラウドのアクセス情報を読み込みます。

   $ source ~/stackrc

2. エラーが発生している Systemd サービスがあるかどうかを確認します。

   $ sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker'

3. アンダークラウドの空き領域を確認します。

   $ df -h

4. アンダークラウド上に NTP をインストールしている場合にはクロックが同期されていることを確認します。

   $ sudo ntpstat

5. アンダークラウドのネットワークサービスを確認します。

   $ openstack network agent list

   全エージェントが Alive で、それらの状態が UP である必要があります。

6. アンダークラウドの Compute サービスを確認します。

   $ openstack compute service list

   全エージェントのステータスが enabled で、状態が up である必要があります。

手順

1. アンダークラウドのアクセス情報を読み込みます。

   $ source ~/stackrc

2. ベアメタルノードのステータスを確認します。

   $ openstack baremetal node list

   全ノードの電源状態が有効で (on)、かつメンテナンスモードが false である必要があります。

3. エラーが発生している Systemd サービスがあるかどうかを確認します。

   $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker' 'ceph*'" ; done

4. 全サービスへの HAProxy 接続をチェックします。コントロールプレーンの仮想 IP アドレスと haproxy.stats サービスの認証情報を取得します。

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE sudo 'grep "listen haproxy.stats" -A 6 /etc/haproxy/haproxy.cfg'

   以下の cURL 要求でそれらの情報を使用します。

   $ curl -s -u admin:<PASSWORD> "http://<IP ADDRESS>:1993/;csv" | egrep -vi "(frontend|backend)" | awk -F',' '{ print $1" "$2" "$18 }'

   <PASSWORD> と <IP ADDRESS> は、haproxy.stats サービスからのそれぞれの情報に置き換えます。その結果表示される一覧には、各ノード上の OpenStack Platform サービスとそれらの接続ステータスが表示されます。

5. オーバークラウドデータベースのレプリケーションの正常性をチェックします。

   $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo clustercheck" ; done

6. RabbitMQ クラスターの正常性を確認します。

   $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo rabbitmqctl node_health_check" ; done

7. Pacemaker リソースの正常性を確認します。

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo pcs status"

   以下の点を確認します。

   • 全クラスターノードが online であること
   • いずれのクラスターノード上でも stopped のリソースがないこと
   • pacemaker で failed のアクションがないこと

8. 各オーバークラウドノードでディスク領域を確認します。

   $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo df -h --output=source,fstype,avail -x overlay -x tmpfs -x devtmpfs" ; done

9. オーバークラウドの Ceph Storage クラスターの正常性を確認します。以下のコマンドを使用すると、コントローラーノード上で ceph ツールが実行されて、クラスターをチェックします。

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

10. Ceph Storage OSD に空き領域があるかどうかを確認します。以下のコマンドを使用すると、コントローラーノード上で ceph ツールが実行され、空き領域をチェックします。

    $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph df"

11. オーバークラウドノードでクロックが同期されていることを確認します。

    $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo ntpstat" ; done

12. オーバークラウドのアクセス情報を読み込みます。

    $ source ~/overcloudrc

13. オーバークラウドのネットワークサービスを確認します。

    $ openstack network agent list

    全エージェントが Alive で、それらの状態が UP である必要があります。

14. オーバークラウドの Compute サービスを確認します。

    $ openstack compute service list

    全エージェントのステータスが enabled で、状態が up である必要があります。

15. オーバークラウドのボリュームサービスを確認します。

    $ openstack volume service list

    全エージェントのステータスが enabled で、状態が up である必要があります。

1. スナップショットを作成するインスタンスのサーバー ID を確認します。

   # openstack server list

2. スナップショットを作成する前に、元のインスタンスをシャットダウンして、全データがディスクにフラッシュされるようにしてください。

   # openstack server stop SERVER_ID

3. インスタンスのスナップショットイメージを作成します。

   # openstack image create --id SERVER_ID SNAPSHOT_NAME

4. このスナップショットイメージで新規インスタンスを起動します。

   # openstack server create --flavor DPDK_FLAVOR --nic net-id=DPDK_NET_ID--image SNAPSHOT_NAME INSTANCE_NAME

5. オプションとして、新規インスタンスのステータスが ACTIVE であることを確認します。

   # openstack server list