设为首页 收藏本站
查看: 741|回复: 0

Windows下做7层软负载方案分析

[复制链接]

尚未签到

发表于 2015-5-9 09:19:15 | 显示全部楼层 |阅读模式
  对windows下做7层软负载做了一些分析,感觉最不靠谱的就是HttpWebRequest,这玩意实现太复杂,包装太深,而且也不是设计为发送大量出站HTTP连接用的,HttpListener应该还行,就是设计为做HTTP服务器用的,实在不行Proxy和RealServer之间用Remoting传递HTTP信息,然后两边把Remoting再转换成HTTP信息。
  大家有啥做7层软负载的经验可以讨论分享一下,最好是windows平台下的。
  
性能分析
  1、 对外网的连接管理和协议解析使用http.sys(HttpApi.dll,HttpListener)内置机制,http.sys在内核级别进行HTTP的连接管理和协议解析,性能应该可以保证。
  2、 对内网RealServer的连接管理和拼包使用HttpWebRequest的内置机制,但有如下问题
  a) 连接管理:默认Proxy向RealServer发送请求会新建立一个连接,收到应答后会拆除连接,也就是说Proxy和RealServer之间会建立大量连接,但是由于受端口(65535)限制,出站连接不可能太多。这个问题要想办法解决,可以尝试把RealServer启用KeepAlive解决。
  b) 拼包:HttpListener收到包后,虽然自动已经解析成对象,但是还要把这些包重新拼成HttpWebRequest的格式发给RealServer,这里面包括拷贝Uri,HttpHeader,Cookies,Body等,这些数据量挺大的,在内存中拷贝一遍肯定损耗性能。该问题应该无法规避。
  3、 如果是常规的web应用(资源访问类),Request小,Response很大,RealServer返回Response时还要经过Proxy,还要进行内存拷贝,这个也非常影响性能。然后7层又做不到LVS的那种DirectRoute机制(需要修改网络包的mac地址),实现IP隧道和TCP的状态迁移需要修改操作系统的TCP/IP协议栈。鉴于代价太大,该问题也无法规避。
  4、 Http协议规定请求和应答必须成对出现,默认情况下一条连接上发送出去请求后要等到收到该请求对应的应答后才能发送下一个请求,虽然Http1.1有pipeline功能,可以成批发送请求,不必先等待应答,但是也有诸多限制,比如规定了POST不应该使用pipeline,一条连接上第一次发送请求也不可以使用pipeline机制,还有每批请求的请求数也不好定夺,批量发送请求后,如果连接断开,会有多个请求失败,等等。HTTP协议不像SIP协议那样靠CallID和Cseq来匹配请求和应答,那样可以纯异步的收发请求和应答,所以在实现Http协议栈时要同步等待应答,然后该连接上才能发送下一批请求,这必然会影响性能。
  5、 HttpListener的异步接收请求和发送应答是普通的APM模式(BeginXXX,EndXXX格式),这种异步模式在频繁调用时会大量产生和销毁IAsyncRequest对象,从而增加了GC的压力,而且IAsyncRequest对象还没有提供自定义池化的接口。如果HttpListener提供了新的基于事件的异步模式(XXXAsync(eventargs)模式,参考Socket.ReceiveAsync方法)会解决这个问题。
  6、 另外由于HttpLisenter是.net的包装类,在用户态执行,而HTTP.SYS是内核态运行,在接受请求,返回应答会进行两次用户态和内核态之间的切换,从而降低性能,如果能在内核态直接进行7层转发就好了,在linux下LVS(KTCPVS)可以做到内核态的基于内容的7层转发,在windows下可能需要做TDI或者NDIS开发,查了些资料,太复杂了,所以也不考虑了先。
可靠性分析
  为了容灾,提高可靠性,考虑如下方案
  1. 7层软负载的前面要有4层负载设备,7层软负载多台,且共享哈希策略,4层设备按Session做随机负载,这样所有的7层软负载机器均可正确处理任何一个请求,且某台7层软负载宕机后,剩下的7层软负载可继续工作,由于4层负载有keepalive功能,可以检测出哪台7层软负载宕机了,并且不给其转发请求。
  2. 7层软负载做双击热备,7层软负载直接接入外网,正常情况下由主服务器处理请求,如果主服务器宕机,备份服务器发现后,通过ARP欺骗获取主服务器原有IP,以把请求吸引到备份服务器上处理(硬件如果支持可能可以考虑主备机共享一个MAC地址),主备切换时可能会造成短时请求失败的现象。
  综合考虑,第二个方案有些山寨和不保险,优先考虑第一个方案。
单元测试
  场景设计:
  比如一个获取用户头像的请求,用户的头像存放在多台DB里,并由多个web服务器(webserver1,webserver2)缓存头像并根据用户的HTTP请求返回给客户端用户头像,由于web服务器缓存了用户头像,是有状态服务,所以HTTP请求里要带userid参数,7层负载根据userid做哈希后把请求路由给缓存该userid对应用户头像的web服务器。
  请求格式:
  GET /getportrait.aspx?userid={userid}
  其中{userid}是Int32类型,路由算法是{userid} mod 2 = 0的话路由给webserver1 ,{userid} mod 2 = 1的话路由给webserver2
  应答格式:
  200 OK HTTP1.0
  Content-Length:5
  Content-Type:text/txt
  
  {userportrait}
  其中为了测试方便{userportrait}为文本格式,就是webserver本身的机器名字
  测试用例:
  请求GET /getportrait.aspx?userid=1111,预期返回应答webserver2
  请求GET /getportrait.aspx?userid=2222,预期返回应答webserver1
  具体测试userid可随机生成整数,并根据是否可被2整除对应答进行预期。
性能测试
  测试准备:
  两台物理机RealServer1和RealServer2,一台软负载机器SoftProxy,两台测试机TestClient1,TestClient2。
  其中SoftProxy的配置:Xeno 3.0G(16核),16G内存,windows2003 x64, 千M网卡(先不考虑双网卡均衡)。
  RealServer配置:Xeno 1.86G(4核),8G内存,windows 2003 x86
  部署:
  RealServer1和RealServer2部署具有返回用户头像的服务,SoftProxy部署7层软负载,TestClient1和TestClient2部署LoadRunner及测试脚本进行测试。
  测试模型:
  在线用户:300个虚拟用户,每个虚拟用户模拟1000客户端,共模拟300000在线用户,每个用户每5秒获取一次头像。
  测试预期:
  预期SoftProxy每秒处理6w的获取头像请求,并且CPU利用率在80%以下,内存利用率在5G以下。
其它问题
  1、 客户端IP
  a) 因为RealServer接收的是SoftProxy的请求,不能直接知道客户端IP,所以SoftProxy需要在转发包的时候加上一个http header以告诉客户端IP
  2、 重定向,身份验证,临时应答,缓存等问题
  a) httpRequest.ServicePoint.Expect100Continue = false;
  b) httpRequest.ServicePoint.UseNagleAlgorithm = false;
  c) httpRequest.AllowWriteStreamBuffering = false;
  d) httpRequest.AllowAutoRedirect = false;
  e) httpRequest.AuthenticationLevel = AuthenticationLevel.None;
  f) httpRequest.AutomaticDecompression = DecompressionMethods.None;
  g) HttpRequestCachePolicy noCachePolicy =  
  new HttpRequestCachePolicy(HttpRequestCacheLevel.NoCacheNoStore);
  httpRequest.CachePolicy = noCachePolicy;
  3、 Cookies咋办?
  a) HttpWebRequest并不支持直接写cookie,只能创建cookie容器,等应答回来后才会有cookies,这个比较郁闷,暂时如下这样写,收到RealServer的应答后把应答里的Cookies复制给Listenresponse并返回给客户端
  httpRequest.CookieContainer = new CookieContainer();
  HttpWebResponse httpResponse = (HttpWebResponse)httpRequest.GetResponse();
  listenresponse.Cookies = httpResponse.Cookies;
  4、 超时值,不好定夺
  a) httpRequest.Timeout = 20;
  b) httpRequest.ReadWriteTimeout = 10;
  
  参考连接
  通过IP隧道实现虚拟服务器(VS/TUN)
http://zh.linuxvirtualserver.org/node/27
通过直接路由实现虚拟服务器(VS/DR)
http://zh.linuxvirtualserver.org/node/28
HttpWebRequest性能问题
http://blog.myspace.cn/e/401154847.htm
内核中的基于内容请求分发
http://zh.linuxvirtualserver.org/node/76
http协议中connection头的作用
http://blog.iyunv.com/barfoo/archive/2008/06/05/2514667.aspx
介绍 http1.0 和 http1.1 区别 HTTP学习笔记 转
http://hi.baidu.com/shengit/blog/item/06691e62ee2967690c33fa1c.html
How to use cookie in HttpWebRequest?
http://social.msdn.microsoft.com/forums/en-US/netfxcompact/thread/6da34864-7768-46de-aa5e-f56a9a619e32/
What is HTTP pipelining?
http://www.mozilla.org/projects/netlib/http/pipelining-faq.html

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-65148-1-1.html 上篇帖子: 分享20款漂亮的Windows 7主题 下篇帖子: Windows Embedded Compact 7试用笔记(1)——新变化
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表