MSCDN一种实时流负载均衡+CDN方案设计

1.概述

MSCDN主要用于支持“CDN+负载均衡+集群服务+热切主备”功能。

1.1.CDN

当用户请求内容时,该内容能够由以最快速度向用户提供,这个挑选“最优”的过程就叫做负载均衡。 ​ CDN骨干点和CDN POP点在功能上不同,中心和区域节点一般称为骨干点,主要作为内容分发和边缘未命中时的服务点;边缘节点又被称为POP(point of presence)节点,CDN POP点主要作为直接向用户提供服务的节点。

1.2.负载均衡

两级调度体系分为全局负载均衡(GSLB)和本地负载均衡(SLB)。GSLB主要根据用户就近性原则,通过对每个服务节点进行“最优”判断,确定向用户提供服务的物理位置。SLB主要负责节点内部的设备负载均衡。 ​ 基于负载均衡的算法主要有三种:轮循(Round-Robin)、最小连接数(Least Connections First),和快速响应优先(Faster Response Precedence) ​ <1>轮循算法,就是将来自网络的请求依次分配给集群中的节点进行处理; ​ <2>最小连接数算法,就是为集群中的每台服务器设置一个记数器,记录每个服务器当前的连接数,负载均衡系统总是选择当前连接数最少的服务器分配任务; 这要比"轮循算法"好很多,因为在有些场合中,简单的轮循不能判断哪个节点的负载更低,也许新的工作又被分配给了一个已经很忙的服务器了。 ​ <3>快速响应优先算法,是根据群集中的节点的状态(CPU、内存等主要处理部分)来分配任务; 这一点很难做到,事实上到目前为止,采用这个算法的负载均衡系统还很少。尤其对于硬件负载均衡设备来说,只能在TCP/IP协议方面做工作,几乎不可能深入到服务器的处理系统中进行监测。但是它是未来发展的方向。

负载均衡常用的算法,基于以上负载均衡算法的使用方式上,又分为如下几种: 1.DNS轮询 ​ 最早的负载均衡技术是通过DNS来实现的,在DNS中为多个地址配置同一个名字,因而查询这个名字的客户机将得到其中一个地址,从而使得不同的客户访问不同的服务器,达到负载均衡的目的。 ​ DNS负载均衡是一种简单而有效的方法,但是它不能区分服务器的差异,也不能反映服务器的当前运行状态,因此当使用DNS负载均衡的时候,必须尽量保证不同的客户计算机能均匀获得不同的地址。 ​ DNS轮询的问题: ​ <1>额外的网络问题:由于DNS数据具备刷新时间标志,一旦超过这个时间限制,其他DNS服务器就需要和这个服务器交互,以重新获得地址数据,就有可能获得不同IP地址。因此为了使地址能随机分配,就应使刷新时间尽量短,不同地方的DNS服务器能更新对应的地址,达到随机获得地址,然而将过期时间设置得过短,将使DNS流量大增; ​ <2>故障热切换实时性慢:DNS负载均衡的另一个问题是,一旦某个服务器出现故障,即使及时修改了DNS设置,还是要等待足够的时间(刷新时间)才能发挥作用,在此期间,保存了故障服务器地址的客户计算机将不能正常访问服务器;

2.反向代理服务器 ​ 使用代理服务器将请求均匀转发给多台服务器,从而达到负载均衡的目的。 ​ 使用反向代理的好处是,可以将负载均衡和代理服务器的高速缓存技术结合在一起,提供有益的性能。 ​ 代理服务器本身虽然可以达到很高效率,但是针对每一次代理,代理服务器就必须维护两个连接,一个对外的连接,一个对内的连接,因此对于特别高的连接请求,代理服务器的负载也就非常之大,是随着并发连接数量的增加,代理服务器本身的负载也变得非常大,最后反向代理服务器本身会成为服务的瓶颈。

3.地址转换网关 ​ 支持负载均衡的地址转换网关,可以将一个外部IP地址映射为多个内部IP地址,对每次TCP连接请求动态使用其中一个内部地址,达到负载均衡的目的(硬件设备是局域网交换机)

  基于DNS解析方式 基于HTTP重定向方式 基于IP路由方式
性能 本地DNS服务器和用户终端DNS缓存能力使GSLB的负载得到有效分担 GSLB处理压力大,容易成为系统性能的瓶颈 借助IP网络设备完成负载均衡,没有单点性能瓶颈
准确度 定位准确度取决于本地DNS覆盖范围,本地DNS设置错误会造成定位不准确 在对用户IP地址数据进行有效维护的前提下,定位准确且精度高 就近性调度准确,但对设备健康性等动态信息响应会有延迟
效率 效率约等于DNS系统本身处理效率 依靠服务器做处理,对硬件资源的要求高 效率约等于IP设备本身效率
扩展性 扩展性和通用性好 扩展性较差,需对各种应用协议进行定制开发 通用性好,但适用范围有限
商用性 在Web加速领域使用较多 国内流媒体CDN应用较多 尚无商用案例

1.3.集群服务

基于Syncthing实现数据的同步,Syncthing是一个持续的时间同步程序,它在两台或多台计算机之间进行文件同步。可使用包mssyncthing.pkg进行在线安装,访问地址为http://IP:8384

1.4.热主备

1.4.1.主-主工作(Active-Active)

这是最常用的集群模型,支撑用户业务的应用程序在正常状态下分别在两台节点上运行,各自有自己的资源,比如IP地址、磁盘阵列上的卷或者文件系统。当某一方的系统或者资源出现故障时,就会将应用和相关资源切换到对方的节点上。 ​ 优点:不会有服务器的“闲置”,两台服务器在正常情况下都在工作; ​ 缺点:若有故障发生导致切换,应用将放在同一台服务器上运行,由于服务器的处理能力有可能不能同时满足数据库和应用程序的峰值要求,这将会出现处理能力不够的情况,降低业务响应水平;

1.4.2.主-从工作(Active-Standby)

为了提供最大的可用性,以及对性能最小的影响,主-从工作方式需要一个在正常工作时处于备用状态的节点,主节点处理客户机的请求,而备用节点处于空闲状态,当主节点出现故障时,备用节点会接管主节点的工作,继续为客户机提供服务,并且不会有任何性能上影响。两节点的Active/Standby模式是HA中最简单的一种,两台服务器通过双心跳线路组成一个集群。应用Application联合各个可选的系统组件如:外置共享的磁盘阵列、文件系统和浮动IP地址等组成业务运行环境。 ​ 缺点:Node2在Node1正常工作时是处于“闲置”状态,造成服务器资源的浪费; ​ 优点:当主服务器发生故障时,从服务器能完全接管应用,并且能保证应用运行时的对处理能力要求;

2.服务器控制模块

服务中文名称 服务英文缩写及全名称
任务处理和内容分发服务 STPCD- Task Processing and Content Distribution Service
负载均衡服务 SLB- Load Balancing Service
内容分发网络 CDN-Content Distribution Network
集群同步服务 SCS-Cluster Synchronization Service
热主备服务 SHB-Hot backup service
本地服务器 LS-Local Server

2.1.服务器控制概述

MSCDN是一套内容分发网络服务,主要包括:负载均衡模块,任务处理和内容分发模块,集群同步模块和热主备模块。 负载均衡模块 ​ 负载均衡模块包括2级调度体系分为全局负载均衡(GSLB)和本地负载均衡(SLB)。全局负载均衡(GSLB)采用”DNS服务方式“进行负载的横向扩容,而采用“位置调度算法机制”计算最优路径,采用”HTTP重定方式“向请求方提供本地负载均衡(SLB)的访问地址,由本地负载均衡(SLB)提供具体的业务服务。本地负载均衡(SLB)采用采用“最优性能+轮循算法”计算最终提供服务的内部服务器地址,采用”HTTP重定方式“向请求方提供该内部服务的访问地址。 任务处理和内容分发模块 ​ 任务处理和内容分发模块主要提供"任务命令的接收和处理+任务同步+流分发同步"的业务功能。任务命令采用UDP(JSON)或标准的HTTP(JSON)方式,包括GET和POST方法。任务同步包括IP命令任务和配置命令任务。直播流分发同步主要包括:主动推送UDP/RTP直播流,RTSP推流节目名同步信息,HLS输出同步信息等;

集群同步模块 ​ 主要用于流媒体版本更新的同步,版本更新仅需要更新STPCD节点,即可实现整个网络版本的更新操作。

热主备 ​ 采用主从工作方式,主要用于对关键节点进行冗余备份;

2.2.服务器控制功能

DNS服务 ​ 通信方式:无需通信 ​ 主备方案:无需主备 ​ 提前配置:将DNS和需要使用的GSLB节点的地址做好映射关系; ​ 实现方式:采用本地搭建DNS服务器(局域网)或购买域名(公网)的方式。本地搭建DNS服务器可采用”BIND软件“(安装包msdnsserver.pkg进行在线安装); ​ 新增节点:手动配置后,重启服务生效;

GSLB ​ 通信方式:UDP(JSON)或标准的HTTP(JSON)方式,包括GET和POST方法; ​ 主备方案:无需主备 ​ 提前配置:SLB节点通信的IP地址和端口; ​ 向上功能:<1>进行业务服务"最优路径"的调度选择; ​ 向下功能:<1>根据SLB节点的心跳信息:监测SLB节点的状态信息(版本、性能等),自动发现和注册新增加的SLB节点(密码配:msgslb,msos123gslb);

STPCD ​ 通信采用UDP(JSON)或标准的HTTP(JSON)方式,包括GET和POST方法。进行必要时需要进行主备部署,提供"任务命令的接收和处理+任务同步+流分发同步"的业务功能。任务命令采用UDP(JSON)或标准的HTTP(JSON)方式,包括GET和POST方法。任务同步包括IP命令任务和配置命令任务。直播流分发同步主要包括:主动推送UDP/RTP直播流,RTSP推流节目名同步信息,HLS输出同步信息等;

通信方式:UDP(JSON)或标准的HTTP(JSON)方式,包括GET和POST方法; ​ 主备方案:主从工作模式,主从使用keepalived进行主备热切,采用SYNCTINHG保存必要文件同步,使用内部连接保持任务信息的实时同步; ​ 提前配置:<1>SLB节点通信的IP地址和端口; ​ 向外功能:<1>接收并处理来自应用层的任务指令; ​ 向内功能:<1>根据SLB节点的心跳信息:监测SLB节点的状态信息(版本、性能等);<2>自动发现和注册新增加的SLB节点(密码配:msstpcd,msos123stpcd);<3>被动向SLB节点提供任务同步信息;<5>主动向SLB节点进行流分发;<3>主动向SLB节点发送来自应用层的任务指令;

SLB ​ 通信方式:UDP(JSON)或标准的HTTP(JSON)方式,包括GET和POST方法; ​ 主备方案:主从工作模式,主从使用keepalived进行主备热切,使用内部连接保持任务信息的实时同步; ​ 提前配置:<1>STPCD节点的IP地址和端口;<2>GSLB节点的IP地址和端口;<3>LS节点通信的IP地址和端口;<4>LS节点流访问IP地址和端口; ​ 向外功能:<1>接收并处理来自STPCD节点的任务指令;<2>进行业务服务"最优路径"的调度路径选择;<3>向GSLB和STPCD节点上报状态信息(版本、性能等);<4>主动从STPCD节点进行任务同步; ​ 向内功能:<1>根据LS节点的心跳信息:监测LS节点的状态信息(版本、性能等);<2>自动发现和注册新增加的LS节点(密码配:msslb,msos123slb);<4>被动向LS节点提供任务同步信息;<5>主动向LS节点进行流分发;<3>主动向LS节点发送来自上级的任务指令;

LS ​ 通信方式:UDP(JSON)或标准的HTTP(JSON)方式,包括GET和POST方法; ​ 主备方案:无需主备 ​ 提前配置:SLB节点的IP地址和端口; ​ 向外功能:<1>向SLB节点上报状态信息(版本、性能等);<2>提供业务服务(RTSP/HTTP/HLS/RTMP等);<3>主动从SLB上同步任务信息; ​ 向内功能:无;

集群管理机制 ​ 同步管理:采用"逐级同步,主备切换"的机制。LS节点同步上级SLB节点,SLB节点同步STPCD主被工作节点,STPCD备节点同步主节点; ​ 升级管理:采用"智能分级治理"的机制。使用SYNCTHING进行升级文件的自动同步。对STPCD进行升级时,将产生软件版本文件,通过SYNCTHING同步分发到下级服务器后,相应软件检测到版本号有更新时,自动重启软件完成集群升级服务; ​ 任务管理:采用"逐级下发,分级治理"的机制。通过将任务指令发送给STPCD,STPCP将任务指令主动发给各个SLB节点(内部流不处理),各个SLB节点再将任务下发到内部的各个LS节点(内部流不处理); ​ 分发同步:采用"逐级下发,分级治理"的机制。通过将”RTP/UDP流“推动给STPCD,STPCP将”RTP/UDP流“动分发到各个SLB节点,各个SLB节点再将”RTP/UDP流“分发到内部的各个LS节点; ​ 配置管理:采用"逐级下发,分级治理"的机制。建立集群专用指令,进行集群更新服务; ​ 节点自动注册:

2.3.协议机制

UDP ​ 通信模型:P2P模型; ​ 优点:程序改动小,实现方便,基于现有的通信接口; ​ 缺点:需要提前知道通信对方的IP和端口,且UDP是不可靠协议; ​ 状态实现:由监测方主动发起监测指令,被监测方进行实时状态的回复; ​ 指令同步实现:本级将自身现有的任务与上级对比,若上级不存在则删除该任务。上级将自身现有的任务与下级对比,若下级不存在则删除该任务;

TCP ​ 通信模型:C/S模型; ​ 优点:TCP协议本身是可靠协议,通信有保障,且穿透力强; ​ 缺点:需要维护下级的连接状态,代码重新开发; ​ 状态实现:由下级进行心跳将自身状态发给上级,上级进行实时状态的回复; ​ 指令同步实现:下级将自身现有的任务与上级对比,若上级不存在则删除该任务。上级将自身现有的任务与下级对比,若下级不存在则删除该任务; HTTP ​ 通信模型:P2P模型; ​ 优点:程序改动小,实现方便,基于现有的通信接口,通信有保障,且穿透力强; ​ 缺点:需要提前知道通信对方的IP和端口; ​ 状态实现:由监测方主动发起监测指令,被监测方进行实时状态的回复; ​ 指令同步实现:本级将自身现有的任务与上级对比,若上级不存在则删除该任务。上级将自身现有的任务与下级对比,若下级不存在则删除该任务;

发布了91 篇原创文章 · 获赞 28 · 访问量 15万+

猜你喜欢

转载自blog.csdn.net/weixin_35804181/article/details/102611207