理想负载均衡技术交流.pptx

  1. 1、本文档共33页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
理想负载均衡技术交流

;目录;管理性… 新业务、应用越来越多、简化因为众多的单点的安全产品带来的管理和运维的复杂度的问题,;分层架构:整个架构是分层的分布式的架构,纵向包括CDN,负载均衡/反向代理,web应用,业务层,基础服务层,数据存储层。水平方向包括对整个平台的配置管理部署和监控;负载均衡方案概述;支持基于tcp/ip连接的任务分配(4层负载均衡) 支持基于应用内容的任务分配(7层负载均衡) 支持负载均衡器自身的横向扩展 支持web集群的动态伸缩;服务发现 通过监听器主动发现服务器部署应用的四层和七层负载均衡服务,通过管理控制台集中管理。四层负载(ali-LVS)和七层负载tengine服务通过zookeeper注册到管理控制台。;目录;;探测模块功能: 实时动态加载节点:应用发布时注册到Zookeeper,由探测模块实时通知IPVS 动态反馈负载均衡:根据综合负载和当前权值,使用加权轮叫调度算法来调度新的请求连接 ;1、当用户向负载均衡调度器(Director Server)发起请求,调度器将请求发往至内核空间 2、PREROUTING链首先会接收到用户请求,判断目标IP确定是本机IP,将数据包发往INPUT链 3、IPVS是工作在INPUT链上的,当用户请求到达INPUT时,IPVS会将用户请求和自己已定义好的集群服务进行比对,如果用户请求的就是定义的集群服务,那么此时IPVS会强行修改数据包里的目标IP地址及端口,并将新的数据包发往POSTROUTING链 4、POSTROUTING链接收数据包后发现目标IP地址刚好是自己的后端服务器,那么此时通过选路,将数据包最终发送给后端的服务器;4层负载均衡-LVS/NAT;4层负载均衡-LVS/DR;1、当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP 。 2、PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链 3、IPVS比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层IP报文,封装源IP为为DIP,目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP,目标IP为RIP 4、POSTROUTING链根据最新封装的IP报文,将数据包发至RS(因为在外层封装多了一层IP首部,所以可以理解为此时通过隧道传输)。 此时源IP为DIP,目标IP为RIP 5、RS接收到报文后发现是自己的IP地址,就将报文接收下来,拆除掉最外层的IP后,会发现里面还有一层IP首部,而且目标是自己的lo接口VIP,那么此时RS开始处理此请求,处理完成之后,通过lo接口送给eth0网卡,然后向外传递。 此时的源IP地址为VIP,目标IP为CIP 6、响应报文最终送达至客户端;客户端属性 请求任意字段 Language URI Cookies HOST HTTP-Head;探测模块:应用负载探测,应用状态探测,结果上报应用管理器 应用管理平台:控制应用、根据应用负载设定通知云平台调整资源;技术实现说明: Session存在分布式共享池内,用户请求可以由负载均衡器随机分配服务器,访问在各个服务器之间切换无需重复生成session。 Session数据存在分布式共享池内,共享池由Redis集群来实现,不会出现单点故障。 Session存储在redis服务器,以sessionId为key,控制redis的key过期时间管理session的失效时间,客户端超过一定时间不再访问此session,则session到期自动失效。;流量控制:tengine流量编程式控制;;产品界面-负载均衡;产品界面-LVS集群;产品界面-Tengine流量编程控制;产品界面-Tengine集群;负载均衡性能指标:测试部署图;性能指标:单台tengine配置的性能测试;性能指标:LVS+tengine扩展性能测试;【 测试分析】 从此次测试可以看出,对同一个应用,完成同样次数的请求,经过varnish缓存比直连应用的提升较为明显,随着请求数增加,提升的幅度也增加。 100W次请求提升在9.6% 200W次请求提升在15.8% 300W次请求提升在32.8%;【 测试分析】 1、该测试所采用的应用仅包含一个113B大小的html文件。 2、由图一可看出对于单台pcserver来说,随着压力的增加,TPS提升。当TPS达到4W左右时,提升变得缓慢,达到瓶颈 3、由图二可分析,由于测试应用为纯静态的html文件,所以对服务器的CPU和内存消耗极小,可知瓶颈并不是由CPU或内存造成。;目录;My SQL Slave;负载均衡-容器集群;负载均衡-分布式WEB;谢 谢!

文档评论(0)

wyjy + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档