10G 网络升级(整体架构 & vPC)

上篇介绍了升级过程中涉及到的业务层面的内容,接下来两篇会着重总结一些技术上的实现细节。在主持此次升级之前,把《Network Warrior》上面的一部分内容过了一遍,除了介绍 752 之外,其他的章节总结的也很到位,尤其是最后的几章节,很多问题都是一针见血,强烈推荐各位看看,上面的总结只有经历过的人才会有共鸣。下面的内容也有部分是出自这本书。

Nexus 7000 使用的是 midplane 架构,跟之前的 backplane 不同,因此需要重新考虑散热问题。比如 7004 使用的是 side-rear 的方式,7018 则是 side-side 的方式。 Nexus 5000/2000 的则是从前到后或者从后到前谁前谁后,这个务必要理解清楚,否则跑了一半机器就烧了歇火了。因此需要考虑 IDC 里面的 hot/cold aisle。这里有两篇(1, 2)  比较早期的文档,专门探讨 752 的散热问题(不仅仅 752 存在这个问题,4948E 也有类似的问题),解决的办法也比较简单,花钱买套 "Nexus Airflow Extension Sleeve"。
上面谈到的是散热问题,7K 的电源模块可能会存在一些问题,默认使用的 250V,16A 的电源线,一般的插线板可能无法插入;另外功耗问题也需要考虑进去,一般的测试环境是无法满足这么大的功耗问题的,所以不管是测试还是正式上架,务必确认这些问题。

Nexus 5000 基本跟 7000 看齐,除了 U 位小些,没有冗余 supervisor 以及 VDC 这类高端功能罢了,其他的差异我认为不是很大。

Nexux 2000 严格来说,并不是交换机,只是一个 fabric extender,他有两类端口,一种叫主机端口,就是连接服务器的,默认激活了 STP BUDU Guard,一旦连上服务器便会 error-disable;另一种是 fabric 端口,用来连接 N5K/N7K,所有的 fabric 端口都是 10G 端口。

说完整体再总结几个 nexus 改进最大的地方,也就是最像 *nix 的地方(1, 2, 3)。
几乎所有的协议都已模块化的方式加载:
# show feature

所有的接口均已 Ethernet 开头,不再分 FastEthernet、GigabitEthnet,这样比较方便操作。

可以使用 tab 补全,类似 shell;除此之外多了很多 pipe,多了 grep 等过滤的工具。

管理平面、控制平面以及数据平面隔离。比如 ssh 产生的为管理流量,并不会影响数据转发的流量。管理平面挂了对生产环境并没有致命的威胁。

默认情况下,nexus 7000 所有的接口都是三层的,因此,要变成 trunk,记得加 switchport。

VDC 这个是 nexus 最大的一个卖点。本次我们没有采用 VDC 这种看上去逼格很高的技术,仔细想想,根本不适合我们的业务场景,线上全是生产环境,第一并不需要流量隔离,第二毕竟是一个虚拟技术,对整体的性能多少还是有些影响的,这个可以类比 *nix 下各种 VM 的实现,其优缺点很明显。根据业务需求选择对应的技术,而不是为了用技术而用技术,技术最终都是为业务服务的,脱离了他技术没有任何意义。

接下来会着重总结 vPC 这个比较创新的技术。在开始之前还是还有必要过一下这个 quick start 的 《Virtual PortChannel Quick Configuration Guide
vPC 这个在 752 的架构中用的很多,主要是为了增加上联的带宽减小收敛比,其次冗余也是一方面,并且他可以做到跨机箱,比传统 port-channel 要好的多。官方有两个文档,一个是《Configuring Virtual Port Channels》,另外一个是《vpc best practices design guide》  可以没事翻阅看看,都是经验总结,看完了可以少走不少弯路。

使用 vPC 最重要的是注意 consistency 的问题,这篇文档描述了这个问题。 show vpc consistency-parameters 是一个非常 handy 的命令,出了问题先通过他查看查看,很可能会发现问题的原因。如果这条命令解决不了,那就按照这个操作一步一步来吧。 《Troubleshooting Virtual Port Channel Issues

vPC 的 domain 编号跟 port channel 的编号一致,否则以后出了问题有的你受了,这是减轻你的痛苦也是减轻后来维护人员的痛苦。 另外,由于 vPC 受众多因素的影响,一点点小的改动都可能导致出现 type 1 的完全中断或者 type 2 的部分中断,因此操作包含 vPC 的机器时,需要格外小心。vPC Domain ID 问题需要注意的是,7K 上的 domain ID 不能跟 5K 上的一样,否则 port channel 会一直处于 suspend 的状态而导致 vPC 无法连接,原因可以看这里

需要注意的是,不管是 port channel 还是 vPC,都无法实现每条物理链路流量的均分。比如我们之前在 stacking 过的 3750X 上做 cross-stack,实现 port-channel。很明显的可以看到,两条物理链路的流量并不均等。


上面这个是两条 1G 的绑定,理论上,要实现流量的均分,必须是 2 条、4 条或者 8 条的绑定,但是实事情况是,即使是两条,也会出现流量不均等的情况。 默认情况下,port channel 会通过目的 mac 的方式做 LB,由此可以看到,当数据包要发往的目的地比较多的时候,才能体现 port channel 的价值。如果,发往的 mac 地址很单一,就会造成流量很集中在某一条物理链路上,后果是,即使这一条物理链路出现过载,交换机也不会自动的将一部分的流量切分到其他的空闲物理链路上。因此,是选择根据源 mac 方式还是目的 mac 亦或是其他更复杂的方式,还是需要根据业务类型来定。

要做 vPC 就离不开 Peer-Keepalive。其最重要的就是 internal 以及 timeout 的时间。前者有 400ms 到 10s 可选,默认 1s 的应该足够了。后者有 3 到 20s 可选,默认 5s。 Peer-keepalive 可以使用 management VRF 或者 default VFR。官方推荐使用前者, 也就是使用 mgmt0 的 ip 作为 src/dst 的地址;如果使用 default VFR,还要建立 SVI,没有必要。另外,两台 peer 的配置最好一样,详细情况可以看这里

接下来就是 Peer-Link,这这两有先后顺序,不要弄反,只有在对端 peer 挂了情况下,Peer-Keepalive 才会启动侦测。

最后,熟悉我们前年升级的应该会知道(1, 2, 3, 4),我们会涉及到跨机房的通信的问题。 之前是在两台 3750X 上起的 port channel,现在一方升级另一方不变,vPC 依然可以很好的胜任,对端 port channel 不变,要升级的这端起 vPC 就可以了。

北京的水(纯水机)

说完了全国最大的农村人口集散地的空气,继续谈谈北京的水,这里说的是饮用水,不是满大街那种臭水沟的水。对北京水质表示堪忧是从电热水壶下面沉淀的厚厚的水垢开始的,这个肉眼能观察到的仅仅是由于硬水中的各种钙镁离子引起的,长期喝这种水据说会增加得结石得风险(我没求证)。再加上由于北京市内以及周边地区严重的污染(1, 2),使得我不得不考虑上一台净水设备。
转了几圈发现净水市场跟空气净化器市场一样,鱼龙混杂,噱头十足,混乱成什么样子了?连一根送水的管子都有普通的 PE 管以及 CCK 之分。这意味即使愿意花钱也未必能解决问题。为此,我周末花了两天时间查阅了大量得资料,对比各种家用净水设施得优劣,最终得出得相比之下"一劳永逸"的方式是买台 RO 纯水机。在深入调研过程中发现,那些动辄五六千的纯水机其实核心部件都一样,无非就是一根陶氏的 RO 膜(0.1 纳米的过滤级别,可以过滤掉所有的细菌,绝大多数的病毒以及金属离子),有的用的还是国产之类的烂货,这玩意儿的成本不过 200RMB,这跟空气净化器 HEPA 滤网一个道理。想想计算机系统里面的 cache,是不是觉得世间万物都是想通的。知道了这些不如自己组装一台 RO(reverse Osmosis) 纯水机了。
市场上的纯水机大同小异,无非是几级过滤是否自动冲洗以及 RO 膜的差别,其他的我认为都是炒作。最终,我的选择:
第一级:1微米 PP 棉
第二级:xx活性炭
第三级:1微米 PP 棉
第四级:DOW 50加仑 RO 膜
第五级:xx活性炭
50 加仑的一个储水 tank;自动冲洗;另外,把第一级的外壳换成了透明的,好观察更换。

一周之后,重达 15kg 的全套装备到货了,为此我花了两天时间,像这位大哥一样,一边看说明书一边学习安装。

记得用冲击钻的时候带上防尘口罩

由于厨房的供水系统比较老,需要改造才能使用,为此在房东的指导下,熟悉了几乎所有的五金工具,最终组装上架了一套纯水机。客观的说,放出来的水确实很甘甜,这个主要是最后一级滤芯的作用。


要维护这套设备也很简单,跟空气净化器一样,定期更换各级滤芯就可以,并且跟空气净化器比,成本低的多,尤其像 PP 棉、活性炭之类的,成本几乎可以忽略不计,RO 膜一年换一次,平均下来一天不到一块钱。
本次最大的收获是同时熟悉了木工以及水电工的基本操作,现在这类工种在加拿大很紧俏,学好五金基建移民有保障啊。另外,基本所有的纯水机都建议棉过滤层 2-3 个月换一次,不过从实际观察来看,我基本一天 50 加仑不到的使用量,一个月之后第一层 PP 棉的颜色已经惨不忍睹了,什么净化设备到了北京(中国有特殊的国情,北京亦然)都要打个对折,空气净化器设备(1, 2, 3)也是这样的。


06/08/2014:我家(江苏)也有一套同样的设备,肉眼观察,北京这边的连续用一个月一级过滤绵就黄的不成样子了,江苏的用了一个月颜色不过微黄,用两撒三个月问题应该不大。北京水的硬度确实很重。

10G 网络升级(业务)

前年(12年)带着一个实习在啥都缺的情况下搞定了两个模块(30+ network devices)的基础网络。今年又搞了一把,又是一个危急存亡关头(真佩服那些经历了若干危急存亡还没死掉的 startup)临危受命,这种烂摊子的事发生的次数已经记不清了,要么忍要么滚,这其实是个很简单的道理。回到正题,既然答应再干一票,索性就做好。
这次的情况是啥都缺但是不缺钱,那问题就相对好办的多,钱能解决的问题都不是问题了,本着"能交给第三方做的尽量都交由其做"的原则(也正是由于这点给后面带了很多的问题),从前期的方案制定一直到最后走线、机器上架加电都外包由他们实施,在这个过程中我们是承担了包工头的角色,一方面跟他们协商一些细节一方面是在后面盯着往前推。当然最核心的 752 的灌装还是我们的人亲自动手来做。

问题的起源之前已经解释过了,业务上来了,想挡都挡不住。最终的架构设计也是烂大街的 752,其实除了这种经典的方式之外,还有一种 766 的架构,不过不大适合我们的业务。下一篇博客会着重总结一下技术面的细方,这篇博客仅仅总结一些业务层面的内容。

在这之前我们一直有一家固定的银牌代理商,合作的还算比较愉快,但是此次升级列出的清单的价格比后来半路杀出的干爹提供的要高一大截,当然直接跟他们说拜拜了,后来发现这是一个非常正确的选择,预算倒不是主要的原因,这个问题我会单独写一篇博客谈谈商务以及采购在整个运维生命周期里面的作用。
接上文,就在跟这家银牌代理商谈的差不多的时候,我们专注于卖假货的干爹半路出世。托他的福,找了家金牌代理商,大陆就那么几家,最终的报价当然有很大的杀伤力。
前戏依然是跟一帮销售加售前的黄金组合扯皮,几次谈下来,合作的也确实比较愉快,最起码邮件的书写没有任何的问题。但是越往后越发现靠不住,全程包括一个预约非常麻烦工作行程排的非常紧的售前兼售后,典型的半吊子。不吹牛逼的说,我花一天时间熟悉下某个协议绝对不会比他差;另外就是若干围绕他转的不知名酱油工程师以及若干实施布线的工程师,布线的老大是我接触的这么多人中比较有好感的,第一次意识到一条光纤也能弯的如此的优雅,看到多少会有些震撼,他们的线是按照弯曲的度数来计算的。
后来跟销售反馈了这个问题,他们也给足了面子,准确的说是给干爹的面子,特意从杭州调了一个工程师,结果打了半天酱油,第二天就回去了。自此之后,在经历了这么多的扯皮之后,还是要说句,不管做什么还是得靠自己,尤其是一些重要的程序。
为什么绝大部分的售前都是个半吊子了?举个印象特深的例子。用百度谷歌我已经不在乎了,能解决问题并且说明原因就好。当时我做了一次 write erase 操作,从头把 752 的十来台设备灌装一遍,因为不是很熟悉,花了估计有 2h,并且很不幸的,最后 7k 跟 5k 之间的 port channel 不通,尝试了若干方法都没找到问题缘由,后来该售前通过一条条对比我的 running-config 跟他自己的 running-config 这种非常 dirty 的方式发现原来是我把 7k 跟 5k 的 domain ID 弄重合了,至于为什么不能这样,含糊其辞的解释了几句话最后来了一句你记住不能一样就好了。后来我翻了下官方文档发现上面写的很清楚,domain ID 确实不能一样。从这件事来说,确实是我对系统的认知不足导致了这个问题的发生,并且由于时间关系,我也没有一页一页的去翻官方几千页的阿拉伯字母,很多都只是看一些 quick start 之类的文档速成学习的,最终的情况就是有些问题理解的不是很透彻。我一知半解因为我的主要工作方向不在这个方面,升级这事顶多算是我的副业,况且 752 的这套架构都是我现学起来的。而对于一个专业从事 752 架构的技术支持来说不能一针见血的指出这么基本的一个问题是不是显得太业余了。这类问题我认为只要平时脱离手册操作过几遍 752,浏览过一部分的官方文档应该都能很快的解决。
所以,在这里由衷的给那些看我博客的工程师一点建议,如果想从事技术路线,尽量少跟或者不跟这类人员打交道,除了浪费时间,你基本不能学到什么有用的。我做这个接口人的角色也并非自愿,上面已经说了。

由于公司之前没有一个人对此类架构的细节熟悉,机器到了之后倒是闹出了不少的笑话,最搞笑的是 7k 由于是 250V 的电源线不适用于目前通用的插线板,前前后后换过好几次插线板以及电源线。另外,由于之前规划的非常糙粗快,导致确定最终的接口方案时,发现还缺少包括 N2K、10G 多膜在内的不少整机以及零部件,好在这类问题都得到了及时的解决。

本次升级就当公司土豪了一把,扔了百来万学费给我去现场学习一下吧。当年见到一台两三万的现在看来非常烂的 R410 还敬畏一下,现在看到这百来万的设备都是直接加电插线开搞,丝毫没有了当年的的那份激动。

推荐两个官方文档,下篇会涉及一些重要的技术细节。
官方有个很基础也很重要的 《NX-OS CLI Management Best Practices Guide》,里面包含了从 Initial Configuration 到 Software upgrade/downgrade 等主要方面的介绍。
还有个 troubleshooting 的手册,写的非常完善。建议好好读读,出现问题之后的解决问题才是体现一个普通工程师跟优秀工程师区别的时候。

另外需要注意的一点,这里的 10G 是指除接入层服务器之外的 10G,除了一些相对特殊的服务(web server, cdn 等)之外,目前 10G 的服务器还不是那么的广泛应用,因此这里的接入层服务器还都是 1G 的接入。如果想了解 10G 服务器的接入,可以参考《Nexus 5K Layout for 10Gb/s Servers》这个(1, 2, 3, 4)系列的博客。 

最后这个是我写的一个简明的 752 step by step

不同业务对网络的要求

前段时间遇到一起比较严重涉及业务也比较广的 outstage。跟大家分享下,我认为比较经典。
由于前端的接 webserver 的交换机(普通的 2960S 1G)在晚高峰阶段撑不住了,导致了大量的丢包。可以看下面这张图。

仔细观察可以发现,在大概 22:00 的时候,只有 outcoming 出现了一个明显的凹陷,而对于 incoming 流量说,几乎没有影响,曲线保持的非常好。
后来通过大量的排查发现,其实这个 imcoming 的主要对应某个单独的业务,而该业务的最明显的特点就是几乎只有进没有出流量,仅仅是一个 POST 请求,而蓝色曲线的则对应其他的几个业务,其同时涉及到进跟出的流量。
再到 SW 上看看就明白情况了:
#show interfaces GigabitEthernet0/48
GigabitEthernet0/48 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is xxxx.yyyy.zzzz (bia xxxx.yyyy.zzzz)
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 85/255, rxload 116/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:52, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 793838

看到这里是不是就明白问题的原因了。

最初的时候,我发现我们的前端机器上 dmesg 有大量的报错,怀疑是 Nginx 的某个 bug 导致的,后来结合上面的情况就一目了然了。现在推测下来,应该是由于交换机的大量丢包,导致 Nginx 不断的向 upstream 重试,消耗了大量的内存,导致上面现象的出现,对比发现,我们同样负载的机器,只有 16G 的内存,没有出现任何的问题。

所以有时候出现问题,需要综合的思考各种情况,站的高才能看的远,这就是为什么有些问题别人解决不了而你能很快的定位到问题的根源。如果在排查过程中根本不知道或者压根没有想起有这回事,把自己仅仅局限于某个工作流水上的某一个零件,那估计一辈子都发现不了问题的根源了,在这种情况下,之前积累的经验会显的更为重要。

桂林小游

11 月随公司去了趟桂林,整理感觉是这类地方已经被过度开发得不像样子了,没什么特别的。记录下,做个纪念。
象山公园,就是那个象鼻山的所在地,去不去都后悔,这生见一次就够了。
古东风景区,有山有水,但是人造迹象太明显,人太多。最后到山顶跟同事一起坐了把类似过山车的下山交通工具还蛮有趣的,那边还有类似 zipline 的东西,但是滑行的距离太短了没玩,价格两位数。
漓江,80分,我们当时是包船从市区沿江坐了 4h 到达阳朔的,风景还是不错,看到最后审美疲劳了。期间我跟另外两个同事花 100RMB 就买通了船长,让其允许我们坐在了船前的甲板上,视野开阔的多,活动的空间也大的多,这人均 30 的交易真是物超所值。
阳朔,估计我们去的那几天不凑巧,满城烟雾缭绕,2.5 跟北京估计有的一比。如果不去远点的地方玩极限活动,市区基本就是个商业中心,传说中最著名的西街其实就是条卖淘宝货的步行街,我走了几步就出来了。
兴坪古镇,好像是叫这名字的,风景还不错,看上去基本处于原始状态,可以去看看。
本次去桂林就是冲着米粉去的,味道确实不错,桂林市区的基本是 3.5RMB 一碗,阳朔的要比市区的贵一倍左右,味道跟市区的差不多。要找到"原生态"的很简单,看当地人去吃的跟着进去就是的了,所以最开始呆市区的几天,早上早点起来,沿路走走就能发现一些当地人常过去的米粉店。我在市区吃到的几次都是没有汤的,就是一份米粉,上面有几片肉,一些葱以及花生米,或者香菜什么的,像下面这两种图一样。

Continue reading

弱密码的危害

前段时间,我收到 wooyun 上白帽子发来的一条消息,大致意思是我们的博客(wordpress)的后台被 crack 了,然后成功的拿到了 shell,最终登陆到我们的内网,由于目前我们测试跟生产环境是通过 VPN 联通的,危害可想而知。被 crack 的缘由说来好笑,由于 wordpress 同时有很多的作者,有的作者为了方便记忆,设置了非常简单的密码,简单到都不需要暴力破解。
暂时解决问题的办法也很简单,最少有如下的几种:
1. 加强密码强度,这个也是首要改进的。但是理论上没有不能暴力破解的密码,尤其在 CSDN 事件之后,基本是人手一个非常高效的字典。
2. 设置一些访问权限也可以从一定程度上缓解此类问题。但是有能力的完全可以伪造 IP 突破限制。
3. 通过虚拟机完全隔离,如果遇到一名社工非常强大的黑客他依然会找到蛛丝马迹

但上,上面说的这些方式都无法从根本解决问题。
wordpress 作为一款非常的流行的 CMS,包括我自身的博客在内,被很多的个人以及企业所青睐,用的人多了,自然的,被盯上的概率也就大了。很多创业公司为了省事,很有可能把公司的博客跟生产环境放到一起,而写博客的作者们通常是一群搞市场搞运营的技术小白,这就大大方便作案了。
除了像 wordpress 这类很火的 CMS,一些运维管理平台同样会由于开放了公网环境,而登陆者的弱密码会造成整个内网沦陷的悲剧。

要真正解决这类问题,至少可以从使用者以及服务提供者两方面入手。
对于使用者来说,自己首先需要意识到这类问题的严重性,掌握一些基础的知识,比如如何设置一个比较健壮的密码,如何设置邮箱等,这少不了安全人员对其教化。有趣的是,有的时候,教化的再多,不如自己的敏感信息被泄漏一次来的更有教训,虽然很无奈但事实就是这样。
而对于服务体提供者来说,除了上面说到的一些简单通用的方式,还可以通过下面的一些方式来加强:
1. 创建用户期间就应该主动检测密码强度,只有达到一定强度的密码才可以注册,目前,不少网站都做的不错。并且,目前很多的系统(Linux, Nexus 等)都可以实现这类最基础也是最有效的功能
2. 频繁登陆出错触发一些规则,比如一天之内登陆错误 3 次不允许访问,10min 钟内登陆错误 3 次禁止访问,具体可以参见不少电商以及金融体系的做法