查字典图书网
查字典图书网
1.4.1 负载均衡器的冗余 到目前为止，我们都只在介绍Web服务器的冗余，还尚未提及负载均衡器的冗余。如果仅有的一台负载均衡器发生故障的话，那么所有的服务都会停止。虽说可以使用冷备份，为预防故障事先多准备一台负载均衡器作为备用，但是当故障发生时若没有人力干预，依旧无法及时恢复运行。 本节将介绍路由器及负载均衡器的故障转移的方法。 1.4.2 虚拟路由器冗余协议（VRRP） 现在市面上有很多包含冗余功能的路由器与负载均衡器的产品。以前由于产品之间安装的冗余实现各不相同，因此基本上都使用厂商独有的协议。 当然不同的协议间不能相互兼容，这会造成很多不便，Cisco公司以 HSRP （Hot Standby Routing Protocol，热备份路由器协议）为基础，制定出了不依赖于厂商的冗余协议，即 VRRP （Virtual Router Redundancy Protocol，虚拟路由器冗余协议）。很多路由器及负载均衡器都采用了在RFC 3768A中定义的VRRP。上一节中介绍的keepalived也使用了VRRP，这样只需再搭建一台负载均衡器，并在keepalived添加相关的设定，就可以实现冗余。 1.4.3 VRRP的拓扑模型 路由器与负载均衡器的故障转移的原理，与1.1节中讲解Web服务器的故障转移流程时提到的“健康检查”“IP地址的映射”几乎是一样的，即检查节点是否正常工作，万一出问题的话，备用节点就会映射VIP（虚拟地址），发生故障转移。 A URL http://www.ietf.org/rfc/rfc3768.txt 在介绍VRRP的搭建及设定前，我们首先对VRRP常用的规则、术语，以及其行为做了如下整理。使用VRRP时，请留心这些关键字：“VRRP报文”“虚拟规则ID”“优先顺序”“抢占模式”“虚拟MAC地址”。 VRRP报文 所谓健康检查，一般是指定期对监控对象的设备发出一些请求，确认这些请求是否取得了应答。而VRRP则通过相反的途径监控主节点的运行，即VRRP的主节点会定期将 VRRP报文 （VRRP Packet）不断地发送到多点传送地址（224.0.0.18，Multicast Address）。由于VRRP报文类似于“播报”主节点可用的信息，因此也被称为“组播信息”（Advertisement)。图1.4.1是VRRP报文的格式，该报文对以下三项数据进行了编排： ● ●IP Address（虚拟IP地址，即VIP） ● ●Virtual Rtr ID（虚拟路由器ID） ● ●Priority（优先顺序） 图1.4.1 VRRP报文的格式※ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Adver Int | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ※ 引自http://www.ietf.org/rfc/rfc3768.txt。 备用节点通常会在正确接收到VRRP报文时进入待机状态，若一段时间没有收到VRRP报文的信息，备用节点就会认为主节点已经宕机，从而启动故障转移。因此在VRRP中，备用节点不会主动地确认主节点的状态。 虚拟路由器ID 向事先决定的组播地址（224.0.0.18）发送VRRP报文时，该组播地址从头到尾都不会改变。如图1.4.2所示，在同一网络上同时设置有多台负载均衡器的情况下，所有的VRRP报文都会发向同一地址。这看起来似乎会引起错误操作，但实际上VRRP中使用了名为虚拟路由器ID的参数，可以分辨实例，因此不会出现问题。如图1.4.2所示，在负载均衡器A、B与负载均衡器C、D中，只需对虚拟路由器ID做出合理设定，就能确保图1.4.2的拓扑模型可以正常工作。 优先顺序 在VRRP的拓扑结构示例中，经常可以看到拓扑结构由Active/Backup两台设备构成，但在实际使用中也有可能同时拥有100台以上的备用节点，这样就可能会造成一个问题：当两台以上的备用节点同时工作时，若是主节点出现问题，那么主节点具体要漂移到哪个备用节点呢？ 在VRRP中，会为各节点设定 优先顺序 （Priority）的值，各节点在接收不到VRRP报文时，会自行发出VRRP报文。由于VRRP报文中有事先设定的优先顺序值，因此通过比较该值，就可以迅速了解到比本节点优先值高的其他节点是否存在。万一有其他节点的优先值比本节点高，则其他节点会比本节点优先升格为主节点。虽然是非常简单的操作，但通过设定节点的优先顺序，在漂移到备用节点时，就可以从优先顺序高的节点依次进行，使优先顺序高的备用节点作为主节点使用。 抢占模式 在VRRP的默认设定中，当比现有的主节点优先顺序高的节点启动时，会发生故障转移。也就是说可以认为优先顺序高的节点一定是主节点。这个行为可以通过设定 抢占模式 （Preemptive Mode）进行改变。将抢占模式设为无效的情况下，只要主节点正常工作，即使其他节点的优先级比主节点高，也不会出现故障转移。 根据情况的不同，选择的抢占模式也不一样。比如主节点的情况已经不乐观，设备很可能会频繁重启，这时将抢占模式设为无效是比较好的选择。相反，如果是为了防止操作失误而希望在两节点都可以选择时，一定要漂移到特定的节点，则将抢占模式设为有效会是比较好的选择。 虚拟MAC地址 VRRP中除了定义了虚拟IP地址，还定义了 虚拟MAC地址 。为了完成映射，在故障保护时，不仅需要映射IP地址，还需要映射MAC地址。如果在不映射MAC地址的情况下映射IP地址，通信目标下所有设备的ARP缓存表都需要更新。为此，一般使用1.1节介绍的gratuitous ARP进行ARP请求，但在以太网（Ethernet）的操作环境中，无法保证所有的设备都能正常收到ARP请求。万一哪个设备的ARP缓存表没有更新，则直到该设备的ARP缓存更新为止，都没办法与这台设备进行通信。 为此，在VRRP中映射MAC地址时，需要对通信目标的ARP请求的更新进行特别处理。例如在RFC 3768中，在进入主节点状态前会发出gratuitous ARP，其实这样做的目的不是为了更新通信目标的ARP缓存表，而是为了更新二层交换机中MAC地址的学习状态。 1.4.4 安装keepalived时可能遇到的问题 在keepalived的VRRP中，由于不使用虚拟MAC地址，因此无法按照RFC 3768的方式进行安装。虽说在Linux平台下可以改变MAC地址，但因为无法拥有多个MAC地址，安装的keepalived中就无法使用虚拟MAC地址，所以在故障转移时就很可能存在ARP请求还尚未更新的设备。在这种情况下，直到ARP缓存清除为止，该设备都无法进行通信。 延迟发送gratuitous ARP（GARP） 为了解决这个问题，keepalived中有一个“grap_master_delay”的设定项目。keepalived在主节点状态漂移后，紧接着就会发出gratuitous ARP，但在这个瞬间大都存在网络不稳定的状况，例如可能流量太过于集中造成无法通信。keepalived为了确保让通信目标能准确地接收到更新ARP的请求，会安排在等待数秒后再发送gratuitous ARP。这个等待的时间可以在grap_master_delay中设定，默认值是5秒。 例如假设有这样一个系统：采用STP（Spanning Tree Protocol，生成树协议）A搭建网络，在二层交换机宕机后，负载均衡器会启动故障转移。在二层交换机宕机的瞬间，STP的收敛（Convergence）开始进行，这可能会造成数秒到数十秒的通信中断。由于在此期间发送的gratuitous ARP并没有实际传到其他节点，因此可以通过设定grap_master_delay在收敛完成后再发送gratuitous ARP。在keepalived的VRRP实现中，因为存在与RFC 3768中所定义的内容不一样的地方，因此在实际网络环境中使用时，有必要验证是否能够正确启动故障转移。 A IEEE 802.1D规定了这种链路管理协议。 1.4.5 keepalived的冗余 接下来，使用keepalived搭建出如图1.4.3所示的系统。图1.4.3中的lv1与lv2是在Linux中安装了keepalived的负载均衡器。代码清单1.4.1是lv1与lv2的keepalived.conf的设定A。表1.4.1中解释了各个参数的意义。 代码清单1.4.1 VRRP的设定❶（lv1的示例） vrrp_instance VI { state MASTER interface eth0 garp_master_delay 5 virtual_router_id 200 priority 101 ←在lv2中修改为100 advert_int 1 authentication { auth_type PASS auth_pass HIMITSU } virtual_ipaddress { 10.0.0.254/24 dev eth0 192.168.0.254/24 dev eth1 } } A 代码清单1.4.1中省略了IPVS（负载分流）的相关设定。 表1.4.1 各参数的意义 参数 说明 state MASTER 启动keepalived的时候，指定是作为MASTER（主节点）启动还是作为BACKUP（备用节点）启动 interface eth0 指定发出或接收VRRP报文的接口 garp_master_delay 5 指定从主节点状态漂移后，到再次发送gratuitous ARP的间隔秒数 virtual_router_id 100 虚拟路由器ID。每个VRRP实例都要指定一个独一无二的值，可指定的范围是0到255 priority 101 VRRP优先顺序的设定值。在选择主节点的时候，该值大的备用节点会优先漂移为主节点 advert_int 1 VRRP报文的发送间隔。以秒为单位来指定。默认值为1秒 virtual_ipaddress VIP（虚拟地址）。书写格式如下，可以同时指定两个以上的虚拟地址 <IPADDR>/<MASK>dev<STRING> 确认VIP 在lv1与lv2中启动了keepalived后，lv1就被分配了VIP（10.0.0.254与192.168.0. 254），但这无法通过 ifconfig 命令来确认，可以通过如图1.4.4所示的 ip 命令进行确认。 图1.4.4 确认VIP lv1:~# ip addr show eth0 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 10.0.0.252/24 brd 10.0.0.255 scope global eth0 inet 10.0.0.254/24 scope global eth0 lv1:~# ip addr show eth1 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.0.252/24 brd 192.168.0.255 scope global eth1 inet 192.168.0.254/24 scope global eth1 确认VRRP的运行情况 故障转移的运行情况的确认结果可总结如下： ❶ 关闭lv1 ➡ lv2=Master ○ ❷ 启动lv1 ➡ lv1=Master，lv2=Backup ○ ❸ 将lv1的eth0网线拔掉 ➡ lv1=Backup，lv2=Master ○ ❹ 将lv1的eth0网线插回 ➡ lv1=Master，lv2=Backup ○ ❺ 将lv1的eth1网线拔掉 ➡ lv1=Master，lv2=Backup × 这样看来，在上述第❺条拔掉eth1网线时，情况似乎有些奇怪。原本在lv1的eth1链路失效时，应该是lv1=Backup，lv2=Master。 分离VRRP实例 在以上的设定中，因为VRRP报文只有eth0传输数据，所以在eth1网线拔掉时自然无法检测出异常。如果想检测出多个实例的故障，就要如代码清单1.4.2所示，对每个接口的VRRP实例都做出定义。这里请注意“virtual_router_id”这个参数，在照搬vrrp_instance代码块中的代码时，请注意不要忘记替换相关的参数。因为VRRP实例是根据virtual_router_id区分的，所以请为每个实例指定一个独一无二的值。 代码清单1.4.2 VRRP的设定❷（lv1的示例） vrrp_sync_group VG { group { VE VI } } vrrp_instance VE { state MASTER interface eth0 garp_master_delay 5 virtual_router_id 200 ←为每个VRRP实例指定独一无二的值 priority 101 ←lv2中修改为100 advert_int 1 authentication { auth_type PASS auth_pass HIMITSU } virtual_ipaddress { 10.0.0.254/24 dev eth0 } } vrrp_instance VI { state MASTER interface eth1 garp_master_delay 5 virtual_router_id 201 ←每个VRRP实例独一无二的值 priority 101 ←lv2中请将这里修改为100 advert_int 1 authentication { auth_type PASS auth_pass HIMITSU } virtual_ipaddress { 192.168.0.254/24 dev eth1 } } 同步VRRP实例 代码块vrrp_sync_group是为了实现多个VRRP实例的状态的同步所需要进行的设定。例如，在对外实例（VE）作为备用节点的情况下，它所联动的对内实例（VI）也需要是备用的。这样在lv1中无论eth0或eth1哪边的网线出现异常，也都能够准确地执行故障转移。 1.4.6 keepalived的应用 之前我们对使用keepalived的VRRP功能来实现故障转移的详情进行了说明。 根据需求的不同，keepalived还有其他使用方法。比如在1.1节的图1.1.6的拓扑结构中，如果使用keepalived的话，搭建起来应该就能更加方便安全。keepalived中还附带一个 --vrrp 选项，据此可以独立地使用VRRP功能。读者可以先从搭建简单的冗余SMTP服务器开始，逐步加深对冗余的理解。