目前网络架构的缺陷

去年(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 也高的惊人。

北京的空气质量(三)

用了一年的 3M 口罩,效果没话说,最初用的头戴式的 9004,没有呼吸阀,感觉也不是特别的密封,冬天戴在眼镜上容易有水汽;后来一段时间换成了 9332,N99 级别的,戴上去效果还不错,不过成本相对来说提高了不少;再后来的很长一段时间用的就是现在戴的这个 9041,耳戴式的,虽然没有呼吸阀门,但是口罩的顶端有一个金属鼻夹,所以密封性还不错,成本也控制在了合理的范围之内。

上面所有的这些装备在我读完了 Richard Saint Cyr 医生写的《Air pollution masks: A review of the best》之后被我抛弃了。文章里面比较了四个口罩,除了经典 3M 之外,一个叫 totobobo 透明口罩引起了我的极大兴趣,调研之后就发现真是各种优点:

  • 塑料(不是很确定)的材质,贴在脸上比 3M 的更加舒服
  • 不漏气,这也就意味着现在这个天气佩戴眼镜里面没有水汽
  • 不会像 3M 那种棉织材料一样带久了会有口水之类的混合味道
  • 外层的 mask 可一直使用,要换的只是两片 N96/N94 的 filter

基本是解决了目前 3M 存在的一些问题,然后立马下单买了一个。用了一周之后发现真是完暴 3M,每天的平均价格跟 9332 的差不多,mask 算是一次性的投资,接下来换 N96 的 filter 就好了,大陆这边平均下来换一次的成本在 20RMB 左右,可以使用一到两周的样子。

第一组 filter 我连续用了 9d,下面是连续几天的照片纪录,效果非常明显。

Continue reading

北京的空气质量(二)

两年前那会儿住中关村鼎好附近,最大的感受是杯子里面的水早上出去的时候还蛮清澈的,晚上下班回来会明显的发现水杯里飘了一层灰。地面、家具几天不扫也会到处都是灰。后来搬到牡丹园这边之后,情况更加的明显。下面用数据说话。

10 月买了台扫地机,第一次扫我屋子(20平)之前,我用扫帚扫了一遍,最起码肉眼看不到灰尘了。结果了?扫了满满 15 杯的灰尘,还好我没让这机器人扫整个屋子,要是这两室一厅扫下来,这机器人估计会自插双目了,每次报警提示集尘盒满了,打开盒子就像下面这个样子。

整整 15 杯的灰尘

Continue reading

Cisco Nexus 5000/7000 概览

Cisco 原厂前段时间送了两台 N5K 的拿过来测试,加上之前幸见到了 N7K 的真身,抽空测试过一段时间,再加上本身比较喜欢玩玩新玩具,于是对 Nexus(主要集中在 5K/7K) 系列做了个大致的了解,供参考。
具体的零部件参数就不在这里展开列举了,官方的比如 Nexus 7000 Series Switches Data Sheet 等都能看到。有几个重要的模块提一下,主要包括:
* chassis
* fabric modules, fabric-2 modules
* supervisor module, second-gen supervisor, supervisor 2E
* I/O module(M/F), F1-F3, M1-2
* power
* fan

印象比较深的是,4 槽的可用性不是很大,除非你的 rack 少的可怜,但是服务器的网卡流量又不小(千兆的平均每台在 300Mbps 以上),更多的是 9、10 槽的型号。包的转发速率已经是以 b(billion)来计的了,所以,性能几乎不是问题。
另外,10 槽的还可以 air filter,这一个 filter 的价格就超过 honeywell 的高端型号了。

每个型号的功耗都不小,10 槽的最大会消耗 7.5KW 左右,这个一般的机柜都没有这么大的电流。因此这个是必须要考虑的一个问题,不然放到 rack 上会悲剧。所幸的是,官方列举的都是最大的功耗,根据之前的经验,实际的按照 2/5-3/5 的最大功耗算就足够了,前提是你的机器不是顶配。

最明显的变化是硬件架构的变化,Intel Xeon 的处理器,内存以条数计算,跟机架式服务器有那么点类似,可以进行增减操作,所以从这种角度来看,更像一台多网卡的服务器。
另外,OS 也彻底的换成了基于 Linux 的 NexusOS,进去之后感觉是那么的亲切,可以看最后的几张截图。

要使用某项功能或者说某个协议,更之前的 IOS 完全不一样,在使用之前需要先激活其对应的进程,然后才可以使用,这是不是借鉴了 Linux 下类似 chkconfig 的做法,不用的就关闭需要使用的就开启。既然能做到开启关闭也就能做到进程的重启,比如 OSPF 的重启等等。

此外,安全性也得到了很大的提升。比如默认开启了 SSHv2,而关闭了老掉牙的 telnet。 RBAC 跟 AAA 协同,提供了更细粒度的访问控制。

最后,新出了一个叫 CMP 的功能,有点类似服务器上的管理卡,使用专用的处理器、内存等,相当于一个独立的 OS,使用他就能实现所有包括电源在内的所有系统组件的重启等操作。是不是很方便。

至于软件上的创新,我认为最大的出彩的地方就是 VDC(Virtual Device Contexts),其实就是把一台物理机划分成了最多 4 个 VM(VDC),他们之间可以划分 port、vlan、portchannel 之类的东西。好处不用多说了,资源的隔离,HA 等等。

虽然 Nexus 早在 08 年最推出了,但是也就近一两年(12, 13)才在大陆市场推广开来,而像 N7700 系列从我最早(01/2013)开始关注到现在(08/2013),大陆还未正式发行。不过真的大规模的使用起来,不知道又要甩 huawei  几条街了。

最近几年炒的特别的火的大数据也确实诞生了不少的新技术,比如像 OpenFlow, SDN 等等,N7K 对其的支持都确实不错。

Continue reading

读取 /proc/net/tcp 的问题

不愿意看过程的直接跳到本文的最后吧。
虽然很多时候我们知道,出来混要还这句话,但是,不得不承认的是,很多时候都是到病入膏肓的时候才来解决问题。比如下面要说的由 netstat 引起的问题。
如果经常处理一些连接数很多的机器就会发现,使用 netstat 查看当前状态,返回的结果会非常的慢,有时候可能 1m 都返回不了结果。比如下面这个最经典的命令:
$ time sudo netstat  -tunlp
Active Internet connections (only servers)

tcp        0      0 x.x.x.x:80              0.0.0.0:*               LISTEN      1278/nginx      

real    0m12.846s
user    0m0.300s
sys     0m12.490s

上面这个就花了 13s 来返回结果。通过 strace 跟踪发现,netstat 的 input 就是 /proc/net/tcp:
$ sudo strace netstat -tunlp

open("/proc/net/tcp", O_RDONLY)         = 3
read(3, "  sl  local_address rem_address "…, 4096) = 4050
read(3, "  26: A11A91D5:0010 5B248875:7E7"…, 4096) = 4050
read(3, "  53: A11A91D5:0010 EF1C0CAB:C7A"…, 4096) = 4050
read(3, "  80: A11A91D5:0010 4D1E8875:3AD"…, 4096) = 4050
read(3, " 107: A11A91D5:0010 6525CFDD:C1A"…, 4096) = 4050
read(3, " 134: A11A91D5:0010 C2EF53DF:82F"…, 4096) = 4050
read(3, " 161: A11A91D5:0010 62803571:585"…, 4096) = 4050

因此如果该文件的条目非常的多(10w+),经常要等几十秒得到结果也就很正常了。

很不幸的是,zabbix 使用的 net.tcp.listen 这个 item 调用的就是 /prco/net/tcp 这个文件,通过做匹配获取指定的端口,速度可想而知。 造成的结果是经常在 1min 内拿不到数据,造成报警。具体的代码可以到 src/libs/zbxsysinfo/linux/net.c 定义的 NET_TCP_LISTEN 函数去 grep 一下。

而很早之前,我就介绍过一篇使用 ss 来取代 netstat 的博客。跟 netstat 最大的不同就是读取的文件不同,因而速度也快的多。看 ss 的 man 可以发现,ss 调用的是 tcp_diag 模块,这个模块具体怎么操作的不是很清楚,我更关心的是他是如何提升效率的。要实现跟上面一样的效果,像下面这样就可以了:
$ sudo ss -lp | grep mongo
0      128                          *:27700                         *:* users:(("mongod",3187,10))
0      128                          *:27701                         *:* users:(("mongod",2050,13))
0      128                          *:27703                         *:* users:(("mongod",20278,12))
0      128                          *:27704                         *:* users:(("mongod",20379,13))
0      128                          *:27705                         *:* users:(("mongod",2099,12))
0      128                          *:27706                         *:* users:(("mongod",11363,12))
0      128                          *:27707                         *:* users:(("mongod",2293,12))
0      128                          *:28700                         *:* users:(("mongod",3187,11))
0      128                          *:27708                         *:* users:(("mongod",2428,12))
0      128                          *:27709                         *:* users:(("mongod",2442,13))
0      128                          *:28701                         *:* users:(("mongod",2050,14))
0      128                          *:27710                         *:* users:(("mongod",2779,12))
0      128                          *:28703                         *:* users:(("mongod",20278,14))

格式化不是很好,tr 处理一下就好了:
$ sudo ss -lp | tr -s ' ' '\t'

说了这么多,其实应到到实际上就是,zabbix 在监控有大量连接机器的时候,如果使用起原生的 net.tcp.listen 等涉及到调用 netstat 的 item,其实准确的说并没有调用 netstat,而是直接 fopen 的 /proc/net/tcp 文件,就会产生上面的问题。办法就是自己写套 template,换成调用 ss 的方式。除此之外,如果使用 LLD(low level discovery),同样的记得别用 netstat 发现监听的端口,改用 ss 既可,对应的脚本可以在这里找到。

结论:
不管什么时候,请使用 ss 而非 netstat 来查看目前系统的状态。

使用 tr, rename, bash 内置变量修改文件名

有如下所示的目录,现要将目录中的 '-" 改成 "_"
$ ll
total 12
drwxrwxr-x 2 jaseywang jaseywang 4096 2012-07-29 15:09 1-2-3/
drwxrwxr-x 2 jaseywang jaseywang 4096 2012-07-29 15:09 4-5-6/
drwxrwxr-x 2 jaseywang jaseywang 4096 2012-07-29 15:09 7-8-9/

g 了如下几种方式,没找到源出处,侵权了可以联系我。

可以通过 tr 实现:
$ find . -type d -name "*-*" -print | while read name; do na=$(echo $name | tr '-' '_'); if [[ $name != $na ]]; then mv "$name" $na; fi; done
Continue reading