ハイ アベイラビリティ環境でのアプリケーションの管理

この章では、Cisco プログラマブル ファブリック ソリューション用に、Cisco DCNM オープン仮想アプライアンス展開でハイアベイラビリティ (HA) 環境を設定する方法について説明します。また、Cisco DCNM オープン仮想アプライアンス内にバンドルされている各アプリケーションの HA 機能に関する詳細も含まれています。


（注）  
DCNM で適切な HA 機能を実現するには、NTP サーバがアクティブ ピアとスタンバイ ピア間で同期されていることが必要です。

この章は、次の項で構成されています。

Information About Application Level HA in the Cisco DCNM オープン仮想アプライアンスのアプリケーション レベル HA に関する情報

Cisco DCNM オープン仮想アプライアンスで実行されるアプリケーションの HA を確保するために、2 つの仮想アプライアンスを実行できます。1 つはアクティブ モードで、もう一方はスタンバイ モードで実行できます。


Note
このドキュメントでは、これらのアプライアンスをそれぞれ OVA-A と OVA-B と呼びます。

このシナリオでは、次のようになります。

  1. すべてのアプリケーションは、両方のアプライアンスで実行されます。

    アプリケーション データは常に同期されるか、アプリケーションが共通のデータベースを共有します (該当する場合)。

  2. 2 つのアプライアンスで実行されているアプリケーションのうち 1 つのみがクライアント要求を処理します。最初は、OVA-A で実行されているアプリケーションです。アプリケーションは、次のいずれかが発生するまで続行します。

    • OVA 上のアプリケーションがクラッシュします。

    • OVA 上のオペレーティング システムがクラッシュします。

    • OVA-A は何らかの理由で電源がオフになっています。

  3. この時点で、他のアプライアンス (OVA-B) で実行されているアプリケーションが引き継がれます。

    DHCP の場合、最初のノードで障害が発生すると、2 番目のノードが IP アドレスの提供を開始します。

  4. OVA-A への既存の接続はドロップされ、新しい接続は OVA-B にルーティングされます。

    このシナリオでは、ノード (OVA-A) の 1 つが最初にアクティブノードと呼ばれ、OVA-B がスタンバイノードと呼ばれている理由を示しています。

自動フェールオーバー

アプリケーション レベルと仮想マシン (VM) レベルおよびスイッチオーバー プロセスは次のとおりです。

  • ロードバランシング ソフトウェア (DCNM/AMQP) によって管理されているアプリケーションのいずれかが OVA-A でダウンした場合、クライアント要求を処理するアクティブノードは障害を検出し、後続の要求をスタンバイ ノード (OVA-B) にリダイレクトします。このプロセスは、アプリケーション レベルのスイッチオーバーを提供します。

  • アクティブノード (OVA A) に障害が発生した場合、または何らかの理由で電源がオフになった場合、スタンバイ ノード (OVA-B) は障害を検出し、OVA-B で Cisco DCNM/AMQP の VIP アドレスを有効にします。また、IP アドレスに関連付けられている新しい MAC アドレスを示すために、ローカル スイッチに追加 ARP を送信します。VIP を使用しないアプリケーションの場合、OVA-B で実行されている DHCPD は OVA-A 上の DHCPD の障害を検出し、それ自体をアクティブにします。OVA で実行されている LDAP は、LDAP がアクティブ-アクティブとして展開されているため、実行を継続します。したがって、VM レベルのフェールオーバーは、4 つのすべてのアプリケーション (DCNM/AMQP/DHCP/LDAP) に対して行われます。

手動でトリガされたフェールオーバー

アプリケーション レベルのフェールオーバーは、手動でトリガすることもできます。たとえば、OVA-B で AMQP を実行し、OVA-A でその他のアプリケーションを実行する場合があります。この場合、OVA-A の SSH 端末にログインし、appmgr stop amqp コマンドを使用して AMQP を停止することができます。

このフェールオーバーは、自動フェールオーバー で説明されているのと同じプロセスをトリガします。AMQP 仮想 IP アドレスへの後続の要求は、OVA B にリダイレクトされます。

ネイティブ HA フェールオーバーおよびトラブルシューティング

ネイティブ HA の特性により、ホストのロールはアクティブからスタンバイ、またはスタンバイからアクティブに切り替えることができます。

ここでは、さまざまな使用例でのトラブルシューティングについて説明します。

アクティブ ホストからスタンバイ ホストへのネイティブ HA フェールオーバー

アクティブ ホストからスタンバイ ホストへのネイティブ HA フェールオーバーが発生した場合は、次の手順を実行します。

  1. DCNM Web UI にログオンし、[管理者 (Administrator)] > [ネイティブ HA (NATIVE HA)] に移動します。

  2. HA のステータスを確認します。DCNM HA ステータスが [OK] モードでない場合は、フェールオーバー操作を実行できません。

    [フェールオーバー（Failover）] をクリックします。Cisco DCNM サーバがシャットダウンし、DCNM スタンバイ アプライアンスが動作可能になります。

  3. Cisco DCNM Web UI を更新します。

    DCNM サーバが動作可能になったら、DCNM Web UI にログインできます。


Note
フェールオーバーをトリガーするには 、アクティブホストでを appmgr stop all または appmgr stop ha-apps を実行しないようにすることを推奨します。Cisco DCNM HA ステータスが [OK] モードでない場合、フェールオーバーの前にスタンバイ DCNM アプライアンスがアクティブなアプライアンスと同期されないため、フェールオーバーによってデータの損失が発生する可能性があります。

DCNM アプリケーション フレームワークに関する問題

DCNM Web UI にアクセスできず、フェールオーバー操作が必要な場合は、Linux コンソールで次のいずれかのコマンドを実行します。

appmgr failover ：このコマンドは、HA ハートビート フェールオーバーをトリガーします。

または

reboot -h now ：このコマンドは、Linux ホストの再起動をトリガーします。これにより、フェールオーバーが発生します。

ただし、両方の HA ピアが同期していない場合、その他のすべての方法でデータ損失のリスクが発生するため、DCNM Web UI を使用してフェールオーバーを実行することをお勧めします。

DCNM の停止と再起動

DCNM を完全に停止して再起動するには、次の手順を実行します。

  1. スタンバイ アプライアンスで、appmgr stop all コマンドを使用してすべてのアプリケーションを停止します。

  2. appmgr status all コマンドを使用して、すべてのアプリケーションが停止しているかどうかを確認します。

  3. アクティブ アプライアンスで、appmgr stop all コマンドを使用してすべてのアプリケーションを停止します。

  4. appmgr status all コマンドを使用して、すべてのアプリケーションが停止しているかどうかを確認します。

  5. 展開されたアクティブ ホストで、 appmgr start all コマンドを使用してすべてのアプリケーションを起動します。

    すべてのアプリケーションが実行されているかどうかを確認します。DCNM Web UI にログオンして、動作しているかどうかを確認します。

  6. 展開されたスタンバイ ホストで、appmgr start all コマンドを使用してすべてのアプリケーションを起動します。

    Web UI で、[管理 (Administration)] > [ネイティブ HA (NATIVE HA)] に移動し、HA ステータスに [OK] と表示されていることを確認します。

スタンバイ ホストの再起動

スタンバイ ホストのみを再起動するには、次の手順を実行します。

  1. スタンバイ ホストで、appmgr stop all コマンドを使用してすべてのアプリケーションを停止します。

  2. appmgr status all コマンドを使用してすべてのアプリケーションが停止したかどうかを確認します。

  3. appmgr start all コマンドを使用して、アプリケーションを起動します。

    Web UI で、[管理 (Administration)] > [ネイティブ HA (NATIVE HA)] に移動し、HA ステータスに [OK] と表示されていることを確認します。

アプリケーション ハイ アベイラビリティ

ここでは、すべての Cisco プログラマブル ファブリック HA アプリケーションについて説明します。

Cisco DCNM オープン仮想アプライアンスには 2 つのインターフェイスがあります。1 つはオープン仮想アプライアンス管理ネットワークに接続し、もう 1 つは強化されたプログラマブル ファブリック ネットワークに接続しています。仮想 IP アドレスは、両方のインターフェイスに対して定義されます。

  • オープン仮想アプライアンス管理ネットワークから、DCNM REST API、DCNM インターフェイス、および AMQP には VIP アドレスを使用してアクセスします。

  • 拡張されたファブリック管理ネットワークから、LDAP と DHCP に直接アクセスします。

次の 3 つの仮想 IP のみが定義されています。

  • DCNM REST API (DCNM 管理ネットワーク上)

  • DCNM REST API (拡張ファブリック管理ネットワーク上)

  • AMQP (dcnm 管理ネットワーク上)


Note
HA で DCNM オープン仮想アプライアンスでは VIP を設定しますが、VIP は DCNM、REST API のアクセスに使用することを目的としています。GUI アクセスの場合でも、DCNM HA ピアの個別 IP アドレスを使用し、同じものを使用して DCNM SAN Java クライアントなどを起動することを推奨します。

プログラマブル ファブリック アプリケー ションとそれに対応する HA メカニズムの完全なリストについては、次の表を参照してください。

プログラマブル ファブリック アプリケーション

HA メカニズム

仮想 IP の使用

注

Data Center Network Manager

DCNM クラスタリング/フェデレーション

対応

各ネットワークに 1 つずつ定義された 2 つの VIP

RabbitMQ

RabbitMQ ミラーリング キュー

対応

OVA 管理ネットワークで定義された 1 つの VIP

リポジトリ

—

—

外部リポジトリを使用する必要があります

データセンターのネットワーク管理

データ センター ネットワーク管理機能は、Cisco Data Center Network Manager (DCNM) サーバで提供されます。Cisco DCNM はデータ センター インフラストラクチャのセットアップ、仮想化、管理、およびモニタリングを提供します。Cisco DCNM には、http://[host/ip] でブラウザからアクセスできます。


Note
Cisco DCNM の詳細については、http://cisco.com/go/dcnm を参照してください。

HA の実装

両方の OVA で動作する Cisco DCNM は、HA 用のクラスタ モードとフェデレーション モードで設定されます。Cisco DCNM フェデレーションは、SAN デバイスの HA メカニズムです。SAN デバイスのグループは、DCNM フェデレーショ ンセットアップの各ノードで管理できます。すべてのデバイスは、単一のクライアント インターフェイスを使用して管理できます。

Cisco DCNM UI で自動フェールオーバーを有効にするには、Admin > Federation を選択します。自動フェールオーバーを有効にし、OVA A で実行されている Cisco DCNM に障害が発生した場合、自動フェールオーバーは、OVA A から OVA B に自動的に管理されるファブリックおよび shallow-discovered LAN のみを移動します。

DCNM 仮想 IP の使用状況

オープン仮想アプライアンス HA セットアップには、デフォルトの HTTP ポートに Cisco DCNM の 2 つの VIP アドレス (各ネットワークに 1 つずつ) があります。これらの VIP は、オープン仮想アプライアンス管理ネットワークおよび拡張ファブリック管理ネットワーク上の DCNM RESTful サービスにアクセスするために使用できます。たとえば、Cisco UCS Director などの外部システムは、オープン仮想アプライアンス管理ネットワークの VIP を指定することができ、要求がアクティブな Cisco DCNM に転送されます。同様に、拡張ファブリック管理ネットワーク内のスイッチは、POAP プロセス中に拡張ファブリック管理ネットワーク上の VIP アドレスにアクセスします。

Cisco DCNM の実際の IP アドレスに直接接続し、クラスタ/フェデレーション セットアップの DCNM の場合と同じように使用することもできます。


Note
DCNM REST API にアクセスする場合にのみ、VIP アドレスを使用することを推奨します。Cisco DCNM Web または SAN クライアントにアクセスするには、サーバの IP アドレスを使用して接続する必要があります。

ライセンス

Cisco DCNM では、最初のインスタンスのライセンスと、2 番目のインスタンスに対応する予備のライセンスがあることを推奨します。

アプリケーションのフェールオーバー

[管理 (Administration)] > [DCNM サーバ (DCNM Server)] > [ネイティブ HA (Native HA)] を選択して、オープン仮想アプライアンス HA ペアが設定されている場合に、Cisco DCNM UI で自動フェールオーバー オプションを有効にします。このプロセスにより、OVA A で実行されている DCNM に障害が発生した場合、DCNM A によって管理されているすべてのファブリックおよび shallow-discovered LAN は、所定の期間 (通常は、OVA A の DCNM の障害発生後約 5 分後) に DCNM B により自動的に管理されます。

Cisco DCNM VIP アドレスは引き続き OVA A に存在します。Representational State Transfer Web Services (REST) コールは、最初に OVA A の VIP アドレスに到達し、OVA B で実行されている Cisco DCNM にリダイレクトされます。

アプリケーション フェールバック

OVA A で Cisco DCNM が起動すると、VIP アドレスによって REST 要求が DCNM A に自動的にリダイレクトされます。

仮想 IP のフェールオーバー

OVA A の Cisco DCNM REST API に設定されている VIP アドレスは、次の 2 つの理由により失敗する可能性があります。

  • OVA A で実行されているロードバランシング ソフトウェアが失敗します。

  • OVA A が失敗します。

Cisco DCNM の VIP アドレスは、自動的に OVA B に移行されます。唯一の違いは、フェールオーバー後に使用される DCNM です。

  • ロードバランシング ソフトウェアの障害が発生した場合、OVA-B の VIP アドレスは要求を DCNM A に送信します。

  • OVA A 障害が発生した場合、OVA B の VIP アドレスは要求を DCNM B に送信します。

自動フェールオーバーにより、DCNM A によって管理されているすべてのファブリックおよび shallow-discovered LAN の所有権が自動的に DCNM B に変更されます。

仮想 IP フェールバック

OVA A が起動され、Cisco DCNM が実行されている場合、VIP アドレスはスタンバイ ノードで実行されたままになります。OVA B から OVA A への仮想 IP アドレスのフェールバックは、次の順序でのみ発生します。

  1. OVA A が起動します。

  2. Cisco DCNM は、OVA A 上で動作します。

  3. OVA B がダウンするか、OVA B でロードバランシング ソフトウェアが失敗します。

RabbitMQ

RabbitMQ は、Advanced Messaging Queuing Protocol (AMQP) を提供するメッセージ ブロッカーです。


Note
30 秒以内に DCNM のサーバ両方で AMQP を停止および再起動する必要があります。そうしない場合、AMQP が開始しない場合があります。RabbitMQ の詳細については、https://www.rabbitmq.com/documentation.html を参照してください。

HA の実装

オープン仮想アプライアンスで HA を有効にすると、オープン仮想アプライアンス管理ネットワークに VIP アドレスが作成されます。vCloud Director などのオーケストレーション システムでは、その AMQP ブローカを VIP アドレスに設定します。

オープン仮想アプライアンスで HA を有効にすると、各ノードで実行する RabbitMQ ブローカも、他のノードで実行されているブローカと重複するように設定されます。両方の OVA は、RabbitMQ クラスタの「ディスク ノード」として機能します。これは、永続キューに保存されているすべての永続メッセージが複製されることを意味します。RabbitMQ ポリシーにより、すべてのキューがすべてのノードに自動的に複製されます。

アプリケーションのフェールオーバー

RabbitMQ A に障害が発生すると、OVA の VIP アドレスは、後続の AMQP 要求を RabbitMQ にリダイレクトします。

アプリケーション フェールバック

RabbitMQ A が起動すると、VIP アドレスが自動的に AMQP 要求の RabbitMQ への指示を開始します。

仮想 IP のフェールオーバー

OVA A で AMQP ブローカに対して設定された VIP アドレスは、次の 2 つの理由により失敗する可能性があります。

  • OVA A で実行されているロードバランシング ソフトウェアが失敗します。

  • OVA A が失敗します。

いずれの場合も、AMQP の VIP アドレスは自動的に OVA B に移行されます。唯一の違いは、フェールオーバー後に使用される AMQP ブローカです。

  • ロードバランシング ソフトウェアの障害では、OVA B の VIP アドレスによって要求が RabbitMQ に転送されます。

  • OVA A で障害が発生した場合、OVA B の VIP アドレスによって、要求が RabbitMQ B に送信されます。

仮想 IP フェールバック

OVA A が起動し、AMQP A が実行されている場合、VIP アドレスは OVA B で実行され続けます (要求を AMQP A に指示します)。RabbitMQ VIP の OVA B から OVA A へのフェールバックは、次の順序でのみ発生します。

  1. OVA A が起動します。

  2. RabbitMQ は、OVA A で実行されます。

  3. OVA B がダウンするか、OVA B でロードバランシング ソフトウェアが失敗します。

リポジトリ

すべてのリポジトリがリモートである必要があります。