サーバは時に負担するサーバーが多すぎる圧力、外部にサービスを提供し、サービスはケースサービスが利用できないので、サーバーは需要を満たすことができないならば、我々は、合理的な範囲内にあるサーバーへの圧力をさせてください生成することができ、あなたは複数のサーバーが全体のサービスを提供する際に、これらの圧力、これらのサーバーを共有し、そして圧力として評価され、その後、我々は、これらのサーバを呼び出すことができます拡張することができ、「ロードバランシングクラスタ。」
LVSは、Linux Virtual ServerのあるLinuxの仮想サーバーと呼ばれています。今、LVSは、すでに標準のLinuxカーネルの一部であり、カーネルLinux2.4以降では、LVSは完全に任意のカーネルパッチを加えることなく、様々な機能モジュールの構築されている、あなたは直接LVSが提供する様々な機能を使用することができます。netfilterのモジュールはipvsadmのための、本、IPVS管理ツールであるとして、カーネル名でLVSは、IPVSです。
LVSロードバランシングが4、それはOSIモデルの第四層の上に構築されている - トランスポート層の上に、おなじみのTCP / UDPがあり、LVSは、TCP /トランスポート層の上に均衡UDPロードをサポートしています。LVSロードバランシングが4であるので、そのような代替のDNSドメイン名の解決、アプリケーション層負荷スケジューリング、クライアント・スケジューリングのような他の高レベルの負荷分散ソリューションと比較しているので、その効率は非常に高いです。
最初の下にいくつかの用語を説明探索するのフォローアップを、容易にするために、
VS：仮想サーバー、スケジューラは、スケジューリングのために責任があります
RS：実サーバ、実際のサービスを提供する責任が、バックエンドサーバー
VIP：サーバー上のLVSのパブリックIP、すなわち、仮想IP
DIP：サーバー上のLVS IPネットワーク、すなわちディレクターIP
RIP：実サーバのIPネットワーク
CIP：クライアントのIP
どのように動作します：
ディスパッチRSに転送されたVS要求パケットの宛先IPと宛先ポートとプロトコルには、RSは、スケジューリングアルゴリズムに従って選択します。
LVS動作モード：
NAT：
SNAT：送信元アドレスを変更します
DNAT：送信先アドレスを変更します
DR：宛先MACを変更
TUN：元の要求IPパケットに加えて、新たなIPヘッダに加え、
FULLNAT：変更要求パケットを送信元と送信先IPに基づきます
LVS作業位置
LVS-NATモード：
LVS-NAT IPパケット変換プロセス
図に示すように：
1.要求はVIP LVSの送信先IP、CIP送信元IPへのクライアントの要求、この場合LVSクライアントホストに送信されます
2. LVSは、クライアントの要求を受信すると、要求はLVSで使用される特定のアルゴリズムに応じて、IPパケットは、特にバックエンドRIPのRealServerは、RIPのRealServerに変更され、標的とします
応答のRealServer対応する要求パケットを受信した場合3、パケットは、目的地IP RIPは、それが受信されて処理されることがわかります。ターゲットIP CIPと比較RIPと比較して、ソースIPに基づいて応答パケット、
LVSは、対応する応答パケットを受信した場合4.応答パケットLVSは、このように応答パケットがクライアントに送信された送信元IP VIP、そのまま送信先IP CIPを、変更します。
5.クライアントは、クライアントに対する応答パケット、VIPの送信元IP、ポート80、及びLVSを受信すると、変換プロセスが透明です。
利点は：物理サーバのクラスタは任意のサポートTCP / IPのオペレーティングシステムを使用することができ、物理サーバにのみロードバランサは、有効なIPアドレスを必要とする、予約済みのプライベートインターネットアドレスを割り当てることができます。
短所：リミテッドスケーラビリティ。サーバ・ノード（通常のPCサーバ）が20以上の数を増やした場合、すべての要求パケットと応答パケットは、ロードバランサの再生を通過する必要があるため、ロードバランサは、システム全体のボトルネックになります。
LVS-NATの推奨事項：
（1）RIPおよびDIP同一のIPネットワーク上の提言を、プライベートネットワークアドレスを使用する必要があり、RSは、DIP（他の中間装置）を指すようにゲートウェイ
（2）要求メッセージと応答メッセージがLVSを介して転送されなければならない、LVSは容易システムのボトルネックになります。しかし、また、一般的なニーズを満たすために
（3）サポートポートマッピングは、ターゲットPORT要求パケットを変更することができます
VSは、Linuxシステムでなければなりません（4）、RSは、任意のOSシステムであってもよいです
LVS-DRモード：
LVSのデフォルトモード。直接経路は、最も広く使用されている、再カプセル化された要求パケットのMACヘッダを介して転送されます。
RSは、（RSは、ループバックの実装によって結合VIP）同じクラスタVIP DRモードにLVSおよび結合を必要とします
请求报文由 LVS 接受，响应报文不经过 LVS，由RealServer(RS）直接返回给用户。因此，DR 模式具有较好的性能，也是目前大型网站使用最广泛的一种负载均衡手段。
源MAC是DIP所在的接口的MAC，
目标MAC是调度算法选出的RS的RIP所在接口的MAC地址；
源IP/端口，以及目标IP/端口均保持不变
LVS和各RS都配置有VIP
LVS-DR报文中IP和MAC转换过程
上图所示：
1.客户端的请求会发往LVS主机，此时，客户端请求报文的源IP为CIP，目标IP为LVS的VIP
2.当LVS收到客户端的请求报文时，会将请求报文中的源MAC修改为本机的DIP所在网卡的MAC,把目标MAC修改为后端某个RealServer的RIP的MAC，具体为哪个RealServer的RIP，取决于LVS使用的具体算法。其他不作修改。
3.当RealServer收到对应的请求报文时，因为RealServer会在本机的LO上绑定了VIP的地址，并且会因为在内核中修改了ARP相关参数从而在同一网络中同时拥有了与LVS同样的IP地址，因此在接收到请求报文时会发现报文的目标IP就是自己的VIP，于是就会接收报文并处理后不经过LVS进行响应。响应报文的源IP则为VIP，目标IP则为CIP，源MAC地址则为RS发送数据包的MAC，目标MAC则为最近的路由MAC。
4.客户端则会收到响应报文，源IP为VIP，端口为80。而LVS相对于客户端而言，转换过程是透明的。
优点：负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与LVS-TUN相比，LVS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。
缺点：要求负载均衡器的网卡必须与物理网卡在一个物理段上。
因为VIP在同一网络中同时存在，必须改变RealServer 对APR报文响应规则
方法1：在RS上使用arptables工具
# arptables -A IN -d $VIP -j DROP
# arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP
方法2：在RS上修改内核参数以限制arp通告及应答级别 (推荐)
arp_announce = 2
arp_ignore = 1
LVS-DR的建议：
(1) RealServer的RIP建议使用私网地址。RIP与DIP在同一IP网络；RIP的网关不能指向DIP，以确保响应报文 不会经过VS
(2) LVS和RS要在同一个物理网络。不能跨地域物理网络调度。
(3) 请求报文要经由VS，但响应报文不经由VS，而由RealServer直接发往Client
(4) 不支持端口映射（端口不能修改）
(5) RealServer可使用大多数OS系统
(6) VS可以只要一块网卡，同时配置VIP和DIP，注意路由走向。
LVS-TUN模式：
转发方式工作，不修改请求报文的IP首部，而在原IP报文之外再封装一个IP首部（源IP是DIP，目标IP是RIP），将报文发往挑选出的目标RealServer；RealServer直接响应给客户端（源IP是VIP，目标IP是CIP）
LVS-TUN报文中IP包头转换过程
上图所示：
1.客户端的请求会发往LVS主机，此时，客户端请求报文的源IP为CIP，目标IP为LVS的VIP
2.当LVS收到客户端的请求报文时，会在原请求报文基础上再封装一个新的IP包头，源IP为本机的DIP，目标IP为后端某个RealServer的RIP，具体为哪个RealServer的RIP，取决于LVS使用的具体算法。其他不作修改。
3.当RealServer收到对应的请求报文时，在接收到请求报文时会发现报文的目标IP就是自己的RIP，于是就会接收报文并处理后不经过LVS进行响应。响应报文的源IP则为VIP，目标IP则为CIP。
4.客户端则会收到响应报文，源IP为VIP，端口为80。而LVS相对于客户端而言，转换过程是透明的。
优点：负载均衡器只负责将请求包分发给物理服务器，而物理服务器将应答包直接发给用户。所以，负载均衡器能处理很巨大的请求量，这种方式，一台负载均衡能为超过100台的物理服务器服务，负载均衡器不再是系统的瓶颈。
缺点：这种方式需要所有的服务器支持"IP Tunneling"(IP Encapsulation)协议。
LVS-TUN的建议：
(1) DIP, VIP, RIP都应该是公网地址(或具备跨网络通讯支持)
(2) RS的网关不能指向DIP
(3) 请求报文要经由VS，但响应不能经由VS
(4) 不支持端口映射
(5) RealServer的OS须支持隧道功能。相对DR模式来讲，具备跨地域物理网络调度。
LVS-FULLNAT模式：
转发工作。通过同时修改请求报文的源IP地址和目标IP地址进行转发。
LVS-FULLNAT报文中IP包头转换过程
上图所示：
1.客户端的请求会发往LVS主机，此时，客户端请求报文的源IP为CIP，目标IP为LVS的VIP
2.当LVS收到客户端的请求报文时，会将源IP修改为本机的DIP，同时将请求报文中的目标IP修改为后端某个RealServer的RIP，具体为哪个RealServer的RIP，取决于LVS使用的具体算法
3.当RealServer收到对应的请求报文时，会发现报文的目标IP就是自己的RIP，于是就会接收报文并 处理后进行响应。响应报文的源IP则为RIP，目标IP则为DIP
4.当LVS收到对应的响应报文时，LVS会将响应报文的源IP修改为VIP，目标IP修改为CIP，于是响应报文被发往客户端。
5.客户端则会收到响应报文，源IP为VIP，端口为80，而LVS相对于客户端而言，转换过程是透明的。
LVS-FULLNAT的建议：
(1) VIP是公网地址，RIP和DIP是私网地址，且通常不在同一IP网络；因此，RIP的网关一般不会 指向DIP
(2) RS收到的请求报文源地址是DIP，因此，只需响应给DIP；但VS还要将其发往Client
(3) 请求和响应报文都经由VS，LVS易于成为系统瓶颈。但是也能满足一般需求
(4) 支持端口映射
注意：此类型kernel默认不支持