advisor は、与えられたサーバー上の負荷に関する情報を提供するために Load Balancer 内で作動するソフトウェア・エージェントです。
標準プロトコル (HTTP、SSL、その他) ごとに異なる advisor が存在します。
Load Balancer 基本コードは定期的に advisor サイクルを実行し、各サイクルで構成内のすべてのサーバーの状況を個別に評価します。
始める前に
advisor は、Load Balancer 内のエージェントです。これは、サーバー・マシンの状態および負荷の状態を評価することを目的としています。これは、サーバーとの事前の対策を講じたクライアント式交換で行われます。advisor は、アプリケーション・サーバーの lightweight クライアントと見なすことができます。
Load Balancer 用にユーザー独自の advisor を作成することで、サーバー・マシンの負荷の
判別方法をカスタマイズすることができます。
advisor が動作する方法についての詳細は、advisorをお読みください。
当製品は、最も一般的なプロトコルに対して、いくつかのプロトコル特有の advisor を提供します。しかし、提供された advisor のすべてを Load Balancer で使用することは意味がありません。
また、Load Balancer は、ユーザーが独自の advisor を作成できる『カスタム advisor』の概念もサポートします。
バインド固有のサーバー・アプリケーションで advisor を使用する場合の制限- バインド固有
サーバー上で advisor を使用するためには、サーバーの 2 つのインスタンスを開始します。1 つは cluster@port 上でバインドするためのインスタンスで、もう 1 つは server@port 上でバインドするためのインスタンスです。
サーバーがバインド固有のものかどうかを判別するには、netstat -an コマンドを発行して server@port を検索します。
サーバーが
バインド固有でない場合、このコマンドの結果は 0.0.0.0:80 です。サーバーがバインド固有のサーバーである場合は、192.168.15.103:80 などのアドレスが表示されます。
ifconfig alias コマンドの代わりに arp publish を使用する場合、Load Balancer は、クラスター IP アドレスへのバインド中にバインド固有サーバー・アプリケーションについてのサーバーのロード・バランシングをする際、advisor の使用をサポートします。
このタスクについて
すべてのクラスターで advisor を特定のポート用に開始することができます (グループ advisor)。
また、別のクラスターで
あれば、同一ポートで別の advisor を実行することが選択できます (クラスター固有の advisor)。
注: 複数のネットワーク・アダプター・カードを備えたコンピューターで Load Balancer を実行している場合、パケットの送信元 IP アドレスを特定のアドレスに指定することで、advisor トラフィックが特定のアダプターを通過するようにすることはできません。
手順
- 選択した advisor を開始します。 実行可能な advisor のリストに関しては、advisor のリスト、またはカスタム advisor の作成を参照してください。
- クラスター固有の advisor: advisor をポート 80 で clusterA 用に開始するには、例えば以下のようにクラスターとポートを両方とも指定します。
dscontrol advisor start ADV_name clusterA@80
このコマンドは、advisor をポート 80 で clusterA 用に開始します。この advisor は、ポート 80 で clusterA 用に接続されているすべてのサーバーに通知されることになります。
- グループ advisor: advisor をポート 80 でその他のすべてのクラスター用に開始するためには、以下のように単にそのポートを指定します。
dscontrol advisor start ADV_name 80
このコマンドは、クラスター固有またはサイト固有の advisor を現在持たないすべての
クラスターおよびサイト用に、advisor をポート 80 で開始します。advisor は、ポート 80 に接
続されているすべてのサーバーに通知されることになります。
- オプション: HTTP advisor または HTTPS advisor を開始する場合、固有のクライアント URL ストリングを定義して、advisor がサーバーの個々のサービスを
モニターできるようにすることができます。このオプションについての詳細は、advisor 要求または応答オプションによるサービス固有のアドバイスの取得を参照してください。
- オプション: advisor 間隔を設定します。 advisor 間隔は、advisor がモニターして、その結果を manager に報告するポートのサーバーから
状況を求める頻度を設定します。advisor 間隔が短過ぎると、advisor が絶えずサーバーに割り込むことになり、パフォーマンスの低下を生じることになります。advisor 間隔が長過ぎると、重み付け
に関する manager の決定が、正確な最新情報に基づかなくなるということになります。
注: advisor のデフォルトは、考えられるほとんどのシナリオで効率よく機能するはずです。
デフォルト以外の値を入力する場合は注意してください。
例えば、ポート 80 の HTTP advisor の場合に、間隔を 3 秒に設定するには、以下のコマンドを入力します。
dscontrol advisor interval http 80 3
manager 間隔より小さい advisor 間隔を指定することは無意味です。advisor 間隔のデフォルト値は 7 秒です。
- オプション: advisor 報告タイムアウトを設定します。 タイムアウト日付がロード・バランシングの判断で manager によって使用されないことを確実にするために、manager は、タイム・スタンプが advisor 報告タイムアウトで設定されている時刻より古い、advisor からの情報を使用しないことになります。advisor 報告タイムアウトは、advisor ポーリング間隔よりも大きくなっている必要があります。タイムアウトが小さいと、manager は、論理的には使用すべき報告を無視します。デフォルトでは、advisor 報告はタイムアウトにはなりません - デフォルト値は無制限です。
例えば、ポート 80 の HTTP advisor のために、advisor 報告タイムアウトを 30 秒に設定するには、次のコマンドを入力してください。
dscontrol advisor timeout http 80 30
advisor 報告タイムアウトの設定についての詳細は、
dscontrol advisorを参照してください。
- オプション: advisor 接続タイムアウト値および受信タイムアウト値を設定します。 Load Balancer の場合、サーバー (サービス) 上の特定のポートが失敗していることを検出する、advisor のタイムアウト値を設定できます。
失敗したサーバー・タイムアウト値 (connecttimeout および receivetimeout) によって、advisor が接続または受信のいずれかの失敗を報告する前に待つ時間が決定されます。
最初に失敗したサーバーを検出するために、advisor 接続タイムアウトおよび受信タイムアウトを最小値 (1 秒) に設定し、advisor および manager 間隔時間を最小値 (1 秒) に設定します。
注: ご利用の環境で中程度から高程度のボリュームのトラフィックが発生し、サーバーの応答時間が長くなる場合は、connecttimeout および receivetimeout の値をあまり小さく設定しないように注意してください。小さく設定しすぎると、advisor がビジー状態のサーバーに、通常よりも早く障害というマークを付けてしまう可能性があります。
例えば、ポート 80 で HTTP advisor の connecttimeout および receivetimeout を 9 秒に設定するには、次のコマンドを入力します。
dscontrol advisor connecttimeout http 80 9
dscontrol advisor receivetimeout http 80 9
接続タイムアウトと受信タイムアウトのデフォルトは、advisor 間隔に指定されている値の 3 倍です。
- オプション: advisor retry 値を設定します。 advisor は、サーバーをダウンとしてマーク付けする前に、接続を再試行する機能を持っています。
advisor は、(再試行回数 + 1) の回数、サーバー照会が失敗するまでは、サーバーに
ダウンというマークを付けしません。retry 値は 3 以下にしてください。
以下のコマンドは、ポート 389 の LDAP advisor に 2 の retry 値を設定します。
dscontrol advisor retry ldap 389 2