本章では、ロード・バランシング・パラメーターの構成方法と、拡張機能に関する Load Balancer のセットアップ方法について説明します。
タスク | 説明 | 関連情報 |
---|---|---|
ロード・バランシングを行っているマシン上の Load Balancer を連結する | 連結された Load Balancer マシンをセットアップします。 | 連結サーバーの使用 |
ハイ・アベイラビリティーまたは相互ハイ・アベイラビリティーを構成する | 2 番目の Dispatcher マシンをセットアップしてバックアップを提供します。 | ハイ・アベイラビリティー |
ルール・ベースのロード・バランシングを構成する | サーバーのサブセットが使用される条件を定義します。 | ルール・ベースのロード・バランシングの構成 |
ポート類縁性のオーバーライドを使用して、サーバーがポート・スティッキー機能をオーバーライドするメカニズムを提供する | サーバーは、そのポートのスティッキー時間の設定をオーバーライドできます。 | ポート類縁性のオーバーライド |
スティッキー (類縁性機能) を使用して、クラスターのポートをスティッキーになるように構成する | クライアント要求を同じサーバーに送信できます。 | Load Balancer の類縁性機能の動作 |
ポート間類縁性を使用して、スティッキー (類縁性) 機能をポート全体に拡張する | 異なるポートから受け取ったクライアント要求を、同じサーバーに送信できます。 | ポート間類縁性 |
類縁性アドレス・マスクを使用して、共通の IP サブネット・アドレスを指定する | 同じサブネットから受け取ったクライアント要求を、同じサーバーに送信できます。 | 類縁性アドレス・マスク (stickymask) |
活動中の cookie の類縁性を使用して、CBR のサーバーのロード・バランシングを行う | セッションにおいて特定サーバーの類縁性を保守できるルール・オプションの 1 つ。 | 活動 Cookie 類縁性 |
受動 Cookie の類縁性を使用して、Dispatcher の Content Based Routing (CBR) および CBR コンポーネントについてサーバーのロード・バランシングを行う | セッションにおいて Cookie 名/Cookie 値を基にして特定サーバーの類縁性を保守できるルール・オプションの 1 つ。 | 受動 cookie 類縁性 |
URI の類縁性を使用して、個々の各サーバーのキャッシュに入れる固有のコンテンツがある Caching Proxy サーバーにわたってロード・バランシングを行う | セッションにおいて URI を基にして特定サーバーの類縁性を保守できるルール・オプションの 1 つ。 | URI 類縁性 |
広域 Dispatcher サポートを構成する | リモート Dispatcher をセットアップして、広域ネットワークにわたるロード・バランシングを行います。あるいは、GRE をサポートするサーバー・プラットフォームを使用して (リモート Dispatcher を使用しない) 広域ネットワークにわたるロード・バランシングを行います。 | 広域 Dispatcher サポートの構成 |
明示リンクを使用する | リンクで Dispatcher をバイパスしないようにします。 | 明示リンクの使用 |
プライベート・ネットワークを使用する | Dispatcher を構成して、プライベート・ネットワークにあるサーバーのロード・バランシングを行います。 | プライベート・ネットワーク構成の使用 |
ワイルドカード・クラスターを使用して、共通のサーバー構成を結合する | 明示的に構成されていないアドレスでは、トラフィックのロード・バランシングを行うための方法としてワイルドカード・クラスターが使用されます。 | ワイルドカード・クラスターを使用したサーバー構成の結合 |
ワイルドカード・クラスターを使用して、ファイアウォールのロード・バランシングを行う | ファイアウォールに対して、すべてのトラフィックのロード・バランシングが行われます。 | ワイルドカード・クラスターを使用したファイアウォールのロード・バランシング |
透過プロキシーに Caching Proxy とワイルドカード・クラスターを使用する | 透過プロキシーを使用可能にするために Dispatcher を使用できるようにします。 | 透過プロキシーに Caching Proxy とワイルドカード・クラスターを使用 |
ワイルドカード・ポートを使用して、構成されていないポートのトラフィックを送信する | 特定のポートに対して構成されていないトラフィックを処理します。 | ワイルドカード・ポートを使用した未構成ポート・トラフィックの送信 |
「サービス妨害攻撃 (Denial of Service Attack)」を使用して、潜在的なアタックを管理者に (アラートによって) 通知する | Dispatcher は、サーバーでハーフ・オープン TCP 接続の著しい量の受信要求を分析します。 | サービス妨害攻撃の検出 |
バイナリー・ログを使用して、サーバーの統計を分析する | サーバー情報をバイナリー・ファイルに保管して検索できるようにします。 | バイナリー・ログを使用したサーバー統計の分析 |
連結クライアント構成を使用する | Load Balancer をクライアントと同一マシン上に 常駐できるようにします。 | 連結クライアントの使用 |
Load Balancer は要求のロード・バランシングを行っているサーバーと同じマシン上に常駐できます。 これは一般に、サーバーの 連結 と呼ばれています。連結は、Dispatcher および Site Selector コンポーネントに適用されます。 また、CBR の場合は、バインド特定 Web サーバーおよびバインド特定 Caching Proxy を使用するときに限り、連結がサポートされています。
Linux: MAC 転送方式を使用して Dispatcher コンポーネントを実行している時に、連結とハイ・アベイラビリティーを両方とも同時に構成するためには、Linux における Load Balancer の MAC 転送の使用時のループバック別名割り当ての代替手段を参照してください。
Solaris: エントリー・ポイント Dispatcher が連結されているときに WAN advisor を構成できないという制限があります。Dispatcher の広域サポートとリモート advisor の使用を参照してください。
Windows: 連結は現在使用されていません。
以前のリリースでは、連結サーバーのアドレスは構成内の非転送先アドレス (NFA) と同じになるように指定する必要がありました。この制限は、取り除かれました。
サーバーが連結されるように構成するために、dscontrol server コマンドには、yes または no に設定できる、collocated というオプションが提供されます。 デフォルトは no です。サーバーのアドレスは、マシン上のネットワーク・インターフェース・カードの有効な IP アドレスでなければなりません。 Dispatcher の NAT または CBR 転送方式で連結したサーバーには、 collocated パラメーターを設定しないでください。
連結サーバーは、次の方法のいずれかで構成できます。
Dispatcher の NAT または CBR 転送については、 NFA 上で未使用のアダプター・アドレスを構成する (別名を割り当てる) 必要があります。 サーバーは、このアドレスに対して listen するように構成します。 次のコマンド構文を使用してサーバーを構成してください。
dscontrol server add cluster:port:new_alias address new_alias router router_ip returnaddress return_address
この構成をしないと、システム・エラーが出されるか、 サーバーからの応答が得られないか、その両方につながります。
Dispatcher の nat 転送メソッドを使用して連結サーバーを 構成する場合、dscontrol server add コマンドで指定するルーターは、 サーバーの IP アドレスではなく、ルーターの実アドレスでなければなりません。
現在、次のオペレーティング・システムでは、Dispatcher マシンで以下のステップを実行すれば、Dispatcher の NAT 転送方式の構成時における連結をサポートすることができます。
arp -s hostname ether_addr pubether_addr にはローカル MAC アドレスが入ります。 これで、ローカル・アプリケーションはカーネル内のリターン・アドレスにトラフィックを送信することができます。
CBR は AIX、HP-UX、Linux、および Solaris プラットフォームで連結をサポートし、追加構成を必要としません。しかし、使用される Web サーバーおよび Caching Proxy はバインド固有でなければなりません。
Site Selector は AIX、HP-UX、Linux、および Solaris プラットフォームで連結をサポートし、追加構成を必要としません。
ハイ・アベイラビリティー機能 (dscontrol highavailability コマンドで構成可能) は、Dispatcher コンポーネントに使用可能 (CBR または Site Selector コンポーネントでは使用不可) です。
Dispatcher の可用性を向上させるために、Dispatcher の高可用性機能は以下のメカニズムを使用します。
可能な場合には、heartbeat ペアの少なくとも 1 つを、 通常のクラスター・トラフィックではなく別個のサブネットにまたがるようにしてください。 heartbeat トラフィックを別個に保持すると、非常に重いネットワーク負荷の最中に起こる偽の引き継ぎを防ぎ、 フェイルオーバー後の完全なリカバリーの時間を短縮させます。
dscontrol highavailability の完全な構文は、dscontrol highavailability — 高可用性の制御 を参照してください。
下記のタスクの多くについて詳しくは、Dispatcher マシンのセットアップ を参照してください。
dscontrol highavailability heartbeat add sourceaddress destinationaddress
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3少なくとも 1 つの heartbeat ペアには、送信元アドレスおよび宛先アドレスとしてそのペア の NFA が必要です。
可能な場合には、heartbeat ペアの少なくとも 1 つを、 通常のクラスター・トラフィックではなく別個のサブネットにまたがるようにしてください。 heartbeat トラフィックを別個に保持すると、非常に重いネットワーク負荷の最中に起こる偽の引き継ぎを防ぎ、 フェイルオーバー後の完全なリカバリーの時間を短縮させます。
実行プログラムが高可用性 heartbeat のタイムアウトに使用する秒数を設定してください。以下に例を示します。
dscontrol executor set hatimeout 3
デフォルトは 2 秒です。
dscontrol highavailability reach add 9.67.125.18リーチ・ターゲットをお勧めしますが、必須ではありません。 詳しくは、heartbeat およびリーチ・ターゲットを使用した障害検出機能を参照してください。
dscontrol highavailability backup add primary [auto | manual] port
dscontrol highavailability backup add backup [auto | manual] port
dscontrol highavailability backup add both [auto | manual] port
dscontrol highavailability statusマシンには、それぞれ正しいロール (バックアップとプライマリー、または両方)、状態、および副状態があるはずです。プライマリーは、活動状態であり、かつ同期化されていなければなりません。バックアップは待機モードであって、間もなく同期化されなければなりません。ストラテジーは同じでなければなりません。
dscontrol cluster set clusterA primaryhost NFAdispatcher1 dscontrol cluster set clusterB primaryhost NFAdispatcher2
dscontrol cluster set clusterB primaryhost NFAdispatcher2 dscontrol cluster set clusterA primaryhost NFAdispatcher1
障害検出の基本的な基準 (heartbeat メッセージによって検出される、活動状態と待機 Dispatcher 間での接続性の喪失) 以外には、到達可能性基準 というもう 1 つの障害検出機構があります。Dispatcher を構成する場合は、正しく機能するようにするために、Dispatcher のそれぞれが到達できるホストのリストを提供できます。2 つの HA パートナーは、heartbeat を通じて互いに継続的に連絡を取り、2 つのうちいずれかが ping できるリーチ・ターゲット数を相互に更新します。待機 Dispatcher が活動状態の Dispatcher より多くのリーチ・ターゲットを ping する場合、フェイルオーバーが発生します。
heartbeat は、活動状態の Dispatcher によって送信され、スタンバイ Dispatcher によって 1/2 秒ごとに受信されることが予想されます。スタンバイ Dispatcher が 2 秒以内に heartbeat を受信できない場合、フェイルオーバーが始まります。heartbeat は、スタンバイ Dispatcher からの引き継ぎを発生させるためにすべて中断しなければなりません。 すなわち、2 組みの heartbeat を構成するときは、両方の heartbeat を中断する必要があるということになります。ハイ・アベイラビリティー環境を 安定させてフェイルオーバーを回避するためには、複数の heartbeat ペアを追加します。
リーチ・ターゲットの場合、Dispatcher マシンが使用するサブネットごとに、少なくとも 1 つのホストを選択しなければなりません。ホストは、ルーター、IP サーバー、または他のタイプのホストでも可能です。ホストの到達可能性は、ホストを ping する reach advisor によって取得されます。heartbeat メッセージが検出できない場合か、プライマリー Dispatcher が到達可能性基準に一致しなくなり、待機 Dispatcher が到達可能である場合は、フェイルオーバーが起こります。あらゆる使用可能な情報をもとに判断するため、活動状態の Dispatcher は、その到達可能性の機能を定期的に待機 Dispatcher に送信します。待機 Dispatcher は、この機能とそれ自身の機能と比較して、切り替えを行うかどうかを決定します。
プライマリー・マシンおよび バックアップ と いう第 2 マシンの 2 つの Dispatcher マシンが構成されます。始動時に、プライマリー・マシンは、マシンが同期化するまで、すべての接続データをバックアップ・マシンに送信します。プライマリー・マシンは 活動状態 になります、すなわち、プライマリー・マシンはロード・バランシングが開始します。その間、バックアップ・マシンは、プライマリー・マシンの状況をモニターしていて、待機 状態にあるといわれます。
バックアップ・マシンは、いつでも、プライマリー・マシンが失敗したことを検出すると、プライマリー・マシンのロード・バランシング機能を引き継ぎ、活動状態のマシンになります。 プライマリー・マシンは、再度操作可能になると、ユーザーによるリカバリー・ ストラテジー の構成方法に応じて応答します。 ストラテジーには、以下の 2 種類があります。
ストラテジー・パラメーターの設定は、両マシンとも同じでなければなりません。
手動リカバリー・ストラテジーでは、引き継ぎコマンドを使用して、パケットの経路指定を強制的に特定のマシンに向けることができます。手動リカバリーは、他のマシンで保守が行われているときは便利です。自動リカバリー・ストラテジーは、通常の不在操作用に設計されています。
相互ハイ・アベイラビリティー構成の場合は、クラスターごとの障害はありません。 一方のマシンでなんらかの問題が発生する場合、たとえその問題が 1 方だけのクラスターに影響を及ぼしても、他方のマシンは両方のクラスターを引き継ぎます。
Dispatcher がパケットを経路指定するには、それぞれのクラスター・アドレスがネットワーク・インターフェース・デバイスに対して 別名割り当てされなければなりません。
ネットワーク・インターフェース・カードに対する別名割り当てについては、ステップ 5. ネットワーク・インターフェース・カードの別名割り当て を参照してください。
Dispatcher マシンは障害を検出すると状態を変更するので、上記のコマンドは自動的に出されなければなりません。Dispatcher は、ユーザー作成のスクリプトを実行して、これを行います。次のディレクトリーにサンプル・スクリプトがあります。
これらのスクリプトを実行するためには、次のディレクトリーに移動する必要があります。
スクリプトは、dsserver の稼働中のみ自動的に実行されます。
以下のサンプル・スクリプトを使用できます。
Windows システムの場合: 構成セットアップにおいて、Site Selector がハイ・アベイラビリティー環境で運用中の 2 つの Dispatcher マシンのロード・バランシングを行うようにする場合は、Metric Server 用の Microsoft スタック上の別名を追加することになります。 この別名が goActive スクリプトに追加されます。 例えば、以下のようになります。
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
goStandby および goInOp の場合は、この別名を除去することが必要になります。 例えば、以下のようになります。
call netsh interface ip delete address "Local Area Connection" addr=9.37.51.28
マシン上に複数の NIC がある場合は、最初に、コマンド・プロンプトで次のコマンドを出すことによってどのインターフェースを使用するかを調べてください: netsh interface ip show address。 このコマンドは正しく構成されたインターフェースのリストを戻し、「ローカル・エリア接続」に番号を付ける (例えば、「ローカル・エリア接続 2」など) ので、どれを使用するかが判別できます。
Linux for S/390® の場合: Dispatcher は、 IP アドレスをある Dispatcher から別の Dispatcher に移動するための無償 ARP を 発行します。したがってこのメカニズムは、基礎ネットワーク・タイプと関連しています。 Linux for S/390 を 稼働しているとき、Dispatcher は、無償 ARP を発行してローカルのインターフェースでアドレスを 構成できるインターフェースでのみ、ネイティブにハイ・アベイラビリティーの引き継ぎ (IP アドレスの移動を含む 完全なもの) を行うことができます。この仕組みは、IUCV や CTC などの point-to-point インターフェースでは正常に動作せず、また qeth/QDIO の一部の構成でも正常に動作しません。
Dispatcher のネイティブな IP 引き継ぎ機能が正常に動作しないこれらのインターフェースや構成の場合には、go スクリプトに適切なコマンドを置き、手動でアドレスを移動することができます。これで、ネットワークの接続形態も確実にハイ・アベイラビリティーの利益を受けられるようになります。
ルール・ベースのロード・バランシングを使用して、パケットが送信されるサーバー、時刻、および理由を微調整することができます。Load Balancer は最初の優先度から最後の優先度に追加したルールをすべてレビューし、真である最初のルールで停止し、ルールに関連するサーバー間のコンテンツのロード・バランシングを行います。ルールを使用しなくても 宛先およびポートに基づいてロード・バランシングが行われますが、ルールを使用すると接続を分散する機能を拡張することができます。
ルールを構成するときはほとんどの場合、その他の優先度が より高いルールによって渡される要求をキャッチするために、 デフォルトの常に真ルールを構成する必要があります。このデフォルトは、 他のすべてのサーバーがクライアント要求に失敗すると、「残念ながら、このサイトは現在ダウンしています。 後でやり直してください。」応答になる場合があります。
なんらかの理由でサーバーのサブセットを使用する場合は、ルールに基づいたロード・バランシングを Dispatcher および Site Selector とともに使用する必要があります。常に、CBR コンポーネントにはルールを使用し なければなりません。
ルールを構成に追加し始める前に、ルールがどのような 論理に従うかの計画を立ててください。
すべてのルールには名前、タイプ、優先順位があり、サーバーのセットと一緒に、範囲の開始値および範囲の終了値がある場合があります。 さらに、CBR コンポーネントのコンテンツ・タイプ・ルールには、それと関連付けられている一致している正規表現パターンもあります。 (コンテンツ・ルールの使用法の例とシナリオおよびコンテンツ・ルールに有効なパターン構文については、付録B. コンテンツ・ルール (パターン) 構文を参照してください。)
ルールは優先度の順序で評価されます。すなわち、優先度が 1 (小さい方の数) のルールは、優先度が 2 (大きい方の数) のルールより前に評価されます。条件を満たした最初のルールが適用されます。ルールが満たされると、それ以上のルールの評価は行われなくなります。
ルールが条件を満たすように、以下の 2 つの条件を満たさなければなりません。
ルールにサーバーが関連していない場合は、ルールは、条件 1 のみを満たしている必要があります。この場合は、Dispatcher は接続要求をドロップし、Site Selector はネーム・サーバー要求をエラーで戻し、 CBR は Caching Proxy がエラー・ページを戻すようにします。
ルールが満たされない場合は、Dispatcher はポートで使用可能なサーバーの全セットからサーバーを選択し、Site Selector はサイト名で使用可能なサーバーの全セットからサーバーを選択し、CBR は Caching Proxy がエラー・ページを戻すようにします。
このルール・タイプは、Dispatcher、CBR、または Site Selector コンポーネントで使用できます。
顧客を選別して顧客のアクセス元に基づいてリソースを割り振る場合は、クライアント IP アドレスに基づいたルールを使用することも考えられます。
例えば、IP アドレスの特定のセットからアクセスしているクライアントから、未払いの (したがって望ましくない) トラフィックが ネットワークに多く到着するとします。dscontrol rule コマンドを使用してルールを作成します。例えば、以下のようにします。
dscontrol rule add 9.67.131.153:80:ni type ip beginrange 9.0.0.0 endrange 9.255.255.255
この "ni" ルールは、望ましくないクライアントからの接続を 排除します。その後、アクセスできるようにしたいサーバーをルールに追加します。サーバーをルールに追加しないと、9.x.x.x アドレスからの要求に対してサーバーが まったくサービスを提供しなくなります。
このルール・タイプは Dispatcher コンポーネントでしか使用できません。
要求時に TCP/IP から特定のポートを要求する種類の ソフトウェアをクライアントが使用している場合に、クライアント・ポートに基づくルールを使用したい場合があります。
例えば、クライアント・ポートが 10002 のクライアント要求が、特に大切な顧客からのアクセスであることが分かっているため、このポートを持つすべての要求が特別に高速のサーバーのセットを使用するように 指示するルールを作成することができます。
このルール・タイプは、Dispatcher、CBR、または Site Selector コンポーネントで使用できます。
容量の計画のため、時刻に基づくルールを使用することも考えられます。例えば、Web サイトが毎日同じ時間帯に アクセスされる場合は、5 つの追加サーバーをピークの時間帯に専用にすることも考えられます。
時刻に基づくルールを使用する理由として、毎晩深夜に一部のサーバーを停止して保守するときに、保守に必要な時間だけそれらのサーバーを除外するルールを設定することなどがあげられます。
このルール・タイプは Dispatcher コンポーネントでしか使用できません。
IP ヘッダーの “type of service” (TOS) の内容に基づくルールを使用することも考えられます。 例えば、クライアント要求が、通常のサービスを示す TOS 値付きで着信した場合には、その要求を 1 つのサーバーのセットに経路指定することができます。別のクライアント要求が、優先順位が高いサービスを示す別の TOS 値付きで着信した場合には、その要求を別のサーバーのセットに経路指定することができます。
TOS ルールを使用すると、dscontrol rule コマンドを使用して、各ビットを TOS バイトで完全に構成することができます。 TOS バイトで一致させたい有効なビットには、0 または 1 を使用します。それ以外は、x を使用します。以下は、TOS ルールを追加する例です。
dscontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
このルール・タイプは、Dispatcher および CBR コンポーネントで使用可能です。
サーバーのいくつかを他のアプリケーションで共有する必要がある場合に、1 秒当たりの接続数に基づくルールを使用したい場合があります。例えば、以下の 2 つのルールを設定できます。
Telnet を使用している場合に、1 秒当たりの接続数が特定のレベル以上に増加するときを除いて、Telnet 用の 5 つのサーバーのうち 2 つを予約したい場合もあります。このようにすると、Dispatcher によって、ピーク時に 5 つのサーバーの すべてにわたってロード・バランシングが行われます。
"connection" タイプ・ルールとともにルール評価オプション "upserversonrule" を設定する: 接続タイプ・ルールの使用時、および upserversonrule オプションの設定時に、サーバー・セット内のサーバーの一部が停止した場合、残りのサーバーが過負荷にならないことを確認できます。 詳細については、ルールのサーバー評価オプションを参照してください。
このルール・タイプは、Dispatcher または CBR コンポーネントで使用可能です。
サーバーが過負荷になり、パケットを破棄する場合に、ポートの活動状態の接続の総数に基づくルールを使用したい場合があります。特定の Web サーバーは、要求に応答するスレッドが十分にない場合でも接続を受け入れ続けます。この結果として、クライアント要求はタイムアウトになり、Web サイトにアクセスしている顧客にサービスが提供されなくなります。活動状態の接続数に基づくルールを使用して、サーバーのプールで容量のバランスを取ることができます。
例えば、サーバーが 250 の接続を受け入れた後、サービスの提供を停止することが経験的に分かっているとします。 dscontrol rule コマンドまたは cbrcontrol rule コマンドを使用してルールを作成することができます。例えば、
dscontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500 または cbrcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500
このルールに、現行のサーバーと、他の処理に使用する追加サーバーを追加します。
予約済み帯域幅および共有帯域幅ルールは、Dispatcher コンポーネントでのみ使用可能です。
帯域幅ルールでは、Dispatcher は、データが特定のサーバー・セットによってクライアントに送達される速度として帯域幅を計算します。 Dispatcher は、サーバー、ルール、ポート、クラスター、および executor のレベルで容量を追跡します。 これらのレベルごとに、バイト・カウンター・フィールド (秒当たりの転送 K バイト数) があります。 Dispatcher はこれらの速度を 60 秒の間隔を基準に計算します。 これらの速度は GUI から、あるいはコマンド行報告の出力から表示できます。
予約済み帯域幅ルールによって、1 セットのサーバーによって送達された秒当たりの K バイト数を制御できます。 構成中のサーバーのセットごとにしきい値を設定する (指定された帯域幅の範囲を割り振る) ことによって、クラスターとポートの組み合わせごとに使用される帯域幅の量を制御および保証できます。
以下は、reservedbandwidth ルールを追加する例です。
dscontrol rule add 9.67.131.153:80:rbw type reservedbandwidth beginrange 0 endrange 300
範囲の開始値と範囲の終了値は秒当たりの K バイト数で指定します。
共有帯域幅ルールを構成する前に、sharedbandwidth オプションを指定した dscontrol executor または dscontrol cluster コマンドを使用して、executor レベルまたはクラスター・レベルで共有できる帯域幅の最大容量 (K バイト/秒) を指定しなければなりません。 sharebandwidth 値は、使用可能な合計帯域幅 (合計サーバー容量) を超えることはできません。 dscontrol コマンドを使用して共有帯域幅を設定すると、ルールの上限だけが決まります。
以下は、コマンド構文の例です。
dscontrol executor set sharedbandwidth size dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth size
sharedbandwidth の size は整数値 (秒当たりの K バイト数) です。デフォルトは 0 です。この値がゼロの場合は、帯域幅を共有できません。
帯域幅をクラスター・レベルで共有すると、クラスターは指定された最大帯域幅を使用できます。 クラスターによって使用される帯域幅が指定された容量より小さいかぎり、このルールは真と評価されます。 使用される合計帯域幅が指定された容量より大きい場合、このルールは偽と評価されます。
executor レベルで帯域幅を共有することにより、Dispatcher 構成全体が最大容量の帯域幅を共有することができます。 executor レベルで使用される帯域幅が指定された容量より小さいかぎり、このルールは真と評価されます。 使用される合計帯域幅が定義された容量より大きい場合、このルールは偽と評価されます。
以下は、sharedbandwidth ルールを追加または設定する例です。
dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel value dscontrol rule set 9.20.34.11:80:shrule sharelevel value
sharelevel の value は executor またはクラスターのいずれかです。sharelevel は sharebandwidth ルールで必須パラメーターの 1 つです。
Dispatcher によって、予約済み帯域幅 ルールを使用して、指定された帯域幅を構成内のサーバーのセットに割り振ることができます。 範囲の開始値と終了値を指定することにより、サーバーのセットによってクライアントに送達される K バイトの範囲を制御できます。 そのルールが真と評価されなくなる (範囲の終了値を超過する) と、次に低い優先度のルールが評価されます。 次に低い優先度のルールが「常に真」ルールの場合、サーバーがクライアントに「サイト・ビジー」応答を返すよう選択できます。
例: ポート 2222 に 3 つのサーバーによるグループがあると想定します。 予約済み帯域幅が 300 に設定されている場合、60 秒の期間に基づいて、1 秒当たりの最大 K バイトは 300 になります。 この速度を超えると、ルールは真と評価されません。 ルールがこれだけであれば、要求を処理するため、3 つのサーバーのうち 1 つが Dispatcher によって選択されます。 より低い優先度の「常に真」ルールがあれば、要求は別のサーバーにリダイレクトされ、「サイト・ビジー」を返される可能性があります。
共有帯域幅ルールは、クライアントへのサーバー・アクセスをさらに提供できます。 特に、予約済み帯域幅ルールに従う低い優先度のルールとして使用される場合、予約済み帯域幅を超過していても、クライアントはサーバーにアクセスできます。
例: 予約済み帯域幅ルールに従う共有帯域幅ルールを使用することによって、制限された方法でクライアントが 3 つのサーバーにアクセスするようにできます。 使用可能な共有帯域幅があるかぎり、ルールは真と評価され、アクセスが認可されます。 共有帯域幅がない場合、そのルールは真ではなく、次のルールが評価されます。 「常に真」ルールが後に続く場合、必要に応じて要求をリダイレクトできます。
前の例で説明した予約済みおよび共有帯域幅の両方を使用することによって、サーバーへのアクセスを認可 (または禁止) するとき、より豊かな柔軟性と制御が可能になります。 帯域幅の使用において特定のポートでのサーバーを限定すると同時に、他のサーバーが可能なかぎり多くの帯域幅を使用するようにできます。
このルール・タイプは Site Selector コンポーネントでしか使用できません。
メトリック全体ルールの場合は、システム・メトリック (cpuload、memload、ユーザー独自にカスタマイズしたシステム・メトリック・スクリプト) を選択し、Site Selector はシステム・メトリック値 (ロード・バランシング済みのサーバーに常駐している Metric Server エージェントによって戻される) とルールに指定されている範囲の開始値および終了値と比較します。サーバー・セット内のすべてのサーバーの 現行システム・メトリック値は、実行するルールの範囲内になっていなければなりません。
以下は、メトリック全体ルールを構成に追加する例です。
sscontrol rule add dnsload.com:allrule1 type metricall metricname cpuload beginrange 0 endrange 100
このルール・タイプは Site Selector コンポーネントでしか使用できません。
メトリック平均ルールの場合は、システム・メトリック (cpuload、memload、ユーザー独自にカスタマイズしたシステム・メトリック・スクリプト) を選択し、Site Selector はシステム・メトリック値 (ロード・バランシング済みの各サーバーに常駐している Metric Server エージェントによって戻される) とルールに指定されている範囲の開始値および終了値と比較します。サーバー・セット内のすべてのサーバーの 現行システム・メトリック値の 平均 が、実行するルールの範囲内になっていなければなりません。
以下は、メトリック平均ルールを構成に追加する例です。
sscontrol rule add dnsload.com:avgrule1 type metricavg metricname cpuload beginrange 0 endrange 100
このルール・タイプは、Dispatcher、CBR、または Site Selector コンポーネントで使用できます。
“常に真” のルールを作成することができます。このようなルールは、関連するサーバーがすべて停止しない限り、常に選択されます。このため、通常は、他のルールよりも 優先順位が低くなければなりません。
複数の “常に真” ルールを用意して、それぞれについて関連するサーバーのセットを持たせることができます。使用可能なサーバーを持つ最初の true のルールが選択されます。例えば、6 つのサーバーを持っているとします。このうちの 2 つに、両方とも停止してしまわない限り、あらゆる状況でトラフィックを処理させます。最初の 2 つのサーバーが停止した場合は、サーバーの 2 番目のセットにトラフィックを処理させます。これらのサーバーが 4 つとも停止した場合は、最後の 2 つのサーバーを使用してトラフィックを処理させます。この場合は、3 つの “常に真” ルールを設定することができます。サーバーの最初のセットは、少なくとも 1 つが稼働している限り常に選択されます。両方とも停止した場合は、2 番目のセットから 1 つ選択され、以下同様に行われます。
他の例として、“常に真” ルールによって、設定済みのどのルールとも着信クライアントが一致しない場合にサービスが提供されないようにしたい場合があります。以下のように dscontrol rule コマンドを使用してルールを作成します。
dscontrol rule add 130.40.52.153:80:jamais type true priority 100
サーバーをルールに追加しないと、クライアント・パケットが応答なしのままドロップしてしまいます。
複数の “常に真” ルールを定義して、優先順位のレベルを変更することによって、実行するルールを調整することができます。
このルール・タイプは、CBR コンポーネントまたは Dispatcher コンポーネント (Dispatcher の CBR 転送方式を使用している場合) で使用可能です。
コンテンツ・タイプ・ルールを使用して、ユーザー・サイトのトラフィックのなんらかのサブセットを処理するようにセットアップされたサーバー・セットに要求を送信します。例えば、あるサーバー・セットを使用してすべての cgi-bin 要求を処理し、別のサーバー・セットを使用してすべてのストリーミング・オーディオ要求を処理し、さらに別のサーバー・セットを使用してその他のすべての要求を処理することができます。 cgi-bin ディレクトリーへのパスと一致するパターンを持つルールを追加し、ストリーミング・オーディオ・ファイルのファイル・タイプと一致するパターンを持つルールを追加し、さらにその他のトラフィックを処理するための、常に真のルールを追加します。 次に、該当するサーバーをそれぞれのルールに追加します。
重要: コンテンツ・ルールおよびコンテンツ・ルールに有効なパターン構文の使用法の例とシナリオについては、付録B. コンテンツ・ルール (パターン) 構文を参照してください。
ポート類縁性のオーバーライドを使用すると、特定サーバーに対するポートのスティッキー性をオーバーライドすることができます。 例えば、各アプリケーション・サーバーへの接続量を制限するルールを使用している とします。そして、オーバーフロー・サーバーは、そのアプリケーションに対して、“please try again later (後でもう一度お試しください)” というメッセージを常に出すように設定されているとします。 ポートの stickytime 値は 25 分です。したがって、クライアントがそのサーバーに対してスティッキーになることは望ましくありません。 ポート類縁性のオーバーライドを使用すると、オーバーフロー・サーバーを変更して、通常そのポートに関連した類縁性を変更することができます。 クライアントが次回にクラスターを要求するとき、オーバーフロー・サーバーではなく、最も使用可能なアプリケーション・サーバーでロード・バランシングが行われます。
サーバーの sticky オプションを使用したポート類縁性のオーバーライドのためのコマンド構文についての詳細は、dscontrol server — サーバーの構成を参照してください。
サンプル構成ファイルを編集することによって、あるいはグラフィカル・ユーザー・インターフェース (GUI) によって、dscontrol rule add コマンドを使用してルールを追加できます。定義したすべてのポートに 1 つ以上のルールを追加することができます。
これは、ルールを追加してから、ルールが真の場合にサービスを提供するサーバーを 定義するという 2 つのステップの処理です。例えば、システム管理者が サイトの各部門からのプロキシー・サーバーの使用の程度を追跡するとします。IP アドレスは部門ごとに与えられます。 クライアント IP アドレスに基づくルールの最初のセットを作成して、各部門の負荷を分割します。
dscontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 dscontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 dscontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255
次に、 異なるサーバーを各ルールに追加してから、各サーバーの負荷を測定し、 それらが使用したサービスに対して部門への請求が正しく行われるように します。例えば、以下のようになります。
dscontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 dscontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 dscontrol rule useserver 130.40.52.153:80:div3 207.72.33.47
サーバー評価オプションは Dispatcher コンポーネントでのみ使用可能です。
dscontrol rule コマンドには、ルールのサーバー評価オプションがあります。evaluate オプションはポートのすべてのサーバー間のルールの条件を評価すること、あるいはルール内のサーバーだけの間のルールの条件を評価することを選択するために使用します。(Load Balancer の初期バージョンでは、ポート上のすべてのサーバー間の各ルールの条件を測ることしかできませんでした。)
以下は、予約済み帯域幅ルールに評価オプションを追加または設定する例です。
dscontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate level dscontrol rule set 9.22.21.3:80:rbweval evaluate level
evaluate level は、port、rule、または upserversonrule のいずれかに設定できます。デフォルトは port です。
ルール内のサーバー間のルールの条件を測るためのオプションによって、以下の特性を使用して 2 つのルールを構成できます。
結果は、トラフィックが最初のルール内のサーバーのしきい値を超えると、 トラフィックは 2 番目のルール内の「サイト・ビジー」サーバーに 送信されます。トラフィックが最初のルール内のサーバーのしきい値を下回ると、新規トラフィックは最初のルール内のサーバーにもう一度続けられます。
前の例で説明した 2 つのルールを使用して、evaluate オプションを最初のルール (ポート上のすべてのサーバー間でルールの条件を評価) の port に設定した場合は、トラフィックがそのルールのしきい値を超えると、トラフィックは 2 番目のルールと関連付けられている「サイト・ビジー」サーバーに送信されます。
最初のルールは、ポート上のすべてのサーバー・トラフィック (「サイト・ビジー」サーバーを含む) を測って、そのトラフィックがしきい値を超えているかどうかを判断します。最初のルールに関連したサーバーの輻輳が低下すると、ポートのトラフィックはまだ最初のルールのしきい値を超えているので、トラフィックは「サイト・ビジー」サーバーに送信され続けるという、不測の結果が起こる場合があります。
Dispatcher および CBR コンポーネントの場合: クラスターのポートをスティッキーになるよう構成すると、類縁性機能が使用可能になります。 クラスターのポートをスティッキーになるように構成すると、以降のクライアント要求を同じサーバーに送信することができます。 これは、executor、クラスター、またはポート・レベルのスティッキー時間を秒単位で設定することによって行います。 この機能は、スティッキー時間を 0 に設定すると使用不可になります。
ポート間類縁性を使用可能にしている場合は、共有ポートの stickytime 値は同じ (ゼロ以外) でなければなりません。 詳しくは、ポート間類縁性を参照してください。
Site Selector コンポーネントの場合: サイト名をスティッキーになるよう構成すると、類縁性機能が使用可能になります。 sitename をスティッキーとして構成することにより、複数のネーム・サービス要求に対してクライアントは同じサーバーを使用できます。 これは、サイト名のスティッキー時間を秒単位で設定することによって行います。 この機能は、スティッキー時間を 0 に設定すると使用不可になります。
サーバーのスティッキー時間値は、ある接続がクローズしてから 新しい接続がオープンするまでの時間間隔で、この間にクライアントは、 最初の接続で使用したサーバーと同じサーバーに送られます。スティッキー時間 の有効期限が切れると、クライアントは最初のサーバーとは異なるサーバ ーに送られる場合が あります。サーバーのスティッキー時間値は、dscontrol executor、 port、または cluster コマンドを使用して構成されます。
類縁性機能が使用不可な場合に、新しい TCP 接続がクライアントから受信されると、Load Balancer は、その時点の適切なサーバーを時間内に選出してパケットを転送します。 次の接続が同じクライアントから到着すると、Load Balancer はその接続を関連のない新しい接続として処理し、その時点の適切なサーバーを時間内に再度選出します。
類縁性機能を使用可能にすると、以降の要求を同じクライアントから受け取った場合に、その要求は同じサーバーに送信されます。
時間が経過すると、クライアントはトランザクションを終了し、類縁性レコードが廃棄されます。これがスティッキー "時間" の意味です。各類縁性レコードは、秒単位の "スティッキー時間" の間だけ存在し続けます。次の接続がスティッキー時間内に受信されると、類縁性レコードは有効のままになり、要求は同じサーバーに送信されます。次の接続がスティッキー時間外に受信されると、レコードは除去されます。その時間の後に受信される接続については、新しいサーバーがその接続に対して選択されます。
サーバーをオフラインにするには、サーバー・ダウン・コマンド (dscontrol server down) を使用します。サーバーが終了するのは、スティッキー時間値の有効期限が切れてからです。
ポート間類縁性は Dispatcher コンポーネントの MAC および NAT/NATP 転送方式にしか適用されません。
ポート間類縁性は、複数のポートを取り扱うために拡張されたスティッキー機能です。 例えば、クライアント要求を最初に 1 つのポートで受け取り、次の要求を別のポートで受け取る場合、ポート間類縁性を使用すると、Dispatcher はそのクライアント要求を同じサーバーに送信することができます。 この機能を使用するには、ポートを以下のようにしなければなりません。
2 つ以上のポートが、同じ crossport にリンクできます。同じポートまたは共有ポートの同じクライアントから引き続き接続が着信すると、同じサーバーがアクセスされます。以下は、ポート間類縁性をもつ複数のポートをポート 10 に構成している例です。
dscontrol port set cluster:20 crossport 10 dscontrol port set cluster:30 crossport 10 dscontrol port set cluster:40 crossport 10
ポート間類縁性が確立されると、ポートの stickytime 値を柔軟に変更することができます。 ただし、すべての共有ポートの stickytime 値を同じ値に変更することをお勧めします。そうでないと、予想外の結果が発生する場合があります。
ポート間類縁性を除去するには、crossport 値を独自のポート番号に戻します。crossport オプションのコマンド構文に関する詳細については、dscontrol port — ポートの構成を参照してください。
類縁性アドレス・マスクは Dispatcher コンポーネントにしか適用されません。
類縁性アドレス・マスクは、共通サブネット・アドレスを基に、クライアントをグループ化するためにスティッキー機能を拡張したものです。 dscontrol port コマンドに stickymask を指定することにより、32 ビット IP アドレスの共通高位ビットをマスクできます。 この機能が構成された場合、クライアント要求が最初にポートに接続すると、同じサブネット・アドレス (マスクされているアドレスのその部分で表される) をもつクライアントからの以降の要求すべてが、同じサーバーに送信されます。
例えば、同じネットワーク Class A アドレスをもつすべての着信クライアント要求を同じサーバーに送信したい場合は、そのポートの stickymask 値を 8 (ビット) に設定します。 同じネットワーク Class B アドレスをもつクライアント要求をグループ化するには、stickymask 値を 16 (ビット) に設定します。 同じネットワーク Class C アドレスをもつクライアント要求をグループ化するには、stickymask 値を 24 (ビット) に設定します。
最良の結果を得るためには、最初の Load Balancer を開始時に、stickymask 値を設定します。stickymask 値を動的に変更すると、予期しない結果が発生します。
ポート間類縁性との相互作用: ポート間類縁性を使用可能にしている場合は、共有ポートの stickymask 値は同じでなければなりません。 詳しくは、ポート間類縁性を参照してください。
類縁性アドレス・マスクを使用可能にするには、以下のような dscontrol port コマンドを発行します。
dscontrol port set cluster:port stickytime 10 stickymask 8
可能な stickymask 値は 8、16、24 および 32 です。 値 8 は、IP アドレス (ネットワーク Class A アドレス) の 最初の 8 の高位ビットをマスクすることを指定します。値 16 は、IP アドレス (ネットワーク Class B アドレス) の 最初の 16 の高位ビットをマスクすることを指定します。 値 24 は、IP アドレス (ネットワーク Class C アドレス) の 最初の 24 の高位ビットをマスクすることを指定します。 値 32 を指定すると、IP アドレス全体をマスクしていて、類縁性アドレス・マスク機能を効果的に使用不可にします。stickymask のデフォルト値は 32 です。
stickymask (類縁性アドレス・マスク機能) のコマンド構文に関する詳細については、dscontrol port — ポートの構成を参照してください。
処理の静止は、Dispatcher および CBR コンポーネントに適用されます。
何らかの理由 (更新、アップグレード、保守など) でサーバーを Load Balancer 構成から除去するために、dscontrol manager quiesce コマンドを使用できます。quiesce サブコマンドによって、既存の接続は、(切断しないで) 完了し、その接続がスティッキーと指定されていて、スティッキー時間が満了していると、その後のクライアントからの新規接続のみを静止サーバーに転送できます。quiesce サブコマンドはそのサーバーへのその他のいかなる新規接続も認可しません。
スティッキー時間が設定されていて、スティッキー時間が満了する前に新規接続を (静止したサーバーの代わりに) 別のサーバーに送信したい場合は、quiesce “now" を使用します。 以下は、サーバー 9.40.25.67 を静止する now オプションの使用例です。
dscontrol manager quiesce 9.40.25.67 now
now オプションは、スティッキー接続を次のように処理する方法を判別します。
これは、安全かつ無理のないサーバーの静止方法です。例えば、サーバーを安全に静止してから、最少量のトラフィックしかない時間 (多分、早朝) を待って、構成からサーバーを除去できます。
dscontrol rule コマンドには、以下のタイプの類縁性を指定できます。
活動 Cookie 類縁性が適用されるのは CBR コンポーネントに対してだけです。
受動 Cookie は、CBR コンポーネントおよび Dispatcher コンポーネントの CBR 転送方式に適用されます。
URI 類縁性は、CBR コンポーネントおよび Dispatcher コンポーネントの CBR 転送方式に適用されます。
affinity オプションのデフォルトは "none" です。 活動 Cookie、受動 Cookie、または URI に対する rule コマンドで affinity オプションを設定するためには、port コマンドの stickytime オプションはゼロ (使用不可) になっていなければなりません。 類縁性がルールに対して設定されていると、そのポートで stickytime は使用可能にはできません。
活動 Cookie 類縁性フィーチャーが適用されるのは、CBR コンポーネントに対してだけです。
これは、特定のサーバーにクライアント「スティッキー」を作成する方法を提供しています。この機能は、ルールのスティッキー時間を正数に設定し、類縁性を “activecookie” に設定することによって使用可能となります。これは、ルールを追加するか、あるいは rule set コマンドを使用すると実行できます。コマンド構文の詳細については、dscontrol rule - ルールの構成を参照してください。
活動 Cookie 類縁性に対してルールが使用可能になると、同じクライアントからの正常に実行された要求が最初に選択したサーバーに送信される間に、標準 CBR アルゴリズムを使用して新規クライアント要求のロード・バランスされます。選択したサーバーは、クライアントへの応答で Cookie として保管されます。クライアントの将来の要求に Cookie が入っていて、各要求がスティッキー時間間隔内に到達する限り、クライアントは初期サーバーとの類縁性を保守します。
活動 cookie 類縁性は、同じサーバーに対する任意の期間のロード・バランシングをクライアントが継続することを確認するために使用されます。 これは、クライアント・ブラウザーが保管する Cookie を送信することによって実行されます。 Cookie には、決定を行うために使用した cluster:port:rule、ロード・バランシングを行ったサーバー、および類縁性が有効でなくなったときのタイムアウト・タイム・スタンプが入っています。 Cookie はフォーマット: IBMCBR=cluster:port:rule+server-time! になっています。 cluster:port:rule および server 情報はエンコードされているため、CBR 構成に関する情報は公開されません。
オンにされた活動 Cookie 類縁性があるルールが起動されると常に、クライアントによって送信される Cookie が調べられます。
次にこの新規 Cookie はクライアントに戻るヘッダーに挿入され、クライアントのブラウザーが Cookie を受け入れるように構成されている場合は以降の要求を戻します。
Cookie の類縁性インスタンスはそれぞれ、長さ 65 バイトで、感嘆符で終了します。 この結果として、4096 バイトの Cookie は、ドメインごとに約 60 の活動状態 Cookie ルールを持つことができます。 Cookie が完全に一杯になると、すべての有効期限切れ類縁性インスタンスが除去されます。 すべてのインスタンスがまだ有効な場合、最も古いものがドロップされ、現在のルール用のインスタンスが追加されます。
ポート・スティッキー時間がゼロ (使用不可) である場合は、ルール・コマンドの活動 Cookie 類縁性オプションに設定できるのは activecookie だけです。 活動 Cookie 類縁性がルールに対して活動状態になっていると、そのポートで stickytime は使用可能にはできません。
特定のルールに対して、活動 cookie 類縁性を使用可能にするには、rule set コマンドを使用してください。
rule set cluster:port:rule stickytime 60 rule set cluster:port:rule affinity activecookie
ルール・スティッキーの作成は、通常はサーバー上のクライアント状態を保管する CGI またはサーブレットに使用されます。この状態は、Cookie ID によって識別されます (これがサーバー Cookie です)。クライアント状態は選択したサーバー上にのみ存在するので、 クライアントは要求間で状態を保持するためにそのサーバーからの Cookie を必要とします。
活動状態の Cookie 類縁性には、現在のサーバー時刻にスティッキー時間間隔を加算し、さらに 24 時間を加えたデフォルトの有効期限があります。 クライアント (CBR マシンに要求を送信している側) のシステムの時刻が不正確であると (例えば、サーバー時刻よりも 1 日進んでいると)、これらのクライアントのシステムでは、Cookie が既に期限切れになっていると思い、CBR からの Cookie を無視してしまいます。 さらに長い有効期限を設定するには、cbrserver スクリプトを変更します。 これを行うためには、スクリプト・ファイル内の javaw 行を編集して、LB_SERVER_KEYS の後に -DCOOKIEEXPIREINTERVAL=X というパラメーターを追加します (ただし、X は有効期限に加算する日数です)。
AIX®、Solaris、 および Linux システムでは、 cbrserver ファイルは /usr/bin ディレクトリーにあります。
Windows システムでは、 cbrserver ファイルは ¥winnt¥system32 ディレクトリーにあります。
受動 cookie 類縁性は、Dispatcher コンポーネントの Content Based Routing (CBR) 転送方式 および CBR コンポーネントに適用されます。Dispatcher の CBR 転送方式を構成する方法については、Dispatcher のコンテンツ・ベースのルーティング (CBR 転送方式)を参照してください。
受動 cookie 類縁性は、クライアントを特定のサーバーに対してスティッキーにする手段を提供します。ルールの類縁性が "passivecookie" に設定されていると、受動 cookie 類縁性によって、サーバーによって生成された自己識別 cookies を基にして、同一サーバーに対する類縁性で Web トラフィックをロード・バランシングできます。受動 cookie 類縁性はルール・レベルで構成してください。
ルールが始動されると、受動 cookie 類縁性が使用可能になっている場合は、Load Balancer はクライアント要求の HTTP ヘッダー中の cookie 名に基づいてサーバーを選択します。Load Balancer によって、クライアントの HTTP ヘッダーの cookie 名と各サーバーに対して構成済みの cookie 値との比較が開始されます。
Load Balancer は、cookie 値にクライアントの cookie 名を 含む サーバーを最初に見つけたとき に、要求に対してそのサーバーを選択します。
クライアント要求中の cookie 名が見つからないか、サーバーの cookie 値の内容のいずれとも一致しない場合は、サーバーは既存のサーバー選択か重み付きラウンドロビン技法を使用して選択されます。
受動 cookie 類縁性を構成するには、以下を行います。
ポート・スティッキー時間がゼロ (使用不可) の場合は、ルール・コマンドの受動 cookie 類縁性オプションに設定できるのは passivecookie だけです。受動 cookie 類縁性がルールに対して活動状態になっていると、ポートに対して stickytime は使用可能にはできません。
URI 類縁性は、Dispatcher の CBR 転送方式および CBR コンポーネントに適用されます。CBR 転送方式を構成する方法については、Dispatcher のコンテンツ・ベースのルーティング (CBR 転送方式)を参照してください。
URI 類縁性によって、固有のコンテンツを個々の個々の各サーバーにキャッシュできる、Caching Proxy サーバーに対して Web トラフィックをロード・バランシングできます。 この結果として、サイトのキャッシュの容量は、複数のマシン上のコンテンツの冗長なキャッシュを除去することによって、効果的に増加することになります。 URI 類縁性はルール・レベルで構成します。ルールが始動されていると、URI 類縁性が使用可能になっていて、同一セットのサーバーがアップになっていて応答している場合は、Load Balancer は同じ URI を付けて新規着信クライアント要求を同じサーバーに転送します。
一般に、Load Balancer は、同一のコンテンツを提供する複数のサーバーに要求を分散できます。キャッシュ・サーバーのグループとともに Load Balancer を使用すると、頻繁にアクセスされるコンテンツは、結局、すべてのサーバーのキャッシュに入れられた状態になります。これは、複数のマシンのキャッシュに入れられた同一のコンテンツを複製することによって、非常に高いクライアントの負荷をサポートします。これが特に役立つのは、高いボリュームの Web サイトの場合です。
しかし、Web サイトが非常に多様なコンテンツに対してクライアント・トラフィックの適度のボリュームをサポートしていて、一段と大容量のキャッシュを複数のサーバー間に広げたい場合は、ユーザー・サイトは、各キャッシュ・サイトに固有のコンテンツが入っていて、Load Balancer がそのコンテンツが入っているキャッシュ・サーバーだけに要求を分散すると一層効果的に実行されることになります。
URI 類縁性を使用すると、Load Balancer によって、キャッシュに入れられたコンテンツを個々のサーバーに分散して、複数マシンでの冗長なキャッシュを除去できます。この機能強化によって、Caching Proxy サーバーを使用する多様なコンテンツ・サーバー・サイトのパフォーマンスは向上することになります。同一サーバーに送信されるのは同一の要求なので、コンテンツは単一サーバーでのみキャッシュに入れられます。さらに、キャッシュの有効サイズは、各新規サーバー・マシンがプールに追加されることによってさらに増大します。
URI 類縁性を構成するには、以下を行います。
ポート・スティッキー時間がゼロ (使用不可) の場合は、ルール・コマンドの URI 類縁性オプションに設定できるのは URI だけです。URI 類縁性がルールに対して活動状態になっていると、ポートに対して stickytime は使用可能にはできません。
この機能は Dispatcher コンポーネントにのみ使用可能です。
Dispatcher の広域サポートを使用中ではなく、Dispatcher の nat 転送方式を使用中ではない場合、Dispatcher 構成は、Dispatcher マシンおよびそのサーバーはすべてが同一の LAN セグメントに接続されていることが必要です (図 32 を参照してください)。 クライアントの要求は Dispatcher マシンに送られ、さらにサーバーに送信されます。 サーバーから、応答が直接クライアントに返されます。
広域 Dispatcher 機能では、リモート・サーバー として知られる オフサイト・サーバーのサポートが追加されています (図 33 を参照してください)。 GRE がリモート・サイトでサポートされていなくて、Dispatcher の NAT 転送方式が使用中でない場合は、そのリモート・サイトは、リモート Dispatcher マシン (Dispatcher 2) およびそのローカル接続されたサーバー (サーバー G、サーバー H、およびサーバー I) から成っていなければなりません。 クライアントのパケットは、インターネットからイニシャル Dispatcher マシンへ移動します。そのイニシャル Dispatcher マシンから、 パケットは、地理的リモート Dispatcher マシンおよびそのローカル接続サーバーの 1 つに移動します。
Dispatcher マシンはすべて (ローカルおよびリモート)、広域構成を稼働するために、 同じタイプのオペレーティング・システムおよびプラットフォーム上になければなりません。
これによって、1 つのクラスター・アドレスで、世界中のクライアント要求をすべてサポートするとともに、世界中のサーバーに負荷を分散させることができます。
さらに、パケットを最初に受信する Dispatcher マシンは、引き続きローカル・サーバーに接続しておくことができ、ローカル・サーバーとリモート・サーバーの間で負荷を分散させることができます。
広域サポートを構成するには、以下を行います。
dscontrol server add cluster:port:server router address
router キーワードの詳細については、dscontrol server — サーバーの構成を参照してください。
エントリー・ポイント Dispatcher の場合:
エントリー・ポイント Dispatcher は第 2 レベル Dispatcher をサーバーと見なします。また、エントリー・ポイント Dispatcher はサーバーとしての第 2 レベル Dispatcher の正常性をモニターし、結果をその Dispatcher の実 IP に結び付けます。
リモート Dispatcher の場合: それぞれのリモート・クラスター・アドレスごとに、以下の構成ステップを行います。 リモート Dispatcher ロケーションにあるハイ・アベイラビリティー構成の場合は、 両方のマシンでこれらのステップを実行しなければなりません。
AIX システム
ifconfig en0 alias 10.10.10.99 netmask 255.255.255.255
dscontrol executor configure 204.67.172.72 en0 255.255.255.255
HP-UX システム、Linux、Solaris、 および Windows システム
この例は、図 34 で説明する構成に適用します。
ここでは、Dispatcher マシンを構成して、ポート 80 のクラスター・アドレス xebec を サポートする方法について説明します。LB1 は 『エントリー・ポイント』 Load Balancer として定義されています。 イーサネット接続を想定します。LB1 には定義済みのサーバーが 5 つ、すなわち、3 つのローカル (ServerA、ServerB、ServerC) および 2 つのリモート (LB2 および LB3) があることに注意してください。 リモートの LB2 および LB3 には、それぞれ 3 つのローカル・サーバーが定義されています。
最初の Dispatcher (LB1) のコンソールで、以下を行います。
dscontrol executor start
dscontrol executor set nfa LB1
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure xebec
2 番目の Dispatcher (LB2) のコンソールで、以下を行います。
dscontrol executor start
dscontrol executor set nfa LB2
dscontrol cluster add xebec
dscontrol port add xebec:80
3 番目の Dispatcher (LB3) のコンソールで、以下を行います。
dscontrol executor start
dscontrol executor set nfa LB3
dscontrol cluster add xebec
dscontrol port add xebec:80
総称経路指定カプセル化 (GRE) は RFC 1701 および RFC 1702 に指定されているインターネット・プロトコルの 1 つです。GRE を使用することで、Load Balancer はクライアント IP パケットを IP/GRE パケットの内部にカプセル化し、それを GRE をサポートしている OS/390® などのサーバー・プラットフォームに転送できます。 GRE サポートによって、Dispatcher コンポーネントは、1 つの MAC アドレスと関連付けられている複数のサーバー・アドレス当てのパケットをロード・バランシングできます。
Load Balancer は GRE を WAN フィーチャーの一部として実装します。 これにより、Load Balancer は、GRE パケットをアンラップできるすべてのサーバー・システムに対する広域ロード・バランシングを直接提供できます。リモート・サーバーがカプセル化された GRE パケットをサポートしている場合は、Load Balancer はリモート・サイトにインストールされている必要はありません。Load Balancer は、WAN パケットを 10 進数値 3735928559 に設定された GRE キー・フィールドとともにカプセル化します。
この例 (図 35) の場合は、GRE をサポートするリモート ServerD を追加するために、WAN サーバーを cluster:port:server 階層内に定義中であるかのように、そのサーバーは Load Balancer 構成内に定義します。
dscontrol server add cluster:port:ServerD router Router1
Linux システムには、GRE のカプセル化を解除する固有の機能があります。 これによって、Load Balancer は、多くのサーバー・イメージが MAC アドレスを 共有している Linux for S/390 サーバー・イメージに対してロード・バランシングを行うことができます。 これによってエントリー・ポイント Load Balancer は、 リモート・サイトの Load Balancer を経由することなく、 直接 Linux WAN サーバーへのロード・バランシングを行うことが可能になります。 これにより、エントリー・ポイント Load Balancer の advisor は、それぞれのリモート・サーバーで直接操作することもできます。
エントリー・ポイント Load Balancer で、WAN の場合に説明したように構成してください。
それぞれ の Linux バックエンド ・サーバーを構成するには、root として以下のコマンドを実行します。(これらのコマンドは、変更がリブート後も保持されるようにするために、システムの始動機能に追加することができます。)
# modprobe ip_gre # ip tunnel add gre-nd mode gre ikey 3735928559 # ip link set gre-nd up # ip addr add cluster address dev gre-nd
一般に、Dispatcher のロード・バランシング機能は、当製品が使用されるサイトの内容とは関係なく働きます。ただし、サイトの内容が重要であり、かつ内容に関する判断が Dispatcher の効率に重大な影響を与える可能性がある領域が 1 つあります。これは、リンク・アドレスの領域です。
サイトの個別のサーバーを指すリンクをページで指定すると、強制的にクライアントが特定のマシンにアクセスするようになるので、すべてのロード・バランシング機能が迂回され、効果がなくなってしまいます。このため、 ページに含まれるすべてのリンクで、常に Dispatcher のアドレスを使用してください。 サイトで自動プログラミングを使用して HTML を動的に作成する場合は、使用するアドレスの種類が常に明らかであるとは限りません。ロード・バランシングを最大限に活用するには、明示アドレスに注意して、可能な場合には回避しなければなりません。
プライベート・ネットワークを使用する Dispatcher および TCP サーバー・マシンを セットアップすることができます。この構成によって、パフォーマンスに影響を与える可能性がある公衆ネットワーク や外部ネットワークでの競合を削減することができます。
AIX システムの場合は、この構成によって、Dispatcher および TCP サーバー・マシンを SP フレームのノードで実行している場合に、高速な SP ハイパフォーマンス・スイッチを利用することもできます。
プライベート・ネットワークを作成するには、各マシンに少なくとも 2 つの LAN カードを用意し、一方のカードをプライベート・ネットワークに接続しなければなりません。異なるサブネットで 2 番目の LAN カードも 構成しなければなりません。Dispatcher マシンは、プライベート・ネットワークを介して TCP サーバー・マシンに クライアント要求を送信します。
Windows システム: executor configure コマンドを使用して、nonforwarding アドレスを構成してください。
dscontrol server add コマンドを使用して 追加されたサーバーは、プライベート・ネットワーク・アドレスを使用して追加しなければなりません。例えば、図 36 の Apple サーバーの例では、以下のようにコマンドをコーディングしなければなりません。
dscontrol server add cluster_address:80:10.0.0.1
以下のようであってはなりません。
dscontrol server add cluster_address:80:9.67.131.18
Site Selector を使用して負荷情報を Dispatcher に提供している場合は、プライベート・アドレスでの負荷を報告するように Site Selector を構成しなければなりません。
プライベート・ネットワーク構成は Dispatcher コンポーネントでしか使用できません。
ワイルドカード・クラスターを使用してサーバー構成を結合する操作は、Dispatcher コンポーネントでしか行えません。
“ワイルドカード” は、複数の IP アドレスに一致するクラスターの機能を指します (すなわち、ワイルドカードとして機能します)。 クラスター・アドレス 0.0.0.0 を使用して、ワイルドカード・クラスターを指定します。
クラスター・アドレスの多くについてロード・バランシングを行っており、ポート/サーバー構成が全クライアントについて同じである場合は、すべてのクラスターを 1 つのワイルドカード・クラスター構成に結合することができます。
この場合でも、Dispatcher ワークステーションのネットワーク・アダプターのいずれかで、各クラスター・アドレスを明示的に構成しなければなりません。ただし、dscontrol cluster add コマンドを使用して 全クラスター・アドレスを Dispatcher 構成に追加する必要はありません。
ワイルドカード・クラスター (アドレス 0.0.0.0) のみを追加して、ロード・バランシングに必要な ポートおよびサーバーを構成します。アドレスを構成したアダプターへのトラフィックについては、すべてワイルドカード・クラスター構成を使用して ロード・バランシングが行われます。
この方法の利点は、最適なサーバーを判別するときに、すべてのクラスター・アドレスへのトラフィックが考慮されることです。1 つのクラスターが受信するトラフィックが多く、サーバーのいずれかで多くの活動状態の接続を作成した場合は、この情報を使用して、他のクラスター・アドレスへのトラフィックについて ロード・バランシングが行われます。
固有のポート/サーバー構成を持つクラスター・アドレスがある場合は、ワイルドカード・クラスターを実際のクラスターと結合し、いくつかを共通構成と結合することができます。固有の構成は、それぞれ実際のクラスター・アドレスに割り当てなければなりません。共通構成は、すべてワイルドカード・クラスターに割り当てることができます。
ワイルドカード・クラスターを使用しファイアウォールをロード・バランシングする操作は、Dispatcher コンポーネントでしか行えません。 クラスター・アドレス 0.0.0.0 を使用して、ワイルドカード・クラスターを指定します。
ワイルドカード・クラスターは、Dispatcher ワークステーションのネットワーク・アダプターで明示的に 構成されていないアドレスへのトラフィックについてロード・バランシングを 行うために使用することができます。これを行うためには、少なくとも、ロード・バランシングを行うトラフィックを Dispatcher が すべて確認することができなければなりません。Dispatcher ワークステーションは、トラフィックのセットに対するデフォルトの経路としてセットアップされていない限り、そのネットワーク・アダプターのいずれでも明示的に構成されていない アドレスへのトラフィックを確認しません。
一度 Dispatcher をデフォルトの経路として構成すると、Dispatcher マシンを介した TCP トラフィックまたは UDP トラフィックは、すべてワイルドカード・クラスター構成を使用してロード・バランシングが行われます。
このアプリケーションの 1 つは、ファイアウォールのロード・バランシングを行うためのものです。ファイアウォールは、すべての宛先アドレスおよび宛先ポートに対するパケットを処理するので、宛先アドレスおよびポートに関係なく、トラフィックのロード・バランシングを行える必要があります。
ファイアウォールは、保護されていないクライアントから保護されたサーバーまでのトラフィック、および保護されたサーバーからの応答をはじめ、保護された側のクライアントから保護されていない側のサーバーへのトラフィック および応答を処理するために使用されます。
2 つの Dispatcher マシンをセットアップし、一方のマシンでは保護されていないファイアウォール・アドレスに対して 保護されていないトラフィックのロード・バランシングを行い、もう一方のマシンでは 保護されたファイアウォール・アドレスに対して保護されたトラフィックのロード・バランシングを 行わなければなりません。これらの Dispatcher の両方が、サーバー・アドレスの異なるセットとともに ワイルドカード・クラスターおよびワイルドカード・ポートを使用しなければならないので、2 つの Dispatcher は 2 つの別個のワークステーションになければなりません。
Dispatcher コンポーネントの場合、透過プロキシーについて、ワイルドカード・クラスターを Caching Proxy とともに使用することはできません。 クラスター・アドレス 0.0.0.0 を使用して、ワイルドカード・クラスターを指定します。
また、ワイルドカード・クラスター機能によって、Dispatcher を使用して Dispatcher と同じマシン上に ある Caching Proxy サーバーの透過プロキシー機能を使用可能にできます。 これは、Dispatcher コンポーネントからオペレーティング・システムの TCP コンポーネントへの通信が必要なので、AIX のみの機能です。
この機能を使用可能にするには、Caching Proxy によるポート 80 でのクライアント要求の listen を開始しなければなりません。 その後、ワイルドカード・クラスターを構成します (0.0.0.0)。ワイルドカード・クラスターで、ポート 80 を構成します。ポート 80 で、Dispatcher マシンの NFA を唯一のサーバーとして構成します。これで、ポート 80 の任意のアドレスに対するクライアント・トラフィックが、すべて Dispatcher ワークステーションで実行されている Caching Proxy サーバーに 送達されるようになります。 クライアント要求は、通常どおりに代行され、応答が Caching Proxy からクライアントに送信されます。このモードでは、Dispatcher コンポーネントはロード・バランシングを行いません。
ワイルドカード・ポートは、明示的に構成されたポートに 対するトラフィックではないトラフィックを処理するために使用することができます。例えば、ファイアウォールのロード・バランシングに使用することができます。また、構成されていないポートへのトラフィックが適切に処理されることを 確認するために使用することもできます。サーバーを指定せずにワイルドカード・ポートを定義することによって、構成されていないポートへの要求が確実に廃棄され、オペレーティング・システムには戻されないようにすることができます。 ポート番号 0 (ゼロ) は、ワイルドカード・ポートを指定するために使用します。例えば、以下のようになります。
dscontrol port add cluster:0
受動 FTP およびワイルドカード・ポート処理のためにクラスターを構成すると、受動 FTP はデータ接続のためにデフォルトで非特権 TCP ポート範囲全体を使用します。これは、クライアントが、ロード・バランシング・クラスターを通じた FTP 制御ポートへの既存接続で、Load Balancer によって FTP 制御接続と同じサーバーに自動的に経路指定された同じクラスターへの後続の制御接続および高位ポート接続 (ポート >1023) を持つことを意味します。
同じクラスター上のワイルドカード・ポートと FTP ポートのサーバー・セットが同じでない場合、高位ポート・アプリケーション (ポート >1023) は、クライアントに既存の FTP 制御接続がないと失敗する可能性があります。したがって、同一クラスター上の FTP とワイルドカード・ポートに異なるサーバー・セットを構成することはお勧めしません。このシナリオが望ましい場合は、FTP デーモン受動ポートの範囲は Load Balancer 構成内で構成しなければなりません。
この機能は Dispatcher コンポーネントにのみ使用可能です。
Dispatcher は、潜在的な「サービス妨害」攻撃を検出し、アラートによって管理者に通知する機能を提供します。Dispatcher は、 サーバーでハーフ・オープン TCP 接続の著しい量の受信要求 (単純なサービス妨害攻撃 (Denial of Service Attack) の特性) を 分析することによってこれを行います。 サービス妨害攻撃では、サイトは多数の送信元 IP アドレスおよび送信元ポート番号から大量の偽造された SYN パケットを受信しますが、このサイトはそれらの TCP 接続用のその後のパケットを 1 個も受信しません。これにより、サーバー上で多数の TCP 接続がハーフ・オープン状態になり、時を経るとサーバーは非常に低速化して、新規着信接続をまったく受け入れなくなる可能性があります。
Load Balancer は、考えられるサービス妨害攻撃 (Denial of Service Attack) のアラートを管理者に通知する、カスタマイズできるスクリプトを起動するユーザー出口を提供します。 次のディレクトリーに、Dispatcher が提供するサンプル・スクリプト・ファイルが入っています。
以下のスクリプトを使用することができます。
これらのファイルを実行するためには、ファイルを次のディレクトリーに移動して、「.sample」ファイル拡張子を除去する必要があります。
DoS 攻撃検出を実装するには、maxhalfopen パラメーターを dscontrol port コマンドで次のように設定します。
dscontrol port set 127.40.56.1:80 maxhalfopen 1000
前述の例では、Dispatcher はハーフ・オープンの現在の合計接続数 (ポート 80 のクラスター 127.40.56.1 にあるすべてのサーバー) としきい値 1000 (maxhalfopen パラメーターによって指定) を比較します。現在のハーフ・オープン接続数がこのしきい値を超えると、アラート・スクリプト (halfOpenAlert) への呼び出しが行われます。ハーフ・オープン接続数がこのしきい値を下回っていると、攻撃は終了していることを示すために、別のアラート・スクリプト (halfOpenAlertDone) への呼び出しが行われます。
maxhalfopen 値を判別する方法を判別する場合: ユーザー・サイトが通常から大量トラフィックへの変化を経験しつつあるときに、定期的に (多分、10 分ごとに) ハーフ・オープン接続報告 (dscontrol port halfopenaddressreport cluster:port) を実行します。 ハーフ・オープン接続報告は、現在の「合計受信ハーフ・オープン接続数」を戻します。 maxhalfopen は、ユーザー・サイトで経験しているハーフ・オープン接続の最大数より 50 から 200% 大きな値に設定する必要があります。
報告される統計データの他に、halfopenaddressreport は、ハーフ・オープン接続になったサーバーにアクセスしたクライアント・アドレス (最大約 8000 個までのアドレスのベア) すべてのログ (..ibm/edge/lb/servers/logs/dispatcher/halfOpen.log) 中に項目を生成します。
バックエンド・サーバーのサービス妨害攻撃からの追加保護を提供するために、ワイルドカード・クラスターおよびポートを構成できます。特に各構成済みクラスターの下にサーバーを使用しないワイルドカード・ポートを追加してください。また、ワイルドカード・ポートがあってサーバーがないワイルドカード・クラスターも追加してください。これには、非ワイルドカード・クラスターおよびポートを扱わないすべてのパケットを廃棄する効果があります。ワイルドカード・クラスターおよびワイルドカード・ポートの詳細については、ワイルドカード・クラスターを使用したサーバー構成の結合 および ワイルドカード・ポートを使用した未構成ポート・トラフィックの送信 を参照してください。
バイナリー・ログ機能を使用すれば、サーバー情報をバイナリー・ファイルに保管することができます。 これらのファイルを処理して、ある時間にわたって収集されたサーバー情報を分析することができます。
以下の情報が、構成で定義されたサーバーごとのバイナリー・ログに保管されます。
この情報には、manager サイクルの一部として executor から取得されるものもあります。したがって、情報をバイナリー・ログに記録するために、manager が実行されていなければなりません。
dscontrol log コマンド・セットを使用して、バイナリー・ロギングを構成します。
start オプションは、ログ・ディレクトリーにあるバイナリー・ログへのサーバー情報の記録を開始します。ログは、毎時 0 分に その日時をファイル名として作成されます。
stop オプションは、バイナリー・ログへのサーバー情報の 記録を停止します。ログ・サービスは、デフォルトによって停止しています。
set interval オプションは、情報がログに 書き込まれる頻度を制御します。manager はサーバー情報を manager 間隔ごとにログ・サーバーへ送信します。情報は、最後にログにレコードが書き込まれてから、指定した秒数の経過後にログに書き込まれます。 デフォルトでは、ログ記録間隔は 60 秒に設定されています。manager 間隔と ログ記録間隔の設定の間には、相関関係があります。ログ・サーバーは manager 間隔秒数以下の速度で情報を提供するので、manager 間隔より短いログ記録間隔を設定しようとしても、実際には manager 間隔と同じ値に設定されます。このログ記録方法によって、サーバー情報を取り込む頻度を任意に細分化することができます。サーバーの重みを計算するために、manager によって確認されるサーバー情報に対する 変更をすべて取り込むことができます。ただし、おそらく、この情報は、サーバーの使用および傾向の分析に必要ではありません。60 秒ごとにサーバー情報をログ記録すると、時間の経過とともにサーバー情報のスナップショットがとられます。ログ記録間隔を非常に低く設定すると、膨大な量のデータが生成される場合があります。
set retention オプションは、ログ・ファイルが保持される期間を制御します。指定した保存時間よりも古いログ・ファイルは、ログ・サーバーによって削除されます。これは、ログ・サーバーが manager によって 呼び出されている場合にのみ行われるので、manager が停止していると古いログ・ファイルでも削除されません。
status オプションは、ログ・サービスの現行の設定を戻します。これらの設定は、サービスが開始されているかどうか、間隔、および保存時間です。
次のディレクトリーにサンプル Java プログラムおよびコマンド・ファイルが入っています。
このサンプルは、ログ・ファイルからすべての情報を検索して画面に出力する方法を示します。カスタマイズすると、データについて必要な種類の分析を行うことができます。Dispatcher に提供されているスクリプトおよびプログラムの使用例を以下に示します。
dslogreport 2001/05/01 8:00 2001/05/01 17:00
これによって、2001 年 5 月 1 日の午前 8:00 から午後 5:00 までの Dispatcher コンポーネント・サーバー情報の報告書が得られます。 (CBR の場合、cbrlogreport を使用してください。)
Load Balancer と同一マシンにクライアントを配置する構成を サポートしているのは、Linux システムのみです。
連結クライアント構成は、他のプラットフォームでは正しく機能しない場合があります。 これは、Load Balancer が別の手法を使用して、サポートする各種のオペレーティング・システムで 着信パケットを検査するためです。ほとんどの場合、 Linux 以外のシステムでは、Load Balancer はローカル・マシンからのパケットを 受信しません。ネットワークから入ってくるパケットだけを受信します。このため、 ローカル・マシンからクラスター・アドレスへの要求は、Load Balancer によって受信されず、 サービスの対象にもなりません。