Load Balancer は、カスタマイズできるスクリプトをトリガーするユーザー出口を
提供します。自動化された (サーバーがダウンとマークされると管理者にアラートを通知するか、単に障害のイベントを記録するなどの) アクションを実行するスクリプトを作成できます。
カスタマイズできるサンプル・スクリプトは、
install_root/servers/samples ディレクトリーの中に入っています。これらのファイルを実行するには、
install_root/servers/bin ディレクトリーにこれらのファイルを移動したうえで、ファイル拡張子「sample」を除去する必要があります。以下のサンプル・スクリプトが提供されています。
- serverDown - サーバーには、manager によってダウンのマークが付けられます。
- serverUp - サーバーには、manager によってバックアップのマークが付けられます。
- managerAlert - すべてのサーバーには、特定ポートがダウンしているというマークが付けられます。
- managerClear - 特定ポートがダウンしているというマークがすべてのサーバーに付けられた後に、少なくとも 1 つのサーバーが復活しています。
クラスターのすべてのサーバーに、(ユーザーまたは advisor によって) ダウンのマークが付けられている場合は、
managerAlert (構成されている場合) が開始し、Load Balancer は、ラウ
ンドロビン手法で
トラフィックをサーバーに経路指定しようとします。クラスターの最後のサーバーがオフラインであることが検出されたときは、serverDown スクリプトは実行されません。
Load Balancer は設計上、サーバーがオンラインに復帰して要求に応答する場合のために、
トラフィックのルーティングを継続します。もし Load Balancer がすべてのトラフィックを破棄したなら、
クライアントは応答を受けなくなってしまいます。Load Balancer が、クラスターの最初のサーバーがオンラインに復帰していることを
検出すると、managerClear スクリプト (構成済みの場合) が実行されますが、
serverUp スクリプト (構成済みの場合) は追加のサーバーがオンラインに復帰するまで実行されません。
serverUp スクリプトと serverDown スクリプトの使用に関して、次のような数種類の考慮事項が設けられています。
- manager のサイクルを advisor 時間より 25% 少なく定義した場合、結果としてサーバーの稼働または停止の偽のレポートが生成されます。デフォルトでは、manager は 2 秒ごとに稼働しますが、advisor は 7 秒ごとに稼働します。したがって、manager では 4 サイクル以内に新規の advisor 情報が得られると予想されます。しかし、この制限を除去する (すなわち manager のサイクルを advisor 時間の 25% より多く定義する) と、単一のサーバー上で複数の advisor がアドバイスできるようになるため、パフォーマンスが著しく低下します。
- サーバーが停止したときには、serverDown スクリプトが実行されます。しかし、serverUp コマンドを発行した場合、manager が advisor サイクルから新規の情報を入手するまでサーバーが稼働すると考えられます。それでもまだサーバーが停止している場合は、serverDown スクリプトが再度実行されます。