Translated message

A translation of this page exists in English.

Warning message

This translation is outdated. For the most up-to-date information, please refer to the English version.

高可用性を使用して Red Hat Enterprise Linux OpenStack Platform 7 のインスタンスを保護する方法

更新 -

本記事では、高可用性 (HA) を使用してインスタンスを保護する方法について説明します。HA のバックエンドには Pacemakerが採用されています。Pacemaker により、コンピュートノードの障害を検知し、障害発生を予測して対応する機能が追加されます。

注記: 本記事は、director を使用してデプロイ済みの既存の Red Hat Enterprise Linux OpenStack Platform 7 環境が完全に HA の状態に設定されていることを前提とします。

環境要件および前提条件

この記事で使用する環境の要件と前提条件は以下の通りです。

  • RHEL OpenStack Platform director を使用して環境がデプロイされていること
  • コントロールプレーンでフェンシングが手動で有効化されていること
  • インスタンスを HA に設定した後に overcloud stack の更新が実行されないこと
  • 以下のパッケージが全ノードにインストールされていること
    • fence-agents-all-4.0.11-27.el7_2.5.x86_64 (以降)
    • pacemaker-1.1.13-10.el7_2.2.x86_64 (以降)
    • resource-agents-3.9.5-54.el7_2.6.x86_64 (以降)
  • コンピュートおよびコントロールプレーンの両方を完全に停止する必要がある
  • 一時ストレージおよびブロックストレージの共有ストレージが環境内で有効になっていること。この要件の例外については、以下を参照してください。

共有ストレージの例外

通常、この設定には共有ストレージが必要です。no-shared-storage オプションの使用を試みると、退避中に InvalidSharedStorage エラーが発生して、別のノード上ではインスタンスの電源がオンにならない可能性が高くなります。ただし、全インスタンスが Block Storage (cinder) ボリュームから起動するように設定されている場合には、インスタンスのディスクイメージを保管するための共有ストレージは必要ないので、no-shared-storage オプションを使用して全インスタンスを退避することが可能となります。退避中に、Block Storage (cinder) ボリュームから起動するようにインスタンスが設定されている場合には、退避されるインスタンスはいずれも、同じ cinder ボリュームから起動することが予想されますが、別のコンピュートノード上で起動することになります。そのため、OS イメージとアプリケーションデータはその Cinder ボリューム上に保持されているので、退避されたインスタンスは、ジョブを即時に再起動することができます。

デプロイメントにこのようなユースケースが含まれる場合には、ステップ 7 で no_shared_storage=1 オプションを指定してください。

インストール

1. まず、コンピュートノード上で libvirtd および全 OpenStack サービスを停止して、無効にしてます。

heat-admin@compute-n # sudo openstack-service stop
heat-admin@compute-n # sudo openstack-service disable
heat-admin@compute-n # sudo systemctl stop libvirtd
heat-admin@compute-n # sudo systemctl disable libvirtd

2. pacemaker-remote を使用するための認証キーを作成します。

コンピュートノードの 1 つでこのステップを実行します。

heat-admin@compute-1 # sudo mkdir -p /etc/pacemaker/
heat-admin@compute-1 # sudo dd if=/dev/urandom of=/etc/pacemaker/authkey bs=4096 count=1
heat-admin@compute-1 # sudo cp /etc/pacemaker/authkey ./
heat-admin@compute-1 # sudo chown heat-admin:heat-admin authkey

3. このキーを director ノードにコピーしてから、残りのコンピュートおよびコントローラーノードにコピーします。

stack@director # scp heat-admin@compute-1:~/ ./
stack@director # scp authkey heat-admin@node-n:~/
heat-admin@node-n # sudo mkdir -p /etc/pacemaker/
heat-admin@node-n # sudo mv authkey /etc/pacemaker/
heat-admin@node-n # sudo chown root:root /etc/pacemaker/authkey

4. 全コンピュートノード上で pacemaker-remote を有効にします。

heat-admin@compute-n # sudo systemctl enable pacemaker_remote
heat-admin@compute-n # sudo systemctl start pacemaker_remote

5. 必要とされるバージョンの pacemaker (1.1.13-10.el7_2.2.x86_64)、fence-agents (fence-agents-all-4.0.11-27.el7_2.5.x86_64)、resource-agents (3.9.5-54.el7_2.6.x86_64`) パッケージがコントローラーおよびコンピュートノードにインストールされていることを確認します。

heat-admin@controller-n # sudo rpm -qa | egrep '(pacemaker|fence-agents|resource-agents)'

6.a BZ#1257414 に必要とされている、制約の回避策を適用します。

注記: この問題は、RHSA-2015:1862 で対処されており、お使いの環境では必要ない可能性があります。

heat-admin@controller-1 # sudo pcs constraint order start openstack-nova-novncproxy-clone then openstack-nova-api-clone
heat-admin@controller-1 # sudo pcs constraint order start rabbitmq-clone then openstack-keystone-clone
heat-admin@controller-1 # sudo pcs constraint order promote galera-master then openstack-keystone-clone
heat-admin@controller-1 # sudo pcs constraint order start haproxy-clone then openstack-keystone-clone
heat-admin@controller-1 # sudo pcs constraint order start memcached-clone then openstack-keystone-clone
heat-admin@controller-1 # sudo pcs constraint order promote redis-master then start openstack-ceilometer-central-clone require-all=false
heat-admin@controller-1 # sudo pcs resource defaults resource-stickiness=INFINITY

6.b BZ#1295835 に必要とされている、制約の回避策を適用します。

注記: この問題は、 RHBA-2016:0264-1 で対処されており、お使いの環境では必要ない可能性があります。

sudo pcs config | grep systemd | awk '{print $2}' | while read RESOURCE; do sudo pcs resource update $RESOURCE op start timeout=200s op stop timeout=200s; done"

7. overcloudrc ファイルを使用して NovaEvacuate の Active/Passive リソースを作成し、auth_url、username、tenant、password の値を指定します。

stack@director # scp overcloudrc heat-admin@controller-1:~/
heat-admin@controller-1 # . ~/overcloudrc
heat-admin@controller-1 # sudo pcs resource create nova-evacuate ocf:openstack:NovaEvacuate auth_url=$OS_AUTH_URL username=$OS_USERNAME \
password=$OS_PASSWORD tenant_name=$OS_TENANT_NAME

注記: 共有ストレージを使用しない場合には、上記の resource create ... コマンドで no_shared_storage=1 オプションを指定してください。詳細は Exception for shared storage を参照してください。

8. nova-evacuate が Floating IP リソース、Image Service (glance)、OpenStack Networking (neutron)、Compute (nova) Service の後に起動されることを確認します。

heat-admin@controller-1 # for i in $(sudo pcs status | grep IP | awk '{ print $1 }'); do sudo pcs constraint order start $i then nova-evacuate ; done
heat-admin@controller-1 # for i in openstack-glance-api-clone neutron-metadata-agent-clone openstack-nova-conductor-clone; do \
sudo pcs constraint order start $i then nova-evacuate require-all=false ; done

9. コントロールプレーンの全 OpenStack リソースを無効にします。

heat-admin@controller-1 # sudo pcs resource disable openstack-keystone --wait=540s

Identity サービスを停止するのに必要な時間 (およびハードウェアの処理能力) に応じて、タイムアウト時間 (--wait) を増やすことを検討してください。

注記: 上記のコマンドで使用しているタイムアウト値 540 は、一例に過ぎません。問題が発生した場合には、その環境に適したタイムアウト期間を計算することができます。
たとえば、Red Hat OpenStack Platform director を使用した標準的なデプロイメントでは、各サービスに割り当てるタイムアウト期間を考慮する必要があります。

  • Identity サービス:

    • openstack-keystone - 120s

  • Telemetry:

    • openstack-ceilometer-central - 120s
    • openstack-ceilometer-collector - 120s
    • openstack-ceilometer-api - 120s
    • openstack-ceilometer-alarm-evaluator - 120s
    • openstack-ceilometer-notification - 120s

  • Compute:

    • openstack-nova-consoleauth - 120s
    • openstack-nova-novncproxy - 120s
    • openstack-nova-api - 120s
    • openstack-nova-scheduler - 120s
    • openstack-nova-conductor - 120s

  • OpenStack Networking:

    • neutron-server - 120s
    • neutron-openvswitch-agent - 120s
    • neutron-dhcp-agent - 120s
    • neutron-l3-agent - 120s
    • neutron-metadata-agent - 120s

上記の例では、期間が最も長いのは、Telemetry、Compute、OpenStack Networking で、それぞれの合計が 600sとなっています。この数値を適切な値と見なしてテストを開始することができます。タイムアウトの計算を検証するには、pcs resource コマンドを使用します。

controller# pcs resource show openstack-ceilometer-central

   Resource: openstack-ceilometer-central (class=systemd type=openstack-ceilometer-central)
    Operations: start interval=0s timeout=120s
   (openstack-ceilometer-central-start-interval-0s)
                monitor interval=60s
   (openstack-ceilometer-central-monitor-interval-60s)
                stop interval=0s timeout=120s
   (openstack-ceilometer-central-stop-interval-0s)

10. 「cibadmin」データを使用して現在のコントローラー一覧を作成します。

heat-admin@controller-1 # controllers=$(sudo cibadmin -Q -o nodes | grep uname | sed s/.*uname..// | awk -F\" '{print $1}')
heat-admin@controller-1 # echo $controllers

11. この一覧を使用して、osprole=controller プロパティーでこれらのノードをコントローラーとしてタグ付けします。

heat-admin@controller-1 # for controller in ${controllers}; do sudo pcs property set --node ${controller} osprole=controller ; done

12. 環境内にすでに存在する stonith デバイスの一覧を作成します。

heat-admin@controller-1 # stonithdevs=$(sudo pcs stonith | awk '{print $1}')
**heat-admin@controller-1 #**echo $stonithdevs`

13. コントロールプレーンサービスをタグ付けし、一覧内の stonith デバイスをスキップして、上記で特定したコントローラーのみで実行されるようにします。

heat-admin@controller-1 # for i in $(sudo cibadmin -Q --xpath //primitive --node-path | tr ' ' '
' | awk -F "id='" '{print $2}' | awk -F "'" '{print $1}' | uniq); do \
found=0
if [ -n "$stonithdevs" ]; then
for x in $stonithdevs; do
if [ $x = $i ]; then
found=1
fi
done
fi
if [ $found = 0 ]; then
sudo pcs constraint location $i rule resource-discovery=exclusive score=0 osprole eq controller
fi
done

14. pacemaker 内でコンピュートノードのリソース作成を neutron-openvswitch-agent から開始します。

heat-admin@controller-1 # sudo pcs resource create neutron-openvswitch-agent-compute \
systemd:neutron-openvswitch-agent --clone interleave=true --disabled --force
heat-admin@controller-1 # sudo pcs constraint location neutron-openvswitch-agent-compute-clone \
rule resource-discovery=exclusive score=0 osprole eq compute
heat-admin@controller-1 # sudo pcs constraint order start neutron-server-clone then \
neutron-openvswitch-agent-compute-clone require-all=false

次に Compute libvirtd リソースを作成します。

heat-admin@controller-1 # sudo pcs resource create libvirtd-compute systemd:libvirtd --clone interleave=true --disabled --force
heat-admin@controller-1 # sudo pcs constraint location libvirtd-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute
heat-admin@controller-1 # sudo pcs constraint order start neutron-openvswitch-agent-compute-clone then libvirtd-compute-clone
heat-admin@controller-1 # sudo pcs constraint colocation add libvirtd-compute-clone with neutron-openvswitch-agent-compute-clone

次に openstack-ceilometer-compute リソースを作成します。

heat-admin@controller-1 # sudo pcs resource create ceilometer-compute systemd:openstack-ceilometer-compute --clone interleave=true --disabled --force
heat-admin@controller-1 # sudo pcs constraint location ceilometer-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute
heat-admin@controller-1 # sudo pcs constraint order start openstack-ceilometer-notification-clone then ceilometer-compute-clone require-all=false
heat-admin@controller-1 # sudo pcs constraint order start libvirtd-compute-clone then ceilometer-compute-clone
heat-admin@controller-1 # sudo pcs constraint colocation add ceilometer-compute-clone with libvirtd-compute-clone

次に nova-compute リソースを作成します。

heat-admin@controller-1 # . /home/heat-admin/overcloudrc
heat-admin@controller-1 # sudo pcs resource create nova-compute-checkevacuate ocf:openstack:nova-compute-wait auth_url=$OS_AUTH_URL username=$OS_USERNAME password=$OS_PASSWORD tenant_name=$OS_TENANT_NAME domain=localdomain op start timeout=300 --clone interleave=true --disabled --force
heat-admin@controller-1 # sudo pcs constraint location nova-compute-checkevacuate-clone rule resource-discovery=exclusive score=0 osprole eq compute
heat-admin@controller-1 # sudo pcs constraint order start openstack-nova-conductor-clone then nova-compute-checkevacuate-clone require-all=false
heat-admin@controller-1 # sudo pcs resource create nova-compute systemd:openstack-nova-compute --clone interleave=true --disabled --force
heat-admin@controller-1 # sudo pcs constraint location nova-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute
heat-admin@controller-1 # sudo pcs constraint order start nova-compute-checkevacuate-clone then nova-compute-clone require-all=true
heat-admin@controller-1 # sudo pcs constraint order start nova-compute-clone then nova-evacuate require-all=false
heat-admin@controller-1 # sudo pcs constraint order start libvirtd-compute-clone then nova-compute-clone
heat-admin@controller-1 # sudo pcs constraint colocation add nova-compute-clone with libvirtd-compute-clone

15. コンピュートノード用に stonith デバイスを追加します。$IPMILAN_USERNAME と $IPMILAN_PASSWORD の値は、お使いの IPMI デバイスに合わせて置き換えてください。

heat-admin@controller-1 # sudo pcs stonith create ipmilan-overcloud-compute-0 fence_ipmilan pcmk_host_list=overcloud-compute-0 ipaddr=10.35.160.78 login=$IPMILAN_USERNAME passwd=$IPMILAN_PASSWORD lanplus=1 cipher=1 op monitor interval=60s`

16. 別の fence-nova stonith デバイスを作成します。

heat-admin@controller-1 # . overcloudrc
heat-admin@controller-1 # sudo pcs stonith create fence-nova fence_compute \
auth-url=$OS_AUTH_URL \
login=$OS_USERNAME \
passwd=$OS_PASSWORD \
tenant-name=$OS_TENANT_NAME \
domain=localdomain \
record-only=1 --force

17. コンピュートノードがフェンシング後に回復できるようにします。

heat-admin@controller-1 # sudo pcs property set cluster-recheck-interval=1min

18. コンピュートノードのリソースを作成して、stonith level 1 にノードの物理フェンスデバイスと fence-nova の両方が含まれるように設定します。

heat-admin@controller-1 # sudo pcs resource create overcloud-compute-n ocf:pacemaker:remote reconnect_interval=60 op monitor interval=20
heat-admin@controller-1 # sudo pcs property set --node overcloud-compute-n osprole=compute
heat-admin@controller-1 # sudo pcs stonith level add 1 overcloud-compute-0 ipmilan-overcloud-compute-0,fence-nova
heat-admin@controller-1 # sudo pcs stonith

19. コントロールおよびコンピュートプレーンサービスを有効にします。

heat-admin@controller-1 # sudo pcs resource enable openstack-keystone
heat-admin@controller-1 # sudo pcs resource enable neutron-openvswitch-agent-compute
heat-admin@controller-1 # sudo pcs resource enable libvirtd-compute
heat-admin@controller-1 # sudo pcs resource enable ceilometer-compute
heat-admin@controller-1 # sudo pcs resource enable nova-compute

20. 環境が安定するまでしばらく待ってから、失敗したリソースはクリーンアップします。

heat-admin@controller-1 # sleep 60
heat-admin@controller-1 # sudo pcs resource cleanup
heat-admin@controller-1 # sudo pcs status
heat-admin@controller-1 # sudo property set stonith-enabled=true

高可用性のテスト

注記: 以下の手順を実行すると、コンピュートノードは警告なしで意図的に再起動されます。

1. 以下のステップでは、オーバークラウドでインスタンスを起動してから、コンピュートノードをクラッシュさせます。

stack@director # . overcloudrc
stack@director # nova boot --image cirros --flavor 2 test-failover
stack@director # nova list --fields name,status,host
stack@director # . stackrc
stack@director # ssh -lheat-admin compute-n
heat-admin@compute-n # sudo su -
root@compute-n # echo c > /proc/sysrq-trigger

2. しばらくすると、インスタンスは稼働中のコンピュートノードで再起動されるはずです。

stack@director # nova list --fields name,status,host
stack@director # nova service-list

参考情報

Comments