网站搭建是什么专业,广告联盟网站怎么做,wordpress取摘要,白城哪家做网站文章目录 一、负载均衡二、负载均衡模型分类三、CDN负载均衡四、LVS负载均衡4.1 LVS 支持的三种模式4.1.1 DR 模式4.1.2 TUN 模式4.1.3 NAT 模式 4.2 LVS 基于 Netfilter 的框架实现 五、负载均衡策略是什么六、常用负载均衡策略图解6.1 轮询6.2 加权轮询6.3 最少连接数6.4 最快… 文章目录 一、负载均衡二、负载均衡模型分类三、CDN负载均衡四、LVS负载均衡4.1 LVS 支持的三种模式4.1.1 DR 模式4.1.2 TUN 模式4.1.3 NAT 模式 4.2 LVS 基于 Netfilter 的框架实现 五、负载均衡策略是什么六、常用负载均衡策略图解6.1 轮询6.2 加权轮询6.3 最少连接数6.4 最快响应6.5 Hash 法 七、用健康探测来保障高可用7.1 HTTP 探测7.2 TCP 探测7.3 UDP 探测 一、负载均衡
负载均衡是云计算的基础组件是网络流量的入口其重要性不言而喻。
什么是负载均衡呢
将用户请求或者说流量通过负载均衡器按照某种负载均衡算法把流量均匀地分散到后端的多个服务器上接收到请求的服务器可以独立的响应请求以期望的规则分摊到多个操作单元上进行执行达到负载分担的目的。并通过它可以实现横向扩展scale out将冗余的作用发挥为高可用。
二、负载均衡模型分类
从应用场景上来说常见的负载均衡模型有全局负载均衡和集群内负载均衡从产品形态角度来说又可以分为硬件负载均衡和软件负载均衡。
全局负载均衡一般通过 DNS 实现通过将一个域名解析到不同 VIP来实现不同的 Region 调度能力。
硬件负载均衡器常见的有 F5、A10、Array它们的优缺点都比较明显优点是功能强大有专门的售后服务团队性能比较好缺点是缺少定制的灵活性维护成本较高。
现在的互联网更多的思路是通过软件负载均衡来实现这样可以满足各种定制化需求常见的软件负载均衡有 LVS、Nginx、Haproxy。 对于用户配置的四层监听LVS 后面会直接挂载用户 ECS七层用户监听 ECS 则挂载在 Tengine 上。四层监听的流量直接由 LVS 转发到 ECS而七层监听的流量会经过 LVS 到 Tenigine 再到用户 ECS。
每一个 Region 里都会有多个可用区达到主备容灾目的每一个集群里都有多台设备第一是为了提升性能第二也是基于容灾考虑。 上图为高性能负载均衡控制管理概要图SLB 产品也有 SDN 概念转发和控制是分离的用户所有配置通过控制台先到控制器通过集中控制器转换将用户配置推送到不同设备上每台设备上都有 Agent 接收控制器下发的需求。
通过本地转换成 LVS 和 Tengine 能够识别的配置这个过程支持热配置不影响用户转发不需要 reload 才能使新配置生效。
三、CDN负载均衡
四、LVS负载均衡
4.1 LVS 支持的三种模式
早期 LVS 支持以下三种模式DR 模式、TUN 模式、NAT 模式 4.1.1 DR 模式
DR 模式经过 LVS 之后LVS 会将 MAC 地址更改、封装 MAC 头内层 IP 报文不动。
报文经过 LVS 负载均衡查找到 RS 之后将源 MAC 头改成自己的目的 MAC 改成 RS 地址MAC 寻址是在二层网络里对网络部署有一定的限定在大规模分布式集群部署里这种模式的灵活性没有办法满足需求。
4.1.2 TUN 模式
TUN 模式走在 LVS 之后LVS 会在原有报文基础上封装 IP 头到了后端 RS 之后RS 需要解开 IP 报文封装才能拿到原始报文。
不管是 DR 模式还是 TUN 模式后端 RS 都可以看到真实客户源 IP目的 IP 是自己的 VIPVIP 在 RS 设备上需要配置这样可以直接绕过 LVS 返回给用户。
TUN 模式问题在于需要在后端 ECS 上配置解封装模块在 Linux 上已经支持这种模块但是 Windows 上还没有提供支持所以会对用户系统镜像选择有限定。
4.1.3 NAT 模式
NAT 模式用户访问的是 VIPLVS 查找完后会将目的 IP 做 DNAT 转换选择出 RS 地址。
因为客户端的 IP 没变在回包的时候直接向公网真实客户端 IP 去路由NAT 的约束是因为 LVS 做了 DNAT 转换所以回包需要走LVS把报文头转换回去。
由于 ECS 看到的是客户端真实的源地址我们需要在用户 ECS 上配置路由将到 ECS 的默认路由指向 LVS 上这对用户场景也做了限制。
4.2 LVS 基于 Netfilter 的框架实现 Netfilter 是 Linux 提供的网络开放平台基于该平台可以开发自己的业务功能模块早期好多安全厂商都是基于 Netfilter 做一些业务模型实现。
这种模型比较灵活但通用模型里更多的是兼容性考虑路径会非常长;而且通用模型中没办法发挥多核特性目前 CPU 的发展更多是向横向扩展。
我们经常见到多路服务器每路上有多少核早期通用模型对多核支持并不是特别友善在多核设计上有些欠缺导致我们在通用模型上做一些应用开发时的扩展性是有限的随着核的数量越来越多性能不增反降。
五、负载均衡策略是什么 正如上图所示的这样由一个独立的统一入口来收敛流量再做二次分发的过程就是负载均衡它的本质和分布式系统一样是分治。在软件系统中为了避免流量分摊不均造成局部节点负载过大如 CPU 吃紧等所以引入一个独立的统一入口来做类似的工作。在软件系统中的负载均衡的背后是策略在起作用而策略的背后是由某些算法或者说逻辑来组成的。负载均衡也有很多算法或者说逻辑在支撑着这些策略也有静态和动态之分。
六、常用负载均衡策略图解
下面来罗列一下日常工作中最常见的 5 种策略。
6.1 轮询 这是最常用也最简单策略平均分配人人都有、一人一次。大致的代码如下
int globalIndex 0; //注意是全局变量不是局部变量。try{return servers[globalIndex];
} finally {globalIndex;if (globalIndex 3)globalIndex 0;
}6.2 加权轮询 在轮询的基础上增加了一个权重的概念。权重是一个泛化后的概念可以用任意方式来体现本质上是一个能者多劳思想。
比如可以根据宿主的性能差异配置不同的权重。大致的代码如下
int matchedIndex -1;
int total 0;for (int i 0; i servers.Length; i)
{servers[i].cur_weight servers[i].weight;//①每次循环的时候做自增步长权重值total servers[i].weight;//②将每个节点的权重值累加到汇总值中if (matchedIndex -1 || servers[matchedIndex].cur_weight servers[i].cur_weight) //③如果 当前节点的自增数 当前待返回节点的自增数则覆盖。{matchedIndex i;}
}
servers[matchedIndex].cur_weight - total;//④被选取的节点减去②的汇总值以降低下一次被选举时的初始权重值。
return servers[matchedIndex];这段代码的过程如下图的表格。()中的数字就是自增数即代码中的 cur_weight。 值得注意的是加权轮询本身还有不同的实现方式虽说最终的比例都是 212。
但是在请求送达的先后顺序上可以有所不同。比如「5-432-1」和上面的案例相比最终比例是一样的但是效果不同。
「5-432-1」更容易产生并发问题导致服务端拥塞且这个问题随着权重数字越大越严重。
例子1053 的结果是「18-17-16-15-14-13-12-11-10-98-7-6-5-43-2-1」
6.3 最少连接数 这是一种根据实时的负载情况进行动态负载均衡的方式。维护好活动中的连接数量然后取最小的返回即可。大致的代码如下
var matchedServer servers.orderBy(e e.active_conns).first();
matchedServer.active_conns 1;
return matchedServer;//在连接关闭时还需对active_conns做减1的动作。6.4 最快响应 这也是一种动态负载均衡策略它的本质是根据每个节点对过去一段时间内的响应情况来分配响应越快分配的越多。
具体的运作方式也有很多上图的这种可以理解为将最近一段时间的请求耗时的平均值记录下来结合前面的加权轮询来处理所以等价于 213 的加权轮询。
题外话一般来说同机房下的延迟基本没什么差异响应时间的差异主要在服务的处理能力上。
如果在跨地域例浙江-上海还是浙江-北京的一些请求处理中运用大多数情况会使用定时「Ping」的方式来获取延迟情况因为是 OSI 的 L3 转发数据更干净准确性更高。
6.5 Hash 法 Hash 法的负载均衡与之前的几种不同在于它的结果是由客户端决定的。通过客户端带来的某个标识经过一个标准化的散列函数进行打散分摊。上图中的散列函数运用的是最简单粗暴的取余法。
题外话散列函数除了取余之外还有诸如变基、折叠、平方取中法等等此处不做展开有兴趣的小伙伴可自行查阅资料。
另外被求余的参数其实可以是任意的只要最终转化成一个整数参与运算即可。
最常用的应该是用来源 IP 地址作为参数这样可以确保相同的客户端请求尽可能落在同一台服务器上。
常用负载均衡策略优缺点和适用场景
我们知道没有完美的事物负载均衡策略也是一样。上面列举的这些最常用的策略也有各自的优缺点和适用场景我稍作了整理如下。 这些负载均衡算法之所以常用也是因为简单想要更优的效果必然就需要更高的复杂度。
比如可以将简单的策略组合使用、或者通过更多维度的数据采样来综合评估、甚至是基于进行数据挖掘后的预测算法来做。
七、用健康探测来保障高可用
不管是什么样的策略难免会遇到机器故障或者程序故障的情况。所以要确保负载均衡能更好的起到效果还需要结合一些健康探测机制。定时的去探测服务端是不是还能连上响应是不是超出预期的慢。
如果节点属于“不可用”的状态的话需要将这个节点临时从待选取列表中移除以提高可用性。一般常用的健康探测方式有 3 种。
7.1 HTTP 探测
使用 Get/Post 的方式请求服务端的某个固定的 URL判断返回的内容是否符合预期。一般使用 HTTP 状态码、Response 中的内容来判断。
7.2 TCP 探测
基于 TCP 的三次握手机制来探测指定的 IP 端口。最佳实践可以借鉴阿里云的 SLB 机制如下图 值得注意的是为了尽早释放连接在三次握手结束后立马跟上 RST 来中断 TCP 连接。
7.3 UDP 探测
可能有部分应用使用的是 UDP 协议。在此协议下可以通过报文来进行探测指定的 IP 端口。最佳实践同样可以借鉴阿里云的 SLB 机制如下图 结果的判定方式是在服务端没有返回任何信息的情况下默认是正常状态。否则会返回一个 ICMP 的报错信息。
