ポーリングスケジューラ--DR LVSクラスタモードのエンタープライズ・ロード・バランシング（重み付け）、健康はDRモードで（ldirectord）を監視します

その他 2020-01-21 00:55:00 訪問数: null

記事のディレクトリ

LVSのダイレクトルーティングモード（DRモード）

原則1、DRモード

、上記、動作モードはDRモデルLVS設定されているホストサーバ内の構造LVS だけスケジューラをLVS、スケジューラは、バックエンド・サーバ・クライアント、DRモードに要求を転送しますクライアントに直接バックエンドサーバから返されたデータの逆パケットデータを送信する必要はありませんし、スケジューリングは唯一のLVSを集中することができ、高効率この時、DSスケジューラ（Directorサーバー）と呼ばれるLVSスケジューラ、RS本当のバックエンドWebサーバ（実サーバ）があります。

  • クライアントが要求を送信する- > DS（スケジューラ） - > PREROUTING - > INPUT - > POSTROUTING - > RS（ 実サーバ） - > LOループバック- > NICはeth0 - >クライアントは、（詳細に説明しました）
  • ループバック・インターフェースを使用して、システム内のデータ通信、カードはeth0を使用して外部との交換
  • その中の効率的なDRモード：クライアントの要求に直接応答しますRSサーバは、要求パケットを送信するためにまっすぐに送られ、逆はスケジューラにデータパケットを返しません。

2、DRモード用語集

  • 送信元MACアドレス：DSスケジューラのMACアドレス
  • 宛先MACアドレス：実サーバのMACアドレスRS

3、DRモードの特性

  • DRモードですべての要求パケットがスケジューラ（DS）によってスケジュールされた要求に応じてRSによって実行される、DSのみの着信要求を処理するの。
  • RIP及びRS、DS DIPは同じネットワークセグメント、通信に使用するMACアドレスでなければなりません。
  • RS上のVIPを設定する必要があります。パケットを介して転送DSと同様に、CIP（：クライアントIP応答パケットの送信元IP）を受信するアドレス（VIPが入口に配置された統一された、IP、クライアントの要求くるIPを発表しました）
  • DRモードでは、ポートマッピングをサポートしていません。
  • DRモードの変更は、MACアドレス、第2層（データリンク層）のMACアドレスである、まだIPは、悪意を持って誰かに接続することができるネットワーク層に、バックエンドサーバーを送信するパケットを持っている、ポーリングしません。その膝にバックエンドサーバーにつながるが、それを解消することができます。

4、DRモードでLVSスケジューラ（ラウンドロビン）

実験環境 ：

ホスト情報 ホスト機能（サービス）
実機172.25.7.250 クライアントクライアント
SERVER1（172.25.7.1） LVSスケジューラ（DS）
SERVER2（172.25.7.2） バックエンドWebサーバ1（RS）
server3の（172.25.7.3） バックエンドWebサーバ2（RS）

1、サーバー1：LVSスケジューラ
ツールのインストールサービスは、戦略ipvsadmのを書きますyumをインストールipvsadmの-y

  • 注：ソースはYUMの6.5バージョンである場合は、ビルド・ロード・バランスソースへのyum必要がこのサービスをインストールすることができます

ここに画像を挿入説明

ここに画像を挿入説明

2、ipvsadmの-Lnリストポリシー（スケジューリングポリシー参照）
ポリシーを追加し、3：

  • 注：-sは、スケジューリングアルゴリズムを示し、rrはポーリングは、-gは、DRモードでLVSスケジューラ作品を表す意味します
  • ipvsadmのは、見--help 10スケジューリングアルゴリズムの合計（コメント）
ipvsadm -A -t 172.25.7.100:80 -s rr 
		#设置客户端进入lvs调度器的入口地址，调度算法是轮询
ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.2:80 -g 
		# 设置lvs的策略：入口的第一台后端服务器的信息
ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.3:80 -g
		# 设置lvs的策略：入口的第二台后端服务器的信息

4、ipvsadmの-Lnリストには、ポリシー（スケジューリングポリシーを参照）を追加
VIPを追加するためのスケジューラに、5：IP addrは172.25.7.100/24 devのeth0のを追加
ここに画像を挿入説明
6、2つのRS：SERVER2、server3の、VIPのコンフィギュレーション、および搭載されているのhttpdサービスの
インストールのhttpd：yumをインストールhttpdの-y
ユーザー・アクセス・エントリ・アドレスを設定します： ip addr add 172.25.7.100/32 dev eth0

  • 注意：子网掩码为32是因为这个ip不对外，只有自己用
  • 在两RS上设置用户访问的入口地址的原因：为了RS（后端web服务器）可以直接给客户端发送资源，不需要再返回给调度器，因为客户端访问的是入口地址，如果不使用入口地址给客户发送资源，客户端可能不会接收这个数据包。如果直接在客户端curl 172.25.7.100发现客户端要不到资源。因为DR工作模式是：client->lvs->rs->client， 由后端服务器端直接送回资源给客户端，但是客户端问172.25.7.100要的资源，后端服务器直接把资源给客户端，客户端不会识别 ，因此要在两个后端服务器上面设置入口地址。
    ここに画像を挿入説明
    ここに画像を挿入説明

7、在两台RS：server2、server3 上 ，编写共享页面

ここに画像を挿入説明

server2

ここに画像を挿入説明

server3

8、在两台RS：server2、server3 上，开启httpd服务

ここに画像を挿入説明

9、在LVS服务器上，查看调度策略

ipvsadm -l #  做解析，慢
ipvsadm -nl #  不做解析，快

ここに画像を挿入説明
10、 在真机上测试：curl 172.25.7.100 在真机上测试，发现客户端发出请求，通过调度器访问web资源的时候，会一直向同一个web服务器（server3）要资源，并 没有实现轮询。

arp -an | grep 172.25.7.100 , 可以看到默认缓存的是server3的mac地址ここに画像を挿入説明

ここに画像を挿入説明
11、arp -d 172.25.7.100 清除缓存 再次测试，没有实现轮询。

ここに画像を挿入説明
ここに画像を挿入説明

  • 注意：此时客户端访问资源有时候轮询，有时候不轮询，出现这样的现象是为什么呢？

因为DR模式是通过 修改MAC地址 进行访问的，调度器和两台web服务器上都有172.25.7.100这个入口地址VIP，所以客户端在请求的时候，三台虚拟机都有可能回复请求，客户端会记录回复他的那台虚拟机的mac地址，所以下次在访问的时候他会找记录过的mac地址对应的虚拟机（有可能是真实的服务器）直接访问，这在现实中是 不允许 的，因为 如果请求全部发往后端某一台真正的服务器的话，这台服务器会因为压力过大而宕机。而且，直接访问后端的真正的服务器，我们的server1（LVS调度器）也就没有起到作用，并没有实现真正意义上的负载均衡，这也是DR模式的一个缺点。这就类似于DDOS攻击，有可能会导致后端服务器瘫痪，造成用户不能正常访问资源。

现在解决DR模式不轮询的问题：

  • 因为客户端第一次访问172.25.7.100的时候server1,server2,server3均可以接收客户端的请求，这个是随机的，有可能不会经过lvs调度器，客户端直接问web服务器要资源。 在两个web后端上进行设置，防止ddos攻击。

方法一：添加arptable策略解决

12、在 server2 上，安装针对MAC地址的防火墙管理工具 yum install -y arptables

  • arptables：用户空间工具,用来 管理 linux内核中的ARP规则表. 这些规则用来检查ARP帧.arptables类似于iptables,但没有那么复杂.iptables工作于ip层,用于对ip包进行管理.arptables工作与arp协议层,用于对arp数据帧进行管理.arptables可以像iptables那样对arp数据帧进行各种规则设置,可以ACCEPT,DROP等
  • arptables -nL 可查看设置的访问规则
  • man arptable 可查看设置规则

ここに画像を挿入説明
ここに画像を挿入説明

13、设置规则：

arptables -A INPUT -d 172.25.7.100 -j DROP		
		##添加策略，让目的地址为172.25.7.100的访问不能到达RS，丢弃客户端的直接访问
		## -d, --destination [!] address[/mask]目的地址
		## -j, --jump target跳到目标

arptables -A OUTPUT -s 172.25.7.100 -j mangle --mangle-ip-s 172.25.7.2	
		##让返回的数据来自server2  172.25.7.2使自己以172.25.7.100的身份发送资源给客户端
cat /etc/sysconfig/arptables                #查看规则
arptables-save > /etc/sysconfig/arptables	#保存策略
cat /etc/sysconfig/arptables                #再次查看
systemctl start arptables.service           #重启服务
systemctl status arptables.service

ここに画像を挿入説明

server3（后端服务器）同理

ここに画像を挿入説明
此时，server2和server3不会接受客户端的请求了，每次客户端的访问只能由LVS调度器接受，即每次客户端只能通过lvs调度器去找web1和web2服务

14、在真机上测试：curl 172.25.7.100 实现了轮询。

ここに画像を挿入説明

ここに画像を挿入説明

当客户端（172.25.7.250）发送数据包给LVS调度器（172.25.7.100） 的时候（源地址172.25.7.250——>>目的地址172.25.7.100）,此时LVS会将源MAC地址变为LVS服务器的MAC地址，将目的MAC地址变为web服务器的MAC地址，然后就实现调度了.直接去找目标MAC地址，然后找web服务器，web服务器直接将数据返回给客户端（IP地址全程不变）

方法二 ： 配置内核参数

  • arp_ignore 和 arp_announce 参数都和 ARP协议 相关，主要 用于控制系统返回arp响应和发送arp请求时的动作。这两个参数很重要，特别是在LVS的DR场景下，它们的配置直接影响到DR转发是否正常。
  • arp_ignore参数的作用：控制系统在收到外部的arp请求时，是否要返回arp响应。1：只响应目的IP地址为接收网卡上的本地地址的arp请求
  • arp_announce的作用：控制系统在对外发送arp请求时，如何选择arp请求数据包的源IP地址。2：忽略IP数据包的源IP地址，选择该发送网卡上最合适的本地地址作为arp请求的源IP地址
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2


sysctl -p

5、DR模式下的LVS调度器（加权轮询算法）

在轮询算法LVS调度器的基础上，更改调度策略：

1、ipvsadm -C 清空策略
2、 添加策略：

ipvsadm -A -t 172.25.7.100:80 -s wrr 
		#设置客户端进入lvs调度器的入口地址，调度算法是加权轮询
ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.2:80 -g -w 1
		# 设置lvs的策略：入口的第一台后端服务器的信息，加权为1
ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.3:80 -g -w 2
		# 设置lvs的策略：入口的第二台后端服务器的信息，加权为2

ここに画像を挿入説明

3、arp -d 172.25.7.100 清除缓存 再次测试，实现了加权轮询
ここに画像を挿入説明

ここに画像を挿入説明

二、DR模式下的健康检测（Idirectord）

  • ldirectord对lvs策略的动态维护：ldirectord是监视集群节点(真实服务器)，并从集群中自动移除节点，我们需要使用ldirectord程序，这个程序在启动时自动建立IPVS表(不用手动建立了)，然后监视集群节点的健康情况，在发现失效节点时将其自动从IPVS表中移除。

背景 ： 之前DR模式下的LVS，我们都是假设后端服务器是可以正常工作。但对于一台后端服务器来说，它不可能永远是可以使用的，有自己的寿命或者会出现其它问题。当lvs集群中的一台后备服务器挂了之后，为了不影响客户的正常访问，应该将它从集群当中踢出去，让客户不再轮询访问。

模拟问题 ：关闭server2的httpd服务，一个web挂了，会影响客户的访问。

ここに画像を挿入説明
ここに画像を挿入説明

现在使用ldirectord这个插件可以解决此问题。

1、在 LVS调度器 （server1）上， 配置 高可用的yum源

ここに画像を挿入説明

ここに画像を挿入説明
ここに画像を挿入説明

2、从真机得到 ldirectord-3.9.5-3.1.x86_64.rpm

ここに画像を挿入説明
3、安装此插件： yum install -y ldirectord-3.9.5-3.1.x86_64.rpm

ここに画像を挿入説明

4、rpm -qpl ldirectord-3.9.5-3.1.x86_64.rpm 查看配置文件的路径
ここに画像を挿入説明
5、cp /usr/share/doc/ldirectord-3.9.5/ldirectord.cf /etc/ha.d

6、vim /etc/ha.d/ldirectord.cf 编辑设置信息

ここに画像を挿入説明

virtual=172.25.7.100:80
        real=172.25.7.2:80 gate			##两个后端rs
        real=172.25.7.3:80 gate
        fallback=127.0.0.1:80 gate		##两个rs都挂了，就访问调度器自己的80端口
        service=http
        scheduler=rr				##轮询算法
        #persistent=600
        #netmask=255.255.255.255
        protocol=tcp
        checktype=negotiate
        checkport=80
        request="index.html"
        #receive="Test Page"
        #virtualhost=www.x.y.z

ここに画像を挿入説明

7、更改策略为：轮询算法

ここに画像を挿入説明

ここに画像を挿入説明

8、开启服务：systemctl start ldirectord

  • 在企业6中， /etc/init.d/ldirectord start脚本方式启动服务

ここに画像を挿入説明
9、在客户端测试：

1）server2和server3都正常时，轮询。
ここに画像を挿入説明
2） 模拟server2挂掉このサーバはIPVSテーブルから削除されているかどうかを調べるだけでなく、サーバー3からクライアントテストの全体の内容に
ここに画像を挿入説明

ここに画像を挿入説明

10、サーバ2とサーバー3がハングアップしている場合には、LVSスケジューラはまた、一般的に非常に短い時間をステージングサーバーとして使用することができるが。
ここに画像を挿入説明
yumをインストール-yのhttpd
ここに画像を挿入説明

ここに画像を挿入説明

ここに画像を挿入説明

ストロベリージョジョチャープ
公開された102元の記事 ・ ウォン称賛21 ・ ビュー5340
プライベートの手紙の 懸念

おすすめ

転載: blog.csdn.net/ranrancc_/article/details/102472160
おすすめ
ランキング
uni.request在接口状态码403等还是走success
Springboot は mybatisplus を統合しており、ページング クエリによって返される Page オブジェクトの合計は常に 0 です。
System.InvalidOperationExceptionが：「BuildWindowCoreは、子ウィンドウのハンドル搭乗を返しません。」
[Example 08] IPD system advancement: version naming rules for version management
カスタム NavigationBar -- UIView による描画
データとデータの移行を復元します（個人的なメモ、無用リーダー）
4. 2次元配列で検索する
vim的私人订制
Flutterのカスタムルーティング切り替えアニメーション
Javaコンテナの方法の簡単なアプリケーションのArrayList
アーカイブ
もっと
2024-05-12(27)
2024-05-11(31)
2024-05-10(33)
2024-05-09(30)
2024-05-08(18)
2024-05-07(34)
2024-05-06(6)
2024-05-05(0)
2024-05-04(18)
2024-05-03(8)

コードワールド

© 2018 codetd.com