第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 の例を以下に示します。

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 アドレスを使用することができます。

module-shards.conf ファイルの例

module-shards = [
{
  name = "default"
  shards = [{
    name="default"
    replicas = [
      "member-1",
      "member-2",
      "member-3"
    ]
  }]
},
{
  name = "topology"
  shards = [{
    name="topology"
    replicas = [
      "member-1",
      "member-2",
      "member-3"
    ]
  }]
}]

他のデータストアを設定する必要がある場合には、セクションをさらに追加することができます (通常は “inventory” など)。これは必須ではなく、デフォルトの設定は、明示的な設定のないシャードに使用され、大半の場合は問題なく機能します。本シナリオでは、デフォルトのシャードのみを設定します。

module-shards = [
{
  name = "default"
  shards = [{
    name="default"
    replicas = [
      "member-1",
      "member-2",
      "member-3"
    ]
  }]
}]

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

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

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

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

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

各スイッチは、Red Hat OpenStack Platform director によりすべてのコントローラーで設定されます。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#L72 に記載されています。

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

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 12 では HAProxy で、メモリー使用量が 30 パーセント低くなります。多くのユーザーはルーターごとに 1 プロキシーを使用し、コントローラーあたりのルーター数が数百もしくは数千にも及ぶため、これは特に重要となります。