LVS集群体系和调度算法

集群体系和调度算法

LVS集群体系架构

	1）使用LVS架设的服务器集群系统有三个部分组成：
		最前端的负载均衡层，用Load Balancer表示，
		中间的服务器群组层，用Server Array表示，
		最底端的数据共享存储层，用Shared Storage表示，
		在用户看来，所有的内部应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务。

	2） Load Balancer层：
		位于整个集群系统的最前端，有一台或者多台负载调度器（Director Server）组成，LVS模块就安装在Director Server上。
		Director的主要作用类似于一个路由器，它含有完成LVS功能所设定的路由表，通过这些路由表把用户的请求分发给Server Array层的应用服务器（Real Server）上。
		同时，在Director Server上还要安装对Real Server服务的监控模块Ldirectord，此模块用于监测各个Real Server服务的健康状况，在Real Server不可用时把它从LVS路由表中剔除，恢复时重新加入。

	3）Server Array层：
		由一组实际运行应用服务的机器组成，Real Server可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个，每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。
		在实际的应用中，Director Server也可以同时兼任Real Server的角色。

	4）Shared Storage层：
		是为所有Real Server提供共享存储空间和内容一致性的存储区域。
		在物理上，一般有磁盘阵列设备组成，为了提供内容的一致性，一般可以通过NFS网络文件系统共享数据。
		但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系统，例如Red hat的GFS文件系统，oracle提供的OCFS2文件系统等。

	5）从整个LVS结构可以看出：
		Director Server是整个LVS的核心，目前用于Director Server的操作系统只能是Linux和FreeBSD。
		linux2.6内核不用任何设置就可以支持LVS功能，而FreeBSD作为Director Server的应用还不是很多，性能也不是很好。
		对于Real Server，几乎可以是所有的系统平台，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。

LVS负载均衡调度算法

	负载调度器是根据各个服务器的负载情况，动态地选择一台Real Server响应用户请求，那么动态选择是如何实现呢，其实也就是我们这里要说的负载调度算法，根据不同的网络服务需求和服务器配置，IPVS实现了如下10种负载调度算法。

	根据其调度时是否考虑各RS当前的负载状态，分为两种：静态方法和动态方法
		静态方法：仅根据算法本身进行调度，包含有rr,wrr,sh,dh。
		动态方法：主要根据各RS当前的负载状态及调度算法进行调度，通过计算法RS当前的overhead值来进行选择，Overhead=value较小的RS将被调度，包含有lc.wlc,sed,nq,lblc,lblcr。

	rr:轮叫调度（Round Robin）
		“轮叫”调度也叫1:1调度，调度器通过“轮叫”调度算法将外部用户请求按顺序1:1的分配到集群中的每个Real Server上，这种算法平等地对待每一台Real Server，而不管服务器上实际的负载状况和连接状态。
		缺点：
			1.每台服务器的工作性能可能有差异，应该能者多劳，轮询没法达到这个效果。
			2.session无法保持，用第一次请求发送到A服务器，第二次请求发送到B服务器，这将是两个不同的会话。
	wrr：加权轮叫调度（Weighted Round Robin） 
		“加权轮叫”调度算法是根据Real Server的不同处理能力来调度访问请求。可以对每台Real Server设置不同的调度权值，对于性能相对较好的Real Server可以设置较高的权值，而对于处理能力较弱的Real Server，可以设置较低的权值，这样保证了处理能力强的服务器处理更多的访问流量。充分合理的利用了服务器资源。同时，调度器还可以自动查询Real Server的负载情况，并动态地调整其权值。
	lc：最少链接调度（Least Connections）
		“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最小连接”调度算法可以较好地均衡负载。
		overhead=active*256+inactive
		当计算结果相同时，就按照自上而下的轮询方式进行选择
	wlc：加权最少链接调度（Weighted Least Connections）（默认调度算法）
		“加权最少链接调度”是“最少连接调度”的超集，每个服务节点可以用相应的权值表示其处理能力，而系统管理员可以动态的设置相应的权值，缺省权值为1，加权最小连接调度在分配新连接请求时尽可能使服务节点的已建立连接数和其权值成正比。
		overhead=(active*256+inactive)/weight
		计算结果相同时，自上而下选择，一般首次所有Real Server都先轮询一遍，每个都处理一个请求，第二轮开始才发挥效果，但是第一次响应请求的有可能是性能最差的服务器（如果性能最差的服务器排在最上面的话）
	sed：最小期望延迟（Shortest Expections Delay）
		overhead=（active+1）*256/weight
		改进版的wlc，这种算法保证了是有权重最高的Real Server首先响应服务，而非初始计算值都是相同造成的轮询。但是，会出现权重大的Real Server过多负载，而权重小的Real Server过于空闲。
	nq：永不排队（Never Queue）
		此算法首次会按照权重挑选，由大到小轮询一遍，之后再按照sed算法来选择，避免了权重小的Real Server过于空闲。
	dh：目的地址哈希调度（Destination Hashing）
		以目的地址为关键字查找一个静态hash表来获得需要的Real Server。此算法一般在有多个防火墙时的场景下应用，在防火墙基于状态追踪的机制下，保证响应报文能够通过同一防火墙发送出去。
	sh：源地址哈希调度（Source Hashing）
		客户端的首次请求按照其他算法选择Real Server，后续请求只要是源地址相同都发送同一台Real Server，这样一定程度上解决了session的问题。
		即以源地址为关键字查找一个静态hash表来获得需要的Real Server。
		缺席：
			现在多数用户是通过snat方式访问互联网的，如一个上百台主机的局域网环境都指向同一个网关，所以对DR而言，源地址都是同一个，而实际上是来自不同客户端的请求，这些请求都经发送到一个Real Server上处理，会严重损害了负载的均衡效果。
	lblc：基于地址的最小连接数调度（Locality-Based Least-Connection）
		将来来自同一目的地址的请求分配给同一台Real Server，如果这台服务器尚未满负荷的话。
		否则分配给连接数最小的Real Server，并以它为下一次分配的首先考虑。
	lblcr：基于地址的带重复最小连接数调度（Locality-Based Least-Connection）
		对于某一目的地址，对应有一个Real Server子集。对此地址的请求，为它分配子集中连接数最小的Real Server。
		如果子集中所有的服务器均已满负荷，则从集群中选择一个连接数较小的服务器，将它加入到此子集并分配连接。若一定时间内，这个子集未被做任何修改，则将子集集中负载最大的节点从子子集删除。