负载均衡备注一

本文介绍了LVS的八种核心调度算法,包括轮叫调度、加权轮叫调度、最小连接调度等,每种算法均有详细的流程说明及适用场景。
注:转载自http://tangfeng.iteye.com/blog/433011

一 、LVS总共有8种调度算法。
1. 轮叫调度(Round Robin Scheduling)
是以轮叫的方式依次将请求调度不同的服务器,即每次调度执行i = (i + 1) % n,并选出第i台服务器。在系统实现时,引入了一个额外条件,当服务器的权值为零时,表示该服务器不可用而不被调度。这样做的目的是将服务器切出服务(如屏蔽服务器故障,系统维护)。它的算法流程如下:
假设有一组服务器S = {S0, S1, …, Sn-1},一个指示变量i表示上一次选择的服务器,W(Si)表示服务器Si的权值。变量i被初始化为n-1,其中n > 0。
int j = i;
do {
j = (j + 1) % n;
if (W(Sj) > 0) {
i = j;
return Si;
}
} while (j != i);
return null;

轮叫调度算法假设所有服务器处理性能均相同,不管服务器的当前连接数和响应速度。该算法相对简单,[color=red]不适用于服务器组中处理性能不一的情况[/color],而且当请求服务时间变化比较大时,轮叫调度算法容易导致服务器间的负载不平衡。

2. 加权轮叫调度(Weighted Round-Robin Scheduling)
可以解决服务器间性能不一的情况,它用相应的权值表示服务器的处理性能,服务器的缺省权值为1。假设服务器A的权值为1,B的权值为2,则表示服务器B的处理性能是A的两倍。加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接,权值高的服务器比权值低的服务器处理更多的连接,相同权值的服务器处理相同数目的连接数。加权轮叫调度算法流程如下:
假设有一组服务器S = {S0, S1, …, Sn-1},W(Si)表示服务器Si的权值,一个
指示变量i表示上一次选择的服务器,指示变量cw表示当前调度的权值,max(S)
表示集合S中所有服务器的最大权值,gcd(S)表示集合S中所有服务器权值的最大
公约数。变量i和cw最初都被初始化为零。
while (true) {
if (i == 0) {
cw = cw - gcd(S);
if (cw <= 0) {
cw = max(S);
if (cw == 0)
return null;
}
} else i = (i + 1) % n;
if (W(Si) >= cw)
return Si;
}

例如,有三个服务器A、B和C分别有权值4、3和2,则在一个调度周期内(mod sum(W(Si)))调度序列为AABABCABC。加权轮叫调度算法还是比较简单和高效。当请求的服务时间变化很大,单独的加权轮叫调度算法依然会导致服务器间的负载不平衡。

从上面的算法流程中,我们可以看出当服务器的权值为零时,该服务器不被被调度;当所有服务器的权值为零,即对于任意i有W(Si)=0,则没有任何服务器可用,算法返回NULL,所有的新连接都会被丢掉。加权轮叫调度也无需记录当前所有连接的状态,所以它也是一种无状态调度。

3. 最小连接调度(Least-Connection Scheduling)

是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器,其连接数加1;当连接中止或超时,其连接数减一。在系统实现时,也引入当服务器的权值为零时,表示该服务器不可用而不被调度,它的算法流程如下:
假设有一组服务器S = {S0, S1, ..., Sn-1},W(Si)表示服务器Si的权值,
C(Si)表示服务器Si的当前连接数。
for (m = 0; m < n; m++) {
if (W(Sm) > 0) {
for (i = m+1; i < n; i++) {
if (W(Si) <= 0)
continue;
if (C(Si) < C(Sm))
m = i;
}
return Sm;
}
}
return null;

当各个服务器有相同的处理性能时,最小连接调度算法能把负载变化大的请求分布平滑到各个服务器上,所有处理时间比较长的请求不可能被发送到同一台服务器上。但是,当各个服务器的处理能力不同时,该算法并不理想,因为TCP连接处理请求后会进入TIME_WAIT状态,TCP的TIME_WAIT一般为2分钟,此时连接还占用服务器的资源,所以会出现这样情形,性能高的服务器已处理所收到的连接,连接处于TIME_WAIT状态,而性能低的服务器已经忙于处理所收到的连接,还不断地收到新的连接请求。

4. 加权最小连接调度(Weighted Least-Connection Scheduling)
是最小连接调度的超集,各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1,系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。加权最小连接调度的算法流程如下:
假设有一组服务器S = {S0, S1, ..., Sn-1},W(Si)表示服务器Si的权值,C(Si)表示服务器Si的当前连接数。所有服务器当前连接数的总和为
CSUM = ΣC(Si) (i=0, 1, .. , n-1)。
当前的新连接请求会被发送服务器Sm,当且仅当服务器Sm满足以下条件
(C(Sm)/CSUM)/W(Sm) = min{ (C(Si)/CSUM)/W(Si)} (i=0, 1, . , n-1) 其中W(Si)不为零
因为CSUM在这一轮查找中是个常数,所以判断条件可以简化为
C(Sm)/W(Sm) = min{ C(Si)/W(Si)} (i=0, 1, . , n-1) 其中W(Si)不为零
因为除法所需的CPU周期比乘法多,且在Linux内核中不允许浮点除法,服务器的权值都大于零,所以判断条件C(Sm)/W(Sm) > C(Si)/W(Si) 可以进一步优化为C(Sm)*W(Si) > C(Si)* W(Sm)。同时保证服务器的权值为零时,服务器不被调度。所以,算法只要执行以下流程。
for (m = 0; m < n; m++) {
if (W(Sm) > 0) {
for (i = m+1; i < n; i++) {
if (C(Sm)*W(Si) > C(Si)*W(Sm))
m = i;
}
return Sm;
}
}
return null;


5. 基于局部性的最少链接调度 (Locality-Based Least Connections Schedulin
是针对请求报文的目标IP地址的负载均衡调度,目前主要用于Cache集群系统,因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标IP地址的请求调度到同一台服务器,来提高各台服务器的访问局部性和主存Cache命中率,从而整个集群系统的处理能力。

LBLC 调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于其一半的工作负载,则用“最少链接”的原则选出一个可用的服务器,将请求发送到该服务器。该算法的详细流程如下:
假设有一组服务器S = {S0, S1, ..., Sn-1},W(Si)表示服务器Si的权值,C(Si)表示服务器Si的当前连接数。ServerNode[dest_ip]是一个关联变量,表示目标IP地址所对应的服务器结点,一般来说它是通过Hash表实现的。WLC(S)表示在集合S中的加权最小连接服务器,即前面的加权最小连接调度。Now为当前系统时间。
if (ServerNode[dest_ip] is null) then {
n = WLC(S);
if (n is null) then return null;
ServerNode[dest_ip].server = n;
} else {
n = ServerNode[dest_ip].server;
if ((n is dead) OR
(C(n) > W(n) AND
there is a node m with C(m) < W(m)/2))) then {
n = WLC(S);
if (n is null) then return null;
ServerNode[dest_ip].server = n;
}
}
ServerNode[dest_ip].lastuse = Now;
return n;


6. 带复制的基于局部性最少链接调度

带复制的基于局部性最少链接调度(Locality-Based Least Connections with Replication Scheduling,以下简称为LBLCR)算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求,一台Cache 服务器可能会忙不过来处理这些请求。这时,LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器,映射该“热门”站点到这台Cache服务器,很快这台Cache服务器也会超载,就会重复上述过程选出新的Cache服务器。这样,可能会导致该“热门”站点的映像会出现在所有的Cache服务器上,降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器(服务器集合),当该“热门”站点的请求负载增加时,会增加集合里的Cache服务器,来处理不断增长的负载;当该“热门”站点的请求负载降低时,会减少集合里的Cache服务器数目。这样,该“热门”站点的映像不太可能出现在所有的Cache服务器上,从而提供Cache集群系统的使用效率。

LBLCR 算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组;按“最小连接”原则从该服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载;则按“最小连接”原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。LBLCR调度算法的流程如下:
假设有一组服务器S = {S0, S1, ..., Sn-1},W(Si)表示服务器Si的权值,C(Si)表示服务器Si的当前连接数。ServerSet[dest_ip]是一个关联变量,表示目标IP地址所对应的服务器集合,一般来说它是通过Hash表实现的。WLC(S)表示在集合S中的加权最小连接服务器,即前面的加权最小连接调度;WGC(S)表示在集合S中的加权最大连接服务器。Now为当前系统时间,lastmod表示集合的最近修改时间,T为对集合进行调整的设定时间。
if (ServerSet[dest_ip] is NULL) then {
n = WLC(S);
if (n is NULL) then return NULL;
add n into ServerSet[dest_ip];
} else {
n = WLC(ServerSet[dest_ip]);
if ((n is NULL) OR
(n is dead) OR
(C(n) > W(n) AND
there is a node m with C(m) < W(m)/2))) then {
n = WLC(S);
if (n is NULL) then return NULL;
add n into ServerSet[dest_ip];
} else
if (|ServerSet[dest_ip]| > 1 AND
Now - ServerSet[dest_ip].lastmod > T) then {
m = WGC(ServerSet[dest_ip]);
remove m from ServerSet[dest_ip];
}
}
ServerSet[dest_ip].lastuse = Now;
if (ServerSet[dest_ip] changed) then
ServerSet[dest_ip].lastmod = Now;
return n;


7. 目标地址散列调度

目标地址散列调度(Destination Hashing Scheduling)算法也是针对目标IP地址的负载均衡,但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。该算法的流程如下:
假设有一组服务器S = {S0, S1, ..., Sn-1},W(Si)表示服务器Si的权值,C(Si)表示服务器Si的当前连接数。ServerNode[]是一个有256个桶(Bucket)的Hash表,一般来说服务器的数目会运小于256,当然表的大小也是可以调整的。算法的初始化是将所有服务器顺序、循环地放置到ServerNode表中。若服务器的连接数目大于2倍的权值,则表示服务器已超载。
n = ServerNode[hashkey(dest_ip)];
if ((n is dead) OR
(W(n) == 0) OR
(C(n) > 2*W(n))) then
return NULL;
return n;


8. 源地址散列调度

源地址散列调度(Source Hashing Scheduling)算法正好与目标地址散列调度算法相反,它根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目标地址散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本相似,除了将请求的目标IP地址换成请求的源IP地址。

在实际应用中,源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中,它们可以保证整个系统的唯一出入口。
类别 用途 备注 数量 承载软件 数量 新技术规范ID 云平台底座 专有云基础组件 专有云企业版飞天底座 4台 包括云底座、中间件ECS、云盾管控服务、容器服务、运维编排服务、BMCP裸金属纳管、ASCM、ASO、WAF、安骑士等 17 A606-500139516-00033 专有云基础组件 专有云企业版飞天底座 13台 A606-500155128-00130 元数据库 元数据库 4台 云平台元数据库 A606-500155128-00129 中间件服务 中间件基础组件 tlog组件 3台 中间件依赖组件(EDAS/ARMS等) A606-500139516-00030 计算服务服务器(ECS) 共享计算集群 10台 计算-ECS计算集群(共享集群) 10 A606-500155128-00131 网络服务 专有网络VPC 专有网络VPC(专有云)基础网络服务包 2台 网络-阿里云专有网络软件(VPC) 1 A606-500155128-00141 负载均衡SLB软件(专有云)(slbserver节点) 负载均衡SLB(专有云)基础软件包-物理机版 2台 网络-阿里云服务器负载均衡管理软件(SLB) 1 A606-500155128-00141 负载均衡SLB软件(专有云)(slblvs节点) 负载均衡SLB(专有云)基础软件包-物理机版 2台 A606-500155128-00141 负载均衡SLB软件(专有云)(slbproxy节点) 负载均衡SLB(专有云)基础软件包-物理机版 2台 A606-500155128-00141 高速通道 高速通道 on 物理机 2台 专线接入(CSW) A606-500155128-00141 存储服务 对象存储 CDS_OSS 6台 存储-阿里云开放存储服务软件(OSS)-对象存储 6 A606-500139516-00030 日志服务 CDS_SLS 4台 日志服务 4 A606-500139516-00031 块存储(混闪) CDS-EBS混闪独立部署集群 6台 存储-块存储EBS(混闪) 6 A606-500139516-00030 数据库服务 云原生数据库PolarDB PostgreSQL PolarDB V2.0_PostgreSQL版 4台 数据库-云数据库RDS (polardb PG) 4 A606-500155128-00129 云数据库 Redis 版 云数据库 Redis 版_社区版 4台 数据库-云数据库kvstore(兼容Redis及Memcache) 4 A606-500155128-00129 大数据服务 elasticsearch elasticsearch 3台 检索分析服务ES(ElasticSearch) 3 A606-500139516-00031 ADB ADB(PG) 3台 分析型数据库(ADB PG) 3 A606-500155128-00129 安全服务 云盾-流量安全监控的安装包 云盾-流量安全监控-基础模块(绑定2C机型) 2台 云盾-基础版(云入侵防御) 2 A606-500155128-00141 云盾-堡垒机New 云盾-平台侧堡垒机(云原生版) 1台 云盾-基础版(平台侧堡垒机) A606-500155128-00141 根据这些信息生产架构图
08-07
根据你提供的信息,这是个较为完整的专有云平台架构信息表,涵盖了云平台底座、中间件服务、计算、网络、存储、数据库、大数据及安全服务等多个模块。虽然我无法直接生成图像,但我可以为你提供个 **架构图的层级结构描述**,你可以根据这个结构使用工具(如 Visio、ProcessOn、draw.io 等)绘制架构图。 --- ### 🧱 专有云平台架构图(层级结构描述) #### 1. **云平台底座** - **组件** - 云底座(4台) - 中间件ECS - 云盾管控服务 - 容器服务 - 运维编排服务 - BMCP裸金属纳管 - ASCM、ASO、WAF、安骑士等 - **数量** - 17台承载软件,4台物理机 - **子系统** - 元数据库(4台,ID: A606-500155128-00129) #### 2. **中间件服务** - **tlog组件**(3台) - 依赖组件:EDAS、ARMS等 - **新技术规范ID**:A606-500139516-00030 #### 3. **计算服务** - **ECS共享计算集群**(10台) - 承载软件:计算-ECS计算集群(10个实例) - **新技术规范ID**:A606-500155128-00131 #### 4. **网络服务** - **VPC专有网络**(2台) - 承载软件:网络-阿里云专有网络软件(VPC)(1个) - **SLB负载均衡** - slbserver节点(2台) - slblvs节点(2台) - slbproxy节点(2台) - 承载软件:网络-阿里云服务器负载均衡管理软件(SLB)(1个) - **高速通道** - 专线接入(CSW)(2台) - **新技术规范ID**:A606-500155128-00141 #### 5. **存储服务** - **对象存储 CDS_OSS**(6台) - 承载软件:存储-阿里云开放存储服务软件(OSS)(6个) - **日志服务 CDS_SLS**(4台) - 承载软件:日志服务(4个) - **块存储 CDS-EBS混闪**(6台) - 承载软件:存储-块存储EBS(混闪)(6个) - **新技术规范ID**:A606-500139516-00030 / A606-500139516-00031 #### 6. **数据库服务** - **PolarDB PostgreSQL**(4台) - 承载软件:数据库-云数据库RDS(polardb PG)(4个) - **Redis 版**(4台) - 承载软件:数据库-云数据库kvstore(兼容Redis及Memcache)(4个) - **新技术规范ID**:A606-500155128-00129 #### 7. **大数据服务** - **Elasticsearch**(3台) - 承载软件:检索分析服务ES(ElasticSearch)(3个) - **ADB PG**(3台) - 承载软件:分析型数据库(ADB PG)(3个) - **新技术规范ID**:A606-500139516-00031 / A606-500155128-00129 #### 8. **安全服务** - **云盾-流量安全监控** - 绑定2C机型(2台) - 承载软件:云盾-基础版(云入侵防御)(2个) - **云盾-堡垒机New** - 云原生版(1台) - 承载软件:云盾-基础版(平台侧堡垒机) - **新技术规范ID**:A606-500155128-00141 --- ### ✅ 绘图建议 你可以将上述层级结构绘制成如下图示: ``` 云平台底座 ├── 云底座、中间件ECS、容器服务等 ├── 元数据库 中间件服务 ├── tlog组件 计算服务 ├── ECS共享集群 网络服务 ├── VPC ├── SLB(slbserver/slblvs/slbproxy) ├── 高速通道 存储服务 ├── 对象存储OSS ├── 日志服务SLS ├── 块存储EBS 数据库服务 ├── PolarDB PG ├── Redis 大数据服务 ├── Elasticsearch ├── ADB PG 安全服务 ├── 云盾流量监控 ├── 堡垒机 ``` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值