XNUMX 台のサーバーの能力ではすべてのリクエストを処理するのに十分ではなく、ソフトウェア メーカーが負荷分散を提供していない場合はどうすればよいでしょうか? ロード バランサーの購入からリクエスト数の制限まで、多くのオプションがあります。 どちらが正しいかは、既存の状況を考慮して状況に応じて決定する必要があります。 この記事では、予算が限られており、無料のサーバーがある場合に何ができるかを説明します。
サーバーの負荷を軽減する必要があるシステムとして、InfoWatch社のDLP（情報漏洩防止システム）を採用しました。 実装の特徴は、「戦闘」サーバーの XNUMX つにバランサー機能を配置することでした。
私たちが遭遇した問題の XNUMX つは、Source NAT (SNAT) を使用できないことでした。 なぜこれが必要なのか、そして問題はどのように解決されたのかについては、さらに詳しく説明します。
したがって、当初、既存のシステムの論理図は次のようになっていました。
ICAP トラフィック、SMTP、ユーザー コンピュータからのイベントは、Traffic Monitor (TM) サーバーで処理されました。 同時に、データベース サーバーは TM 上でイベントを処理した後の負荷に簡単に対処できましたが、TM 自体の負荷は高かったです。 これは、デバイス モニター (DM) サーバー上のメッセージ キューの出現、および TM 上の CPU とメモリの負荷から明らかでした。
一見すると、この方式に別の TM サーバーを追加すると、ICAP または DM のいずれかに切り替えることができますが、フォールト トレランスが低下するため、この方法は使用しないことにしました。
解決策の説明
適切なソリューションを模索する過程で、無料で配布されるソフトウェアに落ち着きました。 とともに 。 なぜなら、keepalived はフェールオーバー クラスターの作成の問題を解決し、LVS バランサーも管理できるからです。
私たちが達成したいこと (TM の負荷を軽減し、フォールト トレランスの現在のレベルを維持すること) は、次のスキームに従って機能するはずです。
機能を確認したところ、サーバーにインストールされているカスタム RedHat アセンブリが SNAT をサポートしていないことが判明しました。 私たちの場合、SNAT を使用して、受信パケットとその応答が同じ IP アドレスから送信されるようにする予定でした。そうでないと、次のような結果になります。
これは受け入れがたい。 たとえば、仮想 IP (VIP) アドレスにパケットを送信したプロキシ サーバーは、VIP からの応答を期待しますが、この場合、バックアップに送信されたセッションの応答は IP2 から返されます。 解決策が見つかりました。次に示すように、バックアップ上に別のルーティング テーブルを作成し、XNUMX つの TM サーバーを別のネットワークに接続する必要がありました。
設定
ICAP、SMTP、TCP 9100 サービスを備えた XNUMX 台のサーバーと、それらの XNUMX 台にロード バランサーがインストールされるスキームを実装します。
6 台の RHELXNUMX サーバーがあり、そこから標準リポジトリといくつかのパッケージが削除されました。
バランスを取る必要があるサービス:
• ICAP – tcp 1344。
• SMTP – tcp 25。
DM – TCP 9100 からのトラフィック送信サービス。
まず、ネットワークを計画する必要があります。
仮想 IP アドレス (VIP):
• IP: 10.20.20.105。
サーバー TM6_1:
• 外部 IP: 10.20.20.101。
• 内部 IP: 192.168.1.101。
サーバー TM6_2:
• 外部 IP: 10.20.20.102。
• 内部 IP: 192.168.1.102。
次に、XNUMX つの TM サーバーで IP 転送を有効にします。 これを行う方法は RedHat で説明されています .
どのサーバーをメインサーバーにし、どのサーバーをバックアップサーバーにするかを決定します。 マスターを TM6_1、バックアップを TM6_2 とします。
バックアップ時に、新しいバランサー ルーティング テーブルとルーティング ルールを作成します。
[root@tm6_2 ~]echo 101 balancer >> /etc/iproute2/rt_tables
[root@tm6_2 ~]ip rule add from 192.168.1.102 table balancer
[root@tm6_2 ~]ip route add default via 192.168.1.101 table balancer上記のコマンドは、システムが再起動されるまで機能します。 再起動後にルートが確実に保持されるようにするには、ルートを次のように入力します。 /etc/rc.d/rc.local、ただし設定ファイルを使用する方が良い /etc/sysconfig/network-scripts/route-eth1 (注: ここでは異なる構文が使用されています)。
両方の TM サーバーに keepalived をインストールします。 配布元として rpmfind.net を使用しました。
[root@tm6_1 ~]#yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/keepalived-1.2.13-5.el6_6.x86_64.rpmkeepalived 設定では、サーバーの XNUMX つをマスターとして割り当て、もう XNUMX つをバックアップとして割り当てます。 次に、負荷分散のための VIP とサービスを設定します。 設定ファイルは通常、次の場所にあります。 /etc/keepalived/keepalived.conf.
TM1サーバーの設定
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state MASTER
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 151
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}
virtual_server 10.20.20.105 1344 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 25 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 9100 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
}TM2サーバーの設定
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}LVS をマスターにインストールし、トラフィックのバランスをとります。 この構成ではサーバーが XNUMX 台しかないため、XNUMX 台目のサーバーにバランサーをインストールするのは意味がありません。
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmバランサーは、すでに構成済みの keepalived によって管理されます。
全体像を完成させるために、両方のサーバーで自動起動する keepalived を追加しましょう。
[root@tm6_1 ~]#chkconfig keepalived onまとめ
結果の確認
両方のサーバーで keepalived を実行してみましょう。
service keepalived startVRRP仮想アドレスの利用可能性を確認する
VIP がマスター上にあることを確認してみましょう。
また、バックアップには VIP はありません。
ping コマンドを使用して、VIP が利用できるかどうかを確認します。
これで、マスターをシャットダウンしてコマンドを再度実行できます ping.
結果は同じままであり、バックアップでは VIP が表示されます。
サービスバランスの確認
SMTP を例に考えてみましょう。 10.20.20.105 への XNUMX つの接続を同時に開始してみましょう。
telnet 10.20.20.105 25マスターでは、両方の接続がアクティブであり、異なるサーバーに接続されていることがわかります。
[root@tm6_1 ~]#watch ipvsadm –Ln
そこで、TM サーバーの XNUMX つにバランサーをインストールすることで、TM サービスのフォールト トレラントな構成を実装しました。 私たちのシステムでは、これにより TM の負荷が半分に減り、水平スケーリングができないという問題をシステムを使用して解決することができました。
ほとんどの場合、このソリューションは追加コストなしですぐに実装できますが、UDP トラフィックのバランスをとる場合など、セットアップに多くの制限や困難が生じる場合があります。
出所： habr.com