lvs系统
2015-10-16 19:28:36   0  举报             
     
         
 AI智能生成
  lvs系统分析
    作者其他创作
 大纲/内容
  设计原则    
     •可伸缩性(Scalability)  
     •高可用性(Availability)  
     •可管理性(Manageability)  
     •价格有效性(Cost-effectiveness)  
     ip负载均衡方式    
     Virtual Server via Network Address Translation(VS/NAT)    
     要求服务器池中机器供相同的网络服务、相同的内容  
     将报文的目标地址 Virtual IP Address改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最后将修改后的报文发送给选出的服务器  
     调度器在连接Hash 表中记录这个连接,当这个连接的下一个报文到达时,从连接Hash表中可以得到原选定服务器的地址和端口,进行同样的改写操作  
     我们在连接上引入一个状态机,不同的报文会使得连接处于不同的状态,不同的状态有不同的超时值    
     nat系统都是有超时时间的,一定时间不使用以后回收连接  
     在缺省情况下,SYN状态的超时为1分钟,ESTABLISHED状态的超 时为15分钟,FIN状态的超时为1分钟  
     缺点    
     通过改写来回包ip地址实现,回包也经过调度器    
     容易产生瓶颈,解决方法    
     在DNS混合集群系统中,有若干个VS/NAT负载调度器,每个负载调度器带自己的服务器集群  
     Virtual Server via IP Tunneling(VS/TUN)  
     Virtual Server via Direct Routing(VS/DR)  
     对于那些将IP地址或者端口号在报文数据中传送的网络服务,需要编写相应的应用模块来转换报文数据中的IP地址或者端口号  
     Virtual Server via IP Tunneling(VS/TUN)    
     解决nat回包都经过调度器,产生瓶颈的问题,使用ip隧道技术    
     将请求报文封装在另一个IP报文中,再将封装后的IP报文转发给选出的服务器  
     服务器收到报文后,先将报文解封获得原来目标地址为VIP的报文,服务器发 现VIP地址被配置在本地的IP隧道设备上,所以就处理这个请求,然后根据路由表将响应报文直接返回给客户  
     根据缺省的TCP/IP协议栈处理,请求报文的目标地址为VIP,响应报文的源地址肯定也为VIP,所以响应报文不需要作任何修改,可以直接返回给客户  
     缺点    
     所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议  
     Virtual Server via Direct Routing(VS/DR)    
     跟VS/TUN 方法相同,VS/DR利用大多数Internet服务的非对称特点,负载调度器中只负责调度请求,而服务器直接将响应返回给客户    
     调度器和服务器组都必须在物理上有一个网卡通过不分断的局域网相连  
     不修改也不封装IP报文,而是将数据帧的MAC地址改为选出服务器的MAC地址,再将修改后 的数据帧在与服务器组的局域网上发送  
     要求    
     要求负载调度器与实际服务器都有一块网卡连在同一物理网段上  
     服务器网络设备(或者设备别名)不作ARP响应  
     负载调度算法    
     IPVS在内核中的负载均衡调度是以连接为粒度的  
     算法    
     轮叫(Round Robin)    
     以轮叫的方式依次将请求调度不同的服务器  
     它无需记录当前所有连接的状态,所以它是一种无状态调度  
     容灾    
     我们引入了一个额外条件,当服务器的权值为零时,表示该服务器不可用而不被调度。  
     缺点    
     不适用于服务器组中处理性能不一的情况,而且当请求服务时间变化比较大时,轮叫调度算法容易导致服务器间的负载不平衡  
     比较    
     和dns方法相比,dns是单机维度的均衡,同一用户的不同连接都会被调度到不同的服务器 上,是连接维度,颗粒更细  
     加权轮叫(Weighted Round Robin)    
     它用相应的权值表示服务器的处理性能  
     加权轮叫调度也无需记录当前所有连接的状态,所以它也是一种无状态调度  
     缺点    
     当请求的服务时间变化很大,单独的加权轮叫调度算法依然会导致服务器间的负载不平衡  
     容灾    
     我们引入了一个额外条件,当服务器的权值为零时,表示该服务器不可用而不被调度。  
     最少链接(Least Connections)    
     算法是把新的连接请求分配到当前连接数最小的服务器  
     缺点    
     当各个服务器的处理能力不同时,该算法并不理想  
     加权最少链接(Weighted Least Connections)    
     加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例  
     基于局部性的最少链接(Locality-Based Least Connections)    
     目的    
     算法的设计目标是在服务器的负载基本平衡情况下,将相同目标IP地址的 请求调度到同一台服务器,来提高各台服务器的访问局部性和主存Cache命中率  
     算法    
     LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不 存在,或者该服务器超载且有服务器处于其一半的工作负载,则用“最少链接”的原则选出一个可用的服务器,将请求发送到该服务器  
     带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)    
     它要 维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射  
     LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器,映射该“热门”站 点到这台Cache服务器,  
     当该“热 门”站点的请求负载增加时,会增加集合里的Cache服务器,来处理不断增长的负载;当该“热门”站点的请求负载降低时,会减少集合里的Cache服务器 数目  
     目标地址散列(Destination Hashing)    
     通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器  
     源地址散列(Source Hashing)    
     它根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空  
     动态反馈负载均衡算法    
     TCP/IP流量的特征通俗地说是有许多短事务和一些长事务组成,而长事务的工作量在整个工作量占有较高的比例  
     http://www.linuxvirtualserver.org/zh/lvs4.html  
     内核Layer-7交换机KTCPVS    
     应用层负载均衡  
     通用体系结构     
     负载调度器(load balancer)    
     主从备份容灾  
     RR-DNS(Round-Robin Domain Name System)    
     不足    
     域名服务器分级缓存    
     缓存时间    
     长则定向到同一台,负载不均  
     为0则请求量大  
     用户缓存    
     滞留时间长短不一导致负载不均  
     可靠维护性差    
     单台机器故障,由于客户端缓存,处理时间久  
     客户端的解决方法    
     客户端收集多个服务器ip,自行均衡  
     向服务器发送负载查询,无响应则换机器重试    
     客户端量大,增加服务器负担  
     基于应用层负载均衡调度    
     通过分析应用层协议选择服务器,反向代理方式获得响应    
     伸缩性有问题,后端无法大规模扩容  
     针对不同应用协议需要重写服务器  
     服务器池(server pool)  
     共享存储(shared storage)  
     监视器,监视系统的状态  
     http://www.linuxvirtualserver.org/zh/lvs3.html  
    
 
 
 
 
  0 条评论
 下一页