Chinaunix

标题: 请问LVS的具体性能？ [打印本页]

作者: keron 时间: 2005-12-18 23:55
标题: 请问LVS的具体性能？
公司准备施行集群方案，目前计划采用基于硬件的四层交换技术
不知道大家在实际使用中有没有测试过LVS系统在高并发情况下的性能表现（如并发1万个Http Connection）。
当然，具体性能表现取决与硬件配置

有没有哪位做过具体的压力测试，有具体硬件配置下的压力测试数据？

如果能用LVS替代硬件四层交换，那是最好不过了。

作者: nntp 时间: 2005-12-19 13:15
放心用吧，我有一个大家都知道的公司的典型案例,用的是lvs, 抗住了比你列的多好多的请求.
涉及商业信息不便透露.

作者: jamesb 时间: 2005-12-21 08:56
http://www.austintek.com/LVS/performance/，老了点，凑合着看吧

作者: gabriel.liao 时间: 2005-12-21 09:33
我也很关心LVS中的IP TUN和IP DR的性能,还有就是最多能够支持多少real server节点?如何计算？最好给点比较新的数据。

作者: jamesb 时间: 2005-12-21 10:03
ip dr可以支持200-300个节点，ip tun可以支持更多，基本上一般的集群没有问题

作者: gabriel.liao 时间: 2005-12-21 11:22
我可能要做256个节点，但是不知道前面的balancer是否可以支撑？并发流量大概能支持多少？有没有具体点的计算模型？如果不涉及保密的，尽量说说，这里先谢谢了。

作者: jamesb 时间: 2005-12-21 13:32
256个节点的钱你都可以出，花钱买个硬件的loading balancer不就行了，ft

作者: nntp 时间: 2005-12-21 14:18

原帖由 gabriel.liao 于 2005-12-21 11:22 发表
我可能要做256个节点，但是不知道前面的balancer是否可以支撑？并发流量大概能支持多少？有没有具体点的计算模型？如果不涉及保密的，尽量说说，这里先谢谢了。

这样规模的项目，不是你这样玩法的。需要专业人员作评估.

作者: nntp 时间: 2005-12-21 14:19

原帖由 jamesb 于 2005-12-21 13:32 发表
256个节点的钱你都可以出，花钱买个硬件的loading balancer不就行了，ft

买了后，万一不行呢? :")

作者: gabriel.liao 时间: 2005-12-21 14:19
如果能用便宜的方案当然就选择便宜的，但是不能因为便宜就不考虑它的性能和高可用性。256个节点都是廉价的PC，现在还不考虑纯粹在硬件上提高效率。

作者: gabriel.liao 时间: 2005-12-21 14:23
现在的确就是在积累经验，进行必要的理论验证，希望能够在实验的基础上确定LVS是否满足需要。

作者: nntp 时间: 2005-12-21 14:24

原帖由 gabriel.liao 于 2005-12-21 14:19 发表
如果能用便宜的方案当然就选择便宜的，但是不能因为便宜就不考虑它的性能和高可用性。256个节点都是廉价的PC，现在还不考虑纯粹在硬件上提高效率。

所以还是我前面说的，你的思路还是纯技术上的问题，用廉价PC当然可以，但是你知道256个节点的故障率会有多少么?

我前面提到的那个公司就是之前采用大量Dell的廉价PC 服务器(甚至还不是PC)，运营后，发现性能价格比的确是上去了，但是运营维护难度很大，业务响应和可用率随节点数增加线性下降，还有伴随原有结构带来的各种麻烦的问题。

我建议你们如果真的有这样规模的项目，找一个专业机构介入进行仔细的评估，从技术，运营，服务成本上进行分析，然后建立一个比较精确的业务模型.

这样规模的项目，如果脑子里面还是买几个机器，算算价格，然后测试几个软件的做法，是肯定玩不起来的.

作者: gabriel.liao 时间: 2005-12-21 14:41
对于256个节点，的确不可能一个阶段就可以完成，只是希望从一些理论数据和具体的案例终结一下LVS是否可以在256或者更多节点的规模内可以达到整个系统随着节点的增加而线性增长？balancer的负载是否也是线性增长的？

很感谢版主所说的很多潜在的风险，的确麻烦的问题很多很多，但是LVS因该不是这个问题的起因，而是这256个节点本身不可避免的客观原因，更重要的是架设在这256个节点上的系统是否能在这么多复杂的情况下正常运行，不过这已经是系统范围内的另外一个问题。

作者: nntp 时间: 2005-12-21 15:43

原帖由 gabriel.liao 于 2005-12-21 14:41 发表
对于256个节点，的确不可能一个阶段就可以完成，只是希望从一些理论数据和具体的案例终结一下LVS是否可以在256或者更多节点的规模内可以达到整个系统随着节点的增加而线性增长？balancer的负载是否也是线性增长的 ...

我想要问一下，一定要256个节点这么多才能够解决你们的负载分配的需求么?

如果有转发和处理效率更高的硬件+软件方案，是否可以缩减这样的规模来换取更好的可靠性和持续服务能力?从而降低部署和运营的成本?

作者: gabriel.liao 时间: 2005-12-21 16:24
主要是受系统的内存容量需求的限制，但是目前32位cpu的限制，一个进程只能访问3G的内存，所以最终目标就必须200个节点以上，即使具体实施没有这么多，目前这个阶段也必须进行必要的研究和验证。

作者: ljhb 时间: 2005-12-21 16:26
标题: 回复 15楼 gabriel.liao 的帖子
换64位

作者: gabriel.liao 时间: 2005-12-21 16:37
目前可能不会考虑64位系统，毕竟会涉及到原有系统32位到64位的移植工作，对于现有的项目影响太大，不仅是接口的影响，更重要的是原有系统内部的修改。如果需要修改原有很多系统的，那么就没有我现在这个项目的必要了。

作者: ljhb 时间: 2005-12-21 16:39
32位to64位就和吃饭一样简单

作者: gabriel.liao 时间: 2005-12-21 16:53
98,99年解决"千年虫"问题的时候可没有人说和吃饭一样容易。
32位到64位移植还是有很多未知问题的。

作者: nntp 时间: 2005-12-21 18:13

原帖由 gabriel.liao 于 2005-12-21 16:24 发表
主要是受系统的内存容量需求的限制，但是目前32位cpu的限制，一个进程只能访问3G的内存，所以最终目标就必须200个节点以上，即使具体实施没有这么多，目前这个阶段也必须进行必要的研究和验证。

现在的pc server都是em64t/amd64的了，你在这方便的信息有点滞后了.

em64t/amd64平台上可以访问更多的内存，就和你熟悉的ix86一样.

作者: foobar 时间: 2006-01-22 01:37
不过x86-64下运行的32位应用进程仍然只有4G的虚拟地址空间，如果需要更多，移植也是必须的。

作者: nntp 时间: 2006-01-22 21:14
备注一下, 确切地说是3.7GB :">

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)