Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

Red Hat OpenStack Platform の高可用性についての理解

Red Hat OpenStack Platform 8

Red Hat OpenStack Platform における高可用性の理解、デプロイ、管理

OpenStack Documentation Team

概要

OpenStack の環境が効率的に稼働する状態を維持するためには、Red Hat OpenStack Platform 8 Director を使用して、OpenStack の主要な全サービスにわたって高可用性および負荷分散を提供する設定を作成できます。本ガイドでは以下の内容について説明します。
  • Red Hat OpenStack Platform 8 Director が作成した基本的な HA 設定。OpenStack HA 機能を理解して操作するためのリファレンスモデルとして使用できます。
  • Red Hat OpenStack Platform 8 に含まれるさまざまなサービスを高可用性にするために使用される HA 機能。
  • Red Hat OpenStack Platform 8 の HA 機能の使用およびトラブルシューティングを行うツールの例

第1章 概要
リンクのコピー

本書で使用しているサンプルの HA デプロイメントは、以下のガイドを参考にしています。

] は、ここで説明する高可用性機能をテストするために特別に構築された特定の設定を示しています。自分で手順を試すことができるように、この設定を再作成する方法の詳細は、xref:buildenv[ を参照してください。

図1.1 director を使用してデプロイした OpenStack HA 環境

computers network osp7 ha 4

HA デプロイメントでは、すべての OpenStack サービスは Pacemaker または HAProxy によって起動および管理される必要があります。これには、すべての関連および依存サービスが含まれます。

たとえば、openstack-dashboard には httpd サービスが必要です。そのため、HA 環境では、httpd を手動で起動または有効にすることはでき ません （例： pcsではなく systemctl を使用）。HA デプロイメントのコロケーションや依存関係の問題の多くは、Pacemaker または HAProxy の外部で管理されるサービスが原因です。

これを回避するには、director で HA デプロイメントを完全にオーケストレーションします。director が使用するテンプレートおよび puppet モジュールにより、すべてのサービスが正しく設定および起動されるようになります（特に HA の場合）。また、HA の問題のトラブルシューティングを行う場合は、可能な限り常に HA フレームワークを介してサービスと対話してください。

第2章 Red Hat OpenStack Platform の HA 機能についての理解
リンクのコピー

Red Hat OpenStack Platform 8 は、高可用性を実装するために複数のテクノロジーを採用しています。高可用性は、OpenStack の設定でコントローラー、コンピュート、およびストレージノードを対象に異なる方法で提供されています。高可用性の実装方法を詳しく調べるには、各ノードにログインして、以下の項に記載したコマンドを実行してください。この操作の出力には、各ノードで HA サービスとプロセスが実行中であることが表示されます。

本ガイドに記載する高可用性 (HA) についての内容の大半は、コントローラーノードに関連しています。Red Hat OpenStack Platform 8 のコントローラーノード上で使用されている主要な HA テクノロジーは 2 つあります。

  • Pacemaker: 仮想 IP アドレス、サービス、およびその他の機能をクラスター内のリソースとして設定することにより、Pacemaker により、定義した OpenStack クラスターリソースのセットが実行中および利用できるようにします。クラスター内のサービスまたはノード全体に障害が発生した場合、Pacemaker はサービスの再起動、クラスターからノードの取得、またはノードの再起動を行うことができます。これらのサービスの大半に対する要求は、HAProxy 経由で行われます。
  • HAProxy: Red Hat OpenStack Platform 8 で director を使用して複数のコントローラーノードを設定すると、HAProxy がこれらのノード上で実行中の OpenStack サービスの一部にトラフィックを負荷分散するように設定されます。
  • Galera: Red Hat OpenStack Platform は MariaDB Galera Cluster を使用して、データベースのレプリケーションを管理します。

OpenStack の高可用性サービスは、以下の 2 つのモードのいずれかで実行されます。

  • Active/Active: このモードでは、Pacemaker により同じサービスが複数のノード上で起動し、トラフィックは HAProxy により要求サービスが実行中のノードに分散されるか、単一の IP アドレスを使用して特定のコントローラーに転送されます。場合によっては、HAProxy はトラフィックをラウンドロビン方式で Active/Active サービスに分散します。コントローラーノード数を増やすと、パフォーマンスを向上させることができます。
  • Active/passive: Active/Active モードで実行できない、または Active/Active モードで実行するには信頼性に欠けるサービスは Active/Passive モードで実行します。これは、サービス内で 1 度にアクティブにできるインスタンスは 1 つのみという意味です。Galera の場合は、HAProxy は stick-table オプションを使用して、受信接続が単一のバックエンドサービスに転送されるようにします。サービスが複数の Galera ノードから同時に同一データにアクセスした場合には、Galera のマスター/マスターのモードはデッドロックになる可能性があります。

本ガイドに記載の高可用性サービスの使用を開始する際には、director システム (アンダークラウド) 自体も OpenStack を実行している点を念頭に置いてください。アンダークラウド (director システム) の目的は、実際に作業を行う OpenStack 環境のシステムを構築、管理することです。アンダークラウドから構築した環境は、オーバークラウドと呼ばれます。オーバークラウドを使用するには、本ガイドではアンダークラウドにログインしてから、調査するオーバークラウドノードを選択します。

第3章 OpenStack HA 環境へのログイン
リンクのコピー

OpenStack HA 環境が稼働している状態で、director (アンダークラウド) システムにログインします。続いて、以下のコマンドを実行して stack ユーザーになります。 

# sudo su - stack

そこから、対応する環境変数を読み込んで、アンダークラウドおよびオーバークラウドと対話することができます。アンダークラウドと対話するには、以下のコマンドを実行します。 

$ source ~/stackrc

同様に、オーバークラウドと対話するには、以下のコマンドを実行します。 

$ source ~/overcloudrc

アンダークラウドまたはオーバークラウド へのアクセスに関する詳細は、基本的なオーバークラウドへのアクセス を参照して ください。

ノードにアクセスして調査するには、まずノードに割り当てられている IP アドレスを確認します。そのためには、アンダークラウドと対話する必要があります。 

$ source ~/stackrc
$ nova list
 +-------+------------------------+---+----------------------+
 | ID    | Name                   |...| Networks             |
 | d1... | overcloud-controller-0 |...| ctlplane=10.200.0.11 |
 ...
注記

参考のために、本ガイドで使用しているテスト環境で director によってデプロイされたノードの名前とアドレスを以下の表にまとめます。

Expand
名前アドレス

overcloud-controller-0

10.200.0.11

overcloud-controller-1

10.200.0.10

overcloud-controller-1

10.200.0.6 (仮想 IP)

overcloud-controller-2

10.200.0.14

overcloud-compute-0

10.200.0.12

overcloud-compute-1

10.200.0.15

overcloud-cephstorage-0

10.200.0.9

overcloud-cephstorage-1

10.200.0.8

overcloud-cephstorage-2

10.200.0.7

独自のテスト環境では、同じアドレス範囲を使用しても、各ノードに割り当てられる IP アドレスは異なる場合があります。

オーバークラウドノードの IP アドレスがわかったら、以下のコマンドを実行してそれらのノードの 1 つにログインできます。この操作を実行するには、オーバークラウドと対話する必要があります。たとえば、overcloud-controller-0 に heat- admin ユーザーとしてログインするには、以下のコマンドを実行します。 

$ source ~stack/overcloudrc
$ ssh heat-admin@10.200.0.11

コントローラー、コンピュート、またはストレージシステムにログインした後には、そこで HA 機能についての調査を開始することができます。

第4章 Pacemaker の使用
リンクのコピー

図1.1「director を使用してデプロイした OpenStack HA 環境」 で示されている OpenStack 設定では、OpenStack サービスの大半は 3 つのコントローラーノード上で実行しています。これらのサービスの高可用性機能を確認するには、heat-admin ユーザーとしてコントローラーのいずれかにログインして、Pacemaker が制御するサービスを確認します。Pacemaker pcs status コマンドの出力には、Pacemaker の全般的な情報、仮想 IP アドレス、サービス、およびその他の Pacemaker 情報が含まれます。

4.1. Pacemaker の全般的な情報
リンクのコピー

pcs status 出力の最初の部分には、クラスターの名前、クラスターが最近変更されたときに現在の DC、クラスター内のノード数、クラスターで設定されているリソースの数、およびクラスター内のノードが表示されます。 

$ sudo pcs status
    Cluster name: tripleo_cluster
    Last updated: Mon Oct  5 13:42:37 2015
    Last change: Mon Oct  5 13:03:06 2015
    Stack: corosync
    Current DC: overcloud-controller-1 (2) - partition with quorum
    Version: 1.1.12-a14efad
    3 Nodes configured
    115 Resources configured
    Online: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]

    Full list of resources:
...

sudo pcs status の最初の出力は、クラスターの名前が tripleo_cluster で、3 つのノード(overcloud-controller-0、-1、および -2)で設定されていることを示しています。現在、3 つのノードはすべてオンライン状態です。

tripleo_cluster という名前のクラスター内で管理されるように設定されたリソースの数は、システムのデプロイ方法によって変更される可能性があります。この例では、115 のリソースがありました。

pcs status の出力の次の部分は、開始されたリソース(IP アドレス、サービスなど)と、それらが実行されているコントローラーノードを正確に示します。次のさまざまなセクションでは、その出力例を示します。

Pacemaker の詳細については、

4.2. Pacemaker で設定された仮想 IP アドレス
リンクのコピー

各 IPaddr2 リソースは、クライアントがサービスへのアクセスを要求するために使用する仮想 IP アドレスを設定します。その IP アドレスに割り当てられたコントローラーノードがダウンした場合、IP アドレスは別のコントローラーに再割り当てされます。この例では、特定の仮想 IP アドレスをリッスンするように現在設定されている各コントローラー(overcloud-controller-0、-1 など)を確認できます。 

 ip-192.168.1.150	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-0
 ip-10.200.0.6	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-1
 ip-172.16.0.10	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-1
 ip-172.16.0.11	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-0
 ip-172.18.0.10	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-2
 ip-172.19.0.10	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-2

それぞれの IP アドレスが最初に特定のコントローラーに接続されている点に注意してください（たとえば、192.168.1.150 は overcloud-controller-0で開始します）。ただし、そのコントローラーがダウンした場合、その IP アドレスはクラスター内の他のコントローラーに再割り当てされます。以下に、表示された IP アドレスと、最初に割り当てられた方法の説明を以下に示します。

  • 192.168.1.150: パブリック IP アドレス( network-environment.yamlの ExternalAllocationPools から割り当て)
  • 10.200.0.6: コントローラー仮想 IP アドレス( undercloud.confの 10.200.0.5-10.200.0.24 に設定された dhcp_start と dhcp_end の範囲の一部)
  • 172.16.0.10: コントローラー上の OpenStack API サービスへのアクセスを提供する IP アドレス( network-environment.yamlの InternalApiAllocationPools から割り当て済み)
  • 172.16.0.11: コントローラーの Redis サービスへのアクセスを提供する IP アドレス( network-environment.yamlの InternalApiAllocationPools から割り当て)
  • 172.18.0.10: ストレージの仮想 IP アドレスおよび Swift プロキシーサービス( network-environment.yamlの StorageAllocationPools から割り当て)
  • 172.19.0.10: ストレージ管理へのアクセスを提供する IP アドレス( network-environment.yamlの StorageMgmtAlloctionPools から割り当て)

pcs コマンドを使用して Pacemaker に設定した特定の IPaddr2 アドレスの詳細を確認することができます。たとえば、特定の仮想 IP アドレスのタイムアウトおよびその他の関連情報を表示するには、IPaddr2 リソースの 1 つに対して次のように入力します。 

$ sudo pcs resource show ip-192.168.1.150
 Resource: ip-192.168.1.150 (class=ocf provider=heartbeat type=IPaddr2)
  Attributes: ip=192.168.1.150 cidr_netmask=32
  Operations: start interval=0s timeout=20s (ip-192.168.1.150-start-timeout-20s)
              stop interval=0s timeout=20s (ip-192.168.1.150-stop-timeout-20s)
              monitor interval=10s timeout=20s (ip-192.168.1.150-monitor-interval-10s)

現在、192.168.1.150 アドレスをリッスンするように設定されているコントローラーにログインしている場合は、以下のコマンドを実行して、アクティブで、そのアドレスをアクティブにリッスンするサービスがあることを確認します。 

$ ip addr show vlan100
  9: vlan100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether be:ab:aa:37:34:e7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.151/24 brd 192.168.1.255 scope global vlan100
       valid_lft forever preferred_lft forever
    inet 192.168.1.150/32 brd 192.168.1.255 scope global vlan100
       valid_lft forever preferred_lft forever

$ sudo netstat -tupln | grep 192.168.1.150
    tcp  0  0 192.168.1.150:6080      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:9696      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8000      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8003      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8004      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8773      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8774      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:5000      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8776      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8777      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:9292      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8080      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:80        0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:35357     0.0.0.0:*  LISTEN      4333/haproxy
    udp  0  0 192.168.1.150:123       0.0.0.0:*              459/ntpd
    ...
    tcp  0  0 0.0.0.0:22              0.0.0.0:*  LISTEN      2471/sshd
    tcp  0  0 0.0.0.0:4567            0.0.0.0:*  LISTEN      10064/mysqld
    ...
    udp  0  0 0.0.0.0:51475           0.0.0.0:*              545/dhclient
    udp  0  0 0.0.0.0:123             0.0.0.0:*              459/ntpd
    udp  0  0 0.0.0.0:161             0.0.0.0:*              1633/snmpd
    ...

ip コマンドは、vlan100 インターフェイスが 192.168.1.150 と 192.168.1.151 の IPv4 アドレスの両方でリッスンしていることを示しています。netstat コマンドの出力では、192.168.1.150 インターフェイスでリッスンしているすべてのプロセスを確認できます。ntpd プロセス（ポート 123 でリッスン）のほかにも、192.168.1.150 で特別にリッスンしている他の唯一のプロセスは haproxy プロセスのみです。また、すべてのローカルアドレス(0.0.0.0)でリッスンしているプロセスは、192.168.1.150 (sshd、mysqld、dhclient、ntpd など)からも利用できます。

netstat 出力に表示されるポート番号は、haproxy がリッスンしている正確なサービスを特定するのに役立ちます。/etc/haproxy/haproxy.cfg ファイル内でそれらのポート番号が表すサービスを調べることができます。以下にいくつかの例を示します。

  • TCP ポート 6080: nova_novncproxy
  • TCP ポート 9696: neutron
  • TCP ポート 8000: heat_cfn
  • TCP ポート 8003: heat_cloudwatch
  • TCP ポート 80: horizon

現時点では、3 つすべてのコントローラーで 192.168.1.150 で特にリッスンしている haproxy.cfg のサービスは 14 つあります。ただし、現在、192.168.1.150 で実際にリッスンしているのは controller-0 のみです。したがって、controller-0 がダウンした場合、HAProxy は 192.168.1.150 を別のコントローラーに再割り当てするだけで、すべてのサービスはすでに実行されていることになります。

4.3. Pacemaker で設定された OpenStack サービス
リンクのコピー

ほとんどのサービスは、クローンセットリソース（または クローン）として 設定 されます。ここでは、各コントローラーで同じ方法で起動し、常に各コントローラーで実行するように設定されます。複数のノードでアクティブになる必要がある場合は、サービスのクローンが作成されます。したがって、複数のノードで同時にアクティブにできるサービスのみをクローンすることができます（つまり、その場合）。クラスター対応サービス）。

他のサービスは Multi-state リソースとして設定されます。マルチステートリソースは、クローンの特殊なタイプです。通常の Clone Set リソースとは異なり、 Multi-state リソースは マスター または スレーブ の状態のいずれかになります。インスタンスが起動すると、スレーブ 状態で起動する必要があります。それ以外は、どちらの状態にも特別な意味はありません。ただし、これらの状態により、同じサービスのクローンは異なるルールや制約で実行できます。

サービスが同時に複数のコントローラーで実行されている場合でも、コントローラー自体は、これらのサービスに実際に到達するために必要な IP アドレスをリッスンしていない可能性があることに注意してください。

クローンセットリソース（クローン）

pcs status のクローン設定を以下に示します。 

Clone Set: haproxy-clone [haproxy]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: mongod-clone [mongod]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: rabbitmq-clone [rabbitmq]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: memcached-clone [memcached]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-nova-scheduler-clone [openstack-nova-scheduler]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: neutron-l3-agent-clone [neutron-l3-agent]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-ceilometer-alarm-notifier-clone [openstack-ceilometer-alarm-notifier]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-heat-engine-clone [openstack-heat-engine]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-ceilometer-api-clone [openstack-ceilometer-api]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: neutron-metadata-agent-clone [neutron-metadata-agent]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: neutron-ovs-cleanup-clone [neutron-ovs-cleanup]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: neutron-netns-cleanup-clone [neutron-netns-cleanup]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-heat-api-clone [openstack-heat-api]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-cinder-scheduler-clone [openstack-cinder-scheduler]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-nova-api-clone [openstack-nova-api]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-heat-api-cloudwatch-clone [openstack-heat-api-cloudwatch]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-ceilometer-collector-clone [openstack-ceilometer-collector]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-keystone-clone [openstack-keystone]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-nova-consoleauth-clone [openstack-nova-consoleauth]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-glance-registry-clone [openstack-glance-registry]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-c openstack-cinder-volume
 Clone Set: openstack-ceilometer-notification-clone [openstack-ceilometer-notification]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-cinder-api-clone [openstack-cinder-api]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: neutron-dhcp-agent-clone [neutron-dhcp-agent]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-glance-api-clone [openstack-glance-api]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: neutron-openvswitch-agent-clone [neutron-openvswitch-agent]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-nova-novncproxy-clone [openstack-nova-novncproxy]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: delay-clone [delay]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: neutron-server-clone [neutron-server]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: httpd-clone [httpd]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-ceilometer-central-clone [openstack-ceilometer-central]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-ceilometer-alarm-evaluator-clone [openstack-ceilometer-alarm-evaluator]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: openstack-heat-api-cfn-clone [openstack-heat-api-cfn]
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 openstack-cinder-volume  (systemd:openstack-cinder-volume):  Started overcloud-controller-0
 Clone Set: openstack-nova-conductor-clone [openstack-nova-conductor] openstack-cinder-volume
     Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]

クローンセット リソースごとに、以下を確認できます。

  • Pacemaker がサービスに割り当てる名前
  • 実際のサービス名
  • サービスが起動または停止されるコントローラー

クローンセットでは、サービスはすべてのコントローラーで同じ方法を起動することを目的としています。特定のクローンサービス(haproxy サービスなど)の詳細を表示するには、pcs resource show コマンドを使用します。以下に例を示します。 

$ sudo pcs resource show haproxy-clone
 Clone: haproxy-clone
  Resource: haproxy (class=systemd type=haproxy)
   Operations: start interval=0s timeout=60s (haproxy-start-timeout-60s)
               monitor interval=60s (haproxy-monitor-interval-60s)
$ sudo systemctl status haproxy
haproxy.service - Cluster Controlled haproxy
   Loaded: loaded (/usr/lib/systemd/system/haproxy.service; disabled)
  Drop-In: /run/systemd/system/haproxy.service.d
           └─50-pacemaker.conf
   Active: active (running) since Tue 2015-10-06 08:58:49 EDT; 1h 52min ago
 Main PID: 4215 (haproxy-systemd)
   CGroup: /system.slice/haproxy.service
           ├─4215 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
           ├─4216 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
           └─4217 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds

haproxy-clone の例には、HAProxy のリソース設定が表示されます。HAProxy は、選択したサービスにトラフィックを負荷分散することで高可用性サービスを提供しますが、ここでは HAProxy 自体を高可用性を維持するには、Pacemaker のクローンサービスとして設定します。

出力から、リソースが haproxy という名前の systemd サービスであることに注意してください。また、監視間隔に加えて、開始間隔とタイムアウト値も含まれています。systemctl status コマンドは、haproxy が現在アクティブであることを示します。haproxy サービスの実際の実行中のプロセスは、出力の最後に一覧表示されます。コマンドライン全体が表示されているため、コマンドに関連付けられている設定ファイル(haproxy.cfg)と PID ファイル(haproxy.pid)が表示されます。

クローンセット リソースで同じコマンドを実行して、現在のアクティビティーレベルと、サービスが実行するコマンドの詳細を表示します。Pacemaker が制御する systemd サービスは、systemd により 無効 に設定されていることに注意してください。これは、システムの起動プロセスではなく、サービスの起動または停止を行うタイミングを制御するのではなく、Pacemaker を必要とするためです。

クローンセット リソースの詳細は、High Availability Add-On リファレンス の リソースのクローン作成 を参照してください。

マルチステートリソース（マスター/スレーブ）

Galera および Redis サービスは、Multi-state リソースとして実行します。このような 2 種類のサービスの場合、pcs status 出力は次のようになります。 

[...]
Master/Slave Set: galera-master [galera]
     Masters: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]

Master/Slave Set: redis-master [redis]
     Masters: [ overcloud-controller-2 ]
     Slaves: [ overcloud-controller-0 overcloud-controller-1 ]
[...]

galera-master リソースでは、3 つのコントローラーすべてが Galera マスターとして実行されています。redis-master リソースでは、overcloud-controller-2 がマスターとして動作し、他の 2 つのコントローラーはスレーブとして動作している。現時点では、galera サービスは 3 つのコントローラーすべてに 1 つの制約セットで実行されており、redis はマスターコントローラーとスレーブコントローラーの異なる制約を受けることができます。

Multi-State リソースの詳細は、High Availability Add-On リファレンス の Multi-State Resources: Resources That Have Multiple Modes を参照してください。

Galera リソースのトラブルシューティングについての詳しい情報は、6章Galera の使用を参照してください。

4.4. Pacemaker の Failed Actions
リンクのコピー

リソースが何らかの形で失敗した場合、pcs status の出力の Failed actions 見出しの下に一覧表示されます。httpd サービスが controller-0 で停止した例を次に示します。 

Failed actions:
    httpd_monitor_60000 on overcloud-controller-0 'not running' (7): call= openstack-cinder-volume        (systemd:openstack-cinder-volume):      Started overcloud-controller-0
190, status=complete, exit-reason='none', last-rc-change='Thu Oct  8 10:12:32 2015', queued=0ms, exec=0ms

この場合、systemd サービス httpd を再起動する必要があります。その他の場合には、問題を追跡/修正してからリソースをクリーンアップする必要があります。詳細は、「コントローラー上のリソースの問題修正」 を参照してください。

4.5. コントローラーのその他の Pacemaker 情報
リンクのコピー

pcs status 出力の最後のセクションでは、電源管理フェンシング（ここでは IPMI）と Pacemaker サービス自体のステータスが表示されます。 

 my-ipmilan-for-controller-0	(stonith:fence_ipmilan): Started my-ipmilan-for-controller-0
 my-ipmilan-for-controller-1	(stonith:fence_ipmilan): Started my-ipmilan-for-controller-1
 my-ipmilan-for-controller-2	(stonith:fence_ipmilan): Started my-ipmilan-for-controller-2

PCSD Status:
  overcloud-controller-0: Online
  overcloud-controller-1: Online
  overcloud-controller-2: Online

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled openstack-cinder-volume        (systemd:openstack-cinder-volume):      Started overcloud-controller-0

  pcsd: active/enabled

my-ipmilan-for-controller の設定では、各ノードに指定されたフェンシングの種別 (stonith:fence_ipmilan) および IPMI サービスの稼働状態が分かります。PCSD Status は、全 3 コントローラーが現在オンラインであることを示します。また、Pacemaker サービス自体には corosync、pacemaker、pcsd の 3 つのデーモンで設定されています。この例では、これら 3 つのサービスすべてがアクティブかつ有効化されています。

4.6. フェンシング用のハードウェア
リンクのコピー

コントローラーノードがヘルスチェックに失敗すると、Pacemaker 指定のコーディネーターとして機能するコントローラーは、Pacemaker stonith サービスを使用して、問題のあるノードをフェンシングします。Stonith は、Shoot the other node in the head の略です。したがって、基本的に DC はクラスターからノードを除外します。

stonith により、フェンスデバイスがどのように OpenStack Platform HA クラスターに設定されているかを確認するには、以下のコマンドを実行します。 

$ sudo pcs stonith show --full
 Resource: my-ipmilan-for-controller-0 (class=stonith type=fence_ipmilan)
  Attributes: pcmk_host_list=overcloud-controller-0 ipaddr=10.100.0.51 login=admin passwd=abc lanplus=1 cipher=3
  Operations: monitor interval=60s (my-ipmilan-for-controller-0-monitor-interval-60s)
 Resource: my-ipmilan-for-controller-1 (class=stonith type=fence_ipmilan)
  Attributes: pcmk_host_list=overcloud-controller-1 ipaddr=10.100.0.52 login=admin passwd=abc lanplus=1 cipher=3
  Operations: monitor interval=60s (my-ipmilan-for-controller-1-monitor-interval-60s)
 Resource: my-ipmilan-for-controller-2 (class=stonith type=fence_ipmilan)
  Attributes: pcmk_host_list=overcloud-controller-2 ipaddr=10.100.0.53 login=admin passwd=abc lanplus=1 cipher=3
  Operations: monitor interval=60s (my-ipmilan-for-controller-2-monitor-interval-60s)

show --full のリストには、フェンシングに関連するコントローラーノード 3 つの詳細が表示されます。フェンスデバイスは、IPMI 電源管理 (fence_ipmilan) を使用して、必要に応じてマシンの電源のオン/オフを切り替えます。各ノードの IPMI インターフェイスに関する情報には、IPMI インターフェイスの IP アドレス (10.100.0.51)、ログインするユーザー名 (admin)、使用するパスワード (abc) が含まれます。各ホストが監視される間隔も (60 秒) 確認することができます。

Pacemaker を使用したフェンシングに関する詳しい情報は、Red Hat Enterprise Linux 7 High Availability Add-On の管理の フェンシングの設定 を参照してください。

第5章 HAProxy の使用
リンクのコピー

HAProxy は、トラフィックの負荷を複数のコントローラーに分散することによって、OpenStack に高可用性機能を提供します。haproxy パッケージには、ロギング機能やサンプル設定と共に、systemd サービスから開始する haproxy デーモンが含まれています。前述のように、Pacemaker は HAProxy サービス自体を高可用性サービス(haproxy-clone)として管理します。

注記

HAProxy の設定を検証する方法については、haproxy.cfg が OpenStack のサービスをロードバランシングできるよう正しく設定されているかどうか、確認する方法はありますか ? の KCS ソリューションを参照してください。

Red Hat OpenStack Platform 8 では、director が haproxy サービスを利用するように複数の OpenStack サービスを設定します。これらのサービスを /etc/haproxy/haproxy.cfg ファイルで設定することによって行われます。そのファイル内の各サービスで、以下を確認できます。

  • listen: 要求をリッスンするサービス名
  • bind: サービスがリッスンする IP アドレスおよび TCP ポート番号
  • server: サービスを提供する各サーバー名、サーバーの IP アドレス、リッスンするポート、その他の情報

director を使用して Red Hat OpenStack Platform 8 をインストールする際に作成される haproxy.cfg ファイルは、HAProxy が管理する 19 の異なるサービスを識別します。以下は、ceilometer リッスンサービスが haproxy.cfg ファイルでどのように設定されているかの例です。 

listen ceilometer
  bind 172.16.0.10:8777
  bind 192.168.1.150:8777
  server overcloud-controller-0 172.16.0.13:8777 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:8777 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:8777 check fall 5 inter 2000 rise 2

この ceilometer サービスの HAProxy 設定の例では、ceilometer サービスが提供される IP アドレスとポートを識別します(162.10.10 および 192.168.1.150 のポート 8777)。172.16.0.10 アドレスは、オーバークラウド内で使用する内部 API ネットワーク(VLAN201)上の仮想 IP アドレスですが、192.168.1.150 の仮想 IP アドレスは外部ネットワーク(VLAN100)上にあり、オーバークラウドの外部からの API ネットワークへのアクセスを提供します。

HAProxy は、これらの 2 つのアドレスに対する要求を overcloud-controller-0 (172.16.0.13:8777)、overcloud-controller-1 (172.16.0.14:8777)、overcloud-controller-2 (172.16.0.15:8777) のいずれかに転送することができます。

これらのサーバーに設定されたオプションでは、ヘルスチェック (check) が有効になり、ヘルスチェックに 5 回失敗すると (fall 5)、サービスは停止されていると見なされます。ヘルスチェックの実行する間隔は、inter 2000 (2000 ミリ秒または 2 秒) に設定されます。また、ヘルスチェックに 2 回成功すると (rise 2)、サーバーは稼働していると見なされます。

コントローラーノードで HAProxy が管理するサービスのリストを以下に示します。

Expand
表5.1 HAProxy が管理するサービス

ceilometer

cinder

glance_api

glance_registry

haproxy.stats

heat_api

heat_cfn

heat_cloudwatch

horizon

keystone_admin

keystone_public

mysql

neutron

nova_ec2

nova_metadata

nova_novncproxy

5.1. HAProxy Stats
リンクのコピー

director により、HA デプロイメントではすべて、HAProxy Stats もデフォルトで有効になります。この機能により、データ転送、接続、サーバーの状態などについての詳細情報を HAProxy Stats のページで確認することができます。

また、director は、HAProxy Stats ページにアクセスするための IP:Port アドレスも設定します。このアドレスを確認するには、HAProxy がインストールされている任意のノードの /etc/haproxy/haproxy.cfg ファイルを開きます。listen haproxy.stats セクションにこの情報が記載されています。以下に例を示します。 

listen haproxy.stats
  bind 10.200.0.6:1993
  mode http
  stats enable
  stats uri /

この場合は、Web ブラウザーを 10.200.0.6:1993 にポイントし、HAProxy Stats ページを表示します。

5.2. 参考資料
リンクのコピー

HAProxy に関する詳しい情報は、HAProxy の設定(ロードバランサーの管理) を参照してください。

haproxy.cfg ファイルで使用できる設定の詳細は、haproxy パッケージがインストールされている任意のシステム（コントローラーノードなど）の /usr/share/doc/haproxy-VERSION/configuration.txt のドキュメントを参照してください。

第6章 Galera の使用
リンクのコピー

高可用性のデプロイメントでは、Red Hat OpenStack Platform は MariaDB Galera Cluster を使用してデータベースのレプリケーションを管理します。「Pacemaker で設定された OpenStack サービス」で説明したように、Pacemaker は、マスター/スレーブセットリソースを使用して Galera サービスを実行します。pcs status を使用して、galera-master が実行中かどうか、およびどのコントローラーで以下を実行します。 

Master/Slave Set: galera-master [galera]
     Masters: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
ホスト名の解決
MariaDB Galera Cluster のトラブルシューティングを行う場合には、まずホスト名の 解決を確認 してください。デフォルトでは、director は Galera リソースを IP アドレスではなく ホスト名 にバインドします。 [1].そのため、ホスト名の解決を妨げる問題（たとえば、間違った DNS や DNS の失敗）により、Pacemaker が Galera リソースを適切に管理できなくなる可能性があります。

ホスト名の解決の問題を除外したら、クラスター自体の整合性を確認します。そのためには、各コントローラーノード のデータベースで Write Set Replication のステータスを確認します。

Write Set Replication の情報は、各ノードの MariaDB データベースに保管されます。関連する変数はそれぞれ wsrep_ の接頭辞を使用します。そのため、データベースクライアントを介してこの情報を直接クエリーできます。 

$ sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'wsrep_%';"
    +------------------------+-------+
    | Variable_name          | Value |
    +------------------------+-------+
    | wsrep_protocol_version | 5     |
    | wsrep_last_committed   | 202   |
    | ...                    | ...   |
    | wsrep_thread_count     | 2     |
    +------------------------+-------+

MariaDB Galera Cluster の正常性と整合性を検証するには、まず最初にクラスターが正しいノード数を報告するかどうかを確認します。続いて、各ノードで以下の点を確認します。

  • 適切なクラスターに属していること
  • クラスターへの書き込みが可能であること
  • クラスターからクエリーおよび書き込みを受信できる
  • クラスター内の他のユーザーに接続されていること
  • ローカルデータベースのテーブルに Write Set をレプリケートしている

以下のセクションでは、各ステータスを調査する方法を説明します。

6.1. データベースクラスターの整合性の調査
リンクのコピー

MariaDB Galera Cluster の問題を調査する場合は、クラスター自体の整合性から始めます。クラスターの整合性を検証するには、各コントローラーノードで特定の wsrep_ データベース変数を確認する必要があります。データベースの変数を確認するには、次のコマンドを実行します。 

$ sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'VARIABLE';"

VARIABLE は、確認する wsrep_ データベース変数に置き換えます。たとえば、ノードの クラスターの状態 UUID を確認するには、以下を実行します。 

$ sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_state_uuid';"
    +--------------------------+--------------------------------------+
    | Variable_name            | Value                                |
    +--------------------------+--------------------------------------+
    | wsrep_cluster_state_uuid | e2c9a15e-5485-11e0-0800-6bbb637e7211 |
    +--------------------------+--------------------------------------+

以下の表には、クラスターの整合性に関連するさまざまな wsrep_ データベース変数をまとめています。

Expand
表6.1 クラスターの整合性を確認するためのデータベース変数
変数サマリー説明

wsrep_cluster_state_uuid

クラスターの状態の UUID

ノードが属するクラスターの ID。全ノードに全く同じ ID が割り当てられている必要があります。異なる ID が割り当てられたノードは、クラスターに接続できません。

wsrep_cluster_size

クラスター内のノード数

これは、任意のノード 1 台で確認することができます。値が実際のノード数を下回る場合には、いずれかのノードでエラーが発生したか、接続を失ったことになります。

wsrep_cluster_conf_id

クラスターの全変更回数

クラスターが複数のコンポーネント (パーティション) に分割されているかどうかを確認します。これは、ネットワークのエラーが原因となっている場合が多いです。全ノードで値が同一でなければなりません。

異なる wsrep_cluster_conf_id を報告するノードがある場合には、wsrep_cluster_status の値をチェックして、クラスター(プライマリー)にまだ書き込み可能かどうかを確認します。

wsrep_cluster_status

Primary コンポーネントのステータス

ノードがまだクラスターへの書き込みをできるかどうかを確認します。その場合には、wsrep_cluster_status は Primary である必要があります。それ以外の値の場合には、ノードが稼働していないパーティションの一部であることを示します。

6.2. データベースクラスターノードの調査
リンクのコピー

Galera クラスターの問題を特定のノードに切り分けることができる場合には、その他の wsrep_ データベース変数が、特定の問題に対応できる可能性があります。これらの変数は、(「データベースクラスターの整合性の調査」 のように)クラスターチェックと同様の方法で確認することができます。 

$ sudo mysql -B -e "SHOW GLOBAL STATUS LIKE 'VARIABLE';"

同様に、VARIABLE を次のいずれかの値に置き換えます。

Expand
表6.2 ノードの整合性を確認するためのデータベース変数
変数サマリー説明

wsrep_ready

ノードがクエリーを受け入れる機能

ノードがクラスターから Write Set を受け入れることができるかどうかを示します。その場合には、wsrep_ready は ON のはずです。

wsrep_connected

ノードのネットワーク接続性

そのノードが他のノードに接続されているかどうかを示します。その場合には、wsrep_connected は ON のはずです。

wsrep_local_state_comment

ノードの状態

ノードの状態の概要を示します。ノードがクラスターにまだ書き込み可能であれば( wsrep_cluster_status が Primary の場合、「データベースクラスターの整合性の調査」を参照)、wsrep_local_state_comment の一般的な値は Joining on SST、Joined、Synced、または Donor です。

ノードが稼働していないコンポーネントの一部の場合には、wsrep_local_state_comment は Initialized に設定されます。

注記

wsrep_connected of ON は、ノードが 一部 のノードにのみ接続されていることを意味します。たとえば、クラスターのパーティションの場合には、そのノードは、クラスターに書き込みができないコンポーネントの一部となっている可能性があります。詳細は、「データベースクラスターの整合性の調査」 を参照してください。

wsrep_connected が OFF の場合、ノードは ANY クラスターコンポーネントに接続されていません。

6.3. データベースレプリケーションのパフォーマンスの調査
リンクのコピー

クラスターとその個々のノードがすべて正常で安定している場合、レプリケーションのスループットを確認してパフォーマンスをベンチマークすることもできます。] および xref:galera-cluster[ と同様に、これには、各ノードで wsrep_ データベース変数が含まれます。 

$ sudo mysql -B -e "SHOW STATUS LIKE 'VARIABLE';"

同様に、VARIABLE を次のいずれかの値に置き換えます。

Expand
表6.3 クラスターのパフォーマンス (レプリケーションのスループット) を確認するためのデータベース変数
変数サマリー

wsrep_local_recv_queue_avg

最後にクエリーされた後のローカル受信キューの平均サイズ

wsrep_local_send_queue_avg

その変数が最後にクエリーされた後の送信キューの平均の長さ

wsrep_local_recv_queue_min および wsrep_local_recv_queue_max

いずれかの変数が最後にクエリーされた後のローカル受信キューの最小サイズと最大サイズ

wsrep_flow_control_paused

その変数が最後にクエリーされた後に フロー制御 が原因でノードが一時停止された時間の割合

wsrep_cert_deps_distance

並行して適用することのできるシーケンス番号(seqno)の最小値と最大値の間の平均距離（つまり、潜在的な並列化度）

これらの変数のいずれかをクエリーするたびに、FLUSH STATUS コマンドはその値をリセットします。クラスターのレプリケーションのベンチマークを行うには、それらの値を複数回クエリーして、その変化を確認する必要があります。この変化は、フロー制御 がクラスターのパフォーマンスにどの程度影響を及ぼしているかを判断するのに役立てることができます。

Flow Control は、クラスターがレプリケーションを管理するために使用するメカニズムです。ローカル受信 Write Set キューが一定の閾値を超えると、ノードがそのキューに追い付くために、フロー制御がレプリケーションを一時停止します。詳しくは、Galera Cluster のサイトで、Flow Control のセクションを参照してください。

さまざまな値とベンチマークの clues については、以下の表を確認してください。

wsrep_local_recv_queue_avg > 0.0
ノードは受信速度で Write Set を適用できないため、レプリケーションスロットリング をトリガーします。このベンチマークの詳しい情報は、wsrep_local_recv_queue_min と wsrep_local_recv_queue_max を確認してください。
wsrep_local_send_queue_avg > 0.0
wsrep_local_send_queue_avg の値が高くなるため、レプリケーションのスロットルおよびネットワークのスループットの問題が発生する可能性があります。これは特に wsrep_local_recv_queue_avg が上昇すると特に当てはまります。
wsrep_flow_control_paused > 0.0

フロー制御によりノードが一時停止されています。ノードが一時停止された時間を確認するには、wsrep_flow_control_paused の値をクエリー間の秒数で乗算します。たとえば、最後のチェックから 1 分後に wsrep_flow_control_paused = 0.50 の場合に、ノードのレプリケーションは 30 秒間一時停止されました。wsrep_flow_control_paused = 1.0 の場合、最後のクエリー以降は、ノードは一時停止されました。

理想的には、wsrep_flow_control_paused は可能な限り 0.0 に近い値でなければなりません。

スロットリングと一時停止の場合には、wsrep_cert_deps_distance をチェックして、（平均で）適用することのできる Write Set の数を確認することができます。次に、wsrep_slave_threads をチェックして、同時に適用することのできる Write Set の数を確認します。

wsrep_slave_threads を高く設定すると、スロットリングと一時停止を軽減するのに役立ちます。たとえば、wsrep_cert_deps_distance は 20 を読み取ると、wsrep_slave_threads を 2 から 4 の 2 倍にすると、ノードが適用できる Write Set の量も 2 倍になります。ただし、wsrep_slave_threads は、ノードの CPU コア数としてのみ高く設定する必要があります。

問題のあるノードの wsrep_slave_threads がすでに最適設定である場合、接続性の問題を調査する際に、ノードをクラスターから除外することを検討してください。


[1] このメソッドは、IPv6 を使用するオーバークラウドで Galera が正常に起動できるようにするために実装されました (詳しくは、BZ#1298671 を参照してください)。

第7章 HA コントローラーリソースの調査と修正
リンクのコピー

pcs constraint show コマンドは、サービスの起動方法に関する制約を表示します。このコマンドの出力には、各リソースの場所、起動順序、および配置する必要があるものに関連する制約が表示されます。問題がある場合には、これらの問題を修正してから、リソースをクリーンアップします。

pcs constraint show コマンドは、リソースがロケーションによって制約されるか（特定のホストでのみ実行可能）、順序付け（開始前に有効にする他のリソースによる依存）、またはコロケーション（別のリソースでコロケーションする必要がある）を示します。ここでは、コントローラーノード上で pcs constraint show の出力が切り捨てられています。 

$ sudo pcs constraint show
Location Constraints:
  Resource: my-ipmilan-for-controller-0
    Disabled on: overcloud-controller-0 (score:-INFINITY)
  Resource: my-ipmilan-for-controller-1
    Disabled on: overcloud-controller-1 (score:-INFINITY)
  Resource: my-ipmilan-for-controller-2
    Disabled on: overcloud-controller-2 (score:-INFINITY)
Ordering Constraints:
  start ip-172.16.0.10 then start haproxy-clone (kind:Optional)
  start ip-10.200.0.6 then start haproxy-clone (kind:Optional)
  start ip-172.19.0.10 then start haproxy-clone (kind:Optional)
  start ip-192.168.1.150 then start haproxy-clone (kind:Optional)
  start ip-172.16.0.11 then start haproxy-clone (kind:Optional)
  start ip-172.18.0.10 then start haproxy-clone (kind:Optional)
  start mongod-clone then start openstack-ceilometer-central-clone (kind:Mandatory)
  start openstack-glance-registry-clone then start openstack-glance-api-clone (kind:Mandatory)
  start openstack-heat-api-clone then start openstack-heat-api-cfn-clone (kind:Mandatory)
  start delay-clone then start openstack-ceilometer-alarm-evaluator-clone (kind:Mandatory)

...

Colocation Constraints:
  ip-172.16.0.10 with haproxy-clone (score:INFINITY)
  ip-172.18.0.10 with haproxy-clone (score:INFINITY)
  ip-10.200.0.6 with haproxy-clone (score:INFINITY)
  ip-172.19.0.10 with haproxy-clone (score:INFINITY)
  ip-172.16.0.11 with haproxy-clone (score:INFINITY)
  ip-192.168.1.150 with haproxy-clone (score:INFINITY)
  openstack-glance-api-clone with openstack-glance-registry-clone (score:INFINITY)
  openstack-cinder-volume with openstack-cinder-scheduler-clone (score:INFINITY)
  neutron-dhcp-agent-clone with neutron-openvswitch-agent-clone (score:INFINITY)

...

この出力には、3 つの主要なセクションが表示されます。

場所の制約
このセクションには、リソースの割り当て場所に関する特定の制約はありません。ただし、出力は、各コントローラーで ipmilan リソースが無効化されていることを示しています。そのため、さらなる調査が必要となります。
Ordering Constraints
ここでは、仮想 IP アドレスリソース(IPaddr2)が HAProxy より前に起動するように設定されていることに注意してください。また、openstack-ceilometer-central-clone の前の mongod-clone の開始や、openstack-glance-api-clone の前に openstack-glance-registry-clone を起動するなど、必須の順序制約も多数あります。これらの制約を把握すると、サービス間の依存関係を把握するのに役立ちます。つまり、壊れたサービスまたは別のリソースを修正できるようにするために、どのような依存関係が存在するべきかを把握します。
Colocation Constraints
このセクションでは、どのリソースを一緒に配置する必要があるかを示します。たとえば、特定の仮想 IP アドレスは haproxy-clone リソースに関連付けられます。さらに、openstack-glance-api-clone リソースは、openstack-glance-registry-clone リソースと同じホストに配置する必要があります。

7.1. コントローラー上のリソースの問題修正
リンクのコピー

失敗したアクションは pcs status コマンドで一覧表示されます。多くの異なる問題が発生する可能性があります。一般的には、以下の方法で問題に対処することができます。

コントローラーの問題

コントローラーのヘルスチェックでエラーが発生した場合には、そのコントローラーにログインしてサービスが問題なく起動できるかどうかを確認してください。サービスの起動で問題がある場合には、コントローラー間での通信の問題がある可能性があることになります。コントローラー間の通信問題のその他の兆候には、以下が含まれます。

  • 1 台のコントローラーが他のコントローラーよりも過度にフェンシングされる
  • 特定のコントローラーから、不審な大量のサービスでエラーが発生している
個別のリソースの問題
コントローラーからのサービスが一般的に機能していますが、個別のリソースに障害が発生している場合は、pcs status メッセージで問題を特定できるかどうかを確認します。さらに情報が必要な場合には、リソースの問題があるコントローラーにログインして、以下のステップのいくつか試してください。

個別の失敗したリソースに関する問題を確認するには、 に記載の Ordering Constraints を参照してください。障害が発生したリソースが依存するすべてのリソースが稼働していることを確認します。その後、下からやり方で修正し、修正します。

障害が発生したリソースとそれが実行されているコントローラーの名前と、コントローラーにログインして問題をデバッグできます。障害が発生したリソースが systemd サービス( openstack-ceilometer-apiなど)の場合は、systemctl を使用してそのステータスを確認し、journalctl を使用してジャーナルメッセージを検索することができます。以下に例を示します。 

$ sudo systemctl status openstack-ceilometer-api
openstack-ceilometer-api.service - Cluster Controlled openstack-ceilometer-api
   Loaded: loaded (/usr/lib/systemd/system/openstack-ceilometer-api.service; disabled)
  Drop-In: /run/systemd/system/openstack-ceilometer-api.service.d
           └─50-pacemaker.conf
   Active: active (running) since Thu 2015-10-08 13:30:44 EDT; 1h 4min ago
 Main PID: 17865 (ceilometer-api)
   CGroup: /system.slice/openstack-ceilometer-api.service
           └─17865 /usr/bin/python /usr/bin/ceilometer-api --logfile /var/log/ceilometer/api.log

Oct 08 13:30:44 overcloud-controller-2.localdomain systemd[1]: Starting Cluster Controlled openstack-ceilo.....
Oct 08 13:30:44 overcloud-controller-2.localdomain systemd[1]: Started Cluster Controlled openstack-ceilom...i.
Oct 08 13:30:49 overcloud-controller-2.localdomain ceilometer-api[17865]: /usr/lib64/python2.7/site-package....
$ sudo journalctl -u openstack-ceilometer-api
-- Logs begin at Thu 2015-10-01 08:57:25 EDT, end at Thu 2015-10-08 14:40:18 EDT. --
Oct 01 11:22:41 overcloud-controller-2.localdomain systemd[1]: Starting Cluster Controlled openstack...
Oct 01 11:22:41 overcloud-controller-2.localdomain systemd[1]: Started Cluster Controlled openstack-ceilometer-api...
Oct 01 11:22:52 overcloud-controller-2.localdomain ceilometer-api[8918]: /usr/lib64/python2.7/...

障害が発生したリソースを修正したら、pcs resource cleanup コマンドを実行して、リソースのステータスとその失敗数をリセットできます。たとえば、httpd-clone リソースの問題を特定して修正したら、次を実行します。 

$ sudo pcs resource cleanup httpd-clone
  Resource: httpd-clone successfully cleaned up

第8章 HA Ceph ノードの調査
リンクのコピー

Ceph Storage を使用してデプロイする場合、Red Hat OpenStack Platform 8 は Ceph クラスターのモニターデーモンとして ceph-mon を使用します。director はこのデーモンを全コントローラーノードにデプロイします。

Ceph のモニタリングサービスが稼働中であるかを確認するには、以下のコマンドを実行してください。 

$ sudo service ceph status
=== mon.overcloud-controller-0 ===
mon.overcloud-controller-0: running {"version":"0.94.1"}

コントローラーおよび Ceph ノードでは、/etc/ceph/ceph.conf ファイルを表示して Ceph がどのように設定されているかを確認できます。以下に例を示します。 

[global]
osd_pool_default_pgp_num = 128
osd_pool_default_min_size = 1
auth_service_required = cephx
mon_initial_members = overcloud-controller-0,overcloud-controller-1,overcloud-controller-2
fsid = 8c835acc-6838-11e5-bb96-2cc260178a92
cluster_network = 172.19.0.11/24
auth_supported = cephx
auth_cluster_required = cephx
mon_host = 172.18.0.17,172.18.0.15,172.18.0.16
auth_client_required = cephx
osd_pool_default_size = 3
osd_pool_default_pg_num = 128
public_network = 172.18.0.17/24

この例では、3 台のコントローラーノード (overcloud-controller-0、-1、-2) がすべて Ceph クラスター (mon_initial_members) を監視するように設定されています。172.19.0.11/24 ネットワーク (VLAN 203) はストレージ管理ネットワークとして使用され、コントローラーと Ceph Storage ノード間の通信パスを提供します。これら 3 つの Ceph Storage ノードは、別のネットワーク上にあります。上記の例からもわかるように、これら 3 つのノードの IP アドレスは、ストレージネットワーク (VLAN 202) 上にあり、172.18.0.15、172.18.0.16、172.18.0.17 として定義されています。

Ceph ノードの現在のステータスを確認するには、ノードにログインして以下のコマンドを実行します。 

# ceph -s
    cluster 8c835acc-6838-11e5-bb96-2cc260178a92
     health HEALTH_OK
     monmap e1: 3 mons at {overcloud-controller-0=172.18.0.17:6789/0,overcloud-controller-1=172.18.0.15:6789/0,overcloud-controller-2=172.18.0.16:6789/0}
            election epoch 152, quorum 0,1,2 overcloud-controller-1,overcloud-controller-2,overcloud-controller-0
     osdmap e543: 6 osds: 6 up, 6 in
      pgmap v1736: 256 pgs, 4 pools, 0 bytes data, 0 objects
            267 MB used, 119 GB / 119 GB avail
                 256 active+clean

ceph -s の出力から、Ceph クラスターの正常性に問題がないことがわかります(HEALTH_OK)。Ceph モニターサービスが 3 つあります(3 つの overcloud-controller ノードで実行)。また、それぞれがリッスンする IP アドレスとポートも表示されています。

Red Hat Ceph Storage に関する詳しい情報は、Red Hat Ceph Storage の製品ページ を参照してください。

第9章 HA コンピュートノードの調査
リンクのコピー

コンピュートノードに障害が発生すると、Pacemaker はそのノード上で失敗したサービスの再起動を試みます。これには、neutron-ovs-agent を起動し、次に ceilometer-compute を起動し、最後に nova-compute することが含まれます。Swift ACO ノードから障害が発生した場合、Swift サービスの再起動の試行は swift-fs、swift-object、swift-container、および swift-account の順序で行われます。これらのサービスの開始に失敗した場合、Pacemaker はコンピュートノードをフェンスします。

付録A Red Hat OpenStack Platform 8 HA 環境の構築
リンクのコピー

オーバークラウド 向けの Red Hat Ceph Storage には、 本ガイドに記載の種別の高可用性 OpenStack 環境をデプロイする手順が記載されています。また、director のインストールと使用 ガイド は、プロセス全体で参照するためにも使用されます。

A.1. ハードウェアの仕様
リンクのコピー

以下の表には、本ガイドで検証するデプロイメントに使う仕様をまとめています。より良い結果を出すには、お使いのテストデプロイメントで CPU、メモリー、ストレージ、NIC を増やしてください。

Expand
表A.1 物理コンピューター
コンピューターの台数割り当てられた用途CPU の数メモリー容量ディスク容量電源管理NIC の数

1

director ノード

4

6144 MB

40 GB

IPMI

2 (外部 x 1、プロビジョニング x 1) + 1 IPMI

3

コントローラーノード

4

6144 MB

40 GB

IPMI

3 (オーバークラウド上のボンディング x 2、プロビジョニング x 1) + 1 IPMI

3

Ceph Storage ノード

4

6144 MB

40 GB

IPMI

3 (オーバークラウド上のボンディング x 2、プロビジョニング x 1) + 1 IPMI

2

コンピュートノード (必要に応じて追加)

4

6144 MB

40 GB

IPMI

3 (オーバークラウド上のボンディング x 2、プロビジョニング x 1) + 1 IPMI

以下のリストでは、director 以外に割り当てられているノードに関連付けられた一般的な機能と接続について説明します。

コントローラーノード
ストレージ以外の OpenStack サービスの多くは、コントローラーノード上で稼働します。全サービスは、この 3 つのノードで複製されます (Active/Active や Active/Passive)。3 つのノードには、信頼性の高い HA が必要です。
Ceph Storage ノード
ストレージサービスは Ceph Storage ノードで稼働して、Ceph Storage 領域プールをコンピュートノードに提供します。この場合も、3 つのノードには、HA を指定する必要があります。
コンピュートノード
仮想マシンは、実際にはコンピュートノードで稼働します。コンピュートノードのシャットダウンやノード間の仮想マシンの移行機能など、キャパシティー要件を満たすのに必要とされる数のコンピュートノードを指定することができます。仮想マシンがストレージにアクセスできるようにするには、コンピュートノードをストレージネットワークに接続する必要があります。また、仮想マシンが他のコンピュートノード上の仮想マシンやパブリックネットワークにアクセスしてサービスを利用できるようするには、コンピュートノードをテナントネットワークに接続する必要があります。
Expand
表A.2 物理および仮想ネットワーク
物理 NICネットワークの理由VLAN用途

eth0

プロビジョニングネットワーク (アンダークラウド)

該当なし

director からの全ノードの管理 (アンダークラウド)

eth1 および eth2

コントローラー/外部 (オーバークラウド)

該当なし

VLAN を使用したボンディング NIC

 

外部ネットワーク

VLAN 100

外部環境からテナントネットワーク、内部 API、OpenStack Horizon Dashboard へのアクセスの許可

 

Internal API

VLAN 201

コンピュートノードとコントローラーノード間の内部 API へのアクセス提供

 

ストレージアクセス

VLAN 202

コンピュートノードと下層のストレージメディアとの接続

 

ストレージ管理

VLAN 203

ストレージメディアの管理

 

テナントネットワーク

VLAN 204

OpenStack に対するテナントネットワークの提供

以下のハードウェアも必要です。

プロビジョニングネットワーク用のスイッチ
このスイッチは、director システム（アンダークラウド）を Red Hat OpenStack Platform 8 環境（オーバークラウド）内の全コンピューターに接続できる必要があります。このスイッチに接続されている、各オーバークラウドノードの NIC は、director から PXE ブートできなければなりません。また、スイッチの portfast が有効に設定されていることを確認してください。
コントローラー/外部ネットワーク用のスイッチ
このスイッチは、図 1 に示した VLAN 用に VLAN タグ付けをするように設定する必要があります。外部ネットワークには、VLAN 100 のトラフィックのみを許可すべきです。
フェンシング用のハードウェア
この設定では、Pacemaker とともに使用するように定義されたハードウェアがサポートされています。対応フェンシングデバイスは、Pacemaker ツールの stonith を使用して判断できます。詳細は、director の インストールと使用 ガイドの コントローラーノードのフェンシング を参照してください。

A.2. アンダークラウドの設定ファイル
リンクのコピー

本項には、本ガイドで使用しているテスト設定の関連する設定ファイルを記載します。IP アドレス範囲を変更する場合は、作成されるアドレス設定を追跡するために 図1.1「director を使用してデプロイした OpenStack HA 環境」 のような図を作成することを検討してください。

instackenv.json

{
      "nodes": [
        {
          "pm_password": "testpass",
          "memory": "6144",
          "pm_addr": "10.100.0.11",
          "mac": [
            "2c:c2:60:3b:b3:94"
          ],
          "pm_type": "pxe_ipmitool",
          "disk": "40",
          "arch": "x86_64",
          "cpu": "1",
          "pm_user": "admin"
        },
        {
          "pm_password": "testpass",
          "memory": "6144",
          "pm_addr": "10.100.0.12",
          "mac": [
            "2c:c2:60:51:b7:fb"
          ],
          "pm_type": "pxe_ipmitool",
          "disk": "40",
          "arch": "x86_64",
          "cpu": "1",
          "pm_user": "admin"
        },
        {
          "pm_password": "testpass",
          "memory": "6144",
          "pm_addr": "10.100.0.13",
          "mac": [
            "2c:c2:60:76:ce:a5"
          ],
          "pm_type": "pxe_ipmitool",
          "disk": "40",
          "arch": "x86_64",
          "cpu": "1",
          "pm_user": "admin"
        },
        {
          "pm_password": "testpass",
          "memory": "6144",
          "pm_addr": "10.100.0.51",
          "mac": [
            "2c:c2:60:08:b1:e2"
          ],
          "pm_type": "pxe_ipmitool",
          "disk": "40",
          "arch": "x86_64",
          "cpu": "1",
          "pm_user": "admin"
        },
        {
          "pm_password": "testpass",
          "memory": "6144",
          "pm_addr": "10.100.0.52",
          "mac": [
            "2c:c2:60:20:a1:9e"
          ],
          "pm_type": "pxe_ipmitool",
          "disk": "40",
          "arch": "x86_64",
          "cpu": "1",
          "pm_user": "admin"
        },
        {
          "pm_password": "testpass",
          "memory": "6144",
          "pm_addr": "10.100.0.53",
          "mac": [
            "2c:c2:60:58:10:33"
          ],
          "pm_type": "pxe_ipmitool",
          "disk": "40",
          "arch": "x86_64",
          "cpu": "1",
          "pm_user": "admin"
        },
        {
          "pm_password": "testpass",
          "memory": "6144",
          "pm_addr": "10.100.0.101",
          "mac": [
            "2c:c2:60:31:a9:55"
          ],
          "pm_type": "pxe_ipmitool",
          "disk": "40",
          "arch": "x86_64",
          "cpu": "2",
          "pm_user": "admin"
        },
        {
          "pm_password": "testpass",
          "memory": "6144",
          "pm_addr": "10.100.0.102",
          "mac": [
            "2c:c2:60:0d:e7:d1"
          ],
          "pm_type": "pxe_ipmitool",
          "disk": "40",
          "arch": "x86_64",
          "cpu": "2",
          "pm_user": "admin"
         }
      ],
      "overcloud": {"password": "7adbbbeedc5b7a07ba1917e1b3b228334f9a2d4e",
      "endpoint": "http://192.168.1.150:5000/v2.0/"
                   }
}

undercloud.conf

[DEFAULT]
image_path = /home/stack/images
local_ip = 10.200.0.1/24
undercloud_public_vip = 10.200.0.2
undercloud_admin_vip = 10.200.0.3
undercloud_service_certificate = /etc/pki/instack-certs/undercloud.pem
local_interface = eth0
masquerade_network = 10.200.0.0/24
dhcp_start = 10.200.0.5
dhcp_end = 10.200.0.24
network_cidr = 10.200.0.0/24
network_gateway = 10.200.0.1
#discovery_interface = br-ctlplane
discovery_iprange = 10.200.0.150,10.200.0.200
discovery_runbench = 1
undercloud_admin_password = testpass
...

network-environment.yaml

resource_registry:
  OS::TripleO::BlockStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/cinder-storage.yaml
  OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml
  OS::TripleO::ObjectStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/swift-storage.yaml
  OS::TripleO::CephStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/ceph-storage.yaml

parameter_defaults:
  InternalApiNetCidr: 172.16.0.0/24
  TenantNetCidr: 172.17.0.0/24
  StorageNetCidr: 172.18.0.0/24
  StorageMgmtNetCidr: 172.19.0.0/24
  ExternalNetCidr: 192.168.1.0/24
  InternalApiAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}]
  TenantAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}]
  StorageAllocationPools: [{'start': '172.18.0.10', 'end': '172.18.0.200'}]
  StorageMgmtAllocationPools: [{'start': '172.19.0.10', 'end': '172.19.0.200'}]
  # Leave room for floating IPs in the External allocation pool
  ExternalAllocationPools: [{'start': '192.168.1.150', 'end': '192.168.1.199'}]
  InternalApiNetworkVlanID: 201
  StorageNetworkVlanID: 202
  StorageMgmtNetworkVlanID: 203
  TenantNetworkVlanID: 204
  ExternalNetworkVlanID: 100
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 192.168.1.1
  # Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: "''"
  # Customize bonding options if required
  BondInterfaceOvsOptions:
    "bond_mode=active-backup lacp=off other_config:bond-miimon-interval=100"

A.3. オーバークラウドの設定ファイル
リンクのコピー

以下の設定ファイルは、本ガイドで使用しているデプロイメントの実際にオーバークラウドの設定を反映しています。

/etc/haproxy/haproxy.cfg （コントローラーノード）

このファイルは、HAProxy が管理するサービスを特定します。これには、HAProxy によってモニタリングされるサービスを定義する設定が記載されています。このファイルは、コントローラーノード上に存在し、全コントローラーノードで同じ内容となります。 

# This file managed by Puppet
global
  daemon
  group  haproxy
  log  /dev/log local0
  maxconn  10000
  pidfile  /var/run/haproxy.pid
  user  haproxy

defaults
  log  global
  mode  tcp
  option  tcpka
  option  tcplog
  retries  3
  timeout  http-request 10s
  timeout  queue 1m
  timeout  connect 10s
  timeout  client 1m
  timeout  server 1m
  timeout  check 10s

listen ceilometer
  bind 172.16.0.10:8777
  bind 192.168.1.150:8777
  server overcloud-controller-0 172.16.0.13:8777 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:8777 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:8777 check fall 5 inter 2000 rise 2

listen cinder
  bind 172.16.0.10:8776
  bind 192.168.1.150:8776
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:8776 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:8776 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:8776 check fall 5 inter 2000 rise 2

listen glance_api
  bind 172.18.0.10:9292
  bind 192.168.1.150:9292
  option httpchk GET /
  server overcloud-controller-0 172.18.0.17:9292 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.18.0.15:9292 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.18.0.16:9292 check fall 5 inter 2000 rise 2

listen glance_registry
  bind 172.16.0.10:9191
  server overcloud-controller-0 172.16.0.13:9191 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:9191 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:9191 check fall 5 inter 2000 rise 2

listen haproxy.stats
  bind 10.200.0.6:1993
  mode http
  stats enable
  stats uri /

listen heat_api
  bind 172.16.0.10:8004
  bind 192.168.1.150:8004
  mode http
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:8004 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:8004 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:8004 check fall 5 inter 2000 rise 2

listen heat_cfn
  bind 172.16.0.10:8000
  bind 192.168.1.150:8000
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:8000 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:8000 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:8000 check fall 5 inter 2000 rise 2

listen heat_cloudwatch
  bind 172.16.0.10:8003
  bind 192.168.1.150:8003
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:8003 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:8003 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:8003 check fall 5 inter 2000 rise 2

listen horizon
  bind 172.16.0.10:80
  bind 192.168.1.150:80
  cookie SERVERID insert indirect nocache
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:80 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:80 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:80 check fall 5 inter 2000 rise 2

listen keystone_admin
  bind 172.16.0.10:35357
  bind 192.168.1.150:35357
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:35357 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:35357 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:35357 check fall 5 inter 2000 rise 2

listen keystone_public
  bind 172.16.0.10:5000
  bind 192.168.1.150:5000
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:5000 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:5000 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:5000 check fall 5 inter 2000 rise 2

listen mysql
  bind 172.16.0.10:3306
  option httpchk
  stick on dst
  stick-table type ip size 1000
  timeout client 0
  timeout server 0
  server overcloud-controller-0 172.16.0.13:3306 backup check fall 5 inter 2000 on-marked-down shutdown-sessions port 9200 rise 2
  server overcloud-controller-1 172.16.0.14:3306 backup check fall 5 inter 2000 on-marked-down shutdown-sessions port 9200 rise 2
  server overcloud-controller-2 172.16.0.15:3306 backup check fall 5 inter 2000 on-marked-down shutdown-sessions port 9200 rise 2

listen neutron
  bind 172.16.0.10:9696
  bind 192.168.1.150:9696
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:9696 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:9696 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:9696 check fall 5 inter 2000 rise 2

listen nova_ec2
  bind 172.16.0.10:8773
  bind 192.168.1.150:8773
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:8773 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:8773 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:8773 check fall 5 inter 2000 rise 2

listen nova_metadata
  bind 172.16.0.10:8775
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:8775 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:8775 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:8775 check fall 5 inter 2000 rise 2

listen nova_novncproxy
  bind 172.16.0.10:6080
  bind 192.168.1.150:6080
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:6080 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:6080 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:6080 check fall 5 inter 2000 rise 2

listen nova_osapi
  bind 172.16.0.10:8774
  bind 192.168.1.150:8774
  option httpchk GET /
  server overcloud-controller-0 172.16.0.13:8774 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:8774 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:8774 check fall 5 inter 2000 rise 2

listen redis
  bind 172.16.0.11:6379
  balance first
  option tcp-check
  tcp-check send info\ replication\r\n
  tcp-check expect string role:master
  timeout client 0
  timeout server 0
  server overcloud-controller-0 172.16.0.13:6379 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.0.14:6379 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.0.15:6379 check fall 5 inter 2000 rise 2

listen swift_proxy_server
  bind 172.18.0.10:8080
  bind 192.168.1.150:8080
  option httpchk GET /info
  server overcloud-controller-0 172.18.0.17:8080 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.18.0.15:8080 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.18.0.16:8080 check fall 5 inter 2000 rise 2

/etc/corosync/corosync.conf ファイル (コントローラーノード)

このファイルは、クラスターのインフラストラクチャーを定義し、すべてのコントローラーノード上で利用することができます。 

totem {
version: 2
secauth: off
cluster_name: tripleo_cluster
transport: udpu
}

nodelist {
  node {
        ring0_addr: overcloud-controller-0
        nodeid: 1
       }
  node {
        ring0_addr: overcloud-controller-1
        nodeid: 2
       }
  node {
        ring0_addr: overcloud-controller-2
        nodeid: 3
       }
}

quorum {
provider: corosync_votequorum

}

logging {
to_syslog: yes
}

/etc/ceph/ceph.conf (Ceph ノード)

このファイルには、Ceph の高可用性設定が記載されています。これには、モニタリングするホストにホスト名、IP アドレスが含まれます。 

[global]
osd_pool_default_pgp_num = 128
osd_pool_default_min_size = 1
auth_service_required = cephx
mon_initial_members = overcloud-controller-0,overcloud-controller-1,overcloud-controller-2
fsid = 8c835acc-6838-11e5-bb96-2cc260178a92
cluster_network = 172.19.0.11/24
auth_supported = cephx
auth_cluster_required = cephx
mon_host = 172.18.0.17,172.18.0.15,172.18.0.16
auth_client_required = cephx
osd_pool_default_size = 3
osd_pool_default_pg_num = 128
public_network = 172.18.0.17/24

法律上の通知
リンクのコピー

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る