アプリケーション ネットワーキング サービス : Cisco LocalDirector 400 シリーズ

LocalDirector に関する FAQ

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2003 年 12 月 1 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


LocalDirector はすでに販売終了となっています。 詳細は、Cisco LocalDirector 400 シリーズの速報を参照してください。


質問


概要

Local Director は、インテリジェントに複数のサーバ間で TCP/IP のトラフィックをロード バランシングする、ハイ アベイラビリティを備えたインターネット スケーラブル ソリューションです。 サーバは、サービスを自動的かつ透過的に開始または停止できます。 Local Director はホット スタンバイのフェールオーバー メカニズムを備えており、サーバ ファームのすべての障害ポイントが排除されます。

このドキュメントでは、Local Director に関するよく寄せられる質問(FAQ)の回答を示します。

Q. Local Director のインターフェイスはいくつ必要ですか。

A. 少なくとも 2 つのインターフェイスが必要です。 これらは、スイッチ内の別々の仮想 LAN(VLAN)、または 2 つの別個のハブで分離される必要があります。

Q. Local Director にセカンダリ アドレスをどのように割り当てますか。

A. Local Director ソフトウェア バージョン 3.1.3 で初めて導入された alias ip address コマンドを実行します。 フェールオーバー モードの場合、これに加えて failover alias ip address コマンドを実行する必要もあります。

Q. Local Director によってどのように実サーバの障害が発生しますか。

A. デフォルトで、Local Director はサーバのアベイラビリティを判別する際に 2 つのメトリック(No Answer Reassign および TCP Reset Reassign)を追跡します。 しきい値および再割当て値を使用して、サーバ障害メカニズムを調整できます。

Q. Local Director 3.1.3 が、失敗した SSL スティッキ接続を再び割り当てないのはなぜですか。

A. この問題は、Secure Sockets Layer(SSL)スティッキが最初に導入された Local Director 3.1.3 で初めて発生するようになりました。 この問題は Cisco Bug ID CSCdp03095登録ユーザ専用)に記述されています。

Q. 最小接続プレディクタを使用する際に、Local Director 3.1.3 が接続を正常に減らさないのはなぜですか。

A. この問題は Cisco Bug ID CSCdp09265登録ユーザ専用)に記述されています。

Q. Local Director 3.1.3 がスタンバイ ユニットに設定を正しく複製しません。 これは、なぜですか。

A. この問題は、LocalDirector バージョン 3.1.3 で初めて発生するようになりました。 Cisco Bug ID CSCdm47752登録ユーザ専用)を参照してください。

Q. SSL スティッキと Internet Explorer 5.0 の問題の回避策は何ですか。

A. ブラウザとして IE 5.0 を使用し、Local Director コード 3.1.x 以降を使用する Local Director を介して SSL セッションを開始するクライアントが、この問題の影響を受けます。 セッションの持続性を維持するために SSL スティッキを使用するよう LocalDirector が設定されている場合、SSL ID が作成されます。 Local Director は特定の実サーバに SSL セッション ID(SID)をマッピングします。 IE 5.0 は 30 秒から 2 分までの間に SSL SID をリセットします。 これにより、セッション持続性を維持するために LocalDirector が使用する情報が無効になります。

SSL アプリケーションでセッション持続性を維持するには、HTTP リダイレクションまたは 汎用スティッキを参照してください。

Q. Local Director 3.1.3 コードを実行すると、SSL スティッキが機能しません。 これは、なぜですか。

A. この問題の対処法はほとんどありません。 とはいえ、次を試みることができます:

  1. SSL バージョン 3 だけをサポートするように Web サーバが設定されていることを確認します。
  2. Local Director でデフォルト ルートを設定します(初期接続がプロキシされるようになります)。 現時点で入手可能な最新リリースにアップグレードすることを強く推奨します(詳細についてはリリース ノートを参照)。
  3. 最後の手段として、問題を正確に特定するためスニファ トレースを実行できます。
  4. サード パーティによる転送の干渉が発生しなかったことを確認するために、検証 - 最終チェックがサーバ側とクライアント側で行われます。 サーバ側とクライアント側で転送の有効性が確認されると、ハンドシェイクが完了します。 確認できない場合、元のハンドシェイクで発生した可能性のあるインターセプトまたは問題を修正しようとして、ハンドシェイクが再度実行されます。

Q. SSL スティッキはどんな用途で使用されますか。

A. Local Director の SSL スティッキは、SSL アプリケーションが使用されるときにセッション持続性を維持します。 SSL は暗号化された伝送手段であるため、クライアントからのトラフィックを識別して確実に同じ実サーバに送るために Local Director で使用できる変数は限られています。 Local Director は、SSL ハンドシェイク プロトコル中にクライアントとサーバの間で作成される SSL SID を使用します。 SSL ハンドシェイク プロトコルを単純化すると、次のとおりです:

  1. クライアント Hello - クライアントでサポートされる暗号化アルゴリズムをサーバに通知し、サーバの ID の検証を求めます。 SSL SID が生成されます。
  2. サーバ Hello - クライアントにデジタル ID を送信し、セッションで使用する暗号アルゴリズムおよび圧縮アルゴリズムを決定します。 SSL セッション ID が確認され、応答で使用されます。
  3. クライアント認証 - サーバの信頼性を検証します。 サーバが検証されると、クライアントは秘密キーを生成し、サーバ Hello で提供されたサーバの公開キーを使って暗号化します。 次いでクライアントは暗号化された秘密キーをサーバに送信します。
  4. サード パーティによる転送の干渉が発生しなかったことを確認するために、検証 - 最終チェックがサーバ側とクライアント側で行われます。 サーバ側とクライアント側で転送の有効性が確認されると、ハンドシェイクが完了します。 確認できない場合、元のハンドシェイクで発生した可能性のあるインターセプトまたは問題を修正しようとして、ハンドシェイクが再度実行されます。

Q. Local Director 仮想サブネットとは異なるサブネットに実サーバを置けますか。

A. はい。 これを実現するために、少なくとも 2 つのネットワーク設定が可能です。

/image/gif/paws/15062/locdirfaq-1.gif

条件

  • Local Director の IP アドレスが 192.1.1.10 255.255.255.0 です。

  • Local Director に対するルータのインターフェイスが 192.1.1.1 255.255.255.0 です。

  • 実サーバは 204.1.1.20 です。

次に実行するコマンド

  • ルータのインターフェイスでセカンダリ アドレスを追加します。 例:204.1.1.1 255.255.255.0。 このアドレスは実サーバと同じサブネット上である必要があります。

  • 実サーバのデフォルト ゲートウェイを 204.1.1.1 に変更します。

  • Local Director のデフォルト ゲートウェイが 192.1.1.1 であることを確認します。

  • また、Local Director で 3.x コードを実行している場合は、エイリアス IP アドレス 204.1.1.10 も追加します。

/image/gif/paws/15062/locdirfaq-2.gif

条件

  • Local Director の IP アドレスが 192.1.1.10 255.255.255.0 です。

  • Local Director に対するルータ 1 のインターフェイスが 192.1.1.1 255.255.255.0 です。

  • Local Director に対するルータ 2 のインターフェイスが 192.1.1.2 255.255.255.0 です。

  • 実サーバは 204.1.1.20 です。

次に実行するコマンド

  • Local Director でルート 204.1.1.0 255.255.255.0 192.1.1.2 を追加して、実サーバのトラフィックを 2 番目のルータに転送できるようにします。

Q. 実サーバのパケットが Local Director を通過してファイアウォールでドロップされることを検出した場合、どうすべきですか。

A. Local Director がテーブルから接続を削除した後、サーバからの FIN(または ACK)パケットの再送信が発生する可能性があります。 構成に secure コマンドを追加すると、Local Director でこのような要求をブロックするように設定できます。 これにより、ロード バランスされた接続に属さないすべてのパケットがブロックされます。 もう一つの解決策として、delay コマンドを構成に追加できます。 このコマンドは、数分後に接続を削除します。 コマンドに関する詳細については、Local Director 4.2 バージョンのコマンド リファレンスを参照してください。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 15062