目前网络架构的缺陷

去年(12 年)我设计的方案在我们某一个机房跑了快一年,目前出现了很严重的性能问题。简单的讲就是交换机撑不住了,下面服务器流量稍微大点就开始丢包。当初为了节约成本的苦头终于吃到了。
我虽然不是专业搞网络的,但是一些基本的理论概念还是很清楚的,至于实践问题,看看文档,在正式上线之前把步骤都理清楚了,自然不会出什么大问题。我之前写了一个小系列的博客,纪录我们的那次升级,可以看看这里(1, 2, 3, 4) 。另外,该机房主要是用来跑 hadoop 的,数据量有多大可想而知。
说说目前存在的问题。
先说优点,当初设计的一个原则就是坚决走二层(核心、接入)的方案,而非传统的三层(核心、汇聚、接入)的方案,这个现在证明完全是正确的。首先都是内网,安全性问题可以放在后面考虑,二层扁平结构最明显的特点就是更小的收敛比,这个对于有大量数据传输的机房是很重要的;相比之下,传统的三层由于收敛比比较高,性能会收到一定的影响,比较时候园区等办公环境而不适合机房尤其是跑 hadoop 的环境。
接着是重点,缺点。目前是一台 2960S 下面挂 10 台 1G(没有做 bonding)的服务器,接入跟核心做的是 2G 的 channel。写到这里应该已经看出来了,这个收敛比还是比较大的,5:1。这个在初期还不是很明显,起初机器数量少,流量也少。但是随着机器数量的增加,情况就不一样了,每台服务器实际是跑不到 1G 的,以我们统计的图表来看,下图,平均一台 200M 左右,但是峰值基本都在 600M 左右,最终计算收敛比的话,还是以 600M 的峰值计算,最好的情况是 600M x 10 = 6G ,但是上面只有 2G 的可用带宽,不行,一种看上去行得通的办法是将 channel 进一步扩大,扩大到 6G,那就意味着一台 2960G 需要额外的 6 个端口来跟 3750X 上联,3750X 也需要由原先的 2 台扩展到 6 台。这也只能满足目前的需求,如果服务器的带宽进一步的往上跑,单台 3750X 的负载也需要进一步的加大,基本就没戏。上面这种方案并不能根本的解决问题。

所以比较根本的解决方案是直接上 N7K,下面可以考虑直接挂 N2K,或者通过先通过一层 N5K 再走 N2K,不管哪种方式,都能达到比较好的效果,收敛比达到 1:1 不在话下,并且应该能满足今后两年的需求。


要发现上面这些问题,除了通过在服务器上的监控数据采集得到的结果做分析之外,最简单的还是在上层的交换机上直接 show:

# show interfaces GigabitEthernet1/0/2
GigabitEthernet1/0/2 is up, line protocol is up (connected)

     reliability 255/255, txload 114/255, rxload 183/255

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2696237866

# show interfaces summary
 *: interface is up
 IHQ: pkts in input hold queue     IQD: pkts dropped from input queue
 OHQ: pkts in output hold queue    OQD: pkts dropped from output queue
 RXBS: rx rate (bits/sec)          RXPS: rx rate (pkts/sec)
 TXBS: tx rate (bits/sec)          TXPS: tx rate (pkts/sec)
 TRTL: throttle count

  Interface               IHQ   IQD  OHQ   OQD  RXBS RXPS  TXBS TXPS TRTL
————————————————————————-
* GigabitEthernet1/0/2     0     0    0 2696238164 724931000  83002 441240000  65852    0  

很明显的可以看到,Gi1/0/2 不管是 txload 还是 rxload 都已经很高的,OQD 也高的惊人。

  • wych

    哈 不久前看到这篇文章的,最近我们也碰到类似的网络架构问题