A. LVSの概要
LVSは、1998年に博士張温-曲によって作成された4つの協定上のワークロード・バランシングソリューションです。ロードバランシングは、現在広く使われているモデルであり、以下のとおりです。
1）は、4つのプロトコル（LVS）で動作：主7良好で作業協定に比べ、レイヤ4プロトコル、性能上のロードバランシングのために使用されます。しかし、プロトコルスタックは、支持体のトランスポート層の不足のより高度な機能のために、トランスポート層で働いています。
2）は、7つの協定（nginxの、HAproxy）で動作します。主にHTTPサービスのより適切なロードバランシング（nginxのもコンパイル時に--with-ストリームのパラメータを追加する必要があり、4で7件の契約上で動作することができます）を、解決するためにサービス、メールサービス、および他の高レベルのプロトコル。、パフォーマンスの少量を犠牲にして4ロードバランシングの合意、と比較するとよりターゲットを絞ったサービスを提供しています。
二つ。LVS動作モード
2.1二段作品：
LVSの動作とiptablesに似た働き、彼らはカーネル空間でのフレームワーク（Netfilterの、IPVS）+管理ツールのユーザー・スペース（iptablesの、ipvsadmの）を持っています。ユーザ空間の管理ツールは、当社の運用ルールへのアクセスを提供し、我々はそれが対応する機能を実現するために動作させるために、カーネルスペースフレームに関連するルールを設定します。
関与LVSモデルは、主に2つのカテゴリに分けることができる：一つは、（クライアントからの要求を受信し、そして実際のIPVSルールとアルゴリズムによって提供されるバックエンドサービスにデバイスを転送するための）監督スケジューラである他は、RealServerの（すなわち、ありますバックエンド本物のサービスを提供するための装置）。LVSは、Netfilterのに入力チェーンを聞いてIPVSカーネル空間にある、ディレクタースケジューラに設置して、どこルールのセット、それが見つかった場合、そのクラスタサービスへのアクセス、強制変更要求ここにメッセージ（識別NATモード、DRモード、モードTUN）、及び直ちにPREROUTINGチェーンに送られます。アクセス要求は、クラスタサービス、または天然に通常のアクセスに応じて、ネットワーク層プロトコルによって決定されていない場合は[IP +ポートに応じて決定]。
2.2注：
LVSモデルは、カーネルNetfilterのフレームワークに依存し、クラスタサービス要求メッセージへのアクセスに対処するため1は、強制的に機能障害のiptablesにつながる可能性の変化を、作られました。LVSため、iptablesのは、一緒に使用することはできません。
カーネルの2,2.4.23以前のバージョンはIPVSコードを内蔵していません、あなたはパッチを適用する必要があります。このバージョンの後、あなたは直接LVSの機能を使用することができます。
三。LVS共通ワーキングモデル
3.1.NATモデル
どのように動作します：
クラスタサービスの場合には、監視たClientIPアクセス、ディレクタースケジューラPOSTROUTINGチェーンDNAT（宛先アドレス変換）を変換するために、スケジューリングアルゴリズムに従ってRealServerIPデータパケットをバックエンドを選択します。後端RealServerの処理要求が完了すると、クライアントを介して再び応答メッセージは、チェーンPREROUTING DirectorでSNATためのディレクター、（ソースアドレス変換）を返信。
長所と短所：
設定は簡単です。欠点は、取締役のうち、データを通過することになっている、すべてのパフォーマンスが悪く、通常は10 RIPを駆動します。
NATモデル注：
1）クラスタ・ノードとディレクターは、同じネットワーク内になければなりません。
2）RIPアドレスだけDIPとの通信のために、一般的にプライベートアドレスです。
すべての着信と発信の通信を担当するクライアントとRealServerの間に位置する3）ディレクター、。
4）デフォルトゲートウェイとしてDIPクラスタ・ノードを使用します。
5）取締役は、ポートマッピングをサポートしています。
6）任意のオペレーティングシステムは、RealServerのように使用することができます。
7）取締役は、簡単にボトルネッククラスタのパフォーマンスになります。
3.2.DRモデル
どのように動作します：
[監督]クライアントの要求を受信した後ディレクタースケジューリング段階は、（クライアントアクセスがVIPのディレクターである）、要求はクラスタサービスへのアクセスであることが判明し、それは要求パケットの宛先MACアドレスを変更し、チェーンにパケットを転送POSTROUTINGによっては、 RealServerは。
各処理ステージは] [RealServerのRealServerはだけではなく、監督との通信のためのIPエイリアス上に配置されたVIP、カプセル化された応答パケットを有します。RealServerの要求パケットを受信すると、データリンクプロトコル自身のMACアドレスが発見され、そのパケットを受信して処理、VIP自体はエイリアス上に配置された見つけるデカプセル化します。
[ステージ]のRealServer RealServerの応答がこの要求パケットを受信し、送信元IPアドレスと宛先IPアドレスが変更されません。このようにする場合、返信パケット、RealServerのザ・IPネットワーク層の応答を直接クライアントには、ディレクターを必要としません。
長所と短所：
利点は、ディレクタースケジューラがのみ要求メッセージを処理する必要がある、応答パケットを処理しないで、効率が大幅に改善され、RealServerの数百人をもたらすことができます。欠点は、NATの設定相対が複合体をモデル化することです。
DRモデル注：
ディレクターとMACアドレスに従って転送されるので、1）各クラスタ・ノードは、同じ物理ネットワーク上になければなりません。
2）RIPは、プライベートネットワークアドレスを持つことができません。
3）取締役は、着信要求のみを扱うのRealServerによって直接クライアントに応答パケットを返信します。
4）RealServerはインターネットルーティング機器にアクセスするためにポイントすることができるように、デフォルトゲートウェイポインティング監督であってはなりません。
5）取締役のポートマッピングを実現することができない、のみ変更されていないMACアドレス、TCP / IPを変更します。
6）ほとんどのオペレーティングシステムは、RealServerの上で使用することができ、サーバーがhide IPをサポートしている必要があります。
開発：ARPに応答するRealServerの道を禁止
VIPルーティングデバイスで書かれた1）固定MACアドレス。
2）チェーンルール定義ルールarptables、ARP応答しません。
3）カーネルパラメータ：二つのパラメータがARPレベルとレベルの発表を放送するために宿主応答を定義するため、arp_announceをarp_ignoreがあります。ユーザと着信ネットワークインタフェースによって要求VIPは、このメッセージを無視ARP、同じではありません。
arp_announce：
0：任意のインタフェース通信外側にマシンの任意のアドレスは、1：そのネットワーク通信インターフェースとしてターゲットネットワークに一致します。2：のみローカルネットワークインタフェースにマッチング広告。デフォルト0。
arp_ignore：
0：マシンは、アドレスのいずれかの表現に対応するために装備されています。1：のみ応答IPアドレスを示すとインタフェースが同じIPネットワークで構成されています。デフォルト0。
3.3.TUNモデル
どのように動作します：
サービスへのディレクタークライアント発見要求パケットとアクセスを受信すると、クラスタで、元のIPパケットの外側スケジューラリクエスト、再びIPパケットをカプセル化し、再び外部ネットワーク（元のIPパケットに送信します層は、RealServerのは、最終的に、異なるネットワークドメインに転送）カプセル化されたIPパケットトンネリングです。
長所と短所：
利点は、オフサイトの災害復旧のニーズに対応する機能です。欠点はディレクターであるとRealServerデバイスは、トンネリングをサポートし、複雑な設定します。
TUNモデル注：
インターネットを介して1）のRealServer。
2）のRealServerザ・RIPは、パブリックアドレスでなければなりません。
3）取締役は、着信要求のみをクライアントに送信され、そこにRealServerの応答パケットを処理します。
4）のみOSのトンネリングプロトコルはRealServerのために使用することができるサポート。
5）ポートマッピングをサポートしていません。
四。LVSの構成の詳細（Centos7）
4.1.NATモデル構成
ネットワーク計画
NATモード
VIP：
192.168.100.150外
DIP：インナー172.16.100.10
RIP1：
172.16.100.11インナー
RIP2：
172.16.100.12インナー
RealServerの設定
1 位のインストールとnginxの設定 2 のyumを インストール nginxの-Y
ディレクターのコンフィギュレーション
1 ＃安装ipvsadmの工具 2 YUM インストール ipvsadmの- Y 3 ＃关闭ICMP重定向 4 エコー 1 >の/ proc / sysの/純/のIPv4 / ip_forward 5 エコー 0 >の/ proc / sysの/純/のIPv4 / CONF /全/ send_redirects 6 エコー 0 >の/ proc / sysの/純/のIPv4 / CONF /デフォルト/ send_redirects 7 エコー 0 >の/ proc / sysの/純/のIPv4 / confに/のeth0 / send_redirects 8 エコー 0 >の/ proc / sysの/純/のIPv4 / CONF / eth1の/ send_redirects 9 ＃ディレクター设置ipvsadmの 10 ipvsadmの-A -t192.168。100.150：80 - S RR 11 ipvsadmの-a -t 192.168。100.150：80 -r 172.16。100.11：80 - M 12 ipvsadmの-a -t 192.168。100.150：80 -r 172.16。100.12：80 -m
4.2.DRモードの設定
ネットワーク計画
監督：
VIPは：192168100150
ディップ：192168100155
RIP1：
LO：0 192 168 100 150（VIP）
リッピング192168100151は、
RIP2
彼に：0 192 168 100 150（VIP）
リッピング192168100152
RealServerの設定
＃は、ARPパケットに応答無効にするには、カーネルパラメータを設定し 、エコーを " 1 " >は、/ proc / sys / net / IPv4の/ confに/ LO / arp_ignore エコー " 2 " >は、/ proc / sys / net / IPv4の/ confに/ LO / arp_announce エコー " 。1 " >は、/ proc / sys / net / IPv4の/ confに/すべて/ arp_ignore エコー " 2 " >は、/ proc / sys / net / IPv4の/ confに/すべて/ arp_announceの ＃configureコン別名VIP ifconfigコマンド LO：0 192.168。100.150放送192.168。100.150ネットマスク255.255。255.255 アップ ＃によるNATモードを使用して実験環境に、ディレクターの前にゲートウェイへのデフォルトルートを追加し、それはそれはもはや設定されているデフォルトゲートウェイに良い仕事のポイントを持っています
ディレクターのコンフィギュレーション
＃nginxのをインストールして設定 yumを インストール nginxの- Y- 転送は＃configureコンポートを エコー 1 >は、/ proc / sys / net / IPv4の/ ip_forward ＃の設定VIP用 のifconfig ens33：0 192.168。100.150放送192.168。100.150ネットマスク255.255。255.255 アップ ＃に追加RealServerのルーティング ルートを追加します。 -host 192.168。100.150：DEVのens33 0 ＃はIPVSを設定 ipvsadmの -Aは-t 192.168。100.155：80 - S RRを ipvsadmの -a -t 192.168。100.155：80 -r 192.168。100.151：80 - グラム ipvsadmの -a -t 192.168。100.155：80 -r 192.168。100.152：80 -g