第7章 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 アドレスの代わりに名前を使用することができます。

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

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

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

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

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

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

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

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

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

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

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 プロキシーを使用し、コントローラーあたりのルーター数が数百もしくは数千にも及ぶため、これは特に重要となります。