今回は、ロードバランサの主な3つの機能について説明します。
3つの機能とは・・・・
1.負荷分散
2.ヘルスチェック
3.サーバ接続維持
3つの機能とは・・・・
1.負荷分散
2.ヘルスチェック
3.サーバ接続維持
1. 負荷分散
まずは、1番重要な機能、負荷分散です。
負荷分散については、以前説明していますので、
ここでは負荷分散アルゴリズム(負荷分散の方法)について説明します。
○負荷分散アルゴリズム
・Round Robin:均等に負荷分散を行う (順番に割り振る)
・Ratio:あらかじめ指定した割合で負荷分散を行う
・Least Connections:最もセッション数の少ない対象を選択して負荷分散を行う
・Observed:セッション数と応答速度を監視し、独自のアルゴリズムにより負荷分散を行う
・Predictive:セッション数と応答速度を計測し、パフォーマンスを予測して負荷分散を行う
大きく分けると以下3つの組み合わせになっています。
1.ラウンドロビン(順番に割り振る)
2.最少接続方式
3.最速方式
2. ヘルスチェック
負荷分散を行うために、対象となるサーバやネットワーク機器の稼働状況をチェックする機能です。
ヘルスチェックで振り分け可能なサーバを判断したり、異常の発生を把握します。
○ヘススチェックの種類
1.pingチェック
負荷分散対象のサーバやネットワーク機器にpingを送り応答があれば正常、
応答がなければ異常と判断します。
2.ポートチェック
通信プロトコルレベルで稼働を確認します。
TCP:SYNパケットを送付して、ACKパケットが返ってくれば正常、
返ってこなければ異常と判断します。
3.コンテンツチェック
WEBサーバの場合、実際のWEBコンテンツがリクエストを返してくるかどうかを判断します。
HTTP(S)のGETやPOSTコマンドでリクエストを送り、
サーバが正常に処理を行えば正常、行えなければ異常と判断します。
4.アプリケーションチェック
実際のアプリケーション動作を行うかどうかで稼働を確認します。
例えば、SIPのREGISTERメッセージを送付し成功を伝えるメッセージ(例:200 OK)が
返ってくるかどうかを確認したり、
RADIUS(分散型クライアント/サーバシステムで、不正なアクセスからネットワークを保護する
もの)のアクセスリクエストに対してアクセプト(ユーザIDの認証)が返ってくるかどうか、
といった確認を行います。
3. サーバ接続維持
同一クライアントからの複数のコネクションを同一サーバに送るための機能です。
例えば、長い間クライアントとサーバとの接続が必要な場合
その間のクライアントのリクエストは同一のサーバに割り振らないといけません。
LBがどのようにして同一クライアントであることを判断するのか、その判断方法について説明します。
○サーバ接続維持方法
・ソースIPアドレス
クライアントのIPアドレスで判断する方法です。
ネットマスク設定も可能なため同一ネットワークで判断することも可能です。
※Proxyサーバが負荷分散されている環境などIPが変則的なクライアントには不向きです。
多数のリクエストが同一のIPから来る場合、サーバの負荷が偏ってしまいます。
・SSLセッションID
SSLセッションIDで判断する方法。IDが同一の間は同一のサーバに割り振ります。
※SSL通信の場合しか使用できません。
またブラウザでセッションIDが一定時間ごとに変更されてしまう機能があるため、
あまり使用されていないのが現状です。
・Cookie
最も一般的な方法です。
Cookieの中に前回アクセスしたサーバの情報(IPアドレス・ポート情報)を埋め込み、
次回のクライアントリクエスト時にロードバランサ(以降LB)でその情報を読み取って
同一サーバにリクエストを割り振ります。
※HTTPSの場合は使用できません。(SSLアクセラレータが存在する環境では使用可能)
・サーバIDやユーザーID(接続サーバやクライアントを識別できる情報)
cookieに対応していない携帯端末向けサイトなどで、前回接続したサーバの情報(サーバID)を
サーバ側でURLに埋め込みその情報をLBで読み込む方法です。
※シスコ、Alteon、ファウンダリ、など主要ベンダー製品がこの方法を導入しています。
URLなどの中に端末個体識別情報などが存在する場合はその情報のハッシュ値により
接続維持を実現できます。
※この方法の導入はBIG-IPのみです。
次の記事で、負荷分散動作のしくみについて説明していきます。
まずは、1番重要な機能、負荷分散です。
負荷分散については、以前説明していますので、
ここでは負荷分散アルゴリズム(負荷分散の方法)について説明します。
○負荷分散アルゴリズム
・Round Robin:均等に負荷分散を行う (順番に割り振る)
・Ratio:あらかじめ指定した割合で負荷分散を行う
・Least Connections:最もセッション数の少ない対象を選択して負荷分散を行う
・Observed:セッション数と応答速度を監視し、独自のアルゴリズムにより負荷分散を行う
・Predictive:セッション数と応答速度を計測し、パフォーマンスを予測して負荷分散を行う
大きく分けると以下3つの組み合わせになっています。
1.ラウンドロビン(順番に割り振る)
2.最少接続方式
3.最速方式
2. ヘルスチェック
負荷分散を行うために、対象となるサーバやネットワーク機器の稼働状況をチェックする機能です。
ヘルスチェックで振り分け可能なサーバを判断したり、異常の発生を把握します。
○ヘススチェックの種類
1.pingチェック
負荷分散対象のサーバやネットワーク機器にpingを送り応答があれば正常、
応答がなければ異常と判断します。
2.ポートチェック
通信プロトコルレベルで稼働を確認します。
TCP:SYNパケットを送付して、ACKパケットが返ってくれば正常、
返ってこなければ異常と判断します。
3.コンテンツチェック
WEBサーバの場合、実際のWEBコンテンツがリクエストを返してくるかどうかを判断します。
HTTP(S)のGETやPOSTコマンドでリクエストを送り、
サーバが正常に処理を行えば正常、行えなければ異常と判断します。
4.アプリケーションチェック
実際のアプリケーション動作を行うかどうかで稼働を確認します。
例えば、SIPのREGISTERメッセージを送付し成功を伝えるメッセージ(例:200 OK)が
返ってくるかどうかを確認したり、
RADIUS(分散型クライアント/サーバシステムで、不正なアクセスからネットワークを保護する
もの)のアクセスリクエストに対してアクセプト(ユーザIDの認証)が返ってくるかどうか、
といった確認を行います。
3. サーバ接続維持
同一クライアントからの複数のコネクションを同一サーバに送るための機能です。
例えば、長い間クライアントとサーバとの接続が必要な場合
その間のクライアントのリクエストは同一のサーバに割り振らないといけません。
LBがどのようにして同一クライアントであることを判断するのか、その判断方法について説明します。
○サーバ接続維持方法
・ソースIPアドレス
クライアントのIPアドレスで判断する方法です。
ネットマスク設定も可能なため同一ネットワークで判断することも可能です。
※Proxyサーバが負荷分散されている環境などIPが変則的なクライアントには不向きです。
多数のリクエストが同一のIPから来る場合、サーバの負荷が偏ってしまいます。
・SSLセッションID
SSLセッションIDで判断する方法。IDが同一の間は同一のサーバに割り振ります。
※SSL通信の場合しか使用できません。
またブラウザでセッションIDが一定時間ごとに変更されてしまう機能があるため、
あまり使用されていないのが現状です。
・Cookie
最も一般的な方法です。
Cookieの中に前回アクセスしたサーバの情報(IPアドレス・ポート情報)を埋め込み、
次回のクライアントリクエスト時にロードバランサ(以降LB)でその情報を読み取って
同一サーバにリクエストを割り振ります。
※HTTPSの場合は使用できません。(SSLアクセラレータが存在する環境では使用可能)
・サーバIDやユーザーID(接続サーバやクライアントを識別できる情報)
cookieに対応していない携帯端末向けサイトなどで、前回接続したサーバの情報(サーバID)を
サーバ側でURLに埋め込みその情報をLBで読み込む方法です。
※シスコ、Alteon、ファウンダリ、など主要ベンダー製品がこの方法を導入しています。
URLなどの中に端末個体識別情報などが存在する場合はその情報のハッシュ値により
接続維持を実現できます。
※この方法の導入はBIG-IPのみです。
次の記事で、負荷分散動作のしくみについて説明していきます。
