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 のサンプルファイル:

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" ]
    }
  }
}

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

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

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

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

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

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

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

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

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

OpenDaylight 側では、ログに表示されるのはクラスターのブロックされているトラフィックのみです。これは、他のポートが ODL コントローラーとの通信に使用されるのが理由です。現在、Red Hat OpenStack Platform director によって開放されるポートの一覧は、https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/opendaylight-api.yaml#L114 に記載されています。

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

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

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

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

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

リファレンス実装では、メタデータサービスは、対応する 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 プロキシーを使用し、コントローラーあたりのルーター数が数百もしくは数千にも及ぶため、これは特に重要となります。