Linux入门攻坚——41、Linux集群系统入门-lvs（2）

lvs-dr：GATEWAY

Director只负责请求报文，响应报文不经过Director，直接由RS返回给Client。

lvs-dr的报文路线如上图，基本思路就是报文不会回送Director，第①种情况是VIP、DIP、RIP位于同一个网段，这样，网络可以共用一个，即使用同一个路由器和交换机；第②种情况VIP与DIP和RIP不在一个网段，响应报文会走单独的网络线路。

对第一种情况进行实操测试：地址分配表

这里主要问题是：当请求报文到来时，它请求的是VIP，在到达VIP所在网络时，需要知道VIP对应的V-MAC，但是因为在Director和RS上都配置了VIP，就会引起混乱，所以这里的关键是确定真正的Director对应的VIP的MAC，方法有三种，一是arp绑定，在请求报文到来的设备上的接口静态绑定Director的V-MAC；二是在RS上使用arptables过滤；三是在内核上设置内核参数：arp_ignore和arp_announce来实现。一二两种方式有一定的局限性，一般使用第三种。

关于arp_ignore和arp_announce，要理解这两个参数，需要明白arp的工作方式：
每新来一台机器，自己通告一下；后来的机器或是前面的机器没有收到，可以主动询问。

ARP协议的作用就是根据IP地址获取其对应的MAC地址。在以太网中，主机要发送一个数据报文，首先需要获取目标MAC地址（如果通信的目标主机在同一网段，那目标MAC地址就是目标主机的MAC地址，否则应该为网关的MAC地址或下一跳的MAC地址），而获取目标MAC地址的方法就是使用ARP协议发送ARP请求数据报文，ARP请求数据报文中会包含发送方的IP地址和MAC地址，并且包含想要获取MAC地址的目标IP地址，该ARP请求数据报文的数据链路层目标地址为广播地址，也就是说它是一个二层广播数据包（因为不知道谁拥有指定目标IP地址，所以只能使用广播方式发送）。在同一局域网的所有主机都将收到该ARP请求数据报文，但是只有拥有目标IP地址的主机才会发送ARP响应数据报文，该ARP响应数据报文包含发送方的IP地址和MAC地址（即对方想要知道的目标MAC地址），并且目标IP地址和MAC地址设置为对方的地址（即ARP请求数据包发送方的地址），并且该数据报文为单播数据报文（其数据链路层目标地址为对方的MAC地址）。

arp_announce参数是定义linux主机发送ARP请求数据报文时如何选择数据报文中使用的发送方IP地址（即Sender IP address）。在系统准备通过网卡发送一个IP数据包前，该IP数据包的源IP地址和目标IP地址通常是已经知道的，然后根据目的IP查询路由表确定发送数据报文的网卡，则发送的网卡也已经确定，那数据链路层的源MAC地址当然也确定了，发送ARP请求数据报文时需要包含发送方IP地址，该IP地址应该是什么呢？大家可能想当然的以为就是要发送的IP数据报文的源IP地址，其实这个是不一定的，尤其是主机有多个网络接口和IP地址时，而arp_announce正是控制该发送方IP地址的选择条件的。arp_announce参数的取值分别是0、1、2，这些取值的意义如下：
0：允许使用任意网卡上的IP地址作为arp请求的源IP，通常就是使用要发送数据报文的源IP。
1：尽量避免使用不属于该发送网卡子网的本地地址作为发送arp请求的源IP地址。
2：忽略IP数据包的源IP地址，选择该发送网卡上最合适的本地地址作为arp请求的源IP地址。

arp_announce - INTEGER
Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent on interface:
0 - (default) Use any local address, configured on any interface
1 - Try to avoid local addresses that are not in the target's subnet for this interface.
This mode is useful when target hosts reachable via this interface require the source IP address in ARP requests to be part of their logical network configured on the receiving interface. When we generate the request we will check all our subnets that include the target IP and will preserve the source address if it is from such subnet. If there is no such subnet we select source address according to the rules for level 2.
2 - Always use the best local address for this target.
In this mode we ignore the source address in the IP packet and try to select local address that we prefer for talks with the target host. Such local address is selected by looking for primary IP addresses on all our subnets on the outgoing interface that include the target IP address. If no suitable local address is found we select the first local address we have on the outgoing interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes no matter the source IP address we announce.
The max value from conf/{all,interface}/arp_announce is used.     

arp_ignore参数是定义linux主机在收到ARP请求数据报文后，发送ARP响应数据报文的条件级别，该参数的取值范围是0～8，各取值的意义分别是：
0：响应任意网卡上接收到的对本机IP地址的arp请求（包括环回网卡上的地址），而不管该目的IP是否在接收网卡上。
1：只响应目的IP地址为接收网卡上的本地地址的arp请求。
2：只响应目的IP地址为接收网卡上的本地地址的arp请求，并且arp请求的源IP必须和接收网卡同网段。
3：如果ARP请求数据包所请求的IP地址对应的本地地址其作用域（scope）为主机（host），则不回应ARP响应数据包，如果作用域为全局（global）或链路（link），则回应ARP响应数据包。
4~7：保留未使用
8：不回应所有的arp请求
arp_ignore - INTEGER
Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured on any interface
1 - reply only if the target IP address is local address configured on the incoming interface
2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied
4-7 - reserved
8 - do not reply for all local addresses

arp_announce是控制本机发送ARP请求报文时，对请求报文的源IP和源MAC进行控制的选项，这里的重点是一是请求报文，二是源IP和源MAC。
   
如上图，右边的Director主机在3.1接口上想发送一个ARP请求报文，请求1.2的MAC地址，现在的问题来了：发送的ARP请求报文，请求的目的IP肯定是1.2，那么源IP是什么，源MAC又是什么？对于源MAC是确定的，就是报文从哪个接口发送出去，就是哪个接口的MAC，所以，这个请求报文的源MAC是1.1接口的MAC，而源IP则根据arp_announce来确定，如果是0，那么最初是哪个IP，就是哪个IP，这里是从3.1发起的ARP请求，那么源IP就是3.1，最终请求报文就是源IP3.1源MAC1.1目的IP1.2这样一个请求报文；如果arp_announce是2，则忽略IP数据报文的源IP地址，选择发送网卡上最合适的本地地址作为arp请求的源IP地址，即选择1.1作为请求报文的源IP，最终请求报文就是源IP1.1源MAC1.1目的IP1.2这样一个请求报文；arp_announce为1，尽量避免使用不属于该发送网卡子网的本地地址作为发送arp请求的源IP地址，这里的发送网卡是1.1所在网卡，所以避免使用不是1.1网络的IP作为源IP，即不使用原来的3.1，而是使用1.1作为源IP，最终请求报文就是源IP1.1源MAC1.1目的IP1.2这样一个请求报文；

arp_ignore是控制本机接收请求报文后的处理，即对响应报文的控制，如上图，从1.2来的ARP请求报文，从1.1接口进入主机，请求3.1的MAC地址，那么，如果arp_ignore为0，则响应任意网卡上接收到的对本机IP地址的arp请求（包括环回网卡上的地址），而不管该目的IP是否在接收网卡上，就是说，主机要对此请求报文进行响应，因为3.1是本主机的一个IP，不管这个报文是从哪个接口进来的，从2.1或3.1或4.1进来的，都进行响应；如果arp_ignore为1，只响应目的IP地址为接收网卡上的本地地址的arp请求，此时1.1接口只配置了1.1地址，3.1不在接收网卡上，此时主机不会响应ARP请求报文，如果1.1接口上同时配置了3.1，那么就会响应；arp_ignore为2，只响应目的IP地址为接收网卡上的本地地址的arp请求，并且arp请求的源IP必须和接收网卡同网段，此时不但检查请求报文的目的IP是在配置在入接口上，还要检查目的IP和源IP是否是同一子网地址，1.2请求3.1的MAC，同时3.1配置在1.1的接口卡上，主机也不会响应，因为源IP和目的IP不在一个子网，1.2请求1.1的MAC，并且请求报文从1.1接口进入，主机才响应；

 在这里的lvs-dr演示中，arp_ignore=1，arp_announce=2，arp_announce为2，lo接口上的VIP不会发送ARP请求，不会以源IP为VIP发送ARP请求报文，arp_ignore为1，只有接收到目的IP为VIP的ARP请求报文的接口，才能响应报文，即接收到对VIP的ARP请求报文的接口上配置了VIP，才能响应，这就杜绝了lo上的VIP对ARP的响应。

配置Director上的VIP，配置在网卡别名上：
ifconfig ens:0 192.168.147.140/32 broadcast 192.168.147.140 up

添加路由： route add -host 192.168.147.140 dev ens33:0

配置RS上的内核参数：

配置RS上的VIP地址：

测试：在Windows宿主机上ping 192.168.147.140，然后看其arp结果：

Director上的MAC：

说明我们PING通的是Director上的VIP。
配置另一台RS：

添加ipvs：

此时访问http://192.168.147.140，不断刷新，会看到RS交替，实现负载均衡。

以上是VIP、DIP、RIP在同一网段的lvs-dr情况。

lvs-dr：VIP，DIP/RIP不在同一网段情况

使用vmware模拟上述情景，需要对vmware的网络有所了解。vmware的网络模式有：
bridge（桥接模式），nat（NAT模式），only host（仅主机）模式

对于vmware中的虚拟机及其之间的通信，如上图，在宿主机中不但虚拟了主机和虚拟网卡，还有虚拟交换机，虚拟主机1与虚拟主机2可以通信，在同一个网络中，虚拟主机2和虚拟主机3可以通信，虚拟主机1和虚拟主机3呢？如果虚拟主机2没有开启路由和核心转发功能，1和3之间就不能通信。那么虚拟主机如何与外部物理主机通信？这要分几种情况。
对于bridge，即桥接模式，实际上是将宿主机的物理网卡模拟成虚拟交换机，在VMWare中就是VMNet0，连接到这个虚拟交换机中的虚拟主机2,3，就可以直接与物理主机通信，同时VMware又为宿主机物理网卡虚拟出一个虚拟网卡，继承物理网卡的配置，这样外部物理主机也可以继续与宿主机通信。
对于nat模式和仅主机模式，相差不多：

nat模式，会在宿主机上安装一块虚拟网卡VMNet8，虚拟的网卡分配的地址一般是.1，如我的是192.168.147.1，然后会虚拟一个NAT路由器，其IP为.2，如我的192.168.147.2，在上图中NAT设置中可以看到，就是网关IP。连接在同一虚拟交换机上的虚拟主机可以访问外部物理主机（通过nat），即设置默认路由为192.168.147.2，就是NAT路由器，通过这个路由进行nat，与宿主机的物理网卡做nat；内部虚拟机之间可以相互访问（同一网络内），通过VMNet8虚拟网卡，虚拟主机可以与宿主机之间相互访问。
only host（仅主机）模式，没有虚拟NAT路由器，即没有192.168.xx.2这个地址，也就无法进行nat，虚拟主机与外部相互之间不通信，VMNet1只用于虚拟主机与宿主机之间的互相访问。
在虚拟交换机上，还可以附加DHCP服务器，进行虚拟机地址的自动分配。

模拟环境搭建：

Director的配置：

ipvsadm -A -t 192.168.61.129:80 -s rr
ipvsadm -a -t 192.168.61.129:80 -r 192.168.217.130:80 -g
ipvsadm -a -t 192.168.61.129:80 -r 192.168.217.131:80 -g

RS配置：
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
ifconfig lo：0  192.168.61.129/32 broadcast 192.168.61.129 up
route add -net 192.168.61.0/24 gw 192.168.217.129

从router上测试，即从192.168.61.130的虚拟机上运行：curl http://192.168.61.129
测试结果是命令卡住，没有结果返回。
使用tcpdump对各虚拟机抓包，http请求从61.130到了61.129，从217.128到了RS，从RS到了217.129，已经回到了router上，好像就是最后router处理不了。

（以后有时间再捣鼓这个吧）

关于ipvsadm -f选项：防火墙标记

netfilter：
  PREROUTING --> INPUT
  PREROUTING --> FORWARD --> POSTROUTING
  OUTPUT --> POSTROUTING

对于用户的请求（外部请求），不会经过OUTPUT链，那么所有的请求都经过PREROUTING，经过PREROUTING后才能到达ipvs，那么，就可以在PREROUTING对请求报文打上标记，使用iptables防火墙进行标记（对报文进行修改），mangle就是进行拆包封包。

在PREROUTING时：  -j MARK --set-mark #
然后在ipvs中：-A -f # 对特定报文进行调度。意味着可以同时对不同类型的报文同时进行调度。

再增加一种功能：ssh
iptables -t mangle -A PREROUTING -d 192.168.61.129 -p tcp --dport 22 -j MARK --set-mark 10
这样，ipvs不需要改动，就实现ssh的负载均衡。

通过FWM定义集群的方式：
  1）在Director上netfilter的mangle表的PREROUTING链上定义用于打标的规则；
  iptables -t mangle -A PREROUTING -d $vip -p $proto --dport &port -j MARK --set-mark #
  2）基于FWM定义集群服务：
  ipvsadm -A -f # -s scheduler
  ipvsadm -a -f # -r $rs-ip -g
功用：将共享一组RS的集群服务统一进行定义。

session保持：session绑定；session复制；session服务器
session绑定：lvs sh算法
  对某一特定服务
lvs persistence：lvs的持久连接：无论ipvs使用何种调度方法，其都能实现将来自于同一个Client的请求始终定向至第一次调度时挑选的RS；
  持久连接模版：独立于算法；
    sourceip   rs   timer
  对多个共享同一组RS的服务器，需要统一进行绑定；

ipvsadm -A -t 192.168.61.129:80 -s rr -p 
ipvsadm -a -t 192.168.61.129:80 -r 192.168.217.130 -g
ipvsadm -a -t 192.168.61.129:80 -r 192.168.217.131 -g

持久连接的实现方式：
  每端口持久：PPC，单服务持久调度；
  每FWM持久：PFWMC，单FWM持久调度；PORT AFFINITY
  每客户端持久：PCC，单客户端持久调度；
    director会将用户的任何请求都识别为集群服务，并向RS进行调度；

lvs的HA（高可用性）：
  SPOF：Single Point Of Failure （单点故障）
  director：高可用集群；
  realserver：让director对其做健康状态检测，并且根据检测的结果自动完成添加或移除等管理功能；
    1）基于协议层次检查：
        ip：icmp；
        传输层：检测端口的开放状态；
        应用层：请求获取关键性的资源；
    2）检查频度：客户容忍度
    3）状态判断：下线谨慎，上线乐观
        下线：ok --> Failure --->  Failure --->  Failure ，也就是多次判断失败后，才下线
        上线：Failure --> ok --> ok，即两次检测成功就上线。
    4）back server，sorry server

关于集群的个人总结：通过lvs的了解，听着高大尚的集群，其实就是一个关于数据包流程改变的过程，由一个前端的调度器，作为总的接入口，然后将报文分配给后面的业务服务器，最后由业务服务器直接返回结果给客户端或者返回给调度器再返回给客户端，中间的调度过程对客户端是透明的，调度的过程中，要考虑后端服务器的负载均衡，就是调度算法，要考虑服务的状态保持，要考虑调度器或业务服务器、存储等的高可用性等等，对客户端的请求报文，可以只通过改变MAC、IP、PORT等改变流向，也可以通过调度器拆包再重新生成新的请求包来实现流向改变并增加新功能，这就是四层和七层路由。关键是构建这个转发网络。