24小时365天不间断服务1.4 路由器及负载均衡器的冗余_24小时365天不间断服务1.4 路由器及负载均衡器的冗余试读-查字典图书网
查字典图书网
当前位置: 查字典 > 图书网 > web > 24小时365天不间断服务 > 1.4 路由器及负载均衡器的冗余

24小时365天不间断服务——1.4 路由器及负载均衡器的冗余

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服务器开始,逐步加深对冗余的理解。

展开全文

推荐文章

猜你喜欢

附近的人在看

推荐阅读

拓展阅读

《24小时365天不间断服务》其他试读目录

• 1.1 冗余的基础
• 1.2 实现Web服务器的冗余……DNS轮询
• 1.3 实现Web服务器的冗余……基于IPVS的负载均衡器
• 1.4 路由器及负载均衡器的冗余 [当前]