10G 网络升级(服务器端 bonding)

本次升级最大的"意外"之一就是关于服务器 bonding 的问题,归根到底还是在升级之前文档看的不够充分,调研的不够仔细。下面会对其做一个比较全面的分析。
说到 bonding,最重要的问题之一就是模式的选择,这个是要根据各自不同业务来选择的,切勿人云亦云,我整理了一份表格,说明每一种模式的一些特性以及交换机对其的支持情况。

选哪个模式最合适?很明显,正常情况下,mode4 是一个比较好的选择,但是需要注意的是端对端尤其是交换机 active/on 选择,对于服务器来说,稍微有点繁杂,需要根据网口的情况来分:

  • 四口的,如果有内外网,没有问题
  • 两口的,如果仅仅有内网或者公网,也没有问题
  • 两口的,如果既要有内网又要有公网,很明显,还缺少两个端口,这时候在 Linux 上做 VLAN  的价值就体现出来了

确认完模式,接下来就是 bonding 的安装,bonding 这个 module 默认应该都是随发型版本加载的,可以在 /etc/modprobe.d/ 目录下面加载;接下来就是修改网卡对应的配置了,各个不同的发型版本大同小异,这里分别给一个 Ubuntu 以及 RHEL 的范例。这两个主流发型版本的 bonding 的配置还是比较灵活的,除了可以在 /etc/modprobe.d/ 里面指定 bonding 的各种参数之外,还可以在 network-scripts/ 以及 interface 里面指定,比如可以在 ifcfg-bond0 里面指定 bonding opts:
# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0

BONDING_OPTS="mode=4 miimon=100"

跟 bonding 有关的几个实时文件分别在 /proc/net/bonding/:
# cat /proc/net/bonding/bond0

以及 /sys/class/net/ 下面:
# cat /sys/class/net/bonding_masters
bond0

# cat /sys/class/net/bond0/bonding/mode
balance-alb 6

# cat /sys/class/net/bond0/address
99:11:11:11:dd:dd

要让 bonding 生效,我认为最 KISS 的办法还是直接重启机器,尽管可以通过 ifenslave 或者在加载完 bonding 之后直接在 /sys/(/sys/class/net/ 下面) 里面 "on the fly"。官方的建议是通过 iproute2(ip link set eth0 master bond0) 或者 sysfs 修改生效,ifenslave 会被逐渐抛弃。
在启动的时候,注意查看系统的 /var/log/messages,这个文件里面能看到很多跟 bonding 相关的信息。

对于 bonding 一对或者多对网卡的监控,可以二选一:
1. miimon
2. arp_interval 以及 arp_ip_target
不用任何监控的弊端之一就是一个网卡挂了无法及时的切换到另外一块网卡上,这个明显是不容许的。
对于 ARP 的监控方式,一般用在兼容 etherchannel 的模式里面,也就是交换机会将流量分散到多条链路上;如果是以 XOR 的方式(单条链路)则不可行。除此之外,ARP 的方式不可以跟 miimon 同时使用。
对于 miimon 来说,有 downdelay, updelay, user_carrier 几个参数比较重要。
如果想使用 balance-xor 或者 802.3ad,还需要了解下 xmit_hash_policy 以便更好的平衡流量。

既然是端到端的系统,除了要考虑服务器方面的 bonding 状态,也要考虑对端 FEX 的支持情况,在上篇已经说过,主流的 2k 跟 5k 的接法无外乎 single-homed 也就是一台 2k 仅连接一台 5k 或者是 dual-homed 也就是一台 2k 同时连接两台 5k。其中前者的 topo 支持 2k 的到服务器的 vPC、FCOE 以及 static pinning,而后者是不可以对 2k 下挂的服务器做 vPC,单凭这一点就没什么优势了,更何况这种接法还有其他不少的缺点。

这里有一篇文章提到遇到 Orphan Port 也就是单上联的情况,这个在实际情况中还时有发生,尤其是比较早期的服务器,那时候网口的数量还不足以达到双上联的标准,对于这类情况,文中分析在 peer link 参与的情况下流量的分布以及需要注意的地方,值得看看。

还有几个需要注意的地方:
1. 路由问题,原先由 eth0 单块网卡处理的现在将由 bond0 接替处理,如果是通过 ifensalve、modprobe 等方式启动的 bonding,注意也要修改对应的路由,重启不存在这类问题。
2. SNMP 问题,需要确保 bonding  这个模块在其他的网络模块之前加载,否则 SNMP 取得的数据会有错乱。
3. 在混杂(promiscuous) 模式下,balance-rr, balance-xor, broadcast 以及 802ad 这四种模式会将混杂模式的设定会传播到所有的 slave 接口;而 active-backup, balance-tlb 以及 balance-alb 这三种则只会传播到 active 的 slave 接口。
4. duplicated 包的问题,最常见的是在初次或者闲置一段时间之后 ping 某台机器的过程中发现不少 (DUP!) 表示的包,正常现象,主要在于交换机广播的机制,最简单的方式是清空一次 MAC 转发表,Nexus 上的示例:
# clear mac address-table dynamic

Thailand 小游(Koh Samui, Chiang Mai, Bangkok)

过年期间跟某只小熊猫去 Thailand 溜达了一圈,享受了半个月的清新的空气,满天的繁星以及自由的网络。下面按照时间顺序,流水账的记录一下。
就在出发去 PVG 的前一天晚上,我的这台历经磨难的 air 的硬盘又挂了。说来好笑,去年在跟三里屯零售店的以出了问题重装系统为指导思想的一帮蠢才吧的员工扯了大半个月之后,他们的头头终于同意给我换一台全新的 mba,可是用了不到三个月,这台笔记本的 SSD 就中招了,把笔记本仍在那儿扔了一周之后,终于换好了 SSD,按理说,应该不会再出现问题。结果,就在我走了前一天晚上,SSD 又光荣牺牲了,还好第二天要去的是上海。2号下午到了上海,下了火车就急匆匆的赶到了他们的香港广场零售店,等了三个多小时,拿到了一台空系统的机器。
3 号早上的飞机,12 点出发的航班延误到了 14 点才出发,到了 HKG 中转,下了飞机看到国泰的小妹们忙的不可开交,一个个扯破嗓子在"拉客",顿时觉得现代这么发达的航空业也不过如此,最后到达 BKK 的时间竟然只比原计划晚了不到 1h,真庆幸。晚上住在了离 BKK 不远的酒店,放下行李之后,在周围溜达,初步勘探下来,除了沿路若干的 711、bigc 以及 tesco,其余的都是路边摊,我们就在路边选了个当地人最多的摊位找了可能是当地的小吃做为了晚饭,口味一般般。
第二天中午直飞到了 Koh Samui。其实除了直飞之外,还可以通过水陆或者水空结合的方式,从 Bangkok 做大巴/飞机到 Surat Thani Province,然后坐船到 Samui,价格会比带有垄断性质的直飞便宜的多,但是耗时也长的多,有时间的完全可以体验一下。不得不说,USM 机场是我见到过的最漂亮的机场(虽然我也没见过多少机场),用几个关键词概括一下就是花、树荫、鸟、蓝天、可爱的飞机。
接下来的四天主要的行程就是晒太阳,我没做特别详细的攻略,基本是走到哪里吃到哪里玩到哪里,海里玩累了就上岸晒太阳吃东西如此循环。住在 Bo Phut 的 Samui Pier Beach Resort,离 Big Buddha(其实没什么意思,属于去跟不去都后悔的那种) 步行大概 15min,人少安静,基本没有聒噪成群结队的大陆土豪。
从我们住的地方往东的那条主路吃到了味道最正的 Tai cuisine,英文名叫 Cafe Uno,一家看上去非常本地化的小餐馆,环境一般般(真正好吃的东西都在那种价格不贵环境一般的地方),他们家的菜单没有价格,统一 60B 一道主食。味道最正的一道主食叫 Kapaw rice,食材很简单,就是 rice, basil, pork, chilli pepper,这个在 711 以及后来其他的餐馆都尝过,但是味道跟他们家比还是有不少差距,有条件的把他们家的菜都吃一遍吧,反正我们是基本做到了,不后悔,下午三点关门,要吃的趁早。靠近他们家有一个流动的卖水果的摊点,菠萝的价格便宜不说,据资深菠萝专家小熊猫的评价,这是她吃过的最好吃的菠萝了,同样的,机不可失时不再来,我们也只买到了两次,后来再过来的时候再也找不到他们了。
除了这两个固定的地方之外,在 Mae Nam beach 以及 Chaweng Beach 呆了两天,推荐个叫 "KohSamui" 的 app,优点是能根据我目前的位置推荐一些比较好的商户。Mae Nam 的 Chill Out cafe 以及 Chaweng 的 synergy samui 都是他推荐的,点几个 dish 两杯 cocktail 一下午很快就过去了。另外,各个海滩上的烤玉米普遍都不错,我们吃过几次,口感非常脆鲜嫩多汁。
最后一天就在酒店做了个 deep tai massage,手法一般关键是环境好,sea view。竟然还可以还价,一人 400,两人 700。
在岛上唯一遗憾的就是交通太混乱了,靠左行驶是一个不大习惯的问题,taxi 以及 Songtaews(中文叫双条车) 漫天要价,由于之前没有研究下这两种交通工具,分别被砍了 400B(都是 3 公里不到),后来有经验了知道要态度坚决的砍价,对半砍。不得不说北京的出租是我见过的最规范最标准的出租。
接着是飞回 Bangkok,根据小熊猫的指示,下了飞机立马酒店 check in,然后赶了个叫 Chatuchak weekend Market,还蛮热闹的,第一次喝到用塑料袋(好像整个 Thailand 都喜欢用塑料袋装熟食)装的 ice tea,里面其实就是自由市场,随便走走也蛮自在的。首都的交通比接下来的包括 Chiang Mai 在内的要规范的多,taxi 基本都是可以打表的。
次日中午到了 Chiang Mai,据说坐火车也是一个很好的选择,沿途风景不错,前提是时间充裕。在 DMK 见识了大陆失足少女狂扫 NaRaYa 的场面。Chiang Mai 是一个国人跟团聚集的地方,基本上如果你能听到各种呱噪以及机场工作人跟乘客谈三观问题的话,十有八九十就是我们的同胞了。我跟小熊猫在某些问题上的观点很一致的,比如在 Chiang Mai 我们看到国人跟团聚集的地方会主动避开,选餐馆会先大概评估下里面大陆同胞的数量,曾经在 USM 这么美好的地方见到工作人员训斥一帮穿戴十分光鲜亮丽的大陆同学的某些不雅行径,大陆护照基本是废止一张跟这些不无关系。
原本是根据小熊猫在吃货俱乐部等各大中文网站做的攻略来的,后来发现情况不妙,你能找的到的其他说中文的也能找到,"Chinese go out, Chinese around"。后来干脆切换到前面在 Samui 的做法,随便跑辅助参考 tripadvisor 的做法。当然 Chiang Mai 最有名的横跨 Ratchadamnoen Rd 的 Sunday night market 绝对不可错过了,我跟小熊猫都看的眼花缭乱,这是目前我见过的最大的市场了,比大陆的有序最重要的干净的多,那天晚上在 Tha Pae Gate 正在举行 Flower Festival 的闭幕式,人流涌动异常欢乐。
接下来的几天在路边感受了一次廉价的 foot massage,在 nanthikan,一个非常不起眼的角落做了一次全身的 hot oil massage,有没有保健效果不知道,但是全身脱光了,黑暗中,被一个看不清容颜的女性全身按压,感觉不一样啊。
吃的方面,在 Nimmanhenin Rd 吃过一次日式简餐,味道应该蛮正的。Dash(我也不大清楚为什么这么火)、Ristr8to² (一家非常有意思的咖啡馆)、Huen Phen(本地小吃,跟我们在 Samui 吃的那家比差不少,只不过离我们的住的地方很近)、Guu Fusion Roti & Tea(印度 Roti)、Kabab Bar(中国人民的老朋友巴基斯坦开的,foursquare 的 Indian Restaurant 有误,pratha 一定要尝一尝) 。只因为看到里面有 live band,进了家叫 The Garden Restaurant 的地方,各点了杯 cocktail,我感觉我点的那杯 Mai Tai 里面糖精放多了,跟在 Chill Out 点的那种甜甜苦苦酸酸的口感完全不一样,直到后来看 tripadvisor 才发现这是家 gay bar。最后什么骑大象、看 ladyboy 的表演、玩 zipline 我们统一都没玩,除了 zipline 某只小猫觉得太危险不让玩,其他的都没什么兴趣。
最后几天呆 Bangkok,真是一段用身难忘的经历。我们去年很早就定好了 Thailand 的酒店机票,结果一帮政客年底闹革命,搞的人心惶惶。我们在 National Stadium 附近定的酒店离 Suthep Thaugsuban 他老人家带领的一帮老弱病残中下贫农的演讲舞台只有不到 5min 的路程,大晚上关了窗子都能听到他们玩摇滚的声音。实事证明了,情况没那么糟糕,这种 protest 无非就是一帮中高产利益集团跟不满另一帮利益集团而已,跟底层人民的关系甚微,恰巧在年前看完了《天葬:西藏的命运》,二者对比下会发现,很多东西都是惊人的相似。在 National Stadium 的现场,跟着 Suthep 玩的都是一帮只会说 Yes 各 no 的农民,白天根本看不到一个穿着像样的年轻人,只有到晚上下班之后,才能看到一些年轻人聚集在广场听 Suthep 演讲,接着是唱歌跳舞,然后继续演讲,后来某天晚上我们也参与近来了(1, 2) 。被封路的沿途商户基本都已关闭,只剩下跟着抗议的农民摆的小摊了,每天免费供应三餐,也算是提前过上社会主义的日子。出了像 Victory Monument 这样的几个闹事区,根本感觉不到这个国家任何的不对劲,21 termainal 照样人来人往,Wat Pho 照样香火旺盛,该怎么玩继续怎么玩。最后一天在 Siam 找了个 shooting range,第一次碰到了真正的 revolver  以及 rifle,时间很快过程很爽,据说资金充裕还可以开坦克玩。
由于要走的前一天晚上在走了 20min 路之后好不容易发现了一家 Tesco 里面有酒卖(Bangkok 大部分地区都禁酒, Chiang Mai & Samui 不受影响),买了两瓶 fruit wine,度数比在 Samui & Chiang Mai 喝的猛一些,结果晚上喝了点就感觉醉了,第二天到了机场又灌了半瓶然后倒掉了。
最后回来要中转的航班被国泰取消了,直接给我们换成了泰国航空的直飞,这样也好,节约了不少时间,不过某只熊猫少吃了一顿看上去还不错的穆斯林的机上餐,有失有得。
最后大赞全 Thailand 公共场所禁烟的举动,这半个月我没有闻到一丝的烟味,身心得到了无比的放松,这比伟光正的小打小闹禁塑料袋不敢触及真正利益集团的的举动要强的多。

OpenSSL(CVE-2014-0160)漏洞修复速度

OpenSSL 不是第一次出现这类影响非常严重的漏洞了,12 年 4 月的 CVE-2012-2110 这个漏洞当时就让我忙活了好一阵子
今天早上扫 feedly 的时候发现了这个漏洞,迅速确认了我们线上的服务器不受影响之后就开始围观了。  
OpenSSL 官方最先挂了通知
几个主要的发行版本都在当天(4 月 8 日)发出了 Heartbleed bug 影响以及修复方式:USN(1, 2) , DSA, Bugzilla

要说影响,基本可以确定包含 taobao 在内的绝大多数的都受到影响了,其他的小电商小网站就不计其数了,wooyun 上有截图为证:

话说这漏洞出来也好长时间了(相对于互联网的速度),到我写这篇博客的时候(08-21-04-08-2014),最少也有五六个小时了。很不幸的是,我跑了一遍,发现还有下面这些网站没有及时的升级打补丁:
1. kyfw.12306.cn,这个证书本来就有问题
2. 126.com/163.com 旗下的各种邮箱
3. login.yahoo.com,  www.flickr.com 这两个一起的,www.tumblr.com 虽然被收购了,估计还没整合好,这次修复的还蛮迅速的
4. www.quora.com 没想到反应这么慢
5. 京东的蛮有意思的,海外、国内登录两套标准,passport.en.jd.com 这个没有 ssl 证书,passport.jd.com 则有证书
6. fitbit.com,毕竟不是专业搞互联网的,速度慢可以理解

上面的在没有确认升级完毕之前,务必不要再登录,要检验是否安全很简单,可以去 github 上跑个脚本或者直接用这个。其他的比如 amazon.com, coursera.org, dropbox.com, evernote.com, facebook, twitter.com, foursquare.com, github.com, instagram.com, vimeo.com, wikipedia.org 我扫的时候发现已经没有问题了(或许原来就没遇到这个漏洞)。

其实这个漏洞保守估计在一周之前就已经发现,但是并没有公开,所以 cloudflare 有足够的时间去升级,今天发布的这个博客绝对是个绝妙的加分项,完爆 ali。

如何修复?
对于服务商,抓紧时间升级。
对于用户,最好修改一遍密码,因为可以确认包括 taobao 在内已经有部分用户的信息泄漏了,如果你是所有网站公用一套登录名密码,连夜修改吧。


update: 07-15-04-09-2014,上面提到的 6 个网站已经全部完成修复,速度还算可以接受。

update: 04-09-2014,Cisco 官方发出了受影响设备的列表,IOS 以及 Nexus 的不在影响之列。

遭受了 NTP 放大攻击

某台开放了公网的服务器流量从某时刻起突然暴涨了,登陆上去排查,ibmonitor&iftop&iptraf 三个工具结合跑一遍,直接定位到了问题的根源,遭受了 ntp amplification,现象以及细节可以看下面五张图。

整个过程中我们的带宽变化

攻击进行时通过 iftop 观察到的现象

攻击进行时通过 iptraf 观察到的现象

停止了 ntp 之后通过 iftop 观察到的

停止了 ntp 之后通过 iptraf 观察到的

关注 cloudflare 官方博客的可以发现,时间跟这次全球性的 400G DDoS 非常吻合,之后通过跟官方联系,确认我们的机器是受害者之一。
除了 NTP 之外,DNS 以及 SNMP 也是易受攻击做 AMP 的协议之一,二者都是 UDP,很容易通过很小的投入产生巨大的流量,根据监控可以发现,机器的进流量在受攻击的这段时间内几乎没有变化,而出去的流量净增 400M+。按照这个量,攻击十台这样的服务器,基本可以搞定一个中型网站的一个或者多个出口。

如何防御?OpenNTPProject 这个项目上写的很详尽

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)也是这样的。