构建一台大容量的NAT服务器

xuledw

收藏 http://linux.chinaunix.net/bbs/v ... d=753474&extra=
接着去年的这个主题

ssffzz1

这个应该是不会的。这个超时是空闲超时，当有流量通过的时候应该刷新计时器的。

ippen

原帖由 ssffzz1 于 2008-7-8 06:18 发表
首先感谢IPPER的大作。但是我也有如下疑问：

1、并发连接数大约16万。这个测试过吗？外网的地址池配置了几个地址啊？
2、后来IPPER说最大并发连接数达到26万，这个又是怎么计算出来的哦。

1.并发连接数16万，系统工作非常稳定，不仅是测试，而且在实际使用中，目前用了超过10台这样的服务器，nat高峰时，流量接近2G，基本上，每台服务器配8个ip
2.并发连接26万是我用过的最大值，不过在这样的负载下，服务器容易受突发流量的影响，所以建议用到16万并发连接，这个不是计算出来，是试验得到的

ippen

原帖由 独孤九贱 于 2008-7-8 12:06 发表


对于大容量NAT服务器，发表一下个人看法，仅供大家拍砖。

1、主要思路还是加大hash表容量，缩短连接超时时间等等——因为剩下的就是优化hash表的建立、查找算法等等了，但是这些不是使用者做的，希望Net ...

1. 开发者考虑的问题不仅是网络，还有其他的应用，所以程序未必能按你的想法进行开发，所以自己做的一些参数调整有时是非常重要的。有的时候，我也不能理解开发者的意图，例如：ip_conntrack_max 和buckets这两个值，为什么定义buckets是内存的1/16384？为什么内存大于1G，buckets被固定为8192？为什么一个buckets对应8个ip_conntrack？不能是4个？16个？32个？是否能优化？上面的这些参数，我曾经编译内核测试过，没有发现有区别，原作者如何定这些参数，到目前为止我都很想了解
2. 高容量确实容易出现问题，也不能一味提高硬件性能来解决，很多时候用分流的方法更有效。提高硬件性能，到了一个极限，如我用到26万并发连接时，系统已经趋于不太稳定了，在当时的情况下，cpu的负载才16%左右，所以提高硬件性能帮助有限
3. 多核的情况我已经测试过了（用centos4.3和centos4.6的内核测试），比单核还差，即使邦定网卡，效率也是不如单核，所以我强调只用up的内核，不要用smp的内核
后两点赞同九溅兄的看法，不过还是那个问题，linux的netfilter部分的设计不仅仅是NAT，还有其他因素，如果希望将nat单独提出来，估计短期内实现不了了

ssffzz1

哦，如果地址池配到8个IP能够达到16W的话，这个就没什么不对了。主要是我看你的范例好像只配了一个地址而已。

kevin.tan

原来的tcp_timeout_established是5天，这个数值太大了，很容易造成内存过度占用，导致系统死机，将其改为如下，

1. 
   
2. unsigned long ip_ct_tcp_timeout_established = 5 MINS;
   

复制代码

将tcp_timeout_established改为5分钟之后，是不是太短，会不会出现如一个ssh连接time_wait超过5分钟而断掉的情况，

又或是一个tcp连接的网游当使用者未使用超过5分钟，而需要重新登入的情况？

独孤九贱

这个应该是不会的。这个超时是空闲超时，当有流量通过的时候应该刷新计时器的。

同意，不过超时时间也不能设置来一味的短，否则也得不尝失。

开发者考虑的问题不仅是网络，还有其他的应用，所以程序未必能按你的想法进行开发，
所以自己做的一些参数调整有时是非常重要的。有的时候，我也不能理解开发者的意图，
例如：ip_conntrack_max 和buckets这两个值，为什么定义buckets是内存的1/16384？
为什么内存大于1G，buckets被固定为8192？为什么一个buckets对应8个ip_conntrack？
不能是4个？16个？32个？是否能优化？上面的这些参数，我曾经编译内核测试过，没有发现有区别，
原作者如何定这些参数，到目前为止我都很想了解

hash桶的大小的选择，做为内核开发者，考虑到与其它子系统的相对平均的分享内存，所以一般都没有设置来为太大。其它子系统，
同样如此。如果内核专门拿来做NAT服务器，把这个值加大是无可厚非的——因为这在种应用中，其它子系统应用是非常少的（例如文件子系统等等）。
hash链的大小：因为链太长，意味着搜索时间有可能会很长。这也是个折衷值而已，我想对于小规模应用， 设为4 - 8，是正常的，对于大规则应用，8 - 16则也是可以接受的，而太长,> 32的值，则要留待实验去检验了。
不过这也跟实际的包的特征有很大的关系，举个例子，把来源地址随机分布，让hash表上到100W。偶的100Mb 线速转发的机器一下子就下降到 2- 3Mb了。

2. 高容量确实容易出现问题，也不能一味提高硬件性能来解决，很多时候用分流的方法更有效。
提高硬件性能，到了一个极限，如我用到26万并发连接时，系统已经趋于不太稳定了，在当时的情况下，
cpu的负载才16%左右，所以提高硬件性能帮助有限

是这样的。因为并不是每个网络都可以分流的，所以提升硬件配置是不得已而为止。这里的硬件配置不仅指CPU，也包含内存、总线，网卡……无论如何，这些还是挺立杆见影的 ——— 但正如你所讲的，这是在一定负载下面，当到了一定程度，硬件的提升带来性能的提升空间就很小了。

3. 多核的情况我已经测试过了（用centos4.3和centos4.6的内核测试），比单核还差，即使邦定网卡，效率也是不如单核，
所以我强调只用up的内核，不要用smp的内核。

Netfilter多对核的支持的确不太好，也许正在改进中吧，但这毕竟不是一件简单的事情。不过我想问的是网卡中断亲和性的问题，不知哪位朋友有没有试过在这种条件下，是否会提升网卡的吞吐性能（因为毕竟不设置，多核就相当于单核在用了）？

xuledw

原帖由 ippen 于 2008-7-8 22:07 发表


1.并发连接数16万，系统工作非常稳定，不仅是测试，而且在实际使用中，目前用了超过10台这样的服务器，nat高峰时，流量接近2G，基本上，每台服务器配8个ip
2.并发连接26万是我用过的最大值，不过在这样的负 ...

想请教下这8个IP
是单个网卡配置了8个ip?(虚拟的多ip对性能有影响么，如果我虚拟了多个ip那么实际的流量压力是不是还是集中在了我的这单个网卡上了) 通过/root/nat这个文件好像是只用了两块网卡。
iptables -t nat -A POSTROUTING -s 内部IP地址/子网 -o $OUTGOING -j SNAT --to $IPPOOL
这样能实现负载均衡么？不知这么说确切么 就是说能判断出那个$IPPOOL负载小空闲而通过其对应的ip出局么

如果是多个内部子网的话 iptables 的POSTROUTING应该怎样写更好些
iptables -t nat -A POSTROUTING -s 内部IP地址/子网1 -o $OUTGOING -j SNAT --to $IPPOOL
iptables -t nat -A POSTROUTING -s 内部IP地址/子网2 -o $OUTGOING -j SNAT --to $IPPOOL
吗？

ssffzz1

错第二种写法，应该只有第一个起作用。如果要配置池，哪么要写到一行上。IPTABLES是顺序匹配的。一般来说一个IP的connect数目不会超过4W。

xuledw

原帖由 ssffzz1 于 2008-7-9 11:14 发表
错第二种写法，应该只有第一个起作用。如果要配置池，哪么要写到一行上。IPTABLES是顺序匹配的。一般来说一个IP的connect数目不会超过4W。

谢谢 知道了
内部IP地址/子网1
内部IP地址/子网2这样写确实不对。优先匹配了
我的意思是内网接口多个（走不同的网段）的情况下 那样写可以吗?
iptables -t nat -A POSTROUTING -s A私 -o $OUTGOING -j SNAT --to $IPPOOL
iptables -t nat -A POSTROUTING -s C私 -o $OUTGOING -j SNAT --to $IPPOOL

[ 本帖最后由 xuledw 于 2008-7-9 12:03 编辑 ]