この指示はCoherence*Extend設定に関係するので、BIG-IP構成ユーティリティを使用する場合に特有です。使用方法に関する指示を実行する方法の詳細は、ユーティリティに付属しているヘルプを参照してください。さらに、指示はBIG-IP LTM 10.2.1に基づいて作成されており、将来リリースされるBIG-IP LTMでは正確でなくなる場合があります。
この付録の内容は次のとおりです。
F5 BIG-IP LTMとは、Coherence*Extendクライアント(クライアント層)を実行している1台以上のコンピュータとCoherence*Extendプロキシ・サーバー(プロキシ層)を実行している1台以上のコンピュータとの間にあるハードウェア・デバイスのことです。アプリケーション・トラフィックの保護、最適化およびロード・バランシングに関して多様なテクニックを使用して、LTMによりクライアント接続を複数のクラスタ化プロキシ・サーバーにおいて分散させます。
図B-1は、外部ネットワーク・クライアントと内部ネットワーク・サーバーとの間において設定されているBIG-IPシステムの概念図を示します。
ノードとは、ネットワーク上にある物理リソースのIPアドレスを識別するBIG-IPシステム上の論理オブジェクトのことです。Coherence*Extendの場合、内部ネットワークで1台以上のプロキシ・サーバーをホストする各コンピュータに対してノードを構成します。
ノードを作成するには、次の手順を実行します。
図B-2に、ノード構成例を示します。
ロード・バランシング・プールは、トラフィックを受信および処理する論理デバイス(プロキシ・サーバーなど)のグループです。クライアントのリクエストで指定された送信先IPアドレスにクライアントのトラフィックを送信するのではなく、BIG-IPシステムではそのプールのメンバーであるサーバーにリクエストを送信します。これによって、サーバーのリソースに関して負荷が効率的に分散されます。
プールを作成する際、プール・メンバーをプールに割り当てます。プール・メンバーとは、サーバー・エンドポイントをネットワーク上で示す論理オブジェクトのことです。Coherence*Extendの場合、プロキシ層コンピュータ上で実行している各JVMプロキシ・サーバーに対してプール・メンバーを作成します。
BIG-IPシステムがリクエストの送信先に選択した特定プール・メンバーは、そのプールに割り当てたロード・バランシング方法により判別されます。ロード・バランシング方法とは、リクエストを処理するプール・メンバーを選択するためにBIG-IPシステムで使用するアルゴリズムのことです。たとえば、デフォルトのロード・バランシング方法はラウンド・ロビンで、これによってBIG-IPシステムで各入力リクエストを次に利用可能なプール・メンバーに送信し、プールにあるサーバーにおいてリクエストが均等に分散されます。
この項の内容は、次のとおりです。
ロード・バランシング・プールを作成するには、次の手順を実行します。
図B-3は、プール構成例を示します。
プールのメンバーをロード・バランシング・プールに追加するには、次の手順を実行します。
図B-4は、プール構成例を示します。以前に作成したノード上で2つのプロキシ・サーバー用プール・メンバーが稼働し、ポートの7100と7077をそれぞれリスニングしていることが示されています。さらに、接続数最小型ロード・バランシング・ポリシーを使用するようにプールが構成されます。
仮想サーバーとは、BIG-IPシステム上でIPアドレスとポートで示されるトラフィック管理オブジェクトのことです。外部ネットワークにあるクライアントは、アプリケーション・トラフィックを仮想サーバーに送信できます。それから、構成指示に応じてそのトラフィックが転送されます。仮想サーバーの主な目的は、内部ネットワークにあるサーバーのプールにおいてトラフィックの負荷を分散させることにある場合が多いです。仮想サーバーを使用することで、クライアント・リクエストを処理するためのリソースの可用性が向上します。Coherence*Extendの場合、以前に構成したプロキシ・サーバーのプールにトラフィックを転送するように仮想サーバーを構成する必要があります。
仮想サーバーを作成するには、次の手順を実行します。
BIG-IP LTM仮想サーバーを使用するようにCoherence*Extendを構成する必要があります。クラスタ側とクライアント側のキャッシュ構成ファイルの両方で構成が行われている必要があります。
BIG-IP LTMを使用するようにCoherence*Extendを構成するには、次の手順を実行します。
サーバーが稼働状態にありトラフィックを受信できることをヘルス・モニターにより確認できます。モニターするトラフィックのタイプに応じて、プールに関連付けることができる多様な事前定義済ヘルス・モニターがBIG-IPシステムにはあります。
Coherence*Extendの場合、TCPヘルス・モニターを使用して、プロキシ・サーバーのプールをモニターできます。BIG-IPデバイスがプロキシ・サーバーとTCP/IP接続を確立できる場合に、このタイプのモニターでプロキシ・サーバーがマークアップされます。プロキシ・サーバーが機能していることが示されているとしても、プロキシ・サーバーで実際にクライアントのトラフィックを処理できることは保証されません。より詳細にモニタリングするには、BIG-IPを使用すればカスタム・ヘルス・モニターを作成して、Coherence*Extendのpingリクエストをプロキシ・サーバーに送信して適切なレスポンスが返されることを確認できます。これによって、プロキシ・サーバーが稼働してクライアントのトラフィックを処理できます。
注意:
BIG-IP LTMモニターは、SSL over TCPをサポートしていません。ヘルス・モニタリング・チェック(pingなど)はクリア・テキストで送信されます。プロキシ・サーバーとのすべての通信を確実に保護するには、SSLオフロードを使用します。詳細は、SSLオフロードの有効化を参照してください。
この項の内容は、次のとおりです。
Coherence*Extendのpingリクエストをプロキシ・サーバーに送信して稼働していることを確認するカスタムCoherence*Extendヘルス・モニターを作成する手順は次のとおりです。
図B-7は、カスタムCoherence*Extendヘルス・モニター構成例を示します。
10.2.1より前のバージョンのBIG-IPを使用する解決法では、手動で外部ヘルス・モニターを構成する必要があります。このためには、実行可能ファイルのシェル・スクリプトをextend_ping
の名前でBIG-IPデバイスの/usr/bin/monitors
ディレクトリに作成します。スクリプトの内容は次のようにします。
#! /bin/bash ############################################################################### ### EXTERNAL MONITOR FOR COHERENCE*EXTEND ### INPUTS: ### $1 The IPV6 formatted IP address of the pool member to test ### $2 The port number of the pool member to test ### $3+ White space delimited parms as listed in the monitor "args" ### OUTPUTS: ### If null is returned, the member is "down" ### If any string of one or more characters is returned, the member is "up" ############################################################################### IP=${1:-"127.0.0.1"} IP=${IP##*:} # This removes the leading ::ffff: PORT=${2:-"80"} TIMEOUT=${3:-1} SLEEP=${4:-1} PID_FILE="/var/run/extend_ping.$IP.$PORT.pid" HEX_REQUEST="0700030000420040" HEX_RESPONSE="09000403004200036440" ### ### Terminate existing process, if any ### if [ -f $PID_FILE ] then kill -9 `cat $PID_FILE` > /dev/null 2>&1 fi echo "$$" > $PID_FILE ### ### Ping the server and return a user friendly result ### RESULT=`/bin/echo "$HEX_REQUEST" | /usr/bin/xxd -r -p | /usr/bin/nc -i \ $SLEEP -w $TIMEOUT $IP $PORT | /usr/bin/xxd -p | /bin/grep \ "$HEX_RESPONSE" 2> /dev/null` if [ "$RESULT" != "" ] ; then /bin/echo "$IP:$PORT is \"UP\"" fi rm -f $PID_FILE
extend_ping
スクリプトを使用するようにBIG-IPを構成する手順は次のとおりです。
図B-8は、外部Coherence*Extendヘルス・モニター構成例を示します。
カスタム・ヘルス・モニターはロード・バランシング・プールと関連付ける必要があります。カスタムCoherence*Extendモニターを作成したら、それをCoherence*Extendロード・バランシング・プールと関連付けます。
カスタム・ヘルス・モニターをロード・バランシング・プールと関連付けるには、次の手順を実行します。
図B-9は、カスタム・ヘルス・モニターを使用するCoherence*Extendプールを示します。
SSLを使用するようにCoherence*Extendを構成して、クライアントとプロキシ・サーバーのプロセスとの間における通信を保護できます。ただし、これには代償があります。特に、SSLを有効にすると、プロキシ層のCPU使用率が劇的に上昇し、各リクエストの待機時間が長くなります。プライバシの理由で保護されているデータの暗号化と復号化の困難な処理からプロキシ・サーバーが、BIG-IP SSL Accelerationにより解放されます。SSLトランザクションをより効率的に処理するように設計されている高いパフォーマンスのデバイスに、CPU負荷の高い復号化処理が移行されます。この手法はSSLオフロードと知られています。
SSLオフロードを有効にするには、次の手順を記載順に実行する必要があります。
サーバーのSSL証明書とキーをBIG-IPシステムにインポートする手順は、次のとおりです。
図B-10は、サーバーSSL証明書構成例を示します。
クライアントSSLプロファイルを作成するには、次の手順を実行します。
図B-11は、クライアントSSLプロファイル構成例を示します。
クライアントSSLプロファイルを使用するようにCoherence*Extend仮想サーバー構成を変更する手順は次のとおりです。
図B-12は、クライアントSSLプロファイルを使用する仮想サーバー構成例を示します。