この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、Content Switching Module(CSM;コンテント スイッチング モジュール)上でヘルス モニタリングを設定する方法について説明します。
実サーバへのヘルス プローブを設定すると、実サーバが正しく動作しているかどうかを調べることができます。実サーバの状態は次のように分類されます。
• サスペクト ― 実サーバに到達できないか、または無効な応答が戻ります。プローブは再試行されます。
• 失敗 ― 指定回数だけ続けて再試行したあと、実サーバは応答に失敗します。失敗という情報が通知されると、CSMは着信接続を相応に調整します。サーバが再びアクティブになるまで、プローブは失敗状態のままです。
CSMは、実サーバのモニタに使用されるプローブをサポートします。プローブを設定する手順は、次のとおりです。
CSMはFTP、Domain Name System(DNS;ドメイン ネーム システム)、HTTPなど、実サーバをモニタするさまざまなプローブ タイプをサポートします。
(注) デフォルトでは、CSM上にプローブは設定されていません。
ヘルス プローブ モニタリング用にCSMを設定する場合は、次の動作を含む多層的アプローチを使用することができます。
• アクティブ プローブ ― これらのプローブを定期的に実行します。Internet Control Message Protocol(ICMP)、TCP、HTTP、およびその他の前もって定義されたヘルス プローブはこのカテゴリに入ります。スクリプト化されたヘルス プローブもここに入ります。アクティブなプローブは、セッションのセットアップまたはシステムのティアダウンに影響しません。
• パッシブ モニタリング(帯域内ヘルス モニタリング) ― サーバをサービス対象外にする可能性のある破壊的なエラー(たとえば、サーバからのリセット[RST]やサーバからの応答なし)が発生していないかセッションをモニタします。これらのヘルス チェックは、フルセッション レートで動作し、サーバの故障を迅速に認識します。
• パッシブHTTPエラー コード チェック(帯域内応答解析) ― CSMは、HTTP戻りコードを解析し、サーバが使用不可になる「サービス利用不可」のようなコードを監視します。パッシブHTTPエラー コード チェックは、セッションのパフォーマンスにはほとんど影響しません。
プローブを用意するには、プローブ サブモードでプローブに名前を付け、プローブ タイプを指定して、プローブを設定する必要があります。
プローブを設定したあとで、プローブを実サーバ ファームに関連付けて、有効にする必要があります。サーバ ファーム内のすべてのサーバは、このサーバ ファームに関連付けられたプローブ タイプのプローブを受信します。1つのサーバ ファームに1つまたは複数のプローブ タイプを関連付けることができます。
実サーバまたは仮想サーバの設定時にポート番号を割り当てる場合は、プローブの設定時にポート番号を指定する必要はありません。プローブは実サーバまたは仮想サーバ コンフィギュレーションからポート番号を引き継ぎます。
ヘルス プローブ コンフィギュレーションでオプションのヘルス プローブ ポート機能を使用し、プローブにポートを明示的に指定することによって、実サーバまたは仮想サーバのポート情報を変更できます。この機能を使用すると、実サーバまたは仮想サーバでポートが指定されていない場合に、ヘルス プローブに使用させるポートを設定できます。
プローブを設定してから、サーバ ファームに1つまたは複数のプローブを関連付けます。サーバ ファーム内のすべてのサーバは、このプールに関連付けられたプローブ タイプのプローブを受信します。
(注) 対応するサービスが動作していない実サーバを含むサーバ ファームに特定タイプのプローブが関連付けられている場合に、そのタイプのプローブを受信すると、実サーバはエラー メッセージを送信します。その結果、CSMが実サーバを失敗ステートにして、サーバ ファームからその実サーバを使用できないようにします。
プローブのタイプおよび名前を指定する手順は、次のとおりです。
|
|
|
---|---|---|
|
• • • • • • • • • |
|
|
プローブ用のオプション ポートを設定します3。 |
|
|
||
|
1.設定からプローブ タイプを削除するには、no形式を使用します。 2.パフォーマンス アラートを受信した場合、帯域内ヘルス モニタリングの方が、よりスケーラブルなソリューションになります。 |
(注) プローブの名前およびタイプを指定すると、最初にデフォルト値が設定されます。デフォルト設定を変更するには、プローブ コンフィギュレーション コマンドを入力します。
(注) タイムアウト値にはopenとreceiveの2種類があります。openのタイムアウトでは、接続のオープンを待機する秒数(SYNの送信後、SYN ACKを待つ秒数)を指定します。receiveのタイムアウトでは、データの受信を待機する秒数(GET/HEAD要求の送信後、HTTP応答を待つ秒数)を指定します。TCPプローブは、オープンするとデータを送信しないでただちにクローズされるので、receiveのタイムアウトは使用しません。
|
|
---|---|
|
|
|
サーバを失敗としてマークするまでに許容されたプローブの失敗回数を設定します1。 |
|
サーバが失敗としてマークされた場合にヘルス チェックを行う間隔を設定します。この時間は秒単位です1。 |
|
失敗状態のサーバを正常としてマークするまでに連続して受信する応答数を設定します1。 |
|
TCP接続を待機する最大時間を設定します。このコマンドはTCP以外のヘルス チェック(ICMPまたはDNS1)には使用しません。 |
|
4.デフォルトの設定に戻すには、このコマンドのno形式を使用します。 5.パフォーマンス アラートを受信した場合、帯域内ヘルス モニタリングの方が、よりスケーラブルなソリューションになります。 |
HTTPプローブは実サーバに対するHTTP接続を確立し、HTTP要求を送信して、応答を確認します。probe probe-name httpコマンドを実行すると、HTTPプローブ コンフィギュレーション サブモードが開始されます。
|
|
|
---|---|---|
|
HTTPプローブを設定して、HTTPプローブ サブモードを開始します1。 |
|
|
HTTP SLBプローブの基本認証値を設定します6。 |
|
|
HTTPプローブから戻ることが予測されるステータス コードを設定します。expect statusコマンドを一度に1つずつ入力することによって、複数のステータス範囲を設定できます1。 min-number ― max-numberを指定しなかった場合、この値が単一のステータス コードになります。最大数を指定した場合、この値がステータス コード範囲の下限になります。 max-number ― ステータス コード範囲の上限です。デフォルト値は0~999(サーバからの応答はどれも有効)です。 ![]() (注) 上限を指定しなかった場合、このコマンドには単一の値(min-number)が設定されます。最小数と最大数の両方を指定した場合、このコマンドには範囲が設定されます。 |
|
|
HTTPプローブのヘッダー フィールドを設定します。複数のヘッダー フィールドを指定できます1。 |
|
|
HTTPプローブで使用する要求メソッドを設定します1。 • • • ![]() (注) CSMがサポートするのは、getおよびhead要求メソッドだけです。postおよびその他のメソッドはサポートしません。デフォルトのメソッドはgetです。 |
ICMPプローブはICMPエコー(pingなど)を実サーバに送信します。probe icmpコマンドを入力すると、ICMPプローブ コンフィギュレーション モードが開始されます。一般的なprobeコマンドはすべてサポートされていますが、openコマンドはサポートされずに無視されます。
|
|
|
---|---|---|
|
ICMPプローブを設定して、ICMPプローブ サブモードを開始します7。 |
|
|
||
|
||
|
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プローブを使用します。Toolkit Command Language(TCL)スクリプトを使用すると、このプローブを設定できます。 第10章「CSMでのTCLスクリプトの使用」 を参照してください。
|
|
|
---|---|---|
|
UDPプローブを設定して、UDPプローブ サブモードを開始します8。 |
|
|
||
|
||
|
TCPプローブは接続を確立および解除します。probe tcpコマンドを入力すると、TCPプローブ コンフィギュレーション モードが開始されます。一般的なprobeコマンドはすべてサポートされます。
|
|
|
---|---|---|
|
TCPプローブを設定して、TCPプローブ サブモードを開始します9。 |
|
|
||
|
FTP、SMTP、またはTelnetプローブは実サーバへの接続を確立し、アプリケーションからグリーティングが届いたかどうかを検証します。probe(ftp、smtp、またはtelnet)コマンドを実行すると、対応するプローブ コンフィギュレーション モードが開始されます。一般的なprobeコマンド オプションはすべてサポートされます。一度に1つずつコマンドを実行することによって、複数のステータス範囲を指定できます。
FTP、SMTP、またはTelnetプローブから戻ることが予測されるステータス コードを設定する手順は、次のとおりです。
|
|
|
---|---|---|
|
FTP、SMTP、またはTelnetプローブを設定し、FTP、SMTP、またはTelnetプローブ サブモードを開始します10。 |
|
|
||
|
||
|
DNSプローブは実サーバにドメイン名解決要求を送信し、戻されたIPアドレスを確認します。probe dns コマンドを実行すると、DNSプローブ コンフィギュレーション サブモードが開始されます。一般的なprobeコマンドはすべてサポートされますが、openはサポートされずに無視されます。
|
|
|
---|---|---|
|
DNSプローブを設定して、DNSプローブ サブモードを開始します11。 |
|
|
DNS接続を行うためのプローブ間の待機間隔、サーバから応答を受信する時間、および実サーバが失敗したとみなされるまでの再試行回数の上限を指定します。 |
接続のバランスを図るために、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サーバ応答で戻りコードを解析しなければなりません。
戻りエラー コード チェックを設定するには、サーバ ファームの属性を設定し、サーバ ファームを戻りコード マップと関連付ける必要があります。
ステップ 1 HTTP仮想サーバが設定されていることを確認します( リダイレクト仮想サーバの設定を参照)。
ステップ 2 マップ戻りコード コマンドを入力して戻りコードのマッピングをイネーブルに設定し、戻りコード マップ サブモードを開始します。
ステップ 4 戻りコード マップをサーバ ファームに割り当てます。
次に、戻りエラー コード チェックをイネーブルにする例を示します。