Catalyst 6500 シリーズ スイッチ コンテント スイッチング モジュール インストレーション コンフィギュレーション ノート Software Release 4.1(2)

プローブ コンフィギュレーション コマンド

次に示すコマンドはすべてのプローブ タイプに共通です。

HTTPプローブの設定

HTTPプローブは実サーバに対するHTTP接続を確立し、HTTP要求を送信して、応答を確認します。 probe probe-name httpコマンドを実行すると、HTTPプローブ コンフィギュレーション サブモードが開始されます。

HTTPプローブを設定する手順は、次のとおりです。

	コマンド	目的
ステップ 1	Router(config-module-csm)# probe probe-name http	HTTPプローブを設定して、HTTPプローブ サブモードを開始します1。
ステップ 2	Router(config-slb-probe-http)# credentials username [ password ]	HTTP SLBプローブの基本認証値を設定します6。
ステップ 3	Router(config-slb-probe-http)# expect status min-number [ max-number ]	HTTPプローブから戻ることが予測されるステータス コードを設定します。 expect statusコマンドを一度に1つずつ入力することによって、複数のステータス範囲を設定できます1。 min-number－max-numberを指定しなかった場合、この値が単一ステータス コードになります。 最大数を指定した場合、この値がステータス コード範囲の下限になります。 max-number－ステータス コード範囲の上限です。 デフォルト値は 0～999（サーバからの応答はいずれも有効）です。 （注） 上限を指定しなかった場合、このコマンドには単一の値（min-number）が設定されます。 最小数と最大数の両方を指定した場合、このコマンドには範囲が設定されます。
ステップ 4	Router(config-slb-probe-http)# header field-name [ field-value ]	HTTPプローブのヘッダー フィールドを設定します。 複数のヘッダー フィールドを指定できます1。
ステップ 5	Router(config-slb-probe-http)# request [ method [ get | head ]] [ url path ]	HTTPプローブで使用する要求メソッドを設定します1。 • get－HTTP get 要求メソッドは、このページを取得するようにサーバに指示します。 • head－HTTP head要求メソッドは、このページのヘッダーだけを取得するように、サーバに指示します。 • url－最大 1275 文字の文字列で URL パスを指定します。デフォルトでは「/」です。 （注） CSM がサポートしているのは、get および head 要求メソッドだけです。post およびその他のメソッドはサポートしません。 デフォルトのメソッドはgetです。

ICMP プローブの設定

ICMP プローブは ICMP エコー（ping など）を実サーバに送信します。 probe icmpコマンドを入力すると、ICMPプローブ コンフィギュレーション モードが開始されます。 一般的なprobeコマンドはすべてサポートされていますが、openコマンドはサポートされずに無視されます。

UDPプローブを設定する手順は、次のとおりです。

UDP プローブの設定

ICMP がないと UDP プローブはサーバのダウンまたはサーバの切断を検出できないため、UDP プローブには ICMP が必要です。 UDP をスーパーバイザ エンジンに関連付けて、ICMP を設定する必要があります。

UDP プローブは Raw UDP プローブのため、CSM はプローブの応答ペイロードに単一のバイトを使用します。 CSM は UDP アプリケーションから意味のある応答がくることを想定していません。 CSM は ICMP 到達不能メッセージを使用して、UDP アプリケーションが到達可能かどうかを判断します。 受信タイムアウトで ICMP 到達可能の応答がない場合でも、CSM はプローブが正常と判断します。 実サーバのIPインターフェイスがダウンまたは切断された場合、UDP プローブは自身で UDP アプリケーションが到達不能になっていることを判断できません。 指定のサーバの UDP プローブのほかに ICMP プローブを設定する必要があります。

CSM は高レベル UDP アプリケーションとして DNS プローブを使用します。 また、TCL スクリプトを使用してこのプローブを設定することもできます。 第 10 章「CSM の TCL スクリプトの使用」 を参照してください。

UDP プローブを設定する手順は、次のとおりです。

TCPプローブの設定

TCP プローブは接続を確立および解除します。 probe tcpコマンドを入力すると、TCPプローブ コンフィギュレーション モードが開始されます。 一般的なprobeコマンドはすべてサポートされます。

TCPプローブを設定する手順は、次のとおりです。

FTP、SMTP、およびTelnetプローブの設定

FTP、SMTP、または Telnet プローブは実サーバへの接続を確立し、アプリケーションからグリーティングが届いたかどうかを検証します。 probe（ftp、smtp、またはtelnet）コマンドを実行すると、対応するプローブ コンフィギュレーション モードが開始されます。 一般的なprobeコマンド オプションはすべてサポートされます。 一度に1つずつコマンドを実行することによって、複数のステータス範囲を指定できます。

FTP、SMTP、またはTelnetプローブから戻ることが予測されるステータス コードを設定する手順は、次のとおりです。

DNS解決要求の指定

DNSプローブは実サーバにドメイン名解決要求を送信し、戻されたIPアドレスを確認します。 probe dns コマンドを実行すると、DNSプローブ コンフィギュレーション サブモードが開始されます。 一般的なprobeコマンドはすべてサポートされますが、openはサポートされずに無視されます。

ドメイン名解決要求を指定する手順は、次のとおりです。

帯域内ヘルス モニタリングの概要

効率的な接続バランスを設計するには、CSM はコンフィギュレーションに含まれているすべての実サーバの状態をたえずモニタしていなければなりません。 帯域内ヘルス モニタリング機能を各サーバ ファームに設定し、サーバの状態をモニタします。 サーバ ファームごとに設定されたパラメータは、そのサーバ ファーム内の個々の実サーバに適用されます。 実サーバが到達不能とみなされるまでに許容される、セッションの異常終了回数を設定できます。また、実サーバをサーバ ファームに再び組み込み、接続を試行するまでの待機時間も指定できます。

この機能は、ヘルス プローブと連動します。 あるサーバにヘルス プローブと帯域内ヘルス モニタリングを両方とも設定した場合、サーバ ファーム内の実サーバでサービスを維持するには、両方のヘルス チェック セットを実行する必要があります。 どちらか一方のヘルス チェック機能でサーバの停止が検出された場合、CSMはロードバランスの対象としてそのサーバを選択しません。

帯域内ヘルス モニタリングの設定

帯域内ヘルス モニタリングを設定する手順は、次のとおりです。

ステップ 1 サーバ ファームが設定されていることを確認します （「サーバ ファームの設定」を参照）。

ステップ 2 serverfarm サブモード コマンドを入力し、各サーバ ファームに対して帯域内ヘルス モニタリングをイネーブルにします。

（注） retriesでは、実サーバをサービスから除外するまでにCSMが許容する、セッションの異常終了回数を指定します。 failedでは、帯域内ヘルス チェックによってサービスから除外された実サーバへの接続を再試行するまでに、CSMが待機する時間を秒単位で指定します。

次に、geoというサーバ ファームに対して帯域内ヘルス モニタリングをイネーブルにする例を示します。

HTTP リターン コード チェックの概要

リターン エラー コード チェック（リターン コード解析）機能は、サーバがいつWebページを正しく返さなかったかを調べる場合に使用します。 この機能は、CSM のパケットを調べる機能を拡張し、HTML リターン コードを解析し、サーバが戻したリターン コードに作用します。

CSM から HTTP 要求を受信したサーバは、HTTP リターン コードを使用して応答します。 CSM はこの HTTP リターン エラー コードを使用することによって、サーバの可用性を判別できます。 特定のリターン コードを受け取った場合に、サーバを使用停止にするように CSM を設定できます。

RFC 2616 で、定義済みコードのリスト（100～599）が指定されています。リターン コードをチェックする場合、一部のコードは特に有効です。 たとえば、404というリターン コードは、URL が見つからなかったという定義です。これは、ユーザが URL を正しく入力しなかった結果である可能性があります。 エラー コード 404 は、不良ディスク ドライブが原因で Web サーバが要求されたデータを見つけられなかった場合など、Web サーバのハードウェアの問題を意味することもあります。 この場合、Web サーバそのものはアクティブですが、ディスク ドライブが故障しているので、要求されたデータを送信できません。 サーバがデータを返せないかぎり、そのサーバには今後、データ送信を要求しないでおくべきです。 リターン コード チェックで使用するエラー コードを特定する場合は、RFC 2616 を参照してください。

HTTP リターン コード チェックを設定すると、CSM はロードバランス対象のすべての HTTP 接続から送信されたHTTP 応答をモニタし、実サーバごとにリターン コードの発生を記録します。 CSM はリターン コードのカウントを保存します。 リターン コードがスレッシュホールドに達した場合、CSM は syslog メッセージを送信したり、またはサーバをサービスから除外したりすることができます。

デフォルトの動作、リターン コードのカウント、syslog メッセージの送信を適用できます。またはサービスから実サーバを削除できます。 これらの動作または一連のこれらの動作をサーバ ファームに適用できます。 1 つの仮想グループを複数のサーバ ファームにバインドすることによって、複数のサーバ ファームで 1つのリターン コード サーバ ファーム ポリシーを再利用することもできます。

（注） 仮想サーバにHTTP リターン コード チェックを設定すると、その仮想サーバのパフォーマンスが低下します。 リターン コードの解析をイネーブルにした場合、あらゆる HTTP サーバ応答でリターン コードを解析しなければなりません。

HTTP リターン コード チェックの設定

リターン エラー コード チェックを設定するには、サーバ ファームの属性を設定し、サーバ ファームをリターン コード マップと関連付ける必要があります。

リターン コード チェックを設定する手順は、次のとおりです。

ステップ 1 HTTP仮想サーバが設定されていることを確認します （「リダイレクト仮想サーバの設定」を参照）。

ステップ 2 マップ リターン コード コマンドを入力してリターン コードのマッピングをイネーブルに設定し、リターン コード マップ サブモードを開始します。

ステップ 3 リターン コードの解析を設定します。

マップで必要とされる照合件数を設定できます。

ステップ 4 リターン コード マップをサーバ ファームに割り当てます。

次に、リターン エラー コード チェックをイネーブルにする例を示します。