查字典图书网
查字典图书网
1.1 冗余的基础 1.1.1 冗余概述 冗余（Redundancy）是指，在故障发生时，使用事先准备好的备份设备，使系统相关功能得以继续提供服务。比如工厂或者医院为了防止停电，一般都准备有发电装置；而公共交通工具为了以防万一，也配备有多个制动系统以确保安全。 提供Web服务的网络与服务器系统也不例外，为了确保服务的可用性，对系统进行冗余处理的情况并不少见。本节将讲解实现系统冗余的基础知识，然后再介绍个简单的例子。 1.1.2 冗余的本质 系统的冗余可以通过以下步骤实现： ❶设想可能发生的故障 ❷根据故障准备备份设备 ❸部署故障发生时切换到备份设备的工作机制 下面按照以上各个步骤，对操作流程进行简单的介绍。 ❶设想可能发生的故障 冗余的第一步就是设想故障发生时的情况。请参考图1.1.1中简单的系统拓扑结构，来考虑该图中可能会导致系统故障的原因。 首先，列出图1.1.1所示的系统可能发生的故障。 ● ●路由器故障所造成的服务停止 ● ●服务器故障所造成的服务停止 ❷预先准备好备份设备 接下来，为了应对故障而预先准备备份设备。在图1.1.1的拓扑结构中增设一套备份设备，得到的拓扑结构如图1.1.2所示。至此，备份路由器和备份Web服务器还尚未连接到网络。 ❸部署工作机制……当故障发生时，切换到备份设备 最后，部署工作机制。部署工作机制通常是指，针对以上❶❷步骤中可能发生的故障节点A及故障属性，考虑通过在硬件层面部署怎样的拓扑才能解决这些故障。 下面以步骤❶中所设想的路由器故障和Web服务器故障为例，对基本工作机制的部署和冗余中用到的基本术语进行讲解。 A 在计算机科学技术名词[MINGC194]的第112页中，关于计算机网络的名词“node”对应的翻译是“结点”，但我们这里将“node”视为有计算能力的单元，就像人体的关节一样，因此译为“节点”。——译者注 1.1.3 应对路由器故障的情况 在图1.1.1的状态下，一旦路由器发生故障，服务就会停止。在图1.1.2中，通过增设备份设备，即便路由器发生故障，也能像图1.1.3中那样仅通过切换连接线就可以方便地解决故障，从而恢复服务。 冷备份 如图1.1.2和图1.1.3所示，我们平常并不会用到备份设备，只有在故障发生时才需要连接到备份设备，该工作机制称为“冷备份”（Cold Standby）。 在此需要关注的重点是：现用设备与备份设备的相关设定需要完全一致。即在冗余系统中“必须确保现用设备始终与备份设备的架构保持同样的状态”。 在使用路由器等网络设备的情况下，因为不用在生产环境中频繁地修改设定（切换连接），而且数据也并非一定要长期保存，所以使用冷备份不失为一个现实可行的方法。 1.1.4 应对Web服务器故障的情况 下面考虑在Web服务器发生故障的时候要如何应对。当Web服务器发生故障时，也可以采取与上述路由器发生故障时同样的思路，即参照图1.1.4切换到备份设备，但此处仍存在一个问题。 热备份 综上所述，在冗余系统中“确保现用设备始终与备份设备的架构保持同样的状态”是非常重要的。 在Web服务器中，面对每天都要更新的网站内容，应用软件或操作系统的版本更新等也在所难免。为了能启用备份设备，就不能停止冷备份设备在生产环境中的各种更新。仅仅为了在发生故障时能启用备份设备，而去费时费力地同步更新站点内容或应用软件版本，这确实有些费力不讨好。 有个好办法可以解决该问题，即让Web服务器的备份设备一直保持接入电源及Internet的状态。在现用设备内容更新时，备份设备也同步更新内容以确保与现用设备的内容一致，如图1.1.5所示。 像这样让两台服务器同时运行，并保持同样状态的使用模式称为“热备份”（Hot Standby）。在使用热备份的情况下，由于不会物理性地插拔网线以切换连接，发生故障也不会宕机太长时间，所以就让及时切换以解决故障成为了可能。 1.1.5 故障转移 当现用设备发生故障时，系统会自动将处理交接到备份设备，该操作称为 故障转移 （Failover）。 服务器的故障转移主要使用“虚拟IP地址”（Virtual IP Address，下文统称VIP）与“IP地址的映射（也称漂移）”来操作。 VIP 图1.1.6是使用VIP搭建Active/Backup（现用设备/备份设备）拓扑结构的例子。图中的Web1是现用设备，目前VIP（10.0.0.1）已经映射到该设备使用的IP地址，通过连接到该VIP来提供Web服务。 IP地址的映射 如图1.1.7所示，当现用设备发生故障时，VIP就会映射到备份设备，让最终用户访问到备份设备Web2。 1.1.6 检测故障 ……健康检查 为了能正常进行故障转移，需要在现用设备发生故障时及时知晓，该操作机制称为 健康检查 （Health Check）。健康检查有各种类型，可以根据用途选择适合的方法。以下举出几种常用的方法： ● ●ICMP监控（第三层A） ICMP监控是指，检查由ICMPB所发出的echo请求是否得到了应答。由于这是最基本的健康检查，因此无法得知Web服务（Apache等）是否已经停止 ● ●端口监控（第四层） 端口监控是指，通过使用TCP协议尝试连接目标主机，检查目标主机是否能被连接。该监控可以得知Web服务是否还在正常运行，但无从得知系统的负载状况，也无从得知错误的回报情况 ● ●服务监控（第七层） 通过实际发出HTTP请求等，检查该请求是否得到了应答。虽说这种方法可以检查所有的异常状况，但根据情况的不同，可能会加重目标主机的负载 A 这里的层次指的是OSI参考模型中的七层结构，下文同。——译者注 B 全称为Internet Control Message Protocol，是异常发生时通知错误及错误信息的协议。 Web服务器的健康检查 在本章的开头，我们设想了在如图1.1.1所示的拓扑结构下可能会发生的两种故障。 其中一种是“服务器故障所造成的服务停止”，为了检测出该故障，需要使用上文介绍的健康检查中的“服务器监控”。为什么需要使用服务器监控呢？因为即使服务器已经接入电源，而且对ICMP测试有应答，我们也依然不能断定Web服务（Apache等）在正常工作。为了检测出Web服务器的故障，需要尝试向需要测试的目标主机实际发出HTTP请求，并确认能否得到应答，这是相对切实有效的方法。 路由器的健康检查 而为了检测出“路由器故障所造成的服务停止”，就需要使用ICMP监控了。请注意这里并不是对路由器进行ICMP监控。因为需要确认的是“路由器是否正确进行了分组（Packet）交换”，因此从网络上的其他主机来监控Web服务器是比较好的选择。总而言之，只要确定Web服务器与Internet能够进行通信就可以了。 * * * 在进行健康检查时，首先要明确目标，这一点最为重要。 1.1.7 搭建Active/Backup的拓扑结构 下面就实际使用Shell脚本，尝试搭建前文中如图1.1.6所示的拓扑结构。这里Web1与Web2已经分配了只属于本机的实际IP地址。在代码清单1.1.1中，每秒对VIP发出一次 ping 测试，若失败，则该脚本会自行将VIP映射到可用主机上。 首先，请在Web1中执行代码清单1.1.1的脚本。在输出字符串“ fail over! ”后，该脚本执行结束，于是VIP就被分配到了Web1。接下来，请在Web2中执行代码清单1.1.1中的脚本，这次每秒都会有一行“ health ok! ”输出。 代码清单1.1.1 failover.sh #!/bin/sh VIP="10.0.0.1" DEV="eth0" healthcheck() { ping -c 1 -w 1 $VIP >/dev/null return $? } ip_takeover() { MAC=`ip link show $DEV | egrep -o '([0-9a-f]{2}:){5}[0-9a-f]{2}' | head -n 1 | tr -d :` ip addr add $VIP/24 dev $DEV send_arp $VIP $MAC 255.255.255.255 ffffffffffff ←❶ } while healthcheck; do echo "health ok!" sleep 1 done echo "fail over!" ip_takeover ※请在Debian/GNU Linux 4.0（内核版本 3.1）以上的版本中执行上面的代码。 请在客户端对VIP执行 ping 指令，并且在执行的同时尝试关闭Web1。一旦Web1关闭，Web2上运行的脚本的健康检查就会失败，从而就会有VIP映射的操作。 如图1.1.8所示，通过在客户端执行的 ping 指令所取得的结果，能够确认在Web1关闭大概三秒钟后，IP地址的映射操作已经完成。 图1.1.8 故障转移的动作确认 ~$ ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=2.46 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=1.86 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=5.06 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=2.64 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=0.453 ms 64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=3.73 ms 64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=3.91 ms 64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=0.418 ms ←在这里关闭Web1 64 bytes from 10.0.0.1: icmp_seq=11 ttl=64 time=3.20 ms ←已经完成Web2的交接 64 bytes from 10.0.0.1: icmp_seq=12 ttl=64 time=1.69 ms 64 bytes from 10.0.0.1: icmp_seq=13 ttl=64 time=1.48 ms IP地址的映射操作 “IP地址的映射操作”并不是单纯的“仅仅更换IP地址”这么简单。为了对此加以验证，我们尝试为两台服务器分配同一IP地址，从其他设备持续发出 ping 指令，并交替拔插LAN网线。可以发现，无论怎么拔插网线，通过 ping 指令也只能确认单台服务器的状态。 在LAN（Ethernet，以太网）中，并不是通过IP地址，而是通过被固定分配给NIC（Network Interface Card，网络适配器）的MAC（Media Access Control Address，介质访问控制）地址来完成通信的。在给其他服务器发送分组的时候，为了取得MAC地址，通常还会使用到ARP（Address Resolution Protocol，地址解析协议）。 ARP协议是指，通过指定目标设备的IP地址，查询目标设备的MAC地址。但由于每次通信时都进行查询效率会非常低，因此通常会将一次取得的MAC地址缓存在ARP缓存表中一段时间。这样一来，即便别的服务器被分配到了相同的IP地址，在ARP缓存表更新之前，该服务器也都没有办法完成通信。所以在分配IP地址到其他服务器时，请务必注意更新ARP缓存表。 你也可以使用 gratuitous ARP （GARP）作为获取MAC地址的手段。在通常没有使用gratuitous ARP的情况下要查询MAC地址时，ARP请求的内容是“请告诉我这个IP地址所对应的MAC地址”。而若是使用了gratuitous ARP，gratuitous ARP则会通知其他主机：“这是我的IP地址和MAC地址。”在代码清单1.1.1（failover.sh）中，在❶处使用了 send_arp 命令，目的就是发送出gratuitous ARP的通知消息。 1.1.8 还想更有效地使用服务器 ……负载分发A 在上述的Active/Backup拓扑结构中，仅使用了现用设备进行处理，而备份设备则闲置没用，仔细想想还真是可惜。若是能同时使用两台服务器来提供服务，那网站整体的处理性能应该会翻倍吧。 A Load Balance，文中在强调分流的逻辑动作时译为了“负载分发”；强调负载的拓扑时译为了“负载均衡”；强调降低负载时译为了“负载分流”。——译者注 使用多台服务器分发处理，网站整体的可扩展性也会随之提高，这样的做法称为被 负载分发 （Load Balance，或负载均衡）。对Web服务器做出负载分发的处理后，将来即便访问量变高，目前的服务器已经无法满足需求，也可以轻易地通过增设服务器来满足相应的需要，而并不需要购买高性能服务器来更换掉现有的无法满足需求的设备。这样一来，即便是旧的服务器也可以贡献余热，也就不会造成浪费。 在下面的1.2节和1.3节，将介绍Web服务器负载分发的具体搭建实例。