十分钟了解负载均衡

不能狭义地理解为给所有实际服务器分配相同的工作负载，因为多台服务器的承载能力是不同的，这可能体现在硬件配置、网络带宽的差异，或者因为某个服务器扮演多个角色。我们所说的“平衡”是指我们希望所有的服务器都不会超载，能够最大限度地发挥程序的功能。 首先我们先来了解一下什么叫“平衡” 不能狭义地理解为给所有实际服务器分配相同的工作量，因为多台服务器的承载能力是不同的，这可能体现在硬件配置和网络带宽的差异上，或者因为某台服务器担当多个服务器的任务。角色。我们所说的“平衡”是指我们希望所有的服务器都不会超载，能够按计划运行。 1.http重定向 当http代理（例如浏览器）向Web服务器请求URL时，Web服务器可以通过http响应标头中的Location标记返回新的URL。这意味着HTTP代理需要继续请求这个新的URL才能完成自动跳转。 性能缺陷： 1. 吞吐率限制 主站点服务器的吞吐量均匀分配到传输的服务器。假设采用RR（Round Robin）调度策略，子服务器的最大吞吐率为1000reqs/s，那么主服务器的吞吐率必须达到3000reqs/s才能充分发挥3个子服务器的作用，那么如果有100个子服务器，那么你能想象主服务器的吞吐率有多大吗？相反，如果主服务器的最大吞吐率为6000reqs/s，则分配给子服务器的平均吞吐率为2000reqs/s，则子服务器当前吞吐率为2000reqs/s。 ***吞吐率为1000reqs/s，因此必须将子服务器数量增加到6个才能满足要求。 2、重定向访问深度不同 有的重定向静态页面，有的重定向更复杂的动态页面，因此实际服务器上的负载差异是不可预测的，主服务器对此一无所知。因此，采用重定向的方式来实现整个站点的负载均衡并不好。 我们需要权衡传输请求的开销和处理实际请求的开销。前者相对于后者越小，重定向的意义就越大，比如下载。你可以尝试很多镜像下载网站，你会发现基本的下载都是使用Location进行重定向的。 2、DNS负载均衡DNS负责提供域名解析服务。访问站点时，实际上首先需要通过站点域名的DNS服务器获取该域名指向的IP地址。在此过程中，DNS服务器完成域名到IP地址的映射。同样，这个映射也可以是一对多的。此时，DNS服务器就充当了负载均衡调度器的作用。它就像http重定向转换策略一样将用户请求分发到多个服务器，但其实现机制完全不同。 使用dig命令查看“baidu”的DNS设置 可见百度有3条A记录 与http重定向相比，基于DNS的负载均衡完全省去了所谓的主站点，或者说DNS服务器已经充当了主站点。但不同的是，作为调度器，几乎不需要担心DNS服务器本身的性能。由于DNS记录可以被用户的浏览器或互联网接入服务提供商的各级DNS服务器缓存，只有当缓存过期时，才会重新请求该域名的DNS服务器进行解析。也有人说DNS没有http的吞吐量限制，理论上可以最大化实际服务器的数量。 特征： 1、可根据用户IP进行智能分析。 DNS服务器可以在所有可用的A记录中找到距离用户记录最近的服务器。 2.动态DNS：每次IP地址发生变化时及时更新DNS服务器。当然，由于缓存的原因，一些延迟是不可避免的。 不足的： 1、用户无法直接看到DNS解析的是哪台实际服务器，给服务器运维人员的调试带来不便。 2.策略的局限性。例如，您不能将HTTP请求的上下文引入到调度策略中。前面介绍的基于HTTP重定向的负载均衡系统中，调度器工作在HTTP层面。它能够充分理解HTTP请求并根据站点的应用逻辑进行设计。调度策略，例如根据请求不同的URL进行合理的过滤和传输。 3、如果要根据实际服务器的实时负载差异来调整调度策略，这就需要DNS服务器在每次解析操作时分析各个服务器的健康状况。对于DNS服务器来说，这种定制开发门槛很高。更不用说大多数网站只使用第三方 DNS 服务。 4.DNS记录缓存。各级节点的DNS服务器上缓存不同的程序会让你头晕。 5、综合以上几点，DNS服务器无法很好地完成工作负载均衡分配。 ***、是否选择基于DNS的负载均衡方式完全取决于您的需求。 3.反向代理负载均衡 大家一定都接触过这个，因为几乎所有主流的Web服务器都热衷于支持基于反向代理的负载均衡。它的核心工作是转发HTTP请求。与之前的HTTP重定向和DNS解析相比，反向代理的调度器扮演了用户和实际服务器之间的中间人的角色： 1.任何对实际服务器的HTTP请求都必须经过调度器 2.调度器必须等待实际服务器的HTTP响应并将其反馈给用户（前两种方法不需要调度反馈，实际服务器直接发送给用户） 特征： 1.丰富的调度策略。比如可以对不同的实际服务器设置不同的权重，达到有能力者多做事的效果。 2、反向代理服务器由于工作在HTTP层面，对并发处理能力要求较高。 3、反向代理服务器本身的转发操作需要一定的开销，比如创建线程、与后端服务器建立TCP连接、接收后端服务器返回的处理结果、分析HTTP头信息等频繁的用户空间和内核空间切换等，虽然这部分时间不长，但是当后端服务器处理请求的时间很短时，转发开销就显得尤为突出。例如，请求静态文件时，使用前面介绍的基于DNS的负载均衡方法比较合适。 4、反向代理服务器可以监控后端服务器，如系统负载、响应时间、可用性、TCP连接数、流量等，并根据这些数据调整负载均衡策略。 5、反射代理服务器允许一个会话周期内的所有用户请求始终转发到特定的后端服务器（粘性会话）。这样做的好处是保持会话的本地访问，防止后端服务器被访问。动态内存缓存是一种资源浪费。 4.IP负载均衡（LVS-NAT） 由于反向代理服务器工作在HTTP层，其自身的开销严重限制了可扩展性，从而限制了其性能极限。 HTTP级别以下能否实现负载均衡？ NAT服务器：工作在传输层。它可以修改发送的IP数据包，将数据包的目的地址更改为实际的服务器地址。 从Linux 2.4内核开始，其内置的Neftilter模块在内核中维护了一些数据过滤表，其中包含了控制数据过滤的规则。幸运的是，Linux提供了iptables来执行插入、修改和删除过滤表等操作。更令人兴奋的是，IPVS模块内置于Linux 2.6.x内核中。其工作本质与Netfilter模块类似，但更侧重于实现IP负载均衡。 想知道您的服务器内核是否安装了 IPVS 模块？输出表示 IPVS 已安装。 IPVS的管理工具是ipvsadm，它提供了基于命令行的配置界面，通过该界面可以快速实现负载均衡系统。这就是大名鼎鼎的LVS（Linux Virtual Server，Linux虚拟服务器）。 1.打开调度器的数据包转发选项 echo 1 > /proc/sys/net/ipv4/ip_forward 2. 检查实际服务器是否使用NAT服务器作为默认网关。如果没有，请添加 路由添加默认网关 xx.xx.xx.xx 3.使用ipvsadm配置 ipvsadm -A -t 111.11.11.11:80 -s rr 添加虚拟服务器，-t后面是服务器的外网IP和端口，-s rr指的是使用简单轮询的RR调度策略（这是一种静态调度策略，此外，LVS还提供了一系列动态的调度策略）调度策略，如最小连接（LC）、加权最小连接（WLC）、最小期望延迟（SED）等） ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -mipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m 添加两台实际服务器（不需要外部IP），-r后面是实际服务器的内部IP和端口，-m表示使用NAT转发数据包。 运行ipvsadm -L -n查看实际服务器的状态。这个做完了。 实验演示了基于 NAT 的负载平衡系统的使用。充当调度程序的 NAT 服务器可以将吞吐量提升到一个新水平，几乎是反向代理服务器速度的两倍，这主要是由于内核中请求转发的开销较低。但是，一旦请求的内容过大，无论是基于反向代理还是基于NAT，负载均衡的整体吞吐量相差并不大。这说明对于开销较大的内容，可以使用简单的反向代理来构建负载均衡。该系统值得考虑。 如此强大的系统仍然有它的瓶颈，那就是NAT服务器的网络带宽，包括内部网络和外部网络。当然，如果你不缺钱，你可以花钱买千兆交换机或者10G交换机，甚至负载均衡硬件设备，但是如果你是个loser怎么办？一个简单有效的办法就是将基于NAT的集群与之前的DNS混合使用，比如5个100Mbps出口宽带的集群，然后利用DNS将用户请求均匀引导到这些集群。同时还可以利用DNS智能解析实现就近区域访问。这样的配置对于大多数企业来说已经足够了，但是对于提供下载或者视频等服务的大型网站来说，NAT服务器还是不够好。 5、直接路由（LVS-DR） NAT工作在网络分层模型的传输层（第4层），而直接路由工作在数据链路层（第2层），看起来比较尴尬。它通过修改数据包的目标MAC地址（不修改目标IP）将数据包转发到实际服务器。不同的是，来自实际服务器的响应数据包将直接发送到客户端，而不经过调度器。 1. 网络设置 这里我们假设一个负载均衡调度器，两台实际服务器，购买三个外网IP，每台机器一个，并且三台机器的默认网关需要相同。最后，设置相同的IP别名，假设别名为10.10。 .120.193.这样就会通过IP别名10.10.120.193来访问调度器，你可以将站点的域名指向这个IP别名。 2.将ip别名添加到loopback接口lo 这是为了防止实际服务器寻找具有此 IP 别名的其他服务器。在实际服务器中运行： 另外，为了防止实际服务器响应来自网络的 IP 别名的 ARP 广播，也请执行以下操作： 回声“1”> /proc/sys/net/ipv4/conf/lo/arp_ignoreecho“2”> /proc/sys/net/ipv4/conf/lo/arp_announceecho“1”> /proc/sys/net/ipv4/ conf/all/arp_ignoreecho "1" > /proc/sys/net/ipv4/conf/all/arp_announce 配置完成后，您可以使用ipvsadm配置LVS-DR集群。 ipvsadm -A -t 10.10.120.193:80 -s rripvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -gipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211 ：8000 - G -g 表示使用直接路由转发数据包LVS-DR相比LVS-NAT最大的优点是LVS-DR不受调度器带宽的限制。例如，假设WAN交换机出口处的三台服务器的带宽限制为10Mbps，只要连接调度器和两台实际服务器的LAN交换机没有速度限制，那么使用LVS-DR理论上可以达到最大出口20Mbps的带宽，因为实际服务器的响应数据包可以直接发送到客户端，而不需要经过调度器，所以它与调度器的出口带宽无关，只与它自己有关。如果使用LVS-NAT，集群只能使用10Mbps带宽。因此，服务响应远远超过请求数据包的数据包越多，就越应该减少调度程序传输请求的开销，就越能提高整体可扩展性，最终就越依赖WAN出口带宽。 总的来说，LVS-DR适合构建可扩展的负载均衡系统。无论是Web服务器、文件服务器、还是视频服务器，都具有优异的性能。前提是你必须为实际服务器购买一系列合法的IP地址。 6.IP隧道（LVS-TUN） 基于IP隧道的请求转发机制：将调度器收到的IP数据包封装成新的IP数据包转发给实际服务器，然后实际服务器的响应数据包就可以直接到达用户端。目前大多数Linux都支持，并且可以使用LVS来实现，称为LVS-TUN。与LVS-DR不同的是，实际服务器可能与调度器不在同一WANt网段。调度器通过IP隧道技术将请求转发到实际服务器。 ，所以实际的服务器也必须有合法的IP地址。 一般来说，LVS-DR和LVS-TUN都适合响应和请求不对称的Web服务器。如何选择取决于您的网络部署需求，因为LVS-TUN可以根据需要部署实际的服务器。不同地区，请求按照就近访问的原则进行传输，所以如果有类似的需求，应该选择LVS-TUN。