Menu Close

Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

第7章 OpenDaylight での高可用性とクラスタリング

Red Hat OpenStack Platform 13 は、neutron と OpenDaylight コントローラーの両方で高可用性クラスタリングをサポートしています。以下の表には、高可用性クラスターを実行する場合の推奨アーキテクチャーをまとめています。

ノード種別ノード数ノードのモード

Neutron

3

active/active/active

OpenDaylight

3

active/active/active

コンピュートノード (nova または OVS)

任意

 

OpenDaylight のロールはコンポーザブルなので、neutron のノードと同じノードまたは別のノードにデプロイすることができます。設定はすべてアクティブモードです。全ノードが要求を処理できます。要求を受信したノードが処理できない場合には、そのノードが別の適切なノードに要求を転送します。全ノードが相互に同期します。Open_vSwitch Database (OVSDB) スキーマのサウスバウンドでは、利用可能なコントローラーノードが Open vSwitch を共有し、各スイッチはクラスター内の特定のノードによって処理されます。

7.1. 高可用性とクラスタリング向けの OpenDaylight の設定

Red Hat OpenStack Platform director は OpenDaylight コントローラーノードをデプロイするので、OpenDaylight のクラスタリングを設定するために必要な全情報を持っています。OpenDaylight の各ノードには、ノードの ロール (クラスター内での名前) を特定して、クラスター内の他のノード (シード ノード) の少なくとも一部を一覧表示した akka.conf 設定ファイルが必要です。ノードには、クラスター内でのデータの複製方法を記述した module-shards.conf ファイルも必要です。Red Hat OpenStack Platform director は、選択したデプロイメントの構成に基づいて適切に設定を行います。akka.conf ファイルはノードに依存する一方、module-shards.conf ファイルはノードとインストールされているデータストア (ならびにそのインストールされた機能。その大部分を制御します) に依存します。

akka.conf のサンプルファイル:

$ docker exec -it opendaylight_api cat /var/lib/kolla/config_files/src/opt/opendaylight/configuration/initial/akka.conf


odl-cluster-data {
  akka {
    remote {
      netty.tcp {
        hostname = "192.0.2.1"
      }
    },
    cluster {
      seed-nodes = [
        "akka.tcp://opendaylight-cluster-data@192.0.2.1:2550",
        "akka.tcp://opendaylight-cluster-data@192.0.2.2:2550",
        "akka.tcp://opendaylight-cluster-data@192.0.2.3:2550"],
      roles = [ "member-1" ]
    }
  }
}

上記のノードの例は シードノード です。これらは、現在のクラスター設定全体を反映する必要はありません。シードノードのリストを使用して現在のクラスター内の実ノードの 1 つが到達可能な限り、起動するノードはクラスターに参加することができます。設定ファイルでは、IP アドレスの代わりに名前を使用することができます。

7.2. クラスターの動作

クラスターは、動的に定義されないので、自動調整は行いません。新しいノードを起動して、その新しいノードのみを設定し、既存のクラスターに接続することはできません。クラスターは、クラスター管理の RPC を使用して、ノードの追加と削除について通知を受ける必要があります。

クラスターはリーダー/フォロワーモデルです。アクティブなノードの 1 つがリーダーとして選択され、残りのアクティブなノードがフォロワーになります。クラスターは、Raft のコンセンサスをベースとするモデルに従って永続化を処理します。この原則に従って、クラスター内のノードの過半数が同意した場合に限り、1 つのトランザクションがコミットされます。

OpenDaylight では、ノードがクラスターとの接続を失った場合には、ローカルのトランザクションは先に進められなくなります。最終的には、タイムアウトして (デフォルトでは 10 分)、フロントエンドのアクターが停止します。これらはすべてシャードごとに適用されるので、シャードによって異なるリーダーを持つことができます。この動作により、以下のいずれかの状況となります。

  • 通信がない状態が 10 分未満の場合には、マイノリティーノードがマジョリティーリーダーに再接続します。全トランザクションがロールバックされ、大半のトランザクションは再生されます。
  • 通信がない状態が 10 分以上の場合には、マイノリティーノードが稼働停止し、ログに情報を記録します。それでも、読み取り専用の要求は完了するはずですが、変更は永続されず、ノードは自律的にクラスターに再度参加できません。

これは、ユーザーがノードをモニタリングする必要があることを意味します。ユーザーは、可用性とクラスターの同期をチェックして、同期されていない時間が長すぎる場合には、それらのノードを再起動します。ユーザーは Jolokia REST サービスを使用して、ノードをモニタリングできます。詳しくは、「Jolokia のモニタリング」を参照してください。

7.3. クラスターの要件

ボンディングや MTU などで、クラスターをサポートするために特定のネットワーク要件はありません。クラスターの通信は、高レイテンシーをサポートしていませんが、データセンターレベルのレイテンシーは受容可能です。

7.4. Open vSwitch の設定

各スイッチは、Red Hat OpenStack Platform director によりすべてのコントローラーで自動設定されます。OVSDB は、クラスターノード内のスイッチ共有をサポートして、一定レベルのロードバランシングを可能にします。ただし、各スイッチはクラスター内の全ノードに連絡して、最初に応答があったノードを選択し、そのノードをデフォルトでマスタースイッチにします。この動作により、コントローラーに割り当てられたノードの クラスタリング が行われ、最も応答が速いノードが大半のスイッチを処理します。

7.5. クラスターのモニタリング

7.5.1. Jolokia のモニタリング

クラスターのステータスをモニタリングするには、OpenDaylight で Jolokia のサポートを有効化する必要があります。

Jolokia のアドレスから、設定データストアクラスターのレポートを取得します。

 # curl -u <odl_username><odl_password>http://<odl_ip>:8081/jolokia/read/org.opendaylight.controller:type=DistributedConfigDatastore,Category=ShardManager,name=shard-manager-config

Jolokia のアドレスから、動作しているデータストアクラスターのレポートを取得します。

 # curl -u <odl_username><odl_password>http://<odl_ip>:8081/jolokia/read/org.opendaylight.controller:type=DistributedOperationalDatastore,Category=ShardManager,name=shard-manager-operational

レポートは JSON ドキュメントです。

注記

環境に応じて IP addressmember-1 の値を変更する必要があります。どのノードが応答してもよい場合には、IP アドレスは仮想 IP をポイントすることができます。ただし、特定のコントローラーのアドレスを指定した方が、より適切な結果が得られます。

この説明には、各ノードで同じリーダーを指定する必要があります。

注記

アップストリームの OpenDaylight チームが開発した Cluster Monitor Tool で、クラスターをモニタリングすることも可能です。これは、OpenDaylight の Github リポジトリーにあります。

このツールは、Red Hat OpenStack Platform 13 の一部ではないため、Red Hat はサポートも提供もしていません。

7.6. OpenDaylight のポートについての理解

OpenDaylight の正式な全ポートの一覧は、OpenDaylight の Wiki ページに掲載されています。このシナリオに関連するポートは以下のとおりです。

ポート番号用途

2550

クラスタリング

6653

OpenFlow

6640、6641

OVSDB

8087

neutron

8081

RESTCONF、Jolokia

コントローラーでこれらのポートへのトラフィックをブロックすると、以下のような影響があります。

クラスタリング
クラスター化されたノードは、通信できなくなります。クラスター化モードで実行する場合には、各ノードにピアが少なくとも 1 つ必要です。全トラフィックがブロックされた場合には、コントローラーが停止します。
OpenFlow
スイッチがコントローラーに到達できなくなります。
OVSDB
Open vSwitch は、コントローラーに到達できなくなります。コントローラーは、アクティブな OVS 接続を開始できますが、スイッチからコントローラーへの ping は失敗して、最終的にスイッチは他のコントローラーにフェイルオーバーします。
neutron
neutron がコントローラーに到達できなくなります。
RESTCONF
REST エンドポイントを使用する外部ツールは、コントローラーに到達できなくなります。このシナリオで影響を受けるのは、モニタリングツールのみのはずです。

OpenDaylight 側では、ログに表示されるのはクラスターのブロックされているトラフィックのみです。これは、他のポートが ODL コントローラーとの通信に使用されていることが理由です。

ターゲットデバイスでこれらのポートへのトラフィックをブロックすると、以下のような影響があります。

クラスタリング
クラスター化されたノードは、通信できなくなります。クラスター化モードで実行する場合には、各ノードにピアが少なくとも 1 つ必要です。全トラフィックがブロックされた場合には、コントローラーが停止します。
OpenFlow
コントローラーはフローをプッシュできなくなります。
OVSDB
コントローラーはスイッチに到達できなくなります (コントローラーは OVS のパッシブ接続に応答可能となります)。

2 つ目の状況では、いずれの場合も、OpenDaylight は設定と稼働状態は別々に維持管理するので、設定は引き続き到達不可能なデバイスをポイントし、コントローラーはそれらのデバイスへの接続を試み続けます。

7.7. OpenDaylight のフローについての理解

フロー説明

Neutron → ODL

Neutron、HA プロキシー、ODL の順序です。Pacemaker は仮想 IP (物理 IP が 3 つでバッキング) を管理します。ドライバーは TCP セッションを開いたままにしようと試みます。これにより影響を受ける場合があります (https://review.openstack.org/#/c/440866/)。

ODL → Neutron

ODL により開始される通信はありません。

ODL → ODL

ODL ノードはポート 2550 (設定可能) で相互に通信します。

ODL → OVS

ODL は、OVSDB (ポート 6640 および 6641) と OpenFlow (ポート 6633) を使用してスイッチと通信します。仮想 IP は関与せず、ODL は全スイッチの IP アドレスを認識しており、各 ODL ノードは全スイッチについて認識しています。

OVS → ODL

ODL は、OVSDB (ポート 6640 および 6641) と OpenFlow (ポート 6633) を使用してスイッチと通信します。仮想 IP は関与せず、ODL が全スイッチを設定して、全コントローラーを認識するようにします。スイッチからコントローラーへの通知は全ノードに送信されます。

7.8. Neutron DHCP エージェント HA

デフォルトの設定では、DHCP エージェントが OVS エージェントと共に全 neutron ノードで実行されます。ロールはコンポーザブルなので、エージェントはコントローラーから分離することができます。DHCP エージェントは、ポートを立ち上げる段階とリースの更新時のみに高可用性にとって重要です。ポートの作成時には、neutron が IP と MAC アドレスを割り当てて、ポートが立ち上がる前に全 DHCP エージェントを適切に設定します。この段階では、受信する DHCP 要求は、全 DHCP エージェントが応答します。

DHCP エージェントに問題が発生した場合にデータプレーンの可用性を最大限にするために、リース期間が長く設定されており、ノードには更新のための遅延が短時間設定されています。このため、DHCP エージェントはほとんど必要ありませんが、必要とされる場合には、利用できない DHCP エージェントに対して要求を実行するノードは即時にフェイルオーバーし、ブロードキャスト要求を発行して、残りの DHCP エージェントをすべて自動的に選択します。

エージェントには、独自のプロセスモニターがあります。systemd によりエージェントが起動され、それらの名前空間が作成されて、その内部でプロセスが開始します。エージェントが機能しなくなった場合には、名前空間は稼動状態のままで、systemd は、他のプロセスを終了したり再起動したりせずにエージェントを再起動します (systemd はそれらのプロセスを所有しません)。次にエージェントは名前空間を再度接続して、実行中の全プロセスと共に再利用します。

7.9. Neutron メタデータエージェント HA

リファレンス実装では、メタデータサービスは、対応する DHCP エージェントと同じ名前空間内で、ネットワークノードと統合されたコントローラー上で実行されます。メタデータプロキシーはポート 80 をリッスンし、既知のメタデータアドレスを使用して静的ルートでトラフィックを仮想マシンからプロキシーにリダイレクトします。プロキシーは Unix ソケットを使用して同じノード上でメタデータサービスと通信し、メタデータサービスは nova と通信します。Unix ソケットでは、プロキシーとサービス間で IP をルーティング可能にする必要はないので、メタデータサービスは、ノードがルーティングされなくても利用可能です。HA は keepalive と VRRP エレクションを使用して処理されます。フェイルオーバー時間は 2-5 秒です。エージェントは、DHCP エージェントと同じように処理されます (systemd および名前空間)。

Red Hat OpenStack Platform 11 のメタデータサービスは、カスタムの Python スクリプトですが、Red Hat OpenStack Platform 13 では HAProxy で、メモリー使用量が 30 パーセント低くなります。多くのユーザーはルーターごとに 1 プロキシーを使用し、コントローラーあたりのルーター数が数百もしくは数千にも及ぶため、これは特に重要となります。