文章目录
1 集群和分布式
系统性能扩展方式:
- Scale UP:垂直扩展,向上扩展,增强,性能更强的计算机运行同样的服务
- Scale Out:水平扩展,向外扩展,增加设备,并行地运行多个服务调度分配问题,Cluster
垂直扩展不再提及:
随着计算机性能的增长,其价格会成倍增长
单台计算机的性能是有上限的,不可能无限制地垂直扩展
多核CPU意味着即使是单台计算机也可以并行的。那么,为什么不一开始就并行化技术?
1.1 集群 Cluster
Cluster:集群,为解决某个特定问题将多台计算机组合起来形成的单个系统
Cluster分为三种类型:
- LB:Load Balancing,负载均衡,多个主机组成,每个主机只承担一部分访问请求
- HA:High Availiablity,高可用,避免SPOF(single Point Of failure)
MTBF:Mean Time Between Failure 平均无故障时间,正常时间
MTTR:Mean Time To Restoration( repair)平均恢复前时间,故障时间
A = MTBF /(MTBF+MTTR) (0,1):99%,99.5%,99.9%,99.99%,99.999%
SLA:服务等级协议(简称:SLA,全称:service level agreement)。是在一定开销下为保障服务的性能和可用性,服务提供商与用户间定义的一种双方认可的协定。通常这个开销是驱动提供服务质量的主要因素。在常规的领域中,总是设定所谓的三个9,四个9来进行表示,当没有达到这种水平的时候,就会有一些列的惩罚措施,而运维,最主要的目标就是达成这种服务水平。
1年 = 365天 = 8760小时
90 = (1-90%)*365=36.5天
99 = 8760 * 1% = 87.6小时
99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟
99.9999= (1-99.9999%)*365*24*60*60=31秒
停机时间又分为两种,一种是计划内停机时间,一种是计划外停机时间,而运维则主要关注计划外停机时间。
- HPC:High-performance computing,高性能 www.top500.org
1.2 分布式系统
分布式存储: Ceph,GlusterFS,FastDFS,MogileFS
分布式计算:hadoop,Spark
分布式常见应用
- 分布式应用-服务按照功能拆分,使用微服务
- 分布式静态资源–静态资源放在不同的存储集群上
- 分布式数据和存储–使用key-value缓存系统
- 分布式计算–对特殊业务使用分布式计算,比如Hadoop集群
1.3 集群和分布式
集群:同一个业务系统,部署在多台服务器上。集群中,每一台服务器实现的功能没有差别,数据和代码都是一样的
分布式:一个业务被拆成多个子业务,或者本身就是不同的业务,部署在多台服务器上。分布式中,每一台服务器实现的功能是有差别的,数据和代码也是不一样的,分布式每台服务器功能加起来,才是完整的业务
分布式是以缩短单个任务的执行时间来提升效率的,而集群则是通过提高单位时间内执行的任务数来提升效率。
对于大型网站,访问用户很多,实现一个群集,在前面部署一个负载均衡服务器,后面几台服务器完成同一业务。如果有用户进行相应业务访问时,负载均衡器根据后端哪台服务器的负载情况,决定由给哪一台去完成响应,并且一台服务器垮了,其它的服务器可以顶上来。分布式的每一个节点,都完成不同的业务,如果一个节点垮了,那这个业务可能就会失败
1.4 集群设计原则
可扩展性—集群的横向扩展能力
可用性—无故障时间 (SLA service level agreement)
性能—访问响应时间
容量—单位时间内的最大并发吞吐量(C10K 并发问题)
1.5 集群设计实现
1.5.1 基础设施层面
提升硬件资源性能—从入口防火墙到后端 web server 均使用更高性能的硬件资源
多域名—DNS 轮询A记录解析
多入口—将A记录解析到多个公网IP入口
多机房—同城+异地容灾
CDN(Content Delivery Network)—基于GSLB(Global Server Load Balance)实现全局负载均衡,如:DNS
1.5.2 业务层面
分层:安全层、负载层、静态层、动态层、(缓存层、存储层)持久化与非持久化
分割:基于功能分割大业务为小服务
分布式:对于特殊场景的业务,使用分布式计算
1.6 LB Cluster 负载均衡集群
1.6.1 按实现方式划分
-
硬件
F5 Big-IP
Citrix Netscaler
A10 A10 -
软件
lvs:Linux Virtual Server,阿里四层 SLB (Server Load Balance)使用
nginx:支持七层调度,阿里七层SLB使用 Tengine
haproxy:支持七层调度
ats:Apache Traffic Server,yahoo捐助给apache
perlbal:Perl 编写
pound
1.6.2 基于工作的协议层次划分
-
传输层(通用):DNAT 和 DPORT
LVS:
nginx:stream
haproxy:mode tcp -
应用层(专用):针对特定协议,常称为 proxy server
http:nginx, httpd, haproxy(mode http), …
fastcgi:nginx, httpd, …
mysql:mysql-proxy, mycat…
1.6.3 负载均衡的会话保持
- session sticky:同一用户调度固定服务器
Source IP:LVS sh算法(对某一特定服务而言)
Cookie - session replication:每台服务器拥有全部session
session multicast cluster - session server:专门的session服务器
Memcached,Redis
1.7 HA 高可用集群实现
keepalived:vrrp协议
Ais:应用接口规范
heartbeat
cman+rgmanager(RHCS)
coresync_pacemaker
2 Linux Virtual Server简介
2.1 LVS介绍
LVS:Linux Virtual Server,负载调度器,内核集成,章文嵩(花名 正明), 阿里的四层SLB(Server Load Balance)是基于LVS+keepalived实现
LVS是全球最流行的四层负载均衡开源软件,由章文嵩博士(当前阿里云产品技术负责人)在1998年5月创立,可以实现LINUX平台下的负载均衡。
LVS 官网:http://www.linuxvirtualserver.org/
阿里SLB和LVS
https://yq.aliyun.com/articles/1803
https://github.com/alibaba/LVS
2.2 LVS工作原理
VS根据请求报文的目标IP和目标协议及端口将其调度转发至某RS,根据调度算法来挑选RS。LVS是内核级功能,工作在INPUT链的位置,将发往INPUT的流量进行“处理”
2.3 LVS集群体系架构
2.4 LVS 功能及组织架构
负载均衡的应用场景为高访问量的业务,提高应用程序的可用性和可靠性。
2.4.1 应用于高访问量的业务
如果您的应用访问量很高,可以通过配置监听规则将流量分发到不同的云服务器 ECS(Elastic Compute Service 弹性计算服务)实例上。此外,可以使用会话保持功能将同一客户端的请求转发到同一台后端ECS
2.4.2 扩展应用程序
可以根据业务发展的需要,随时添加和移除ECS实例来扩展应用系统的服务能力,适用于各种Web服务器和App服务器。
2.4.3 消除单点故障
可以在负载均衡实例下添加多台ECS实例。当其中一部分ECS实例发生故障后,负载均衡会自动屏蔽故障的ECS实例,将请求分发给正常运行的ECS实例,保证应用系统仍能正常工作
2.4.4 同城容灾 (多可用区容灾)
为了提供更加稳定可靠的负载均衡服务,阿里云负载均衡已在各地域部署了多可用区以实现同地域容灾。当主可用区出现机房故障或不可用时,负载均衡仍然有能力在非常短的时间内(如:大约30s中断)切换到另外一个备可用区恢复服务能力;当主可用区恢复时,负载均衡同样会自动切换到主可用区提供服务。
使用负载均衡时,您可以将负载均衡实例部署在支持多可用区的地域以实现同城容灾。此外,建议您结合自身的应用需要,综合考虑后端服务器的部署。如果您的每个可用区均至少添加了一台ECS实例,那么此种部署模式下的负载均衡服务的效率是最高的。
如下图所示,在负载均衡实例下绑定不同可用区的ECS实例。正常情况下,用户访问流量将同时转至发主、备可用区内的ECS实例;当可用区A发生故障时,用户访问流量将只转发至备可用区内的ECS实例。此种部署既可以避免因为单个可用区的故障而导致对外服务的不可用,也可以通过不同产品间可用区的选择来降低延迟。
如果采取如下图所示的部署方案,即在负载均衡实例的主可用区下绑定多台ECS实例,而在备可用区没有任何ECS实例。当主可用区发生故障时会造成业务中断,因为备可用区没有ECS实例来接收请求。这样的部署方式很明显是以牺牲高可用性为代价来获取低延时。
2.4.5 跨地域容灾
您可以在不同地域下部署负载均衡实例,并分别挂载相应地域内不同可用区的ECS。上层利用云解析做智能DNS,将域名解析到不同地域的负载均衡实例服务地址下,可实现全局负载均衡。当某个地域出现不可用时,暂停对应解析即可实现所有用户访问不受影响。
2.5 LVS应用场景
2.5.1 音视频大流量场景
对象存储(Object Storage Service,简称OSS),是阿里云对外提供的海量、安全和高可靠的云存储服务
音视频海量流量自动分发
音视频应用中由于用户与主播之间需要实时大量的互动,因此,用户的流量非常大,而直播业务的波峰波谷效应明显,这对整个系统的弹性、稳定性和可用性带来了巨大的挑战
提高横向扩展能力
添加或删减负载均衡后端的服务器实时生效,可根据业务流量大小实时增减
抵御海量流量
业务发展快,访问流量巨大,负载均衡可对多台云服务器进行流量分发服务
提升应用可用性
负载均衡提供后端服务器的健康检查,实时屏蔽异常服务器,提升系统可用性
2.5.2 网络游戏动静分离场景
动静请求分离,快速稳定交付
游戏业务有很多图片等静态资源需要加载,通过CDN实现全球用户访问静态资源的加速;当用户在游戏中有互动时,产生的访问流量非常大,此时为了保证互动实时性,需要使用负载均衡进行流量分发
动态请求流量分发
动态请求量大,采用多台云服务器计算处理,并利用负载均衡服务随时进行流量分发
静态请求快速加载
静态内容选择对象存储,接入CDN服务,进一步优化内容分发链路,让内容即刻加载
2.5.3 多层次容灾架构场景
跨地域跨可用区的容灾方案
用户业务遍布各地域,使用云解析DNS将不同地域用户智能解析访问到相应的业务系统内,使用负载均衡进行海量的访问流量分发,还可构建地域级、可用区级的多层容灾架构
智能解析
智能判断提供最佳的访问解析地址,使访问用户获得最快捷、最流畅的体验
流量分发
业务发展快,访问流量巨大,负载均衡可对多台云服务器进行流量分发服务
多层次容灾
云解析提供跨地域的高可用,负载均衡可实现可用区级的高可用
2.5.4 海量访问流量分发场景
2.6 LVS集群类型中的术语
VS:Virtual Server,Director Server(DS), Dispatcher(调度器),Load Balancer
RS:Real Server(lvs), upstream server(nginx), backend server(haproxy)
CIP:Client IP
VIP:Virtual serve IP VS外网的IP
DIP:Director IP VS内网的IP
RIP:Real server IP
访问流程:CIP <–> VIP == DIP <–> RIP
3 LVS 工作模式和相关命令
3.1 LVS集群的工作模式
- lvs-nat:修改请求报文的目标IP,多目标IP的DNAT
- lvs-dr:操纵封装新的MAC地址
- lvs-tun:在原请求IP报文之外新加一个IP首部
- lvs-fullnat:修改请求报文的源和目标IP
3.1.1 LVS的NAT模式
vs-nat:本质是多目标IP的DNAT,通过将请求报文中的目标地址和目标端口修改为某挑出的RS的RIP和PORT实现转发
(1)RIP和DIP应在同一个IP网络,且应使用私网地址;RS的网关要指向DIP
(2)请求报文和响应报文都必须经由Director转发,Director易于成为系统瓶颈
(3)支持端口映射,可修改请求报文的目标PORT
(4)VS必须是Linux系统,RS可以是任意OS系统
3.1.2 LVS的DR模式
LVS-DR:Direct Routing,直接路由,LVS默认模式,应用最广泛,通过为请求报文重新封装一个MAC首部进行转发,源MAC是DIP所在的接口的MAC,目标MAC是某挑选出的RS的RIP所在接口的MAC地址;源IP/PORT,以及目标IP/PORT均保持不变
DR模式的特点:
1.、Director和各RS都配置有VIP
2.、确保前端路由器将目标IP为VIP的请求报文发往Director
- 在前端网关做静态绑定VIP和Director的MAC地址
- 在RS上使用arptables工具
arptables -A IN -d $VIP -j DROP
arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP
- 在RS上修改内核参数以限制arp通告及应答级别
/proc/sys/net/ipv4/conf/all/arp_ignore
/proc/sys/net/ipv4/conf/all/arp_announce
3、RS的RIP可以使用私网地址,也可以是公网地址;RIP与DIP在同一IP网络;RIP的网关不能指向DIP,以确保响应报文不会经由Director
4.、RS和Director要在同一个物理网络
5.、请求报文要经由Director,但响应报文不经由Director,而由RS直接发往Client
6.、不支持端口映射(端口不能修改)
7.、无需开启 ip_forward
8.、RS可使用大多数OS系统
3.1.3 LVS的TUN模式
转发方式:不修改请求报文的IP首部(源IP为CIP,目标IP为VIP),而在原IP报文之外再封装一个IP首部(源IP是DIP,目标IP是RIP),将报文发往挑选出的目标RS;RS直接响应给客户端(源IP是VIP,目标IP是CIP)
TUN模式特点:
- RIP和DIP可以不处于同一物理网络中,RS的网关一般不能指向DIP,且RIP可以和公网通信。也就是说集群节点可以跨互联网实现。DIP, VIP, RIP可以是公网地址
- RealServer的tun接口上需要配置VIP地址,以便接收director转发过来的数据包,以及作为响应的
报文源IP - Director转发给RealServer时需要借助隧道,隧道外层的IP头部的源IP是DIP,目标IP是RIP,而
RealServer响应给客户端的IP头部是根据隧道内层的IP头分析得到的,源IP是VIP,目标IP是CIP - 请求报文要经由Director,但响应不经由Director,响应由RealServer自己完成
- 不支持端口映射
- RS的OS须支持隧道功能
应用场景:
一般来说,TUN模式常会用来负载调度缓存服务器组,这些缓存服务器一般放置在不同的网络环境,可以就近
折返给客户端。在请求对象不在Cache服务器本地命中的情况下,Cache服务器要向源服务器发送请求,将结
果取回,最后将结果返回给用户。
LAN环境一般多采用DR模式,WAN环境虽然可以用TUN模式,但是一般在WAN环境下,请求转发更多的被
haproxy/nginx/DNS等实现。因此,TUN模式实际应用的很少,跨机房的应用一般专线光纤连接或DNS调度
3.1.4 LVS的FULLNAT模式
通过同时修改请求报文的源IP地址和目标IP地址进行转发
CIP --> DIP
VIP --> RIP
fullnat模式特点:
- VIP是公网地址,RIP和DIP是私网地址,且通常不在同一IP网络;因此,RIP的网关一般不会指向
DIP - RS收到的请求报文源地址是DIP,因此,只需响应给DIP;但Director还要将其发往Client
- 请求和响应报文都经由Director
- 相对NAT模式,可以更好的实现LVS-RealServer间跨VLAN通讯
- 支持端口映射
注意:此类型kernel默认不支持
3.1.5 LVS工作模式总结和比较
NAT | TUN | DR | |
---|---|---|---|
Real Server | any | Tunneling | Non-arp device |
Real server network | private | LAN/WAN | LAN |
Real server number | low (10~20) | High (100) | High (100) |
Real server gateway | load balancer | own router | Own router |
优点 | 端口转换 | WAN | 性能最好 |
缺点 | 性能瓶颈 | 要求支持隧道,不支持端口转 换 | 不支持跨网段和端口转换 |
lvs-nat与lvs-fullnat:
- 请求和响应报文都经由Director
- lvs-nat:RIP的网关要指向DIP
- lvs-fullnat:RIP和DIP未必在