手順

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

手順

1. director に stack ユーザーとしてログインします。

2. 現在設定されている OpenStack Platform リポジトリーを無効にします。

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-10-rpms

3. 新しい OpenStack Platform リポジトリーを有効にします。

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-11-rpms

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

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

   注記

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

5. デフォルトのプロビジョニング/コントロールプレーンネットワークが 192.0.2.0/24 から 192.168.24.0/24 に変わりました。以前の undercloud.conf ファイルで、デフォルトのネットワーク値を使用していた場合には、プロビジョニング/コントロールプレーンネットワークは 192.0.2.0/24 に設定されます。これは、undercloud.conf ファイルの特定のパラメーターを設定して、192.0.2.0/24 ネットワークを引き続き使用する必要のあることを意味します。それらのパラメーターは以下のとおりです。

   • local_ip
   • network_gateway
   • undercloud_public_vip
   • undercloud_admin_vip
   • network_cidr
   • masquerade_network
   • dhcp_start
   • dhcp_end

   ネットワークの値を undercloud.conf に設定して、今後アップグレードを実行する間に 192.0.2.0/24 CIDR を引き続き使用するようにします。openstack undercloud upgrade コマンドを実行する前に、ネットワークの構成が正しく設定されていることを確認してください。

6. yum コマンドを実行して、director の主要なパッケージをアップグレードします。

   $ sudo yum update -y instack-undercloud openstack-puppet-modules openstack-tripleo-common python-tripleoclient

7. 以下のコマンドを実行してアンダークラウドをアップグレードします。

   $ openstack undercloud upgrade

8. アンダークラウドのアップグレードプロセスが完了するまで待ちます。

手順

1. director に stack ユーザーとしてログインします。

2. 現在設定されている OpenStack Platform リポジトリーを無効にします。

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-11-rpms

3. 新しい OpenStack Platform リポジトリーを有効にします。

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-12-rpms

4. オーバークラウドが Ceph Storage とともに構成されている場合には、ceph-ansible パッケージをインストールします。

   $ sudo yum install -y ceph-ansible

5. yum コマンドを実行して、director の主要なパッケージをアップグレードします。

   $ sudo yum update -y python-tripleoclient

6. /home/stack/undercloud.conf ファイルを編集して、enabled_drivers パラメーターに pxe_ssh ドライバーが含まれていないことを確認します。Virtual Baseboard Management Controller (VBMC) が推奨されるようになったため、このドライバーは非推奨となり、Red Hat OpenStack Platform から削除されました。この新しいドライバーと移行の手順については、『director のインストールと使用方法』ガイドの「Virtual Baseboard Management Controller (VBMC)」の項を参照してください。

7. 以下のコマンドを実行してアンダークラウドをアップグレードします。

   $ openstack undercloud upgrade

8. アンダークラウドのアップグレードプロセスが完了するまで待ちます。

手順

1. director に stack ユーザーとしてログインします。

2. 現在設定されている OpenStack Platform リポジトリーを無効にします。

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-12-rpms

3. 新しい OpenStack Platform リポジトリーを有効にします。

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-13-rpms

4. yum コマンドを実行して、director の主要なパッケージをアップグレードします。

   $ sudo yum update -y python-tripleoclient

5. 以下のコマンドを実行してアンダークラウドをアップグレードします。

   $ openstack undercloud upgrade

6. アンダークラウドのアップグレードプロセスが完了するまで待ちます。

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

   $ sudo reboot

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

手順

1. イメージを直接 registry.access.redhat.com からオーバークラウドデプロイメントにプルするには、イメージパラメーターを指定するための環境ファイルが必要となります。以下のコマンドにより、この環境ファイルが自動的に作成されます。

   (undercloud) $ openstack overcloud container image prepare \
     --namespace=registry.access.redhat.com/rhosp13 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml

   • 任意のサービス用の環境ファイルを指定するには、-e オプションを使用します。
   • Ceph Storage を使用している場合には、Ceph Storage 用のコンテナーイメージの場所を定義する追加のパラメーターを指定します: --set ceph_namespace、--set ceph_image、--set ceph_tag
2. これで、イメージの場所が記載された overcloud_images.yaml 環境ファイルがアンダークラウド上に作成されます。このファイルをデプロイメントで指定します。

手順

1. ローカルアンダークラウドレジストリーのアドレスを特定します。アドレスは、以下のパターンを使用します。

   <REGISTRY IP ADDRESS>:8787

   アンダークラウドの IP アドレスを使用します。これは undercloud.conf ファイルの local_ip パラメーターで設定済みのアドレスです。以下のコマンドでは、アドレスが192.168.24.1:8787 であることを前提としています。

2. イメージをローカルレジストリーにアップロードするためのテンプレートと、それらのイメージを参照する環境ファイルを作成します。

   (undercloud) $ openstack overcloud container image prepare \
     --namespace=registry.access.redhat.com/rhosp13 \
     --push-destination=192.168.24.1:8787 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml \
     --output-images-file /home/stack/local_registry_images.yaml

   • 任意のサービス用の環境ファイルを指定するには、-e オプションを使用します。
   • Ceph Storage を使用している場合には、Ceph Storage 用のコンテナーイメージの場所を定義する追加のパラメーターを指定します: --set ceph_namespace、--set ceph_image、--set ceph_tag

3. これで 2 つのファイルが作成されます。

   • リモートソースからのコンテナーイメージの情報が含まれている local_registry_images.yaml。このファイルを使用して、Red Hat Container Registry (registry.access.redhat.com) からアンダークラウドにイメージをプルします。

   • アンダークラウド上の最終的なイメージの場所が記載されている overcloud_images.yaml。このファイルはデプロイメントで指定します。

     両方のファイルが存在することを確認します。

4. registry.access.redhat.com からアンダークラウドにコンテナーイメージをプルします。

   (undercloud) $ sudo openstack overcloud container image upload \
     --config-file  /home/stack/local_registry_images.yaml \
     --verbose

   ネットワークおよびアンダークラウドディスクの速度によっては、必要なイメージをプルするのに時間がかかる場合があります。

   注記

   コンテナーイメージは、およそ 10 GB のディスク領域を使用します。

手順

1. イメージをローカルレジストリーにプルするためのテンプレートを作成します。

   $ source ~/stackrc
   (undercloud) $ openstack overcloud container image prepare \
     --namespace=rhosp13 \
     --prefix=openstack- \
     --output-images-file /home/stack/satellite_images \

   • 任意のサービス用の環境ファイルを指定するには、-e オプションを使用します。
   • Ceph Storage を使用している場合には、Ceph Storage 用のコンテナーイメージの場所を定義する追加のパラメーターを指定します: --set ceph_namespace、--set ceph_image、--set ceph_tag
   注記

   このステップの openstack overcloud container image prepare コマンドは、registry.access.redhat.com 上のレジストリーをターゲットにして、イメージのリストを生成します。ここでは、後半のステップで使用する openstack overcloud container image prepare コマンドとは異なる値を指定します。

2. これで、コンテナーイメージの情報が含まれた satellite_images という名前のファイルが作成されます。このファイルを使用して、コンテナーイメージを Satellite 6 サーバーに同期します。

3. satellite_images ファイルから YAML 固有の情報を削除して、イメージ一覧のみが記載されたフラットファイルに変換します。この操作は、以下の sed コマンドで実行します。

   (undercloud) $ awk -F ':' '{if (NR!=1) {gsub("[[:space:]]", ""); print $2}}' ~/satellite_images > ~/satellite_images_names

   これにより、Satellite サーバーにプルするイメージのリストが提供されます。

4. satellite_images_names ファイルを、Satellite 6 の hammer ツールが含まれるシステムにコピーします。あるいは、『Hammer CLI ガイド』に記載の手順に従って、hammer ツールをアンダークラウドにインストールします。

5. 以下の hammer コマンドを実行して、実際の Satellite 組織に新規製品 (OSP13 Containers) を作成します。

   $ hammer product create \
     --organization "ACME" \
     --name "OSP13 Containers"

   このカスタム製品に、イメージを保管します。

6. 製品にベースコンテナーイメージを追加します。

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP13 Containers" \
     --content-type docker \
     --url https://registry.access.redhat.com \
     --docker-upstream-name rhosp13/openstack-base \
     --name base

7. satellite_images ファイルからオーバークラウドのコンテナーイメージを追加します。

   $ while read IMAGE; do \
     IMAGENAME=$(echo $IMAGE | cut -d"/" -f2 | sed "s/openstack-//g" | sed "s/:.*//g") ; \
     hammer repository create \
     --organization "ACME" \
     --product "OSP13 Containers" \
     --content-type docker \
     --url https://registry.access.redhat.com \
     --docker-upstream-name $IMAGE \
     --name $IMAGENAME ; done < satellite_images_names

8. コンテナーイメージを同期します。

   $ hammer product synchronize \
     --organization "ACME" \
     --name "OSP13 Containers"

   Satellite サーバーが同期を完了するまで待ちます。

   注記

   設定によっては、hammer から Satellite サーバーのユーザー名およびパスワードが要求される場合があります。設定ファイルを使って自動的にログインするように hammer を設定することができます。詳細は、『Hammer CLI ガイド』の「認証」セクションを参照してください。

9. Satellite 6 サーバーでコンテンツビューを使用している場合には、新規コンテンツビューを作成して、イメージを取り入れます。

10. base イメージに利用可能なタグを確認します。

    $ hammer docker tag list --repository "base" \
      --organization "ACME" \
      --product "OSP13 Containers"

    これにより、OpenStack Platform コンテナーイメージのタグが表示されます。

11. アンダークラウドに戻り、Satellite サーバー上のイメージ用に環境ファイルを生成します。環境ファイルを生成するコマンドの例を以下に示します。

    (undercloud) $ openstack overcloud container image prepare \
      --namespace=satellite6.example.com:5000 \
      --prefix=acme-osp13_containers- \
      --tag-from-label {version}-{release} \
      --output-env-file=/home/stack/templates/overcloud_images.yaml

    注記

    このステップの openstack overcloud container image prepare コマンドは、Satellite サーバーをターゲットにします。ここでは、前のステップで使用した openstack overcloud container image prepare コマンドとは異なる値を指定します。

    このコマンドを実行する際には、以下の情報を含めてください。

    • --namespace: Satellite サーバー上のレジストリーの URL およびポート。Red Hat Satellite のデフォルトのレジストリーポートは 5000 です。例: --namespace=satellite6.example.com:5000

    • --prefix=: プレフィックスは Satellite 6 の命名規則に基づきます。これは、コンテンツビューを使用するかどうかによって異なります。

      • コンテンツビューを使用する場合、構成は [org]-[environment]-[content view]-[product]- となります (例: acme-production-myosp13-osp13_containers-)。
      • コンテンツビューを使用する場合、構成は [org]-[product]- となります (例: acme-osp13_containers-)。
    • --tag-from-label {version}-{release}: 各イメージの最新のタグを特定します。
    • -e: オプションのサービスの環境ファイルを指定します。

    • --set ceph_namespace、--set ceph_image、--set ceph_tag: Ceph Storage を使用する場合には、Ceph Storage のコンテナーイメージの場所を定義する追加のパラメーターを指定します。ceph_image に Satellite 固有のプレフィックスが追加された点に注意してください。このプレフィックスは、--prefix オプションと同じ値です。以下に例を示します。

      --set ceph_image=acme-osp13_containers-rhceph-3-rhel7

      これにより、オーバークラウドは Satelite の命名規則の Ceph コンテナーイメージを使用することができます。

12. これで、Satellite サーバー上のイメージの場所が記載された overcloud_images.yaml 環境ファイルが作成されます。このファイルをデプロイメントで指定します。

手順

1. ceph-ansible パッケージをアンダークラウドにインストールします。

   [stack@director ~]$ sudo yum install -y ceph-ansible

2. ストレージの環境ファイルで、最新のリソースと設定を使用するようにします。これは、以下のように変更する必要があります。

   1. resource_registry は、puppet/services サブディレクトリーの代わりに、コア Heat テンプレートコレクションの docker/services サブディレクトリーからコンテナー化されたサービスを使用します。以下に例を示します。

      resource_registry:
        OS::TripleO::Services::CephMon: /usr/share/openstack-tripleo-heat-templates/puppet/services/ceph-mon.yaml
        OS::TripleO::Services::CephOSD: /usr/share/openstack-tripleo-heat-templates/puppet/services/ceph-osd.yaml
        OS::TripleO::Services::CephClient: /usr/share/openstack-tripleo-heat-templates/puppet/services/ceph-client.yaml

      上記の行を、以下のように置き換えます。

      resource_registry:
        OS::TripleO::Services::CephMon: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-mon.yaml
        OS::TripleO::Services::CephOSD: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-osd.yaml
        OS::TripleO::Services::CephClient: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-client.yaml

      重要

      この設定は、/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml の環境ファイルに記載されています。このファイルは、-e でデプロイメントのコマンドに追加することができます。

   2. 新しい CephAnsibleDisksConfig パラメーターを使用して、ディスクのマッピングの方法を定義します。以前のバージョンの Red Hat OpenStack Platform では、ceph::profile::params::osds hieradata を使用して OSD レイアウトを定義していました。この hieradata を CephAnsibleDisksConfig パラメーターの構成に変換します。たとえば、hieradata に以下の内容が記載されているとします。

      parameter_defaults:
        ExtraConfig:
          ceph::profile::params::osd_journal_size: 512
          ceph::profile::params::osds:
            '/dev/sdb': {}
            '/dev/sdc': {}
            '/dev/sdd': {}

      この場合には、CephAnsibleDisksConfig は以下のようになります。

      parameter_defaults:
        ExtraConfig: {}
        CephAnsibleDisksConfig:
          devices:
          - /dev/sdb
          - /dev/sdc
          - /dev/sdd
          journal_size: 512
          osd_scenario: collocated

      ceph-ansible に使用する OSD ディスクレイアウトオプションの完全な一覧は、/usr/share/ceph-ansible/group_vars/osds.yml.sample のサンプルファイルを参照してください。

3. 今後は、デプロイメントのコマンドで -e オプションを使用して新しい Ceph の設定環境ファイルを指定するようにしてください。

手順

1. director の動的な Ansible スクリプトが OpenStack Platform 12 バージョンに更新され、オーバークラウドプラン内の RoleNetHostnameMap Heat パラメーターを使用してインベントリーを定義するようになりました。ただし、オーバークラウドは現在 OpenStack Platform 11 のテンプレートバージョンを使用しており、これには RoleNetHostnameMap パラメーターがないため、一時的な静的インベントリーファイルを作成する必要があります。このファイルは、以下のコマンドを実行すると生成することができます。

   $ openstack server list -c Networks -f value | cut -d"=" -f2 > overcloud_hosts

2. 以下の内容を記述した Ansible Playbook (undercloud-ca.yml) を作成します。

   ---
   - name: Add undercloud CA to overcloud nodes
     hosts: all
     user: heat-admin
     become: true
     vars:
       ca_certificate: /etc/pki/ca-trust/source/anchors/cm-local-ca.pem
     tasks:
       - name: Copy undercloud CA
         copy:
           src: "{{ ca_certificate }}"
           dest: /etc/pki/ca-trust/source/anchors/
       - name: Update trust
         command: "update-ca-trust extract"
       - name: Get the swift endpoint
         shell: |
           sudo hiera swift::keystone::auth::public_url | awk -F/ '{print $3}'
         register: swift_endpoint
         delegate_to: 127.0.0.1
         become: yes
         become_user: stack
       - name: Verify URL
         uri:
           url: https://{{ swift_endpoint.stdout }}/healthcheck
           return_content: yes
         register: verify
       - name: Report output
         debug:
           msg: "{{ ansible_hostname }} can access the undercloud's Public API"
         when: verify.content == "OK"

   この Playbook には複数のタスクが含まれており、各ノードで以下の操作を実行します。

   • アンダークラウドの認証局ファイルをオーバークラウドノードにコピーします。アンダークラウドによって生成された場合には、デフォルトの場所は /etc/pki/ca-trust/source/anchors/cm-local-ca.pem です。
   • オーバークラウドノードで、CA トラストデータベースを更新するコマンドを実行します。
   • オーバークラウドノードから、アンダークラウドの Object Storage Public API をチェックして、成功したかどうかを報告します。

3. 以下のコマンドで Playbook を実行します。

   $ ansible-playbook -i overcloud_hosts undercloud-ca.yml

   ここでは、一時インベントリーを使用して、Ansible にオーバークラウドノードを指定します。

   カスタムの認証局ファイルを使用している場合は、ca_certificate 変数で場所を変更することができます。以下に例を示します。

   $ ansible-playbook -i overcloud_hosts undercloud-ca.yml -e ca_certificate=/home/stack/ssl/ca.crt.pem

4. その結果、Ansible の出力には、ノードのデバッグメッセージが表示されます。以下に例を示します。

   ok: [192.168.24.100] => {
       "msg": "overcloud-controller-0 can access the undercloud's Public API"
   }

手順

1. 環境ファイルを選択して、ExtraConfig パラメーターが設定されているかどうかを確認します。

   $ grep ExtraConfig ~/templates/custom-config.yaml

2. コマンドの出力で、選択したファイルのいずれかのロールに ExtraConfig パラメーター (例: ControllerExtraConfig) が表示された場合には、そのファイルの全パラメーター構造を確認します。

3. SECTION/parameter 構文で value が続くいずれかの puppet Hierdata がパラメーターに含まれている場合には、実際の Puppet クラスに置き換えられている可能性があります。以下に例を示します。

   parameter_defaults:
     ExtraConfig:
       neutron::config::dhcp_agent_config:
         'DEFAULT/dnsmasq_local_resolv':
           value: 'true'

4. director の Puppet モジュールを確認して、パラメーターが Puppet クラス内に存在しているかどうかを確認します。以下に例を示します。

   $ grep dnsmasq_local_resolv

   その場合には、新規インターフェースに変更します。

5. 構文の変更の実例を以下に示します。

   • 例 1:

     parameter_defaults:
       ExtraConfig:
         neutron::config::dhcp_agent_config:
           'DEFAULT/dnsmasq_local_resolv':
             value: 'true'

     変更後

     parameter_defaults:
       ExtraConfig:
         neutron::agents::dhcp::dnsmasq_local_resolv: true

   • 例 1:

     parameter_defaults:
       ExtraConfig:
         ceilometer::config::ceilometer_config:
           'oslo_messaging_rabbit/rabbit_qos_prefetch_count':
             value: '32'

     変更後

     parameter_defaults:
       ExtraConfig:
         oslo::messaging::rabbit::rabbit_qos_prefetch_count: '32'

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. Fast Forward Upgrade の parepare コマンドを実行します。

   $ openstack overcloud ffwd-upgrade prepare \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /home/stack/templates/custom_repositories_script.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • カスタム設定の環境ファイル (-e で指定)。以下に例を示します。

     • コンテナーイメージの場所が記載された環境ファイル (overcloud_images.yaml)。アップグレードのコマンドで --container-registry-file の使用に関する警告が表示される場合があることに注意してください。このオプションは非推奨になり、コンテナーイメージの環境ファイルには -e を使用するのが推奨されるようになっているので、警告は無視して問題ありません。
     • 該当する場合は、非推奨になった CLI オプションを Heat パラメーターにマッピングする環境ファイル。deprecated_cli_options.yaml を使用します。
     • 該当する場合は、カスタムリポジトリーのスクリプトを指定する環境ファイル。custom_repositories_script.yaml を使用します。
     • Ceph Storage ノードを使用する場合には、関連する環境ファイル
     • お使いの環境に関連する追加の環境ファイル
   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   • 該当する場合には、--roles-file を使用する、カスタムロール (roles_data) のファイル
   重要

   ffwd-upgrade コマンドの実行を確認するプロンプトが表示されます。yes と入力してください。

3. オーバークラウドプランが OpenStack Platform 13 バージョンに更新されます。Fast Forward Upgrade の準備が完了するまで待ちます。

4. Fast Forward Upgrade の コマンドを実行します。

   $ openstack overcloud ffwd-upgrade run

   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   重要

   ffwd-upgrade コマンドの実行を確認するプロンプトが表示されます。yes と入力してください。

5. Fast Forward Upgrade が完了するまで待ちます。

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. アップグレードのコマンドを実行します。

   $ openstack overcloud upgrade run --roles Controller --skip-tags validation

   注記

   OpenStack Platform サービスはオーバークラウド上では非アクティブな状態で検証できないため、上記のコマンドには --skip-tags validation を使用しています。

   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
3. コントローラーノードのアップグレードが完了するまで待ちます。

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. アップグレードのコマンドを実行します。

   $ openstack overcloud upgrade run --nodes compute-0 --skip-tags validation

   注記

   OpenStack Platform サービスはオーバークラウド上では非アクティブな状態で検証できないため、上記のコマンドには --skip-tags validation を使用しています。

   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
3. テスト用ノードのアップグレードが完了するまで待ちます。

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. アップグレードのコマンドを実行します。

   $ openstack overcloud upgrade run --roles Compute --skip-tags validation

   注記

   OpenStack Platform サービスはオーバークラウド上では非アクティブな状態で検証できないため、上記のコマンドには --skip-tags validation を使用しています。

   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
3. コンピュートノードのアップグレードが完了するまで待ちます。

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. アップグレードのコマンドを実行します。

   $ openstack overcloud upgrade run --roles CephStorage --skip-tags validation

   注記

   OpenStack Platform サービスはオーバークラウド上では非アクティブな状態で検証できないため、上記のコマンドには --skip-tags validation を使用しています。

   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
3. ノードのアップグレードが完了するまで待ちます。

4. Ceph Storage のアップグレードコマンドを実行します。以下に例を示します。

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e <ENVIRONMENT FILE> \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /home/stack/templates/custom_repositories_script.yaml
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       --ceph-ansible-playbook '/usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml,/usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml'

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • カスタム設定の環境ファイル (-e で指定)。以下に例を示します。

     • コンテナーイメージの場所が記載された環境ファイル (overcloud_images.yaml)。アップグレードのコマンドで --container-registry-file の使用に関する警告が表示される場合があることに注意してください。このオプションは非推奨になり、コンテナーイメージの環境ファイルには -e を使用するのが推奨されるようになっているので、警告は無視して問題ありません。
     • 該当する場合は、非推奨になった CLI オプションを Heat パラメーターにマッピングする環境ファイル。deprecated_cli_options.yaml を使用します。
     • 該当する場合は、カスタムリポジトリーのスクリプトを指定する環境ファイル。custom_repositories_script.yaml を使用します。
     • Ceph Storage ノード用の関連する環境ファイル
     • お使いの環境に関連する追加の環境ファイル
   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   • 該当する場合には、--roles-file を使用する、カスタムロール (roles_data) のファイル
   • 以下の Ansible Playbook
   • /usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml
   • /usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml
5. Ceph Storage ノードのアップグレードが完了するまで待ちます。

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. Fast Forward Upgrade の最終処理のコマンドを実行します。

   $ openstack overcloud ffwd-upgrade converge \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /home/stack/templates/custom_repositories_script.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <OTHER ENVIRONMENT FILES>

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • カスタム設定の環境ファイル (-e で指定)。以下に例を示します。

     • コンテナーイメージの場所が記載された環境ファイル (overcloud_images.yaml)。アップグレードのコマンドで --container-registry-file の使用に関する警告が表示される場合があることに注意してください。このオプションは非推奨になり、コンテナーイメージの環境ファイルには -e を使用するのが推奨されるようになっているので、警告は無視して問題ありません。
     • 該当する場合は、非推奨になった CLI オプションを Heat パラメーターにマッピングする環境ファイル。deprecated_cli_options.yaml を使用します。
     • 該当する場合は、カスタムリポジトリーのスクリプトを指定する環境ファイル。custom_repositories_script.yaml を使用します。
     • Ceph Storage ノードを使用する場合には、関連する環境ファイル
     • お使いの環境に関連する追加の環境ファイル
   • カスタムのスタック名を使用する場合には、--stack オプションでその名前を渡します。
   • 該当する場合には、--roles-file を使用する、カスタムロール (roles_data) のファイル
   重要

   ffwd-upgrade コマンドの実行を確認するプロンプトが表示されます。yes と入力してください。

3. Fast Forward Upgrade の最終処理が完了するまで待ちます。

手順

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

   $ source ~/stackrc

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

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

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

   (undercloud) $ df -h

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

   (undercloud) $ sudo ntpstat

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

   (undercloud) $ openstack network agent list

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

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

   (undercloud) $ openstack compute service list

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

手順

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

   $ source ~/stackrc

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

   (undercloud) $ openstack baremetal node list

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

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

   (undercloud) $ 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. エラーが発生しているコンテナー化されたサービスがあるかどうかを確認します。

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'exited=1' --all" ; done
   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'status=dead' -f 'status=restarting'" ; done

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

   (undercloud) $ 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 /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg'

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

   (undercloud) $ 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 サービスとそれらの接続ステータスが表示されます。

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

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

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

   (undercloud) $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker exec $(ssh heat-admin@$NODE "sudo docker ps -f 'name=.*rabbitmq.*' -q") rabbitmqctl node_health_check" ; done

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

   (undercloud) $ 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 のアクションがないこと

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

   (undercloud) $ 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

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

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

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

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

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

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

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

    (undercloud) $ source ~/overcloudrc

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

    (overcloud) $ openstack network agent list

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

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

    (overcloud) $ openstack compute service list

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

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

    (overcloud) $ openstack volume service list

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

手順

1. stack ユーザーの images ディレクトリー (/home/stack/images) から既存のイメージを削除します。

   $ rm -rf ~/images/*

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

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

3. director に最新のイメージをインポートします。

   $ openstack overcloud image upload --update-existing --image-path /home/stack/images/

4. ノードが新しいイメージを使用するように設定します。

   $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f value)

5. 新規イメージが存在することを確認します。

   $ openstack image list
   $ ls -l /httpboot

手順

1. stackrc ファイルを読み込みます。

   $ source ~/stackrc

2. オーバークラウドに関連する全環境ファイルを指定してデプロイのコマンドを実行します。

   $ openstack overcloud deploy \
       --templates \
       -e <ENVIRONMENT FILE>

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • -e を使用してカスタム設定環境ファイル
   • 該当する場合には、--roles-file を使用する、カスタムロール (roles_data) のファイル
3. デプロイメントが完了するまで待ちます。