アプリケーション ネットワーキング サービス

LocalDirector のフェールオーバ設定

注意: 本製品は既に生産⁄販売を終了しております。


White Paper

LocalDirector のフェールオーバ設定





要約⁄目的

LocalDirector を互いにバックアップするように設定し、1 台が故障した場合に他のもう 1 台が役割を引き継ぐようにすることができますが、これは、フォールト・トレラントを備えた Web アプリケーション・システムの唯一の構成要素です。この文書では、ミッション・クリティカルな Web アプリケーション・サーバ・システムに対して冗長コンポーネントを設置する際の次の問題点について説明します。

  • LocalDirector のフェールオーバ
  • フェールオーバの動作の仕組み
  • フェールオーバの設定例
  • 高性能なフェールオーバの設定例
  • フェールオーバが機能していることを確認するテスト
  • FAQ(よくある質問)

LocalDirector については詳細に説明されているので、ユーザは、ネットワーク上の LocalDirector または他のコンポーネントが故障した場合の LocalDirector の動作や、テスト方法、再起動方法の詳細を理解できます。設定例も図表入りで用意されており、標準的な設置例を紹介しています。

LocalDirector のフェールオーバ

冗長構成での LocalDirector は、同一の装置 2 台で構成され、同じ機能を提供します。これらの装置はまったく同様に設定され、これらを接続する非対称フェールオーバ・ケーブルによって、「プライマリ」装置、「セカンダリ」装置として指定されます。障害が発生すると、片方の装置によって他方の装置の状態が捕捉されて操作が切り替わり、MAC レイヤアドレスが交換されますが、これらの装置の設定が互いに「プライマリ」から「セカンダリ」に、あるいはその逆に再設定されることはありません。


図 1:LocalDirector のフェールオーバ・ケーブルの取り付け

図 1:LocalDirector のフェールオーバ・ケーブルの取り付け

通常モードでは、「プライマリ」装置が「active」であり、つまり、LocalDirector を介してネットワーク・データのフローを処理している装置になります。「セカンダリ」装置は「standby」状態の装置です。「active」な装置に障害が発生すると、「active」と「standby」の設定が切り替わります。障害の起きた装置が再度回復したときは、その装置が「プライマリ」LocalDirector である場合でも、自動的には「active」になりません。

フェールオーバ用の冗長な LocalDirector の設定

フェールオーバ構成で使用されている 2 台の LocalDirector では、同一のモデル番号で同一のソフトウェア・リリースが実行されている必要があります。この 2 台の装置間の唯一の相違点は、「プライマリ」LocalDirector 側でピンの 1 本が+5 v に設定された非対称フェールオーバ・ケーブルによって設定されていることです。使われていないインターフェースが LocalDirector に取り付けられている場合、インターフェースの停止を識別する「hello」パケットがアクティブなインターフェースすべてに送られているときには、必ずこのインターフェースを無効にしてください。インターフェースを使用するように設定されている状態のときに何も接続されていないと、LocalDirector ではこのインターフェースに障害があると見なされ、フェールオーバの処理が開始されます。

現在、フェールオーバ機能によって起動時にフェールオーバ・ケーブルが自動的に検出され、ケーブルが接続されている場合にはフェールオーバが有効になります。この「自動検出」機能は、「フェールオーバなし」の設定ステートメントよりも優先されます。フェールオーバを使用している 2 台の装置のうち 1 台と、もう 1 台の装置が接続されていない場合は、両方の装置を接続できるようになるまで、アクティブな装置からフェールオーバ・ケーブルをはずしておきます。その装置が「プライマリ」装置であれば、問題はありません。しかし、その装置が「セカンダリ」装置の場合、その装置によってフェールオーバ・ケーブルが検出されてノーマル・モードであると見なされ、制御は「プライマリ」装置に委ねられます。この結果、スタンドアロン状態の装置がアクティブな制御を自動的に得られないことになります。

サーバの障害を考慮する場合、フェールオーバの目的で冗長 LocalDirector を設定する最初の手順は「プライマリ」装置の設定です。サーバがダウンしたとき、サーバの障害は LocalDirector によって制御されます。この時、LocalDirector に障害は生じません。よって、サーバの障害に関する問題は、LocalDirector の基本的な設定でカバーされます。

プライマリ装置の設定をセカンダリ装置にコピーするには、次の 3 つの方法があります。

1. 「standby」装置の初期ブートが完了したときに、「active」装置が自身の設定全体を「standby」装置に複製する。

2. 「active」装置にコマンドが入力されたとき、そのコマンドが「standby」装置に送られる。(このコマンドはフェールオーバ・ケーブルを経由して送られます)。

3. 「active」装置で「write standby」コマンドを入力することにより、「active」装置の設定全体が強制的に「standby」装置に送られる。

2 台の装置間の設定は、次の 2 つの条件下で「アウト・オブ・シンク」の状態になることがあります。

1. 「standby」装置がダウンしたときに、「active」装置を設定する。

2. 「standby」装置を設定する。この状況では、設定が同期されていないという警告メッセージが表示されます。

設定が同期されていない状態では、フェールオーバが予測していたように確実に動作しなくなり、非常に危険です。この状態を正常にするには、「standby」装置の設定を削除し、次に「active」装置から「write standby」コマンドを実行します。また、メモリ内の設定のコピーについても同期が取られることに留意してください。「active」装置での「write mem」コマンドでは、「standby」装置の設定は「standby」装置のメモリに書き込まれません。

ダウングレードの途中で設定がアウト・オブ・シンクになる場合は、特に悪い影響をもたらすことがあります。それは、古いソフトウェアでサポートされていない新しいコマンドが「standby」装置に残っている場合があるためです。古いコマンドの新しい形式が LocalDirector で実行されない場合、設定が「アウト・オブ・シンク」になることがあります。ソフトウェアのアップグレードの場合、新しいソフトウェアは古いコマンドを正しく読み取るため、この問題は生じません。しかし、古いコマンドが新しいリリースでサポートされている形式に変更されることがあります。

冗長構成での基本的なアドレスの問題

LocalDirector の他のマニュアルでも説明されているように、現在各 LocalDirector に関連するアドレスには、4 つの基本的な種類があります。

1. 装置のアドレス(「ip address」コマンド)。これはルータと同様に、telnet セッションなどで LocalDirector を管理するためのアドレスです。ただし、これは LocalDirector に接続されたデバイスのゲートウェイ・アドレスではありません。

2. 実アドレスに変換される仮想アドレス(「virtual」コマンド)

3. LocalDirector の背部にあるアプリケーション・デバイスの実アドレス(「real」コマンド)

4. 「alias」コマンドで設定される、セカンダリ・アドレス。

冗長構成では、フェールオーバ・アドレスも設定します。これは、ネットワークを経由して「standby」装置と通信する場合に使用するアドレスです。


図 2:基本的なフェールオーバ・アドレス

図 2:基本的なフェールオーバ・アドレス

冗長構成では、2 台の LocalDirector は、それぞれネットワークに接続されています。「active」装置では、「プライマリ」装置のシステム IP アドレスと MAC アドレスを使用します(「プライマリ」装置は、フェールオーバ・ケーブルの「Primary」または「Unit 0」と書かれた側のプラグが取り付けられている装置です)。「standby」装置では、「セカンダリ」装置のフェールオーバ IP アドレスと MAC アドレスを使用します。切り替えが発生した場合、これらの装置では、ネットワーク上での互いの存在を置き換えるために、使用している IP アドレスと MAC アドレスが切り替えられます。この動作はネットワークからは見えません。IP アドレスと MAC アドレスの関係は完全に同一のままなので、ネットワークの ARP テーブルがタイムアウトにされたり、変更されたりする必要はありません。ネットワーク上の他の機器についても、この冗長性や切り替えの発生を意識する必要はありません。システム IP アドレスとフェールオーバ IP アドレスは、同じサブネットにある必要があることに注意してください。この 2 つの装置の間にルータは配置できません。ルータは、バックアップ用 LocalDirector の MAC アドレスではなく、自身の MAC アドレスで応答するためです。

この 2 台の装置は別々の MAC アドレスを持つため、両方をスイッチに接続することができ、これらのスイッチによりどちらの装置が「active」であるかが判別されます。フェールオーバが発生すると、片方のポートから他方のポートへ MAC アドレスが移動されたことがスイッチによって認識され、2 台目の LocalDirector からのトラフィックが認識されるまで、スイッチは blocking モードに移行します。その後、スイッチは自身のテーブルを再設定し、パケットは新しくアクティブになった LocalDirector を経由してルートされます。これについては、スイッチの設定に関する節でさらに詳しく解説します。

外部 MAC アドレスは、LocalDirector の 1 つのポートだけに関連付けられることにも注意してください。これは、複数のインターフェースが同一の VLAN に接続されている場合、LocalDirector を経由した複数のリンクのロード・バランスを行うようにスイッチやサーバが設定されていない限り、LocalDirector から 1 つのポートだけがアクティブにされます。

フェールオーバの動作の仕組み

障害が発生したサーバの識別は、LocalDirector の障害の識別とは別の機能です。LocalDirector では、サーバが新しい接続要求に応答しないことに基づいて、障害の起きたサーバを識別します。LocalDirector でサーバの障害を識別し、制御する方法については、『リファレンス・ガイド』を参照してください。サーバが機能していないことをすばやく識別する方法や、再起動の方法に関するオプションが複数用意されています。

LocalDirector 間でのフェールオーバは、次の方法で判別されます。

  • ネットワーク・アクティビティ
  • フェールオーバ通信
  • フェールオーバ・ケーブルを介して接続されているもう一方の装置の電源や稼働のステータス

アクティブ装置でこれらの要素のいずれかに障害が発生すると、スタンバイ装置によりアクティブな制御が引き継がれます。

ネットワーク・アクティビティ - LocalDirector では、自身のインターフェース上で、双方のリンク・ステータスやネットワーク・トラフィックをチェックしています。ネットワーク・ケーブルをはずすと、双方のテストに障害が確実に発生します。このケーブルは 2 台の装置間の設定情報の転送に使用されており、これによって装置間の同期が保たれています。

フェールオーバ通信 - 2 台の装置では、すべてのネットワーク・インターフェースを使用して、5 秒ごとに特殊なフェールオーバ「hello」パケットを互いに送信しています。また、フェールオーバ・ケーブル経由でも 5 秒ごとに「hello」パケットが送信されています。いずれかの装置のインターフェースで「hello」パケットが 30 秒間受信されなかった場合、その装置ではそのインターフェースをテスト・モードにして、障害が発生した箇所を判別します。ネットワーク・インターフェースのテストは割り込み式ではないため、テスト・モードの間も通常のトラフィックの受け渡しは試みられます。テストは、ネットワーク・トラフィックに関係する 4 つの個別のテストで構成されます。テスト・モードにあるインターフェースでトラフィックを受け入れることができる場合、そのインターフェースは「稼働中」であると見なされます。インターフェースで他の装置からの「hello」パケットを受信できなかった場合、そのインターフェースがテスト・モードにされることを忘れないでください。このインターフェースが他のネットワーク・トラフィックを受信できる場合、相手の装置の側で「hello」パケットを送信できないエラーが発生していると考えられます。結果として、相手の装置に障害が発生していることになります。他の装置ではネットワーク・トラフィックを受信できるのに対して、テストしている装置では受信できないと判断された場合、テストしている装置自体に障害があります。

LocalDirector のソフトウェアのリリース 3.3 以上では、ネットワーク・トラフィックへの 10 秒間のポーリング間隔を変更できます。リリース 2.2 以上では、フェールオーバ・アドレスを 0.0.0.0 に設定して、フェールオーバ・メカニズムのネットワーク接続(「hello パケット」)の部分を完全に使用できないようにすることができます。

リンク状態が失われることによって、ネットワーク接続にも障害が発生します。LocalDirector のイーサネット・インターフェースでリンク・ステートが失われた場合、そのインターフェースがダウンしたと仮定され、もう一方の装置に対してフェールオーバが開始されます。この障害モードでは、フェールオーバが開始するまで 30 秒間待つ必要がありません。

フェールオーバ・ケーブル - このケーブルには、実際にケーブルの状態を判断する 3 つの方法が備えられています。すべてのネットワーク・インターフェースをモニタリングするほか、フェールオーバ機能によって相手の装置の電源ステータスも監視し、さらにフェールオーバ・ケーブル自体のステータスも監視します。フェールオーバ・ケーブルには、相手の装置が接続されているかどうか、および相手の装置に電源が入っているかどうかを検出する機能があります。相手の装置にケーブルが接続されていない場合、切り替えは無効になります。アクティブ装置に電源が供給されなくなると、スタンバイ装置側では 5 秒以内にこれを障害と見なします。

装置が「failed」したと判断されると常に、この装置のネットワーク・インターフェースはシャットダウンされ、アクティブになる義務を負いません。このような場合にはすべて、この状態を通知するための Syslog および SNMP トラップ・メッセージが送信されます。「failed」装置が「active」装置である場合、切り替えが発生します。装置が一度「failed」状態になると、「failover reset」コマンドによって復元されるまで、アクティブになる義務は負いません。

次の表では、一般的な障害の種類により、これらの機能がどのように冗長性に反映されるかを示しています。


表 1:さまざまな障害におけるフェールオーバのアクション
アクション アクティブな装置の反応 非アクティブな装置の反応 最終的な結果
アクティブな装置のフェールオーバ・ケーブルを切断する

ケーブルが切断されたと判断します。アクションなし。

非アクティブ状態のまま「Hello」パケットを引き続き受信します。

変化はありません。

非アクティブな装置のフェールオーバ・ケーブルを切断する

ありません

ケーブルが切断されたことを識別し、自身が failed 状態になったことを宣言します。

変化はありません。

フェールオーバ・ケーブルを切断する

非アクティブな装置の電源が切れ、ケーブルに問題はないと判断します。

アクティブな装置の電源が切れ、ケーブルに問題はないと識別します。

いずれの装置もアクティブになります。

アクティブな装置の電源を切る

非アクティブな装置の電源が切れたと判断します。

---

アクティブな装置はアクティブのままです。

非アクティブな装置の電源を切る

---

アクティブな装置の電源が切れたと判断し、自身がアクティブになります。

非アクティブな装置がアクティブになります。

アクティブな装置のネットワーク・ケーブルを切断する

ネットワークの問題と判断し、セカンダリ装置のステータスを確認して、非アクティブな装置に問題がなければ、フェールオーバを開始します。

アクティブな装置からのフェールオーバの起動に応答し、自身がアクティブになります。

非アクティブな装置がアクティブになります。

非アクティブな装置のネットワーク・ケーブルを切断する

このインターフェースを介して非アクティブな装置から送られる「hello」パケットがなくなるため、自身のケーブルでネットワーク・ケーブルに問題がないことを確認し、非アクティブな装置に問題があると判断します。

インターフェース上のケーブルに障害があると判断し、非アクティブのままとなります。

アクションはありません。

ハブの障害

リンクの状態、「hello」パケット、および他のネットワーク・トラフィックが失われ、非アクティブな状態になります。

リンクの状態、「hello」パケット、および他のネットワーク・トラフィックが失われ、非アクティブな状態になります。

いずれの装置も非アクティブになります。

「active」装置自体が故障した時点ですでに「standby」装置も「failed」の場合、いずれの装置も「failed」状態になることに注意してください。

切り替えられた環境での操作

切り替えられた環境で操作するときのフェールオーバに関する問題の解決は、3 つの部分から構成されます。最初に、特定の MAC アドレスをあるポートから別のポートへ移動させたスイッチをアップデートする問題があります。この問題を解決するには、その装置から(その装置が故障しない限り)新しい MAC アドレスおよび IP アドレスを使用して各インターフェースに一連の「hello」メッセージを送信させ、スイッチで内部 MAC テーブルがアップデートされるようにします。その後、スイッチでは 2 つの別々の方向にある MAC アドレスを認識し、ネットワーク上に見かけのブリッジ・ループを作成します。スイッチがスパニング・ツリーに関与している場合、スイッチによって、ループに陥ったあらゆるインターフェースがブロック(パケットが転送されないように)されます。

この問題については 3 つの解決策がありますが、最初の 2 つを次に示します。

1. スイッチに対して「set port fast」コマンドを使用する。

2. LocalDirector に直接接続されているポートに対するスパニング・ツリーを無効にする。

いずれの方法も、スイッチが blocking モードにならないようにします。また、フェールオーバ・アドレスを 0.0.0.0 に設定することによっても、LocalDirector でのネットワーク障害モードを無効にできます。これにより、このインターフェースでの「hello」パケットが排除されますが、LocalDirector のインターフェースが「waiting」状態になることもありません。

この「blocking」の問題に対する 3 番目の解決策は、LocalDirector に接続されているポートでスパニング・ツリーを使用する必要がある場合に適用されます。インターフェースがブロックされている総時間数は、スイッチで設定されている「転送遅延時間」です。この時間の間、スイッチではブリッジ・ループのより詳細な徴候を求めるためにインターフェースを監視します。2 つのアドレスの重複レイヤを示すトラフィックが存在しなければ、この時間が経過した後、スイッチによりこれらのポートが通常の動作に戻されます。このネットワーク・トラフィックの「blocking」により、フェールオーバによって送信された「Hello」パケットが転送されないという 2 番目の問題が生じます。ただし、LocalDirector のインターフェースは、パケットがスイッチのブロッキングを考慮した上で転送される前に 20 秒間「waiting」状態になります。この状態では、ネットワーク・トラフィックはアクティブ装置を経由して自由に流れます。しかし、フェールオーバでは「hello」メッセージが 2 回受信されるのを待ってからインターフェースの監視を再開します。これにより、フェールオーバを阻害することなく、スイッチを blocking 状態にすることができます。2 つ目の「Hello」メッセージが受信されると、フェールオーバによりインターフェースの通常のモニタリングが再開されます。前述のように、フェールオーバ IP アドレスを 0.0.0.0 に設定することによっても、LocalDirector での「waiting」状態を回避できます。LocalDirector のソフトウェアのリリース 3.3 以上では、「hello」パケットのタイミングを増加させ、スイッチが「blocking」モードを終わらせる機会を増やすこともできます。

マシンが故障したとき、次のようにログ・ファイルで waiting 状態を確認できます(ソフトウェアのバージョン 2.2)。

08-12-1998     17:17:07     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 1 waiting

スイッチが「blocking」状態になる総時間数は設定可能ですが、どのような値が設定されている場合でも、LocalDirector では、インターフェースを再度有効にする前に「Hello」メッセージを受信するまで待機します。

2 台のスイッチが冗長スイッチ構成で同時に使用されている場合は、ISL(Inter-Switch Link)またはトランクの使用も必要になります。これにより、LocalDirector の障害時にも、スイッチではスイッチ間のトラフィックの受け渡しができるようになります。これは、LocalDirector の冗長構成で説明されています。

スイッチの使用に関しては、さらに考慮すべき事項があります。スイッチの BPDU パケットは、インターフェースが保護されていない限り、LocalDirector に直接送られます。BPDU のパケットは、LocalDirector の両側に同一の VLAN がある場合には、LocalDirector にだけ転送されます。そして、スイッチに接続しているインターフェースのいずれかに同一の VLAN が含まれている限りこのような動作が発生するため、LocalDirector の二重構成ではこのような設定は推奨しません。LocalDirector のフェールオーバでは BPDU の受け渡しのためのポートも変更されるため、VLAN が復旧されない場合があります。


図 3:LocalDirector の両側にある同一の VLAN

図 3:LocalDirector の両側にある同一の VLAN
ステートフル・フェールオーバの設定

LocalDirector でのステートフル・フェールオーバとは、「standby」の LocalDirector で「active」な LocalDirector の設定のコピーを保持するだけでなく、アクティブな接続とその状態を示すテーブルのコピーも保持することを意味します。これは、「active」な装置が故障しても接続がまだ有効な場合、ユーザがサーバとのアクティブなセッションを保持できることを意味します。ただし、ほとんどの場合、故障の発生時に送信されていた情報は失われます。

LocalDirector では、ステートフル・フェールオーバを仮想 IP アドレスに基づいて設定する必要があります。これにより、「replicate」コマンドで指定された仮想アドレスに対し、接続テーブルの同期が行われます。接続テーブルのアップデートは、他のインターフェースを指定しない限り、2 台の LocalDirector 間のインターフェース 0 を通じて転送されます。また、クロス・ケーブルを使った専用のネットワーク接続を設定する方法によっても、これらの装置間で状態に関する情報を移動させることができます。このネットワーク接続には、ファースト・イーサネット・ケーブルを使用します。この接続をアップデート情報の通信専用にする必要はありませんが、高いパフォーマンスの設定では、アップデートのトラフィックによりかなりの負荷が生じる場合があります。


図 4:ステートフル・フェールオーバの配線

図 4:ステートフル・フェールオーバの配線

非常に短いクロス・ケーブルは、2 台の LocalDirector の直接接続には、ケーブルが接続に対して DC リンクの状態を示している場合でも使用できないことがあります。短いケーブルでは、回線上のリフレクションを適切に無視するためのポートの損失が十分にない場合があるためです。

ステートフル・フェールオーバを設定するには、さらに「replicate virtual」コマンドを実行する必要があります。ステートフル・フェールオーバの設定例は、設定例の節で示しています。

ステートフル・フェールオーバの状況では、LocalDirector での損失で保持されるものと失われるものに注意してください。2 台の装置間で接続テーブルが複製され、LocalDirector がオンラインの状態になったときには、これによって既存の TCP 接続を認識します。これは、すでに開始されたセッションは保存されることを意味します。失われる項目は次のとおりです。

  • 障害時に発生していた送信。この結果、ユーザは情報を再送信する必要があります。ワークステーションでタイムアウトが障害時間(最長 30 秒)より長く設定されている限り、セッション全体が維持されます。
  • バージョン 3.13 より前のバージョンでは、高度なレベルの情報(SSL ステータスなど)は、LocalDirector では維持されない。これらのセッションはタイムアウトになることがあります。以降のリリースでは、このような状態は生じません。

LocalDirector のステートフル・フェールオーバの組み合わせについてのトラブルシューティングは、通常の組み合わせによるトラブルシューティングと同様です。ログ・ファイルや syslog メッセージも同じです。

バージョン 3.13 以降のコードが実行されている LocalDirector でのステートフル・フェールオーバの第一の目的は、ロード・バランスが行われているアレイにある特定サーバに対する接続の「持続性」を維持することです。

「stickied」の各仮想サーバでは、それぞれの「sticky」接続に関連付けられた実サーバを示すテーブルが作成されます。このことは、「sticky」コマンドのすべてのバージョン - generic「sticky」、SSL「sticky」、cookie「sticky」、および「buddy」ペアリング - に該当します。「sticky」テーブルが「standby」マシンへ複製されることは、LocalDirector のフェールオーバが終了したときに、「sticky」および「buddy」の関連付けが維持されることを意味します。この方法では、TCP 接続がタイムアウトになっても、クライアントは同じ実サーバへ戻ります。

フェールオーバで使用されるコマンド

フェールオーバで使用される一般的なコマンドについて説明します。

[no] failover - フェールオーバを有効⁄無効にする

[no] failover active -装置を active / standby 状態にする

failover <ip> - フェールオーバ IP アドレスを設定する(セカンダリ・マシンのアドレス)

failover reset - 両方の装置の failed 状態をクリアし、フェールオーバを再起動させる

フェールオーバ・アドレスはセカンダリ LocalDirector のアドレスで、ネットワーク上で参照されますが、1 台目の LocalDirector 以外からは使用されません。フェールオーバが発生すると、スタンバイの役割を持つ LocalDirector によってこのアドレスが使用されます。

ステートフル・フェールオーバの場合は、次のコマンドを使用します。

replicate interface <no> - 接続についての接続ステータスが、このインターフェースを経由して他の LocalDirector に送信されるようにする

replicate <virtual name> - この仮想インターフェースへの接続についての接続ステータスが維持されるようにする

replicate コマンドは、ソフトウェアのリリースによっては、コマンド・ライン・インタプリタで受け入れられますが、イーサネット・インターフェース上でのみ動作します。複製は、Fast Etherchannel、ギガビット・イーサネット、あるいは FDDI 上では動作しません。

簡単なフェールオーバの構成

2 台の LocalDirector - プライマリ LocalDirector の設定

syslog output 20.3

no syslog console

enable password 000000000000000000000000000000 encrypted

hostname localdirector

interface ethernet 0 auto

interface ethernet 1 auto

mtu 0 1500

mtu 1 1500

no ping-allow 0

no ping-allow 1

ip address 171.71.85.165 255.255.0.0

no rip passive

failover

failover ip address 171.71.85.160

password cisco

no snmp-server contact

no snmp-server location

virtual 171.71.85.161 is

real 171.71.85.202 is

real 171.71.85.201 is

name 171.71.85.202 server2

name 171.71.85.201 server1

name 171.71.85.161 vtest

bind 171.71.85.161 171.71.85.202

bind 171.71.85.161 171.71.85.201

セカンダリ LocalDirector での設定は行いません。セカンダリ LocalDirector の構成はプライマリ装置から取得します。セカンダリ装置の設定が有効で、1 台目の装置の設定と一致していることを確認するには、コンソール上で設定モードに入り、write t を実行します。プライマリ LocalDirector の設定が表示されます。これはメモリに格納されますが、フラッシュには書き込まれません。

ステートフル・フェールオーバの設定 - 上記の設定に加えて、次のコマンドを使用します。ステートフル・フェールオーバは仮想マシンを基本として設定されるため、次の replicate vtest コマンドでは、状態に関する情報は仮想インターフェース vtest のために維持されます。interface 3 は、状態に関する情報を他のコンピュータに転送するために使用されます。

replicate vtest

replicate interface 3

高性能なフェールオーバの設定

ほとんどのユーザは非常に負荷の高い状況で LocalDirector を使用しています。このような状況では、着信トラフィックを LocalDirector も含む、複数の場所にルートさせるために、冗長スイッチが使用されています。次の例は、これまでに説明した LocalDirector のフェールオーバ機能をすべて活用した典型的な設置例です。


図 5:高性能な LocalDirector の基本的な構成

図 5:高性能な LocalDirector の基本的な構成

あらゆるコンポーネントの障害に対するこの構成の動作方法について説明します。

ルータの障害では、HSRP により他のルータがアクティブにされます。そしてスイッチにより、スイッチのポート上で検出されるアクティビティに基づいて、バックアップ・ルータがアクティブであると判断されます。LocalDirector は非フェールオーバ状態のままであり、アクティブな LocalDirector へのトラフィックはスイッチ間リンクによって維持されます。サーバへのダウンストリーム・トラフィックは、非フェールオーバ状態と同様に動作します。

スイッチの障害では、そのスイッチに接続された LocalDirector がアクティブの場合にはフェールオーバが発生します。これは、インターフェースがダウンしたと認識されるためです(「hello」パケットを受け取れないため)。その LocalDirector がアクティブでない場合、ISL リンクを通じてそのスイッチが故障したと判断される以外は何も起きません。そして、アクティブな LocalDirector に接続されているスイッチが負荷を引き継ぎます。

LocalDirector の障害では、LocalDirector でフェールオーバが発生します。新しくアクティブになった LocalDirector がトラフィックの送受信を開始します。スイッチでは、LocalDirector で使用されている MAC アドレスが他のポートに移動されます。これらの装置は、ISL リンクを介して通信します。前述したように、スイッチがスパニング・ツリー・グループの一部である場合、これらのパケットは転送時間の倍の時間だけブロックされます。

遅延パラメータ

上記の設定では、サーバ側のスイッチの障害により、そのスイッチに接続されているサーバへのアクセスができなくなることに注意してください。この問題を解決するには、サーバへの接続を二重化します。


図 6:二重ポートによるサーバ構成

図 6:二重ポートによるサーバ構成

二重ポートのサーバを構築するには、3 つの解決策があります。第一の方法は、2 つの VLAN 上に 2 つの別個のアドレスを持つ 2 つのポートを設定することです。この方法では、LocalDirector の状態が変化すると、それと同時にバイパス側のスイッチと関連付けられた「実」サーバの状態も変化します。これにより、継続性のある設定が機能しなくなるため、よい方法とは言えません。他の解決策としては、冗長ドライバ・ソフトウェアまたは冗長なポート・カードを使用する方法があります。いずれの方法でも、各サーバは 1 つの IP アドレスと MAC アドレスを持ち、フェールオーバ後に正しく操作するには「sticky」な設定を必要とします。いずれの場合においても、サーバはルーティングを無効にするため、2 台の LocalDirector 間のパスは提供されません。

この図では、両方のスイッチが 2 台の LocalDirector にクロス接続されていることも示しています。これにより、LocalDirector の片方に障害が発生したときに、ISL またはトランクからトラフィックが遠ざけられます。

LocalDirector に数台のサーバしか接続されていない場合は、サーバの前面からスイッチを排除することもできます。この場合、各サーバが二重ポート、シングルアドレスで構成され、ステートフル・フェールオーバ接続の情報のルーティングのために 2 台の LocalDirector 間にネットワーク・リンクが設置されていることが必要です(サーバでは 2 つのインターフェース間でのルートを行わないため)。LocalDirector と HSRP ルータ間からスイッチを排除することは、容易ではありません。このインターフェース間には「hello」パケットが流れていますが、、LocalDirector が「inactive」になった場合でも、ルータではフェールオーバが発生しません。それは、「inactive」な状態でも、ネットワーク・インターフェースは依然としてアクティブであるためです。この構成を動作させるには、フェールオーバ・アドレスを 0.0.0.0 に設定して、「hello」パケットを無効にする必要があります。

リダンダント電源の計画

冗長な Web サーバ・サイトの計画では、電源の障害に対する計画を立て、別の電源回路にある機器を使用して影響を受ける機器をバックアップすることが重要です。つまり、すべての Web サーバを同一の回路上に存在させないようにします。

また、複数のフェールオーバが同時に発生するような方法で電源を供給しないことが重要です。たとえば、ゲートウェイ・ルータの 1 台とスイッチが、同じ電源回路または電源装置から電源を得ているとします。この状況は、スイッチとルータの両方が同時にルートを集中させようとすることを意味します。これはよい状態ではなく、非常に負荷の高いネットワークの状況では必ず問題を引き起こします。

冗長 LocalDirector 構成の検証とテスト

最初のステップは、2 台の装置間が接続されているかどうかの確認です。プライマリ装置からセカンダリ装置へ PING を送信し、これらの装置間がネットワーク接続されていることを確認します。また、2 台の装置間のパケットをスニファして、「Hello」パケットが正しく生成されていることを確認することもできます。すべてのインターフェースが「waiting」状態でないことを確認することでも、接続性を確認できます。(インターフェースの状態は、後出の「show failover」コマンドで説明します)。

以下は、ソフトウェアのリリース 2.2 でのパケットの例です。

IP:----- IP Header -----

IP:

IP:Version = 4, HEADER LENGTH = 20 BYTES

IP:Type of service = 00

IP: 000. .... = ROUTINE

IP: ...0 .... = NORMAL DELAY

IP: .... 0... = NORMAL THROUGHPUT

IP: .... .0.. = NORMAL RELIABILITY

IP:Total length = 30 BYTES

IP:Identification = 42832

IP:Flags = 0X

IP: .0.. .... = MAY FRAGMENT

IP: ..0. .... = LAST FRAGMENT

IP:Fragment offset = 0 BYTES

IP:Time to live = 255 SECONDS/HOPS

IP:Protocol = 105(?)

IP:Header checksum = FECF (CORRECT)

IP:Source address = [10.0.0.171], LD

IP:Destination address = [10.0.0.172], LD-FAIL

IP:No options

IP:[10 byte(s)of data]

フェールオーバ・ケーブルが正常であるかどうかは、セカンダリ装置の電源を落とし、syslog イベントが生成されることを確認することでもチェックできます。設定が 2 つの方法でコピーされていることを確認するのもよい方法です。最初に、セカンダリ装置が設定されていることを確認します。次に設定行を入力し、エラー・メッセージが生成されることを確認します。「show failover」コマンドの出力を使用して、LocalDirector にフェールオーバが設定されていることと、ネットワーク接続とフェールオーバ・ケーブルに問題がないことを確認することもできます。これらの例は、フェールオーバ・ケーブルが取り付けられていて、動作していることを前提としています。また、これらの装置のシステム IP アドレスが 192.168.89.1、フェールオーバ IP アドレスが 192.168.89.2 として設定されていることを前提としています。

次の例は、「show failover」の通常の出力を示しています。各装置が使用している IP アドレスが表示されていることに注意してください。フェールオーバ IP アドレスが入力されていない場合は 0.0.0.0 として表示され、そのインターフェースのモニタリングは「waiting」状態のままになります(「waiting」状態の説明については、次の例を参照してください)。

Failover On

Cable status:Normal

This host:Primary - Active

Active time:6885(sec)

Interface 0(192.168.89.1):Normal

Interface 1(192.168.89.1):Normal

Other host:Secondary - Standby

Active time:0(sec)

Interface 0(192.168.89.2):Normal

Interface 1(192.168.89.2):Normal

次の例は、フェールオーバによってネットワーク・インターフェースのモニタリングが開始されていない場合を示しています。ネットワーク・インターフェース上で相手の装置からの 2 つ目の「hello」パケットを受信するまで、フェールオーバによるネットワーク・インターフェースのモニタリングは開始されません。これには 30 秒間かかります。この装置がスパニング・ツリーが実行されているネットワーク・スイッチに接続されている場合、この 30 秒間の遅延に加えて、スイッチで設定されている「転送遅延」時間の倍の時間がかかります(通常は 15 秒として設定されています)。ネットワーク・スイッチは一時的なブリッジ・ループを検出します。このループが検出されると、「転送遅延」時間の間、これらのインターフェースでのパケットの転送が停止されます。次に、さらに「転送遅延」時間分だけ「listen」モードに入ります。この間、スイッチではブリッジ・ループが傍受され、トラフィックは転送されません(したがって、フェールオーバの「hello」パケットは転送されません)。転送遅延時間の倍の時間(30 秒)が経過した後、トラフィックのフローが再開されます。各 LocalDirector は、30 秒に相当するもう一方の装置からの「hello」パケットを受信するまで、「waiting」モードのままです。この間、LocalDirector はトラフィックを通過させ、「hello」パケットを受信しないことによって装置が障害状態にならないようにしているだけです。他のフェールオーバ・モニタリングはすべて稼働しています(たとえば、電源、リンクのインターフェースの損失、フェールオーバ・ケーブルの「hello」)。

Failover On

Cable status:Normal

This host:Primary - Active

Active time:6930(sec)

Interface 0(192.168.89.1):Normal(Waiting)

Interface 1(192.168.89.1):Normal(Waiting)

Other host:Secondary - Standby

Active time:15(sec)

Interface 0(192.168.89.2):Normal(Waiting)

Interface 1(192.168.89.2):Normal(Waiting)

次は、フェールオーバによって障害が検出された例です。プライマリ装置のインターフェース 1 が障害の原因であることに注意してください。この装置は、障害のために「waiting」モードに戻ります。障害が起きた装置は、自身をネットワークからはずし(インターフェースがダウン)、以降は「hello」パケットをネットワークに送信しません。障害が起きた装置が取り替えられ、フェールオーバの通信が再開されるまで、アクティブな装置は「waiting」状態のままです。

Failover On

Cable status:Normal

This host:Primary - Standby(Failed)

Active time:7140(sec)

Interface 0(192.168.89.2):Normal(Waiting)

Interface 1(192.168.89.2):Failed(Waiting)

Other host:Secondary - Active

Active time:30(sec)

Interface 0(192.168.89.1):Normal(Waiting)

Interface 1(192.168.89.1):Normal(Waiting)

以前に説明したように、0.0.0.0 のフェールオーバ・アドレスのオプションを使用して、「waiting」状態をなくすことができ、フェールオーバの時間が劇的に減少します。ここでは、0.0.0.0 のフェールオーバ・アドレスが使用されている例を示します。

フェールオーバ設定での SYSLOG の使用

次に示すのは、バージョン 2.2 のソフトウェアを使用し、「failover active」コマンドを使用して切り替えられた LocalDirector の組み合わせからの syslog の例です。

08-12-1998     17:15:56     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 1 normal

08-12-1998     17:15:57     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 0 normal

08-12-1998     17:17:04     Local4.Critical     171.71.85.165     Primary:Switching to OK.

08-12-1998     17:17:05     Local4.Critical     171.71.85.160     Secondary:Switching to OK.

08-12-1998     17:17:05     Local4.Critical     171.71.85.160     Secondary:Switching to OK.

08-12-1998     17:17:05     Local4.Critical     171.71.85.165     Primary:Switching to OK.

08-12-1998     17:17:07     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 1 waiting

08-12-1998     17:17:07     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 0 waiting

08-12-1998     17:17:08     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 1 waiting

08-12-1998     17:17:08     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 0 waiting

08-12-1998     17:17:13     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 1 normal

08-12-1998     17:17:13     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 0 normal

08-12-1998     17:17:17     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 1 normal

08-12-1998     17:17:17     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 0 normal

08-12-1998     17:17:37     Local4.Critical     171.71.85.165     Primary:Power failure other side.

08-12-1998     17:17:37     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 1 waiting

08-12-1998     17:17:38     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 0 waiting

片方の LocalDirector だけが sysylog ホストの「<aaa.aaa.aaa.aaa >」コマンドを使用して設定されている場合でも、両方の LocalDirector から syslog ホストへレポートが行われていることに注意してください。「セカンダリ」の LocalDirector には、このコマンドが「プライマリ」からコピーされています。

次に示すのは、ネットワーク接続がダウンし、「hello」パケットが受信されなくなった場合のログ・ファイルの例です。

08-12-1998     17:40:38     Local4.Critical     171.71.85.165      Primary:Mate reporting failure.

装置が接続を取り戻すと、次のメッセージ・ストリームが表示されます。

08-12-1998     17:44:35     Local4.Critical     171.71.85.160     Secondary:Link status `Up' on interface 1

08-12-1998     17:44:35     Local4.Critical     171.71.85.160     Secondary:Switching to OK.

08-12-1998     17:44:35     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 1 waiting

08-12-1998     17:44:35     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 0 waiting

08-12-1998     17:44:45     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 1 normal

08-12-1998     17:44:45     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 0 normal

次の例は、フェールオーバの reset コマンドを使用して、プライマリ装置が「active」な装置にリセットされた時の syslog の出力例です。

08-12-1998     17:28:03     Local4.Critical     171.71.85.165     Primary:Switching to OK.

08-12-1998     17:28:04     Local4.Critical     171.71.85.160     Secondary:Switching to OK.

08-12-1998     17:28:04     Local4.Critical     171.71.85.160     Secondary:Switching to OK.

08-12-1998     17:28:04     Local4.Critical     171.71.85.165     Primary:Switching to OK.

08-12-1998     17:28:04     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 1 waiting

08-12-1998     17:28:05     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 0 waiting

08-12-1998     17:28:05     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 1 waiting

08-12-1998     17:28:05     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 0 waiting

08-12-1998     17:28:09     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 1 normal

08-12-1998     17:28:10     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 0 normal

08-12-1998     17:28:12     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 1 normal

08-12-1998     17:28:12     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 0 normal

次は、プライマリ装置がアクティブなときにセカンダリ装置の電源に障害が起きた場合の出力例です。

08-12-1998     17:31:04     Local4.Critical     171.71.85.165     Primary:Power failure other side.

08-12-1998     17:31:04     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 1 waiting

08-12-1998     17:31:04     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 0 waiting

電源が回復すると、次のように出力されます。

08-12-1998     17:34:40     Local4.Critical     171.71.85.165     Primary:Power failure other side.

08-12-1998     17:34:55     Local4.Critical     171.71.85.165     Primary:Cable OK.

08-12-1998     17:35:00     Local4.Critical     171.71.85.165     Primary:Begin Configuration Replication:Sending to mate

08-12-1998     17:35:04     Local4.Critical     171.71.85.160     Secondary:End Configuration Replication

08-12-1998     17:35:04     Local4.Critical     171.71.85.165     Primary:End Configuration Replication

08-12-1998     17:35:05     Local4.Critical     171.71.85.160     Secondary:Link status `Up' on interface 1

08-12-1998     17:35:05     Local4.Critical     171.71.85.160     Secondary:Switching to OK.

08-12-1998     17:35:06     Local4.Critical     171.71.85.160     Secondary:Link status `Up' on interface 0

08-12-1998     17:35:06     Local4.Critical     171.71.85.160     Secondary:Switching to OK.

08-12-1998     17:35:10     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 1 normal

08-12-1998     17:35:10     Local4.Critical     171.71.85.160     Secondary:Monitoring on interface 0 normal

08-12-1998     17:35:15     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 1 normal

08-12-1998     17:35:15     Local4.Critical     171.71.85.165     Primary:Monitoring on interface 0 normal

フェールオーバと始動時の SNMP トラップの出力

LocalDirector には、エージェントに SNMP アラームを送信するための SNMP トラップがプログラムされています。次は、「プライマリ」装置が「active」モードのときに、「セカンダリ」装置の電源に障害が発生した場合のリリース 2.2 からの出力例です。

Enterprises 9.9.41.2.0.0.1 received from:171.71.85.165 at 8/14/97 2:07:19 PM

TimeStamp:1 days 22h:11m:07s:63th
Agent address: 171.71.85.165
Manager Address: 171.71.85.148
Community:public
Enterprise:enterprises 9.9.41.2
Bindings(8)

Binding#1:sysUpTime.0****(timeticks)1 days 22h:11m:07s63th

Binding#2:internet 6.3.1.1.4.1.0****(oid)enterprises 9.9.41.2.0.0.1

Binding#3:enterprises 9.9.41.2.3.1.2****(octets)20

Binding#4:enterprises 9.9.41.2.3.1.3****(int,int32)2

Binding#5:enterprises 9.9.41.2.3.1.4****(octets)Syslog Trap

Binding#6:enterprises 9.9.41.2.3.1.5****(octets)Primary:Power failure other side

Binding#7:enterprises 9.9.41.2.3.1.2****(timeticks)1 days 22h:11m:07s63th

Binding#8:internet 6.3.1.1.4.3.0****(oid)enterprises.9.9.41.2

Enterprises 9.9.99.2.0.0.2 received from:171.71.85.165 at 8/14/98 2:07:19PM

TimeStamp:1 days 22h:11m:07s:63th
Agent address: 171.71.85.165
Manager Address: 171.71.85.148
Community:public
Enterprise:enterprises 9.9.99.2
Bindings(4)

Binding#1:sysUpTime.0****(timeticks)1 days 22h:11m:07s63th

Binding#2:internet 6.3.1.1.4.1.0****(oid)enterprises 9.9.99.2.0.0.2

Binding#3:enterprises 9.9.99.1.3.2****(int,int32)2

Binding#4:internet 6.3.1.1.4.3.0****(oid)enterprises 9.9.99.2

装置の電源が回復すると、装置から約 20 個の SNMP メッセージが送信されます。これは、障害の起きた装置を再起動するための Syslog エントリにほぼ匹敵します。次に示すのは、最初の 2 つです。

Enterprises 9.9.99.2.0.0.2 received from:171.71.85.165 at 8/14/97 2:07:19 PM

TimeStamp:1 days 22h:34m:10s:89th
Agent address: 171.71.85.165
Manager Address: 171.71.85.148
Community:public
Enterprise:enterprises 9.9.41.2
Bindings(8)

Binding#1:sysUpTime.0****(timeticks)1 days 22h:34m:10s89th

Binding#2:internet 6.3.1.1.4.1.0****(oid)enterprises 9.9.41.2.0.0.1

Binding#3:enterprises 9.9.41.2.3.1.2****(octets)20

Binding#4:enterprises 9.9.41.2.3.1.3****(int,int32)2

Binding#5:enterprises 9.9.41.2.3.1.4****(octets)Syslog Trap

Binding#6:enterprises 9.9.41.2.3.1.5****(octets)Primary:Cable OK

Binding#7:enterprises 9.9.41.2.3.1.2****(timeticks)1 days 22h:34m:10s89th

Binding#8:internet 6.3.1.1.4.3.0****(oid)enterprises.9.9.41.2

Enterprises 9.9.99.2.0.0.2 received from:171.71.85.165 at 8/14/98 2:07:19PM

TimeStamp:1 days 22h:34m:10s:89th
Agent address: 171.71.85.165
Manager Address: 171.71.85.148
Community:public
Enterprise:enterprises 9.9.99.2
Bindings(4)

Binding#1:sysUpTime.0****(timeticks)1 days 22h:34m:10s89th

Binding#2:internet 6.3.1.1.4.1.0****(oid)enterprises 9.9.99.2.0.0.2

Binding#3:enterprises 9.9.99.1.3.2****(int,int32)1

Binding#4:internet 6.3.1.1.4.3.0****(oid)enterprises 9.9.99.2

LocalDirector にプログラムされている他の SNMP トラップについての情報は、『リファレンス・マニュアル』に記述されています。

FAQ(よくある質問)

質問 2 台の装置の間で、始動時の初期化はどのように行われますか。

回答 フェールオーバのデフォルトは、オフ(フェールオーバなし)です。ただし、最初のブート時にフェールオーバ・ケーブルが接続されていると、フェールオーバ機能によってケーブルが自動的に検出され、フェールオーバがオンになります。これは、ブート時のみに適用されます。稼働中の装置にケーブルを取り付けた場合、フェールオーバを始動するために「failover」コマンドを発行する必要があります。フェールオーバ・ケーブルがブート時に接続されていない場合、その装置は直ちにアクティブな装置になります。

次の説明は、フェールオーバが有効で、両方の装置にフェールオーバ・ケーブルが接続されていることを前提としています。

装置が初めてブートされたときには、デフォルトで standby の状態になります。30 秒以内にアクティブな制御を取得する装置がない場合は、この装置がアクティブになります。この装置がプライマリで、もう一方の装置が非アクティブの場合、プライマリ装置がアクティブな装置になります。これは、プライマリ装置とセカンダリ装置の両方が互いに 30 秒以内にブート処理を完了した場合、プライマリ装置がアクティブになることを意味します。セカンダリ装置がすでにアクティブである場合、プライマリ装置はスタンバイのままになります。プライマリ装置では、アクティブな制御を自動的に取得しません。

スタンバイ装置が初めてブートされたとき、アクティブ装置からスタンバイ装置へ、設定が完全に複製されます。この後、コマンドが入力されると、そのコマンドがアクティブ装置からスタンバイ装置へ送られます。設定すべてを強制的に複製するには、「write standby」コマンドを使用します。スタンバイ装置に入力されたコマンドは、アクティブ装置へ複製されません。スタンバイ装置でコマンドを入力しようとすると、警告メッセージが表示されます。このメッセージは、設定が同期されないことに対する警告です。コマンド自体は実行されます。

質問 障害の原因となるものは何ですか。

回答 障害の検出は次の事項に基づいて行われます。

  • NIC(Network Interface Card)の状態。
NIC のリンク・ステータスがダウンすると、装置に障害が発生します。ダウンとは、稼働しているポートに NIC が接続されていないことを意味します。NIC が「down」として設定されている場合は、このテストでは障害とは見なされません。
  • フェールオーバのネットワーク通信
2 台の装置では、すべてのネットワーク・インターフェースを使用して、互いに「hello」パケットを送信します。「hello」パケットが 30 秒間受信されなかった場合、そのインターフェースはテスト・モードにされて、障害が発生した箇所を判別します。
  • フェールオーバ・ケーブルの通信
2 台の装置では、フェールオーバ・ケーブルを使用して、互いに「Hello」メッセージを送信します。スタンバイ装置でアクティブ装置からのメッセージが 30 秒間受信されなかった場合(ケーブルの状態は問題ない場合)は、スタンバイ装置がアクティブになります。
  • Cable のエラー。
ケーブルで接続されているため、各装置では次の項目を判別できます。
  • 相手側の装置での電源障害。
  • 装置自身にケーブルが接続されていない。
  • 相手側の装置にケーブルが接続されていない。

スタンバイ装置側でアクティブ装置の電源の切断(あるいはリセット)を検出した場合、スタンバイ装置がアクティブな制御を引き継ぎます。ケーブルが接続されていない場合、syslog が生成されますが、切り替えは行われません。ただしブート時は例外で、ケーブルが接続されていないことが判明した時点で装置がアクティブになります。フェールオーバ・ケーブルが取り付けられていない状態で両方の装置が起動した場合、両方の装置がネットワーク上で競合する重複した IP アドレスでアクティブになります。この状態では、LocalDirector でもブリッジ・ループが作成され、ネットワークを飽和させます。フェールオーバを正常に作動させるには、フェールオーバ・ケーブルを取り付けることが必要です。

質問 障害の検出にはどのくらいの時間を要しますか。

回答

  • ネットワーク・インターフェース・カードのエラーは、20 秒以内に検出されます。
  • ネットワーク通信のエラーは、30 秒以内に検出されます。
  • フェールオーバ通信のエラーは、30 秒で検出されます。
  • 電源の障害(およびケーブルの障害)は、5 秒以内に検出されます。

質問 フェールオーバが開始されると、どのようなことが生じますか。

回答 いずれかの装置で切り替えが開始されます。切り替えが行われると、装置は、使用している IP アドレスや MAC アドレスの他、自身の状態も互いに交換します。ネットワークの視点から見ると、スタンバイ装置はアクティブだった装置と透過的に置き換えられます。すでに設定はすべてスタンバイ装置上に複製されているため、設定のアップデートを行う必要はありません。「replication」が有効にされていない場合、2 台の装置で接続状況は共有されません。フェールオーバによる切り替えが発生した時点で、アクティブな接続は失われます。クライアントは、新しいアクティブ装置を介して、接続を再度確立させる必要があります。

質問 実行する必要がある分断および回復のための手順は何ですか。

回答 分断および回復のために必要な手順はありません。

質問 どのようなメンテナンスが必要ですか。

回答 メンテナンス事項はありません。エラーや切り替えが発生すると、syslog および SNMP トラップが生成されます。故障した装置を修理および交換する以外には、実行することは何もありません。

質問 ステートフル・フェールオーバでは、どのような場合にセッションが失われますか。

回答 フェールオーバの発生時に処理中であったパケットに関するデータが失われますが、通常は、TCP セッションがタイムアウトにされない限りは再送信が行われます。サーバおよびブラウザのタイムアウトは、「standby」状態の LocalDirector が再送信を再開する時間よりも長くしておく必要があります。

ステートフル・フェールオーバによりアドレスは変更されません。このため、SSL セッションは、セッションがタイムアウトになる前に冗長システムが回復しない限り、元のまま維持されます。

質問 FDDI 環境でもフェールオーバは動作しますか。

回答 はい、フェールオーバは FDDI でもサポートされています。

質問 冗長構成で使用されている 2 台の LocalDirector のソフトウェアをアップグレードする正しい手順はどのようなものですか。たとえば、どちらの装置を先にアップグレードしますか。

回答 最初に、「プライマリ」装置が「active」モードであることをテストしてください。アクティブである場合、最善の手順は、まず「セカンダリ」装置をオフラインにしてアップグレードします。次に、「プライマリ」装置で「failover active」コマンドを使用し、「セカンダリ」装置を「active」にします。次に、「プライマリ」装置をアップグレードします。この装置を「standby」モードのままにすることができるため、装置を「active」状態に切り替える回数が少なくなります。スタンバイ装置の古い設定のコマンドがすべて実行されたことを確認してください。アップグレードで問題はほとんど発生しませんが、この手順でソフトウェアの以前のバージョンへ戻す場合は、問題が発生することがあります。

アップグレードの途中でマシン上に異なるバージョンのソフトウェアが存在することによる問題は通常は発生しませんが、ソフトウェアのリリースが混在した状態での長期間の使用は推奨できません。個々の装置上で異なるリリースのソフトウェアを使用する場合の問題については、リリース・ノートを確認してください。

質問 ステートフル・フェールオーバのために、どのような装置を追加する必要がありますか。

回答 状態に関する情報を送信するためのファースト・イーサネット・インターフェースが使用可能であれば、「ステートフル・フェールオーバ」の構成を構築するためにハードウェアの追加は必要ありません。

質問 冗長構成の組み合わせに telnet 接続すると、どの装置に接続されますか。

回答 LocalDirector の IP アドレスを使用している場合は、「active」な装置に接続されます。フェールオーバ IP アドレスに対して telnet を実行すると、「standby」装置に接続されます。

質問 LocalDirector のユーザ・インターフェースまたは LUI はどのようにフェールオーバを処理しますか。

回答 この 2 つは独立しています。LUI 3.1 以上でのプローブ機能または CVS(Content Verification System)では、サーバを無効にしますが、LocalDirector は無効にしません。

質問 「active」な LocalDirector が故障して、「standby」装置も「」状態にある場合、どのようになりますか。

回答 両方の装置が「failed」状態になり、処理やブリッジは停止されます。

質問 「failed」した装置は telnet セッションを受け付けますか。

回答 はい、受け付けます。


更新日:2001 年 8 月 10 日