Linux集群简介以及lvs
之前介绍了lvs-nat的工作模型已经集群搭建与测试，因为调度器在中间起到一个支点的作用，请求报文与响应报文都需要经过调度器，调度器压力随之增大，因此调度器成为了整个集群中的性能瓶颈，进而可能会引发单点故障。为了避免这种情况发生，章文嵩先生提出了lvs-dr集群架构，lvs-dr通过为请求报文重新封装一个数据链路层首部(MAC地址)进行报文转发，重新封装之后的报文源MAC地址是DIP所在网络接口的MAC地址，目的MAC地址是某个利用调度算法挑选出来的后端RS的RIP所在借口的MAC地址，源IP地址和源PORT以及目的IP和目的PORT在整个报文转发的过程中保持不变。下面是拓扑图：https://s4.运维网.com/oss/201710/21/e5669bc8d572dafcba5220b2a2d6d924.png假定客户端IP在172.16.0.0/16网段，后端RS的IP在192.168.100.0/24网段。调度器上同时设定CIP与DIP分别在两个网段以进行沟通，后端RS上也需要设定RIP与VIP，这里VIP的作用是为了能使RS接受请求报文。这就产生了一个问题，当客户端请求报文发出至交换机时，交换机会广播哪台主机有VIP这个IP地址，这时RS与VS都可以给予响应，因此为了避免这个问题引入了arp_ignore和arp_announce这两个内核参数。另一个问题是当RS回复响应报文时的源IP地址会是RIP这样客户端会认为此报文是虚假信息不予接受，因此为了避免这个问题需要在RS上设置一条特殊的路由，当接受报文时先经过lo接口上的VIP以设置源IP地址为VIP。
下面配置一个lvs-dr集群并进行测试：
编写脚本配置后端RS服务器的VIP，特殊的路由转发功能，以及arp_ignore,arp_announce：https://s1.运维网.com/oss/201710/23/0ad41e94e863c934cd17fc27324cacce.png-wh_500x0-wm_3-wmp_4-s_1794747743.pnghttps://s2.运维网.com/oss/201710/23/201e28aa5902469a09e4fb4622d5603e.png-wh_500x0-wm_3-wmp_4-s_1326685878.pnghttps://s2.运维网.com/oss/201710/23/6af47d0367e4e9064528675fb877913f.png
然后配置后端RS的RIP：192.168.100.0/24网段的任意IP，实验里选择192.168.100.2和192.168.100.3，看一下配置好的IP以及网关：https://s4.运维网.com/oss/201710/23/d7a36ae905c0aa8054b0e5cf91c6821d.png
https://s3.运维网.com/oss/201710/23/4eb2427b1fe631c00b1e45095bfbde5d.png
https://s5.运维网.com/oss/201710/23/72be70c674409eda9b8c6988898632bd.png接下来就可以配置调度服务器的DIP和VIP以及ipvsadm配置的内容，注意这里调度服务器只有一个网卡，我们将DIP配置在网卡上，而VIP则配置在别名网卡上：https://s4.运维网.com/oss/201710/23/670e1dde65884eaa8959cd123b6c2396.png
在ipvsadm上配置时，lvs-dr算法是默认算法，因此不需要专门指定算法类型：https://s3.运维网.com/oss/201710/23/4a3df72377bc02cdee52d1febe4ab311.png
https://s5.运维网.com/oss/201710/23/ff07e180f5a772ff065f53dbd698fbb2.png
因为DIP和VIP不在同一网段，假定客户端与VIP在同一网段，所以添加一台虚拟机当做客户机来监测集群情况，配置如下：https://s2.运维网.com/oss/201710/23/758202bc3a6183b73f4681936ef7bb2c.png
接下来监测集群使用状况：
https://s3.运维网.com/oss/201710/23/d1af9364659f5179d275c24b05d173f3.png
https://s3.运维网.com/oss/201710/23/e03872a42f6fcdc220426a219efa17d9.png
采用rr轮询算法调度后端服务器，客户端10次申请，后端RS轮询提供服务，并且reply报文不经过调度器转发，成功实现lvs-dr集群的构建。
页:
[1]