Top / ロードバランサ

ロードバランサ

Tweet

目次 †

ロードバランサ †

• ＝負荷分散装置
• ＝LB
• レイヤ4レベルとレイヤ7レベルの負荷分散装置がある。
• MSのNLBの機能は、負荷分散装置ではないが、負荷分散の仕組みである。
• SSLによって暗号化されると、Cookieなどのデータの中身を判断した負荷分散は行えない。
  • 対策としては、SSLアクセラレータを負荷分散装置の前に配置する。
• ロードバランサはVIPを持ち、ポートにサーバープールを割り当てる。
  • VIPはグローバルIPアドレス側のポートに割り振る。

ロードバランサの機能 †

1. パケットの解析・変換
   • パケットの送信先IPアドレス（VIP）を振り分け先のIPアドレスに置き換える。
2. 処理の振り分け
   • 振り分け方法は負荷分散アルゴリズムに依存する。
3. セッション管理
   • ロードバランサによって同一ユーザーのアクセスを複数のサーバーに振り分けられると、セッション情報の管理をDBなどに持ち、アクセスの度にDB情報を参照する必要がある。これはDBに負荷がかかることを意味する。
     • この問題を防ぐために、ロードバランサ側では同一ユーザーのアクセスは同一サーバーに振り分けるように制御する必要がある。
4. ヘルスチェック
5. ロードバランサ自身の冗長化

歴史 †

• インターネットトラフィックの増大によって、ボトルネックになり始めたサーバー接続部分（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つのサーバーにアクセスしているように見える。
  • クライアントからパケットが送られてくると、ロードバランサはパケットヘッダに記載されている地震のVIPとVMAC(Virtual MAC Address)を、サーバーファームの実際のサーバーのRMAC(Real MAC Address)とRIP(Real IP Address)へ書き換えてから送出する。
  • サーバーからの戻りパケットについては、これと逆の書き換えを行い、クライアント側へパケットを送出する。

[補講]クライアントとスイッチ間、スイッチとサーバー間の通信に分割して考えるとわかりやすい。　◇

フィルターベース †

• フィルターベースとは、クライアントからの通信を受け付ける物理ポートでフィルタリングを行い、特定のパケットをサーバーへ強制的に転送（リダイレクト）する方式である。
  • このフィルタリングには、主にクライアントから送られてくるパケットの宛先アプリケーションポート番号を用いる。
• フィルタベースでは、パケットはルーティングされるのではなく、あくまで受信するパケットの情報を基に物理ポートへ強制転送される。
  • この仕組みは他のネットワーク機器では見られないロードバランサ独自の転送処理である。

[例]キャッシュサーバーの負荷分散を行う場合、HTTP（TCP/80番）をフィルタルールに設定することで、クライアントのWebブラウザ側で何らかの設定をすることなく、HTTPのパケットのみをリダイレクトできる。

　この手法は、FWやSSLアクセラレーターのロードバラインシングでも多用される。　◇

負荷分散アルゴリズムの種類 †

　ロードバランサの割り振りアルゴリズムとして、負荷分散アルゴリズムが使用される。

• ラウンドロビン
• 重み付け
• 優先順位
• 接続数（リーストコネクション）
• 応答時間（レスポンスタイム）
• 複合型
• HTTPヘッダ

ラウンドロビン †

• アクセス順ごとに、振り分ける先を切り替える。
• 各サーバーに性能差がない場合に、ラウンドロビンを用いることが多い。

重み付け †

• 各サーバーに重みを付け、アクセスを振り分けるときに使用する。
• 性能差があるサーバーが存在する場合に有効である。

優先順位 †

• サーバーに優先順位（プライオリティ）を付け、優先順位の高いサーバーのアクセスが一定以上を超えた場合に、優先順位が次に高いサーバーに振り分ける。
• プライオリティが低いサーバーが負荷が低いときは、異なる用途に使用することができる。

接続数 †

• 現在アクティブなセッションの数より、最もセッション数の少ないサーバーのIPアドレスにリクエストを割り振る。

• セッション維持数が少ないサーバーに振り分ける。

応答時間 †

• サーバーのCPU使用率やレスポンスタイムなどを考慮し、最も負荷の低いサーバーのIPアドレスにリクエストを割り振る。
• ロードバランサからパケットを送信し、応答時間が最短であるサーバーに振り分ける。
  • 「応答時間が最短＝負荷が最も低い」と判断する。

複合型 †

• 他のアルゴリズムを複合して使用する。

HTTPヘッダ †

• L7のロードバランサで使用可能。
• サーバーによって動作を変えたい場合に使用する。

[例]HTTPヘッダのURLに".cgi"が含まれるのみ、CGIサーバーに振り分ける。　◇

[例]HTTPヘッダ内のUser-Agentでサーバーを振り分ける。

パーシステンス †

• ロードバランサでセッションステートフルを実現する機能のこと。

主なパーシステンス †

ソースIPアドレス（発信元IPアドレス）によるパーシステンス †

• クライアントの送信元IPアドレスが同一の場合に、同一サーバーに振り分ける。
• Proxy、ファイアウォール、NATにより同一ユーザーが特定しにくい場合は、振り分けに偏りが生じる可能性がある。
• クライアント側のネットワークがProxyのロードバランスを行っていて、毎回送信元IPアドレスが変わる場合は、この方式でセッション管理はできない。

Cookieによるパーシステンス †

• HTTPヘッダのCookieが同一の場合に、同一サーバーに振り分ける。
• Cookieの埋め込み方法として、�　屮蹇璽疋丱薀鵐蟻Δ�CookieにサーバIDを埋め込む方法」と�◆屮機璽弌実Δ砲�COOKIEに特定の文字列を埋め込む方法」がある。
• 他APサーバーなどがCookieを使用する場合に、ロードバランサが付与したCookieを上書きしないかどうかなどの確認が必要である。

URLによるパーシステンス †

• URLへの情報埋め込みの場合、URLはユーザーが直接編集可能な情報のために、不正アクセスの対策が必要である。
• 一般にハッシュ値を組み込むようにする。

SSL Session-IDによるパーシステンス †

• SSL Session-IDによるセッション管理は、Session-IDが同一な場合に、同一サーバーに接続する。
• ブラウザによってはこの方法は使えない。
  • 例えば、IEは使用不能。IEの機能でデフォルト2分に1回、SSLネゴシエイションを行うためにSSL Session-IDが変わってしまうためである。

[補講]HTTPSの通信（接続がSSL）の場合、アプリケーションデータは暗号化されるためCookieを用いる方法は使えない。

　なお、送信元IPアドレス、SSL Session-IDをセッション管理に用いることはできる。◇

ロードバランサのヘルスチェック †

• L3の監視：Ping監視
  • ネットワークの到達性しか監視できない。
• L4の監視：TCP監視
  • TCP接続確認しか監視できない。
• L7の監視：アプリケーション監視
  • アプリケーションの動作に合わせた監視ができる。

[補講]UDPポートの監視は困難である。　◇

ロードバランサの配置の種類 †

• Two-Arm(inline)
• One-Arm

Two-Arm(inline) †

• 通信経路上にロードバランサを配置するため、通信経路がわかりやすく構成がシンプルになる。
• 拡張性がなく、ロードバランサがボトルネックとなる可能性がある。
  • 特にサーバーからクライアントへの動画や音声の戻り通信がロードバランサに集中して、負荷が高くなる。

One-Arm †

• ロードバランサをスイッチに横付けで配置する方法である。
• One-Arm配置では、装置の性能を最大限に引き出せるほか、スイッチ側のVLAN設定により、ロードバランサとの接続を論理的に設定できるため、柔軟に構成の追加変更を行うことが可能である。
• サーバのVirtual Interface（Loopback interface）にロードバランサのVIPと同じIPアドレスを設定する必要があり、これに伴い通信経路を把握しづらくなる。

One-Armの種類 †

• One-Arm(DSR)
  • 返りのトラフィックがロードバランサを経由しない構成のこと。
  • DSRとは"Direct Server Return"のことである。
• One-Arm(Bridged)
  • 横付けに配置しつつ、行きと返りで同じルートを通る構成のこと。
  • クライアント側とサーバー側で、VLANなどを分ける必要がある。
• One-Arm(Routed)
  • 横付けに配置しつつ、行きと返りで同じルートを通る構成のこと。
  • クライアント側とサーバー側で、VLANなどを分ける必要がある。

ロードバランサのデメリット †

• メンテナンスの負荷が増大する。
  • サーバーが増えると、増えた分だけメンテナンスの手間が増える。
  • 複数のサーバーにアクセスログが分散するため、アクセスログ解析に工夫が必要である。

ロードバランサの冗長化の手法 †

• VRRPを利用した冗長化構成
  • 正常時はロードバランサAからVRRP Advertisement（広告）パケットが送信される。
  • 障害によりロードバランサAがダウンし、VRRP Advertisement（広告）パケットが送信不可になると、ロードバランサBはロードバランサAのIPアドレスとMACアドレスを引き継ぐ。
  • 復旧した後、プライオリティが高いVRRP Advertisementパケットがロードバランサから送信されるようになるため、元の状態に戻る。
• 共有IPアドレス＋シリアル接続によるハートビート
  • サーバーアプライアンス型のロードバランサに多い。
  • 正常時はロードバランサAで共有IPアドレスをアップする。また、ロードバランサAとロードバランサBはシリアルケーブル経由でハートビート確認を行っている。
  • ロードバランサAが障害によってダウンすると、ハートビート確認が失敗する。すると、ロードバランサBは共有IPアドレスをアップする。
  • ロードバランサAを復旧した後で、手動でロードバランサAに共有IPアドレスをアップする。

転送先サーバーの障害 †

• ロードバランサは配下のWebサーバーの稼動状態を監視する。障害を検知した場合、クライアントのリクエストを他のサーバーへ動的に振り向ける（フェイルオーバー）ことができる。
• 静的コンテンツであれば、クライアントは何も意識する必要はない。
  • 一方、動的コンテンツであれば、フェイルオーバーするとセッションの情報が失われるため、そのときのセッション状態は初期化される。
• 障害時にセッションの情報が失われないためには、ファイルオーバー以外の何らかの仕組みが必要である。

[補講]ServletやJSPのHTTPSession、EJBのStateful Session Beanというセッション情報がある。

　これらの情報はAPサーバーのJVM上に格納されている。リクエストの分散、セッション情報の冗長化の2つの機能により、APサーバーは冗長化される。また、APサーバー内の冗長化も、この2つの機能により実現される。　◇

バーチャルホスティング †

• HTTPヘッダのHostやUser-Agentの情報を利用して、IPアドレスやホスト名を仮想的に操作する手法のこと。

パケットタイプとプロキシタイプの違い †

第7層の情報を基にロードバランシングする場合 †

• 結論から言うと、両者のロードバランサに違いはない。
• パケットを転送するためには、パケットの内容を確認する必要がある。
  • 挙動はスイッチタイプとプロキシタイプの相違点が存在している。
    • 両タイプとも第7層の情報を基にする場合には、一旦クライアントからのセッションを終端し、サーバーとセッションを張り直している。

第4層の情報を基にロードバランシングする場合 †

• 異なるのは第4層の情報を扱う場合には、違いがある。
• スイッチタイプは第4層の情報を扱う場合、パケットのヘッダを書き換えてサーバー側へ転送するか、あるいは特定の物理ポートへ強制的に転送する。
  • つまり、スイッチ的な挙動となる。
• 一方、プロキシタイプは第7層の情報を扱う場合と同様に、セッションを終端にして張り直す。
  • つまり、Proxyサーバー的な挙動となる。

ロードバランサによるセキュリティ対策 †

• DoS攻撃やワームは、膨大なパケットを送信してくるために、ファイアウォールでの負荷が問題になる。
  • そこでインターネットとの境界に置かれたロードバランサがこれらのパケットを検知・破棄することで、ファイアウォールが検査すべきパケットが減るため、負荷を軽減できる。

スイッチタイプのロードバランサで構成したホットスタンバイ構成 †

• アクティブなスイッチが背後のサーバーの状態によって、マスター・バックアップを切り替えたり、スタンバイのスイッチがブロッキングポートを設定したりすることよって、柔軟な冗長構成を実現する。
• このようなホットスタンバイ構成を組もうとすると、VLAN1とVLAN2の各セグメントでL2ループができてしまう。
  • そこで、スタンバイ状態のロードバランサが、自動的にロードバランサ間のリンク以外のポートをブロックすることで、ループを回避する。
  • したがって、スパニングツリーなどのループ回避プロトコルを考慮する必要がない。
    • これにより、リンク切断が起きたときの収束時間が短縮され、またネットワークの設計を簡便にすることにも繋がる。

参考文献 †

• 『絵で見てわかるITインフラの仕組み』
• 『ネットワーク現場の教科書　改訂版』