1.負荷分散装置（LB:Load Balancer）
・負荷分散装置＝ロードバランサと思ってよい。ネットワークスペシャリスト試験ではLBと図に書かれることが多い。
・道路（road）ではなく、負荷（load）をバランス（balace）良く分配する装置（er）
・過去問にはロードバランサの基本機能の説明として「クライアントからの要求が特定のサーバに集中しないように、複数のサーバに振り分ける。（H20NW午前 問9）」との記載がある。
・SSLによって暗号化されると、Cookieなどのデータの中身を見た負荷分散が行えない。SSLアクセラレータをどこに置くかという問題がSMで出題されていた。（H17年SM午後1 問3 設問2(2)）
・HTTPはステートレスな通信である。そこで、HTTPの通信が毎回違うサーバに振り分けられるとやっかい。過去問では、どうやってセッションを保持するかについて問われたと思う。
・L4レベルとL7レベルの負荷分散装置がある。
・L3レベルの負荷分散は、負荷分散装置ではなくVRRPなどのルータの機能で実現することが多い。
・実際の製品としては、BigIPやリンクプルーフなどがあるだろう。また、Microsoft社のNLBの機能も、負荷分散装置ではないが、負荷分散の仕組みである。それ以外にはDNSラウンドロビンによる負荷分散をとる方法もある。
・仕組み
負荷分散装置が実IP以外に仮想IPアドレスを持つ。
・実際の製品では、負荷分散の機能だけでなく、セキュリティ機能や高速化（SSLの高速化、帯域圧縮）機能なども付加した製品が多く、アプリケーションスイッチと呼ばれることもある。（試験には出ないと思う）
では、LBの設定画面を紹介します。Citrix Netscalerでの設定です。1つ目が仮想IPの設定で、10.1.1.254を設定しています。また、その次が、振り分け先のサーバの設定です。振り分け先のサーバとして、192.168.1.101などの3つのIPアドレスを設定しています。
2.負荷分散装置（過去問での解説）
H21年NW午後1問3に負荷分散装置（LB：ロードバランサ）に関する出題がある。これを解説することで、負荷分散装置の理解を深めてほしい。
 [増強するeシステムの構成] eシステムの増強は，情報システム部のP君が担当することになった。P君は，eシステムの利用者数と，ベンダから入手したパフォーマンスに関する仕様を基に，eSVRとLBの機種を選定した。また，コンテンツと管理情報の一元管理のために，ファイルサーバも併せて導入することにした。 選定したLBは，(ⅰ)処理の振分け機能，(ⅱ)[ ア ]維持機能，(ⅲ)ヘルスチェック機能 をもっている。(ⅰ)には，様々な方式がある。システムの応答時間は，eSVRの負荷の増加とともに長くなると考えられたので，応答時間が最短のeSVRに処理を振り分ける方式を採用することにした。(ⅱ)には，リクエスト元のIPアドレスに基づいて行うレイヤ3方式や，Webページにアクセスしたユーザに関する情報を保持する[ イ ]に埋め込まれた，セッションIDに基づいて行うレイヤ7方式などがある。eシステムを利用するPCには， IPアドレスが固定設定されているので，レイヤ3方式を利用することにした。(ⅲ)には，レイヤ3，レイヤ4及びレイヤ7の各レイヤで稼働状況を監視する方式がある。eシステムのサービスポートの稼働状況を監視するために，レイヤ4方式を利用することにした。 LBの故障時に，ネットワーク構成を変更しなくてもeシステムの運用が継続できるように，LBとeSVRは，図の構成で設置することにした。 PCからのeシステム利用には，社内のPCを三つのブロックに分け，各ブロックのPCごとに，異なったeSVRのホスト名を指定させる。DNSで，三つのホスト名に一つのVIPを対応付けることによって，LB経由でeSVRに接続できる。このように， eSVRのホスト名を使い分けることで，LBの故障時にも①DNSの設定変更によって，3台のeSVRに処理を振り分けることができる。選定したLBには， PCからVIPあてに送信されたパケットの，送信元IPアドレスをLBの実アドレスに変換してeSVRに転送する，ソースNAT機能がある。ソースNAT機能を利用すると，既設eSVRのネットワーク情報の設定変更が不要になる。しかし，②管理上必要な情報が，eSVRのログから取得できなくなってしまう問題があるので，ソースNAT機能は利用しないことにした。 |
負荷分散装置の機能には以下がある。 ※問題文を活用して解説します。
また、また、負荷分散とセッション維持は別物であることを、きちんと認識してください。基本的に、負荷分散はL3かL4です。
ただ、アプリケーションの作りの関係から、Cookie情報を保持したいときがある。そんな場合。負荷分散はL4で実施した後、セッション維持はL7、つまりCookieでする、なんてことは、普通によくある
※通常、SSLであっても、SSLはLBで復号するので、Cookieは分かるはず。
(1)処理の振分け機能・・・負荷分散装置の基本機能
「(i)には様々な方式がある。」と書かれているように、様々な方式があります。例えば、ラウンドロビン方式として順番に振り分ける、接続されているセッション数が少ないサーバに振り分ける、サーバの負荷を判断して振り分ける、などがあります。
この問題では「応答時間が最短」のサーバに振り分けると述べられています。振分け方式は製品によって異なります。
以下は、CitixのNetScalerの設定画面です。振り分け方式として、ROUNDROBIN、LEASTCONNECTION（最もコネクション数が少ない）、などが選べることがわかります。
また、振り分ける際にL4レベルでの振分けも可能で、ポート番号を見てアプリケーションごとにサーバを振り分けることもできます。
そして、L7レベルでも振り分けはできますが、あまり使わないでしょう。たとえば、URLでの振り分けです。
http://www.example.com/siteA/ ⇒サーバ１
http://www.example.com/siteB/ ⇒サーバ２
(2)セッション維持機能・・・接続先のサーバが変化しても、利用者のセッションを維持する。
ユーザが情報を入力したり、その入力情報に基づいた動きをするサーバの場合、LBにて違うサーバに接続させられては困る。
セッション維持機能って必要ですか？
振分け機能で、同じサーバに接続するのでは？
送信元IPアドレス単位で振分けていれば、同じサーバに接続するでしょう。でも、ラウンドロビン方式や、負荷状況を見て振り分ける場合には、別のサーバに振分けられるかもしれません。ですから、セッション維持機能は必要です。
①L3方式
リクエスト元のIPアドレスに基づいてセッションを維持する。実際には、一定時間が過ぎるとIPアドレス情報と接続サーバとの関係を保持した情報は廃棄されるであろう。
②L7方式
Cookieに埋め込まれたセッションIDに基づいて行う。または、HTTPのヘッダ内容を見る場合がある。この場合は、TCPのコネクションを確立しないと中身を見ることができないので、LBがサーバの代わりに3Wayハンドシェイクのコネクションを確立する。その後、LBが接続するサーバのみとTCPコネクションを確立することになる。
以下は、CitixのNetScalerの設定画面です。Persistenceなので、セッション維持の設定です。Cookieが選択できることがわかります。
Cookieの名前を設定できる画面がありますが、どういう意味ですか？
CookieはサーバとPCでやり取りされるもの。LBは関与できないですよね？
そこは大きな間違い。そのCookieというのは、サーバが発行したものではなく、LBがクライアントPCに発行する。あくまでも、LBによるセッション維持のためだけのCookieである。
(3)ヘルスチェック機能・・・サーバの生死を確認する機能
「レイヤ3、レイヤ4及びレイヤ7の各レイヤで稼働状況を監視する方式がある。」と述べられている。
後半に述べられている、LB故障時の仕組みは非常に面白い。
業務で参考にさせてもらうつもりだ。
よくある設計として、LBをインラインに入れる。つまり「PC→LB→サーバ」という一連の流れで接続するのだ。LBはフェールオープン機能が無いものが多いため、LBが故障すると、サーバへの通信ができなくなる。そこで、LBをやむなく（無駄に）二重化することが多い。
情報処理試験のこの問題文では、LBを1台で運用する方法を書いている。LBをインラインに入れず、DNSの設定変更だけでサーバへアクセスできるようにしているのである。
何を言っているのか分からない人も多いかもしれないが、感動したのは私だけでは無いと思う。
3.DSR方式の負荷分散装置
負荷分散装置は、ネットワーク上にどう構成するのでしょうか。一つは、ネットワークのインライン上に配置する方式です。もう一つは、DSR（Direct Server Return）方式です。
インラインで配置する方式の場合は、往路と復路の両方でLBを経由します。一方のDSR方式では、フルスペルの通り、また、DSR方式は，応答パケットをサーバ（Server）に直接（Direct）返信（Return）する方式です。よって、往路と復路が異なります。
（１）インライン上に配置する方式
この方式であれば、SSLを終端したり，HTTPヘッダを挿入したりするなど，様々な処理が行えます。この方式の動作は次のとおりです。
①PCが送信した要求パケットは，LBが受信します。
②LBは，振り分け先のサーバに要求パケットを送信します。
③サーバは応答パケットをLBに送信します。
④LBは応答パケットをPCに送信します。
（２）DSR方式
DSRは、直接（Directに）パケットを返信（Return）します。この方式の動作は次のとおりです。
①PCが送信した要求パケットを，LBが受信します。
②LBは，振り分け先のサーバに要求パケットを送信します。
③サーバは応答パケットをPCに直接返信します。
この方式の利点は、スループット向上が期待できることと、LBが故障してもDNSの設定変更だけでサーバと通信させられることです。具体的には、サーバの仮想IPアドレスとしてLBのIPアドレスを指定していたところ、実サーバのIPアドレスを指定するのです。
