†=負荷分散装置=LBレイヤ4レベルとレイヤ7レベルの負荷分散装置がある。MSのNLBの機能は、負荷分散装置ではないが、負荷分散の仕組みである。SSLによって暗号化されると、Cookieなどのデータの中身を判断した負荷分散は行えない。対策としては、SSLアクセラレータを負荷分散装置の前に配置する。ロードバランサはVIPを持ち、ポートにサーバープールを割り当てる。VIPはグローバルIPアドレス側のポートに割り振る。†パケットの解析・変換パケットの送信先IPアドレス(VIP)を振り分け先のIPアドレスに置き換える。処理の振り分け振り分け方法は負荷分散アルゴリズムに依存する。セッション管理ロードバランサによって同一ユーザーのアクセスを複数のサーバーに振り分けられると、セッション情報の管理をDBなどに持ち、アクセスの度にDB情報を参照する必要がある。これはDBに負荷がかかることを意味する。この問題を防ぐために、ロードバランサ側では同一ユーザーのアクセスは同一サーバーに振り分けるように制御する必要がある。†インターネットトラフィックの増大によって、ボトルネックになり始めたサーバー接続部分(100Mbps)の負荷経験のためにギガビットNICが登場した。続けてこれを収容するためにギガビットL2スイッチが登場した。NICとL2スイッチがギガビットに対応したことにより、サーバーとスイッチの間の帯域は確保されたが、しばらくするとサーバーのCPUに高い負荷がかかることが問題になってきた。この問題への対応として、1パケット当たりのデータサイズを増加させるジャンボフレームという技術を用い、パケットの数を減らすことでサーバーの負荷を減らす方策を採る機器が登場した。ところが、インターネットのトラフィックはその後も増え続け、1台のサーバーで対応するという手法自体が不可能なほどになるまでに増大してしまった。当時可能であった対策としては、大きなコストをかけてサーバーのスペックを向上させるか、DNSラウンドロビンを用いてサーバーへのアクセスを分散することであった。DNSラウンドロビンは正確なアクセス分散ができない。そこでロードバランサ(L4-7スイッチ)が登場した。当初のロードバランサは現在の一般的なものと異なり、第3層の処理はできず、サポートするプロトコルもHTTPを中心としたものであった。以下の2種類が存在するのは、ロードバランサがアプリケーションサーバーのようにサービスを提供する特徴を持つためである。†ロードバランサに特化した設計されたネットワークプロセッサ(ASIC)を搭載し、パケットのヘッダ部分を書き換えてスイッチングすることで、非常に高速なロードバランシング機能を提供する。†ネットワーク機器に特化して開発されたOSを採用することで、高い信頼性を確保する。スイッチタイプとは異なり、IntelのPentiumプロセッサのような汎用チップをメインCPUとして使用している場合が多く、コスト面やハードウェア構成の自由度にメリットを持つ。ソフトウェアの自由度も高く、UNIX/Linuxベースのものも多い。仮想サーバーベースとは、ロードバランサ上に仮想のIPアドレス(VIP)を設定する手法である。ロードバランサは通常外部からアクセスを受けるため、VPIとしてグローバルIPアドレスを割り当てることが多い。この場合、外部のDNSサーバーに登録されるIPアドレスとVIPは同一になる。すべてのクライアントはこのVIPにアクセスして、VIPを保持するロードバランサは自分宛のアクセスを処理しながら実際のサーバーと通信し、クライアントとサーバー間の通信を仲介する。そのため、クライアントからは1つのサーバーにアクセスしているように見える。Address)へ書き換えてから送出する。サーバーからの戻りパケットについては、これと逆の書き換えを行い、クライアント側へパケットを送出する。[補講]クライアントとスイッチ間、スイッチとサーバー間の通信に分割して考えるとわかりやすい。†フィルターベースとは、クライアントからの通信を受け付ける物理ポートでフィルタリングを行い、特定のパケットをサーバーへ強制的に転送(リダイレクト)する方式である。このフィルタリングには、主にクライアントから送られてくるパケットの宛先アプリケーションポート番号を用いる。フィルタベースでは、パケットはルーティングされるのではなく、あくまで受信するパケットの情報を基に物理ポートへ強制転送される。この仕組みは他のネットワーク機器では見られないロードバランサ独自の転送処理である。[例]キャッシュサーバーの負荷分散を行う場合、HTTP(TCP/80番)をフィルタルールに設定することで、クライアントのWebブラウザ側で何らかの設定をすることなく、HTTPのパケットのみをリダイレクトできる。この手法は、FWやSSLアクセラレーターのロードバラインシングでも多用される。†ロードバランサの割り振りアルゴリズムとして、負荷分散アルゴリズムが使用される。†アクセス順ごとに、振り分ける先を切り替える。各サーバーに性能差がない場合に、ラウンドロビンを用いることが多い。各サーバーに重みを付け、アクセスを振り分けるときに使用する。性能差があるサーバーが存在する場合に有効である。†サーバーに優先順位(プライオリティ)を付け、優先順位の高いサーバーのアクセスが一定以上を超えた場合に、優先順位が次に高いサーバーに振り分ける。プライオリティが低いサーバーが負荷が低いときは、異なる用途に使用することができる。現在アクティブなセッションの数より、最もセッション数の少ないサーバーのIPアドレスにリクエストを割り振る。セッション維持数が少ないサーバーに振り分ける。†サーバーのCPU使用率やレスポンスタイムなどを考慮し、最も負荷の低いサーバーのIPアドレスにリクエストを割り振る。ロードバランサからパケットを送信し、応答時間が最短であるサーバーに振り分ける。「応答時間が最短=負荷が最も低い」と判断する。他のアルゴリズムを複合して使用する。†L7のロードバランサで使用可能。サーバーによって動作を変えたい場合に使用する。[例]HTTPヘッダのURLに".cgi"が含まれるのみ、CGIサーバーに振り分ける。◇[例]HTTPヘッダ内のUser-Agentでサーバーを振り分ける。†ロードバランサでセッションステートフルを実現する機能のこと。クライアントIPアドレスを基にリクエストを割り振るWebサーバーを決定する。例:クライアントIPアドレスの末尾が奇数なら、Webサーバー#1にするなど。HTTPヘッダ内に、どのWebサーバーにアクセスしたかという情報を保持する。URLコンテキスト内にどのWebサーバーにアクセスしたか、情報を保持する。†クライアントの送信元IPアドレスが同一の場合に、同一サーバーに振り分ける。Proxy、ファイアウォール、NATにより同一ユーザーが特定しにくい場合は、振り分けに偏りが生じる可能性がある。クライアント側のネットワークがProxyのロードバランスを行っていて、毎回送信元IPアドレスが変わる場合は、この方式でセッション管理はできない。†HTTPヘッダのCookieが同一の場合に、同一サーバーに振り分ける。Cookieの埋め込み方法として、�「ロードバランサ側でCookieにサーバIDを埋め込む方法」と�「サーバー側にてCOOKIEに特定の文字列を埋め込む方法」がある。他APサーバーなどがCookieを使用する場合に、ロードバランサが付与したCookieを上書きしないかどうかなどの確認が必要である。†URLへの情報埋め込みの場合、URLはユーザーが直接編集可能な情報のために、不正アクセスの対策が必要である。一般にハッシュ値を組み込むようにする。Session-IDによるセッション管理は、Session-IDが同一な場合に、同一サーバーに接続する。ブラウザによってはこの方法は使えない。Session-IDが変わってしまうためである。[補講]HTTPSの通信(接続がSSL)の場合、アプリケーションデータは暗号化されるためCookieを用いる方法は使えない。Session-IDをセッション管理に用いることはできる。†L3の監視:Ping監視ネットワークの到達性しか監視できない。L4の監視:TCP監視TCP接続確認しか監視できない。L7の監視:アプリケーション監視アプリケーションの動作に合わせた監視ができる。[補講]UDPポートの監視は困難である。通信経路上にロードバランサを配置するため、通信経路がわかりやすく構成がシンプルになる。拡張性がなく、ロードバランサがボトルネックとなる可能性がある。サーバーからクライアントへの動画や音声の戻り通信がロードバランサに集中して、負荷が高くなる。†ロードバランサをスイッチに横付けで配置する方法である。One-Arm配置では、装置の性能を最大限に引き出せるほか、スイッチ側のVLAN設定により、ロードバランサとの接続を論理的に設定できるため、柔軟に構成の追加変更を行うことが可能である。interface)にロードバランサのVIPと同じIPアドレスを設定する必要があり、これに伴い通信経路を把握しづらくなる。†One-Arm(DSR)返りのトラフィックがロードバランサを経由しない構成のこと。Return"のことである。One-Arm(Bridged)横付けに配置しつつ、行きと返りで同じルートを通る構成のこと。クライアント側とサーバー側で、VLANなどを分ける必要がある。One-Arm(Routed)横付けに配置しつつ、行きと返りで同じルートを通る構成のこと。クライアント側とサーバー側で、VLANなどを分ける必要がある。†メンテナンスの負荷が増大する。サーバーが増えると、増えた分だけメンテナンスの手間が増える。複数のサーバーにアクセスログが分散するため、アクセスログ解析に工夫が必要である。Advertisement(広告)パケットが送信される。Advertisement(広告)パケットが送信不可になると、ロードバランサBはロードバランサAのIPアドレスとMACアドレスを引き継ぐ。Advertisementパケットがロードバランサから送信されるようになるため、元の状態に戻る。共有IPアドレス+シリアル接続によるハートビートサーバーアプライアンス型のロードバランサに多い。正常時はロードバランサAで共有IPアドレスをアップする。ロードバランサAとロードバランサBはシリアルケーブル経由でハートビート確認を行っている。ロードバランサAが障害によってダウンすると、ハートビート確認が失敗する。すると、ロードバランサBは共有IPアドレスをアップする。ロードバランサAを復旧した後で、手動でロードバランサAに共有IPアドレスをアップする。†ロードバランサは配下のWebサーバーの稼動状態を監視する。障害を検知した場合、クライアントのリクエストを他のサーバーへ動的に振り向ける(フェイルオーバー)ことができる。静的コンテンツであれば、クライアントは何も意識する必要はない。動的コンテンツであれば、フェイルオーバーするとセッションの情報が失われるため、そのときのセッション状態は初期化される。障害時にセッションの情報が失われないためには、ファイルオーバー以外の何らかの仕組みが必要である。Beanというセッション情報がある。これらの情報はAPサーバーのJVM上に格納されている。リクエストの分散、セッション情報の冗長化の2つの機能により、APサーバーは冗長化される。APサーバー内の冗長化も、この2つの機能により実現される。†HTTPヘッダのHostやUser-Agentの情報を利用して、IPアドレスやホスト名を仮想的に操作する手法のこと。結論から言うと、両者のロードバランサに違いはない。パケットを転送するためには、パケットの内容を確認する必要がある。挙動はスイッチタイプとプロキシタイプの相違点が存在している。両タイプとも第7層の情報を基にする場合には、一旦クライアントからのセッションを終端し、サーバーとセッションを張り直している。異なるのは第4層の情報を扱う場合には、違いがある。スイッチタイプは第4層の情報を扱う場合、パケットのヘッダを書き換えてサーバー側へ転送するか、あるいは特定の物理ポートへ強制的に転送する。スイッチ的な挙動となる。プロキシタイプは第7層の情報を扱う場合と同様に、セッションを終端にして張り直す。Proxyサーバー的な挙動となる。†DoS攻撃やワームは、膨大なパケットを送信してくるために、ファイアウォールでの負荷が問題になる。そこでインターネットとの境界に置かれたロードバランサがこれらのパケットを検知・破棄することで、ファイアウォールが検査すべきパケットが減るため、負荷を軽減できる。†アクティブなスイッチが背後のサーバーの状態によって、マスター・バックアップを切り替えたり、スタンバイのスイッチがブロッキングポートを設定したりすることよって、柔軟な冗長構成を実現する。このようなホットスタンバイ構成を組もうとすると、VLAN1とVLAN2の各セグメントでL2ループができてしまう。そこで、スタンバイ状態のロードバランサが、自動的にロードバランサ間のリンク以外のポートをブロックすることで、ループを回避する。したがって、スパニングツリーなどのループ回避プロトコルを考慮する必要がない。これにより、リンク切断が起きたときの収束時間が短縮され、またネットワークの設計を簡便にすることにも繋がる。Sorryサーバー(3191d)。