LVSを使用した負荷分散
そのため、ロードされたサーバーがあり、突然それをアンロードしたかったのです。 同じ（同じ）を設定して入力しましたが、ユーザーは常に最初に移動します。 この場合、もちろん、負荷のバランスを考慮する必要があります。
最初に提案するのは、ラウンドロビンDNSの使用です。 誰も知らない場合、これは、各DNS要求に新しいIPを与えるだけで、n番目のサーバー間で要求を分散できる方法です。
短所は何ですか：
入力と出力の間に「コンピューターが多すぎる」ことを追加する価値はありませんが、状況を制御するいくつかの方法が必要です。
そして、ここでLinux Virtual ServerまたはLVSが私たちの助けになります。 実際、これはバージョン2.0-2.2以降のどこかに存在するカーネルモジュール（ ipvs ）です。
彼はどんな人ですか？ 実際、これはL4ルーター（私はL3と言いますが、著者はL4を主張します）であり、与えられたルートでパケットを透過的かつ制御可能にルーティングできます。
主な用語は次のとおりです。
ディレクターは、このIPVSモジュール（IP仮想サーバー）を切り替え、パケット転送ルールを設定し、VIPを上げます-通常は外部インターフェイスのエイリアスとして。 ユーザーはVIPを通過します。
VIPに到着したパケットは、選択された方法でいずれかのRealserverに転送され、そこで正常に処理されています。 クライアントには、1台のマシンで作業しているようです。
パケット転送ルールは非常に簡単です。VIP：ポートのペアによって定義される仮想サービスを定義します。 サービスはTCPまたはUDPです。 ここで、ノードの回転方法（スケジューラー、スケジューラー）を設定します。 次に、ファームのサーバーのセット、RIP：ポートのペアを指定し、選択したスケジューラで必要な場合は、パケット転送方法と重みも指定します。
こんな感じです。
はい、ipvsadminパッケージを置くことを忘れないでください、それはあなたのディストリビューションのリポジトリにあるべきです。 いずれにしても、DebianとRedHatにあります。
上記の例では、仮想HTTPサービス192.168.100.100を作成し、その中にサーバー127.0.0.1、192.168.100.2、および192.168.100.3を含めます。 「-w」スイッチは、サーバーの重みを設定します。 高いほど、リクエストを受信する可能性が高くなります。 重みを0に設定すると、サーバーはすべての操作から除外されます。 サーバーを使用停止する必要がある場合に非常に便利です。
パケットはデフォルトでDR方式を使用して転送されます。 一般的に、次のルーティングオプションを使用できます。
DRは最も単純ですが、たとえば、宛先ポートを変更する必要がある場合は、iptablesにルールを描画する必要があります。 ただし、NATでは、ファーム全体のデフォルトルートをディレクタに向ける必要があります。これは、特に実サーバーにも外部アドレスがある場合は必ずしも便利ではありません。
配信セットには複数のプランナーがあります。詳細については、手順をご覧ください。 主なものだけを考えてみましょう。
さらに、サービスには永続性が必要である、つまり 指定された期間、ユーザーをいずれかのサーバーに保持します。同じIPからのすべての新しいリクエストは同じサーバーに転送されます。
したがって、上記の例では、VIP 192.168.100.100で仮想サーバーを取得する必要がありましたが、これについてipvsadmが楽しく説明しています。
ただし、接続しようとしても何も起こりません！ 問題は何ですか？ 最初のステップは、エイリアスを上げることです。
しかし、ここでも失敗が待っています-パッケージは変更されずに実サーバーのインターフェースに到着するため、マシン向けではないので愚かにカーネルを起動します。 この問題を解決する最も簡単な方法は、VIPをループバックに上げることです。
どのような場合でも、ディレクターの外部インターフェイスと同じサブネットを調べるインターフェイスでピックアップしないでください。 そうしないと、外部ルーターが間違ったマシンのMACをキャッシュして、すべてのトラフィックが間違った場所に送られる可能性があります。
これで、必要な場所でバッグが実行されます。 ところで、ディレクター自身が実サーバーになる可能性があります。これはこの例で確認できます。
この決定において、サービス全体の破壊を引き起こす失敗の明らかなポイントは、ディレクター自身になります。
まあ、それは問題ではありません。ipvsadmはデーモンモードをサポートし、複数のディレクター間のテーブルと現在の接続を同期する機能を備えています。 1つは明らかにマスターになり、残りはスレーブになります。
私たちに何が残っていますか？ 障害が発生した場合に、ディレクター間でVIPを移動します。 ここでは、ハートビートなどのHAソリューションが役立ちます。
別のタスクは、ファームからのサーバーの監視とタイムリーな廃止です。 これは、重みを使用して行うのが最も簡単です。
両方の問題を解決するために、さまざまなタイプのサービスに合わせて多くのソリューションが作成されています。 個人的には、LVSのまさに著者であるUltramonkeyのソリューションが一番好きでした。
RedHatにはPiranhaと呼ばれるネイティブなものがあり、ファームとディレクターを監視するための独自のデーモンセットと、いくつかの不器用なWebインターフェースさえありますが、HAバンドルで3つ以上のディレクターをサポートしていません。 理由はわかりません。
そのため、Ultramonkeyは、ハートビートとldirectordの2つのメインパッケージで構成されています。 1つ目はVIPの昇格と移動を含むディレクターにHAを提供し（一般的にはディレクターだけでなく使用できます）、2つ目はipvsadm構成をサポートし、ファームの状態を監視します。
ハートビートの場合、3つの構成を描画する必要があります。 基本バージョンには詳細なコメントが付いているため、例を挙げてください。
authkeys
さまざまなマシンでデーモン許可を構成します。
ハリソース
ここには、HAを作成するリソースと移動時に取得するサービスに関する情報があります。
つまり インターフェイスでeth0 192.168.100.100/24を上げて、ldirectordを起動します。
ha.cf
HAクラスターをサポートする方法と、実際に誰がクラスターに入るのかを説明します。
Ldirectordにはconfigが1つしかないため、一般的にはすべてが明確になっています。
つまり ldirectordは2秒ごとにhttpを介してalive.htmlファイルをプルし、「I'm alive！」行が含まれていないか、さらに悪いことにサーバーが応答しない場合、デーモンはすぐに0に設定し、以降の転送から除外されます。
重みは自分で設定することもできます。たとえば、フィールド上でクラウンを動かし、現在のloadavgなどに応じて計算します。 -誰もあなたからipvsadmへの直接アクセスを奪いません。
LVSの範囲であるインターネット上のあらゆる場所は、主にWebサーバーのバランスを取ると考えられていますが、実際には、非常に多くのサービスのバランスを取ることができます。 プロトコルが1つのポートに置かれ、状態がない場合、問題なく平衡化できます。 状況は、sambaやftpなどのマルチポートプロトコルではより複雑ですが、解決策もあります。
ところで、Linuxは実サーバーである必要はありません。 TCP / IPスタックを備えたほとんどすべてのOSを使用できます。
また、ポートではなく、高レベルのプロトコルの知識で動作する、いわゆるL7ルーターもあります。 日本人の仲間はこの機会にUltramonkey-L7を開発しています。 ただし、今は触れません。
どのバランシングソリューションを使用していますか？
どんなコメントやコメントでも喜んでいます。
DNS-RR
最初に提案するのは、ラウンドロビンDNSの使用です。 誰も知らない場合、これは、各DNS要求に新しいIPを与えるだけで、n番目のサーバー間で要求を分散できる方法です。
短所は何ですか：
- 管理が困難です。IPアドレスのグループを記録したので、それだけで、体重管理、サーバーステータスは監視されていません。
- 実際、IP範囲にリクエストを分散しますが、サーバーの負荷を分散しません。
- クライアントDNSキャッシュはすべてのラズベリーを破ることができます
入力と出力の間に「コンピューターが多すぎる」ことを追加する価値はありませんが、状況を制御するいくつかの方法が必要です。
LVS
そして、ここでLinux Virtual ServerまたはLVSが私たちの助けになります。 実際、これはバージョン2.0-2.2以降のどこかに存在するカーネルモジュール（ ipvs ）です。
彼はどんな人ですか？ 実際、これはL4ルーター（私はL3と言いますが、著者はL4を主張します）であり、与えられたルートでパケットを透過的かつ制御可能にルーティングできます。
主な用語は次のとおりです。
- ディレクター -ルーティングを提供する実際のノード。
- Realserverは、サーバーファームの主力製品です。
- VIPまたは仮想IPは、仮想（多数の実サーバーから収集された）サーバーの単なるIPです。
- したがって、 DIPとRIPはIPディレクターおよび実サーバーです。
ディレクターは、このIPVSモジュール（IP仮想サーバー）を切り替え、パケット転送ルールを設定し、VIPを上げます-通常は外部インターフェイスのエイリアスとして。 ユーザーはVIPを通過します。
VIPに到着したパケットは、選択された方法でいずれかのRealserverに転送され、そこで正常に処理されています。 クライアントには、1台のマシンで作業しているようです。
ルール
パケット転送ルールは非常に簡単です。VIP：ポートのペアによって定義される仮想サービスを定義します。 サービスはTCPまたはUDPです。 ここで、ノードの回転方法（スケジューラー、スケジューラー）を設定します。 次に、ファームのサーバーのセット、RIP：ポートのペアを指定し、選択したスケジューラで必要な場合は、パケット転送方法と重みも指定します。
こんな感じです。
# ipvsadm -A -t 192.168.100.100:80 -s wlc
# ipvsadm -a -t 192.168.100.100:80 -r 192.168.100.2:80 -w 3
# ipvsadm -a -t 192.168.100.100:80 -r 192.168.100.3:80 -w 2
# ipvsadm -a -t 192.168.100.100:80 -r 127.0.0.1:80 -w 1
はい、ipvsadminパッケージを置くことを忘れないでください、それはあなたのディストリビューションのリポジトリにあるべきです。 いずれにしても、DebianとRedHatにあります。
上記の例では、仮想HTTPサービス192.168.100.100を作成し、その中にサーバー127.0.0.1、192.168.100.2、および192.168.100.3を含めます。 「-w」スイッチは、サーバーの重みを設定します。 高いほど、リクエストを受信する可能性が高くなります。 重みを0に設定すると、サーバーはすべての操作から除外されます。 サーバーを使用停止する必要がある場合に非常に便利です。
パケットはデフォルトでDR方式を使用して転送されます。 一般的に、次のルーティングオプションを使用できます。
- 直接ルーティング （ゲートウェイ）-パケットは変更されずにファームに直接送信されます。
- NAT （マスカレード）は、単なるトリッキーなNATメカニズムです。
- IPIPカプセル化 （トンネリング）-トンネリング。
DRは最も単純ですが、たとえば、宛先ポートを変更する必要がある場合は、iptablesにルールを描画する必要があります。 ただし、NATでは、ファーム全体のデフォルトルートをディレクタに向ける必要があります。これは、特に実サーバーにも外部アドレスがある場合は必ずしも便利ではありません。
配信セットには複数のプランナーがあります。詳細については、手順をご覧ください。 主なものだけを考えてみましょう。
- ラウンドロビン-みんなの相互責任。
- 重み付きラウンドロビンも同じですが、サーバーの重みを使用します。
- 最小接続-接続数が最も少ないサーバーにパケットを送信します。
- 重み付き最小接続-同じですが、重みを考慮します。
さらに、サービスには永続性が必要である、つまり 指定された期間、ユーザーをいずれかのサーバーに保持します。同じIPからのすべての新しいリクエストは同じサーバーに転送されます。
落とし穴
したがって、上記の例では、VIP 192.168.100.100で仮想サーバーを取得する必要がありましたが、これについてipvsadmが楽しく説明しています。
ipvsadm -L -n
IP Virtual Server version 1.0.7 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.100.100:80 wlc
-> 192.168.100.2:80 Route 3 0 0
-> 192.168.100.3:80 Route 2 0 0
-> 127.0.0.1:80 Local 1 0 0
ただし、接続しようとしても何も起こりません！ 問題は何ですか？ 最初のステップは、エイリアスを上げることです。
# ifconfig eth0:0 inet 192.168.100.100 netmask 255.255.255.255
しかし、ここでも失敗が待っています-パッケージは変更されずに実サーバーのインターフェースに到着するため、マシン向けではないので愚かにカーネルを起動します。 この問題を解決する最も簡単な方法は、VIPをループバックに上げることです。
# ifconfig lo:0 inet 192.168.100.100 netmask 255.255.255.255
どのような場合でも、ディレクターの外部インターフェイスと同じサブネットを調べるインターフェイスでピックアップしないでください。 そうしないと、外部ルーターが間違ったマシンのMACをキャッシュして、すべてのトラフィックが間違った場所に送られる可能性があります。
これで、必要な場所でバッグが実行されます。 ところで、ディレクター自身が実サーバーになる可能性があります。これはこの例で確認できます。
単一障害点
この決定において、サービス全体の破壊を引き起こす失敗の明らかなポイントは、ディレクター自身になります。
まあ、それは問題ではありません。ipvsadmはデーモンモードをサポートし、複数のディレクター間のテーブルと現在の接続を同期する機能を備えています。 1つは明らかにマスターになり、残りはスレーブになります。
私たちに何が残っていますか？ 障害が発生した場合に、ディレクター間でVIPを移動します。 ここでは、ハートビートなどのHAソリューションが役立ちます。
別のタスクは、ファームからのサーバーの監視とタイムリーな廃止です。 これは、重みを使用して行うのが最も簡単です。
両方の問題を解決するために、さまざまなタイプのサービスに合わせて多くのソリューションが作成されています。 個人的には、LVSのまさに著者であるUltramonkeyのソリューションが一番好きでした。
RedHatにはPiranhaと呼ばれるネイティブなものがあり、ファームとディレクターを監視するための独自のデーモンセットと、いくつかの不器用なWebインターフェースさえありますが、HAバンドルで3つ以上のディレクターをサポートしていません。 理由はわかりません。
ウルトラモンキー
そのため、Ultramonkeyは、ハートビートとldirectordの2つのメインパッケージで構成されています。 1つ目はVIPの昇格と移動を含むディレクターにHAを提供し（一般的にはディレクターだけでなく使用できます）、2つ目はipvsadm構成をサポートし、ファームの状態を監視します。
ハートビートの場合、3つの構成を描画する必要があります。 基本バージョンには詳細なコメントが付いているため、例を挙げてください。
authkeys
auth 2
#1 crc
2 sha1 mysecretpass
#3 md5 Hello!
さまざまなマシンでデーモン許可を構成します。
ハリソース
ここには、HAを作成するリソースと移動時に取得するサービスに関する情報があります。
director1.foo.com IPaddr::192.168.100.100/24/eth0 ldirectord
つまり インターフェイスでeth0 192.168.100.100/24を上げて、ldirectordを起動します。
ha.cf
keepalive 1
deadtime 20
udpport 694
udp eth0
node director1.foo.com # <-- uname -n !
node director2.foo.com #
HAクラスターをサポートする方法と、実際に誰がクラスターに入るのかを説明します。
Ldirectordにはconfigが1つしかないため、一般的にはすべてが明確になっています。
checktimeout=10
checkinterval=2
autoreload=yes
logfile="/var/log/ldirectord.log"
# Virtual Service for HTTP
virtual=192.168.100.100:80
real=192.168.100.2:80 gate
real=192.168.100.3:80 gate
service=http
request="alive.html"
receive="I'm alive!"
scheduler=wlc
protocol=tcp
checktype=negotiate
つまり ldirectordは2秒ごとにhttpを介してalive.htmlファイルをプルし、「I'm alive！」行が含まれていないか、さらに悪いことにサーバーが応答しない場合、デーモンはすぐに0に設定し、以降の転送から除外されます。
重みは自分で設定することもできます。たとえば、フィールド上でクラウンを動かし、現在のloadavgなどに応じて計算します。 -誰もあなたからipvsadmへの直接アクセスを奪いません。
適用性
LVSの範囲であるインターネット上のあらゆる場所は、主にWebサーバーのバランスを取ると考えられていますが、実際には、非常に多くのサービスのバランスを取ることができます。 プロトコルが1つのポートに置かれ、状態がない場合、問題なく平衡化できます。 状況は、sambaやftpなどのマルチポートプロトコルではより複雑ですが、解決策もあります。
ところで、Linuxは実サーバーである必要はありません。 TCP / IPスタックを備えたほとんどすべてのOSを使用できます。
また、ポートではなく、高レベルのプロトコルの知識で動作する、いわゆるL7ルーターもあります。 日本人の仲間はこの機会にUltramonkey-L7を開発しています。 ただし、今は触れません。
他に読むものは何ですか？
- LVS-HOWTO-読むために厳密に必要
- LVS-mini-HOWTO-簡単に
- レッドハットピラニア
- ウルトラモンキー
どのバランシングソリューションを使用していますか？
どんなコメントやコメントでも喜んでいます。
All Articles