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

Red Hat OpenStack Platform 12 は、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 の例を以下に示します。

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

7.2. クラスターの動作

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

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

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

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

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

7.3. クラスターの要件

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

7.4. Open vSwitch の設定

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

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

7.5.1. Jolokia のモニタリング

クラスターのステータスをモニタリングするには、OpenDaylight で Jolokia のサポートを有効化する必要があります。データストアのクラスタリングレポートは、Jolokia のアドレス (http://192.0.2.1:8181/jolokia/read/org.opendaylight.controller:Category=Shards,name=member-1-shard-inventory-config,type=DistributedConfigDatastore) から取得することができます。このレポートは、JSON ドキュメント形式です。

注記

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

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

注記

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

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

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

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

ポート番号用途

2550

クラスタリング

6653

OpenFlow

6640、6641

OVSDB

8087

neutron

8181

RESTCONF、Jolokia

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

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

OpenDaylight 側では、ログにはクラスタリングのブロックされたトラフィックのみが表示され、それ以外は何も記録されません (他のポートは、ODL コントローラーとの通信に使用されるため)。現在 Red Hat OpenStack Platform director により開放されるポートは https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/opendaylight-api.yaml#L72 に記載されています。

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

クラスタリング
上記と同じ
OpenFlow
コントローラーはフローをプッシュできなくなります。
OVSDB
コントローラーはスイッチに到達できなくなります (コントローラーは OVS のパッシブ接続に応答可能となります)。

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

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

フロー説明

Neutron → ODL

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

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