32---keepalived功能及使用场景(2)

==========

两个问题：

在继续讲keepalived之前让我们先思考两个问题：

1.如果我们只有一台调度器(lvs/Nginx)，且它到后端real server集群的物理连接断了(如网卡、光模块、线缆等损坏)，那该怎么应对？

2.如果我们只有一台调度器(Nginx等软件实现的)，但是不巧的是Nginx进程被杀死了，那该怎么应对？

显然以上都是单点故障，遇到单点故障很棘手，我们应该避免。一般来讲网络中关键节点都应该有至少两个，所以我们的调度器也应该至少两台，组成高可用(HA)集群，如下图 ：

图中有两台调度器，正常情况下流量仅流经director1，也就是director1 作为MASTER，director2 作为BACKUP。我们期望的是当MASTER的 eth1或 eth3 接口挂掉后，director2 能够承接director1的所有流量。同时，如果direcotr1为Nginx反代(包括7层和伪34层)，当Nginx进程挂掉后，也能完成流量切换。如何实现呢？用 keepalived。

在数通网络中，我们通常使用VRRP来做默认网关的冗余，keepalived也是靠实现VRRP协议来完成流量从 director1 到director2 的倒换的。如果不熟悉VRRP，建议去某度文库搜索下数通厂商的vrrp技术白皮书。理解了VRRP的工作原理后再来看 keepalived， so easy。（务必要先搞懂VRRP协议，厂商的vrrp技术白皮书已经写的很详细了，如华为。）

言归正传，使用keepalived，以下3种情况下会触发倒换(也就是图中流量从 director1 切到 director2)：

场景描述：图中eth1和eth2起vrrp，且eth1被选举为MASTER(准确地说MASTER和BACKUP都是针对接口说的，不过我们在一定场合下也称路由器的状态为MASTER/BACKUP)

1.  director1 的eth1接口down掉，这很容易理解，物理接口down掉了，无法发送vrrp advertisement，作为BACKUP的director2这时候就会接替原来director1的角色，成为MASTER。

2. 我们可以让 keepalived 进程在director1监控eth3接口的状态，如果该接口down掉，则停止在eth1接口上发送vrrp advertisement，把MASTER角色让个director2。这通过keepalived.conf中的track_interface命令配置来实现。

3. 我们可以让 keepalived 执行某脚本，该脚本周期性地检测诸如进程等的设备状态并返回code，keepalived根据脚本返回的code值调整(减小)director1发出的vrrp 通告中的priority至小于director2发出的通告中的priority,把MASTER角色让给director2。这通过keepalived.conf中的track_script命令配置来实现。

好，现在给出几个实例，我们通过如下两个拓扑完成实验验证。

Note：如中rs1,rs2,rs3是3台不同的物理机，只不过图中画在了一起。

实例一：

使用拓扑一， 仅仅在 director1 和 director2 的左侧接口起 vrrp，VRIP为192.168.10.131，物理接口分别为 192.168.10.128 和 192.168.10.135。设置 192.168.10.128所在借口有 higher priority，以使之被选举为master，当master接口挂掉后，backup接口开始发送 vrrp advertisement，成为master。director 1 和 director2 的配置分别如下：

补充：组播地址 && VRID 要设置成一样才会被认为是同一个 vrrp_instance

===== director1 配置 =====

global_defs {

  notification_email {

    root@localhost
  }
  notification_email_from root@localhost
  smtp_server 127.0.0.1

  smtp_connect_timeout 30

  router_id 6A   //设置 router-id

  vrrp_mcast_group4 224.0.0.18  //设置组播地址，同一个vrrp_instance中的组播地址一定要相同

}

vrrp_instance OUTSIDE_VI_1 {  //创建一个instance，名字随意(本地有效，报文不含之)，但是建议主备同名

   state MASTER  //预设置角色，其实没有大用，鹿死谁手还得比拼priority等

   interface eth1  //指定加入instance的接口

   virtual_router_id 1 //设置VRID，同一个vrrp_instance中的VRID一定要相同

   priority 100 //本机在vrrp_instance中的优先级，准确说应该是接口的优先级

   advert_int 1 //通告每隔1s发送一次

   authentication { //通告验证使用简单验证，仅vrrp 2.0支持，而keepalived就是实现的vrrp 2.0

       auth_type PASS

       auth_pass 1111

   }

   virtual_ipaddress {

       192.168.10.131   //vrrp的VRIP

   }

}

===== director2 配置 =====

global_defs {

  notification_email {

    root@localhost
  }
  notification_email_from root@localhost
  smtp_server 127.0.0.1
  smtp_connect_timeout 30

  router_id 6B

  vrrp_mcast_group4 224.0.0.18  //同一vrrp_instance的组播地址要一致

}

vrrp_instance OUTSIDE_VI_1 {
   state BACKUP

   interface eth6   //指定加入instance的接口

   virtual_router_id 1   //同一vrrp_instance的VRID要一致

   priority 99
   advert_int 1
   authentication {
       auth_type PASS

       auth_pass 1111

   }

   virtual_ipaddress {
       192.168.10.131
   }

}

配置完成后，重启keepalived。手动关闭 director1 的eth1，ip link set eth1 down，然后在vmnet1 上抓包，发现director2 的eth6 开始发送vrrp advertisement，也就是说director2的eth6已经是MASTER，切换完成。实验完成后再恢复eth1到up状态。

实例二：