前年兼职搞的时候规模还没这么大，整个步骤也很顺利，基本做的就是些插拔网线的操作。这次规模较前年比，已经是翻了几番(30 组机架)，不可能再由一人带一实习生这种套路来完成。增加人手首当其冲，所幸，这次升级的人手还是比较充裕的，我们这边包括我在内一个网络工程师，两个运维；我们的服务供应商驻守了两位网络工程师以及若干的布线人员；我们的托管商将驻场的值班工程师由原先的 1 位临时增加到了 5 位。
升级最终的结果当然是成功的，但是中间的过程确是崎岖无比，原本计划从 2 月 18 日 10:00pm 到 19 日 4:00am 6h 的 scheduled downtime 由于遇到了种种事先没有预想到的问被迫被延期到了 20 日的凌晨 3:00am，中间经历了难熬的 30h。
下面先写些"八卦"。
第一天晚上最大的失败就是在升级网络的时候连同服务器也一起带着升级了，其实这是两件事，完全可以独立开来做。最终导致内网任何一点之间的丢包高达 50%，处于完全瘫痪的状态。从拔第一跟网线的 11:00 pm 开始到最后一根网线插上，已经到了 19 日的 7:00am 多，在现场 debug 了 2h 多小时，基本确定是网卡 mode 的问题。
回去休息，感觉基本是锁定了问题所在，起床后在高度兴奋的状态下扫了若干的文档，有九成以上的把握是 bonding mode 的问题。
晚上吃完饭买完能量补给，跟我们的工程师再次亲临现场，花了一个多小时的时间，拿一组整机柜做了实验，100% 确认了是 bonding mode 造成的问题。接下来一直到 3:00am 的这段时间就是一人操作一人配合改完了所有服务器的 bonding mode 以及测试确认，现场还出现了一些人为操作的失误，多花了些时间去排查，如果细心点应该 2 点左右就能结束。
至此，整体框架已经升级完毕，剩下的一些诸如服务器无法启动、路由不通等问题这是后话。
下面逐条总结这次升级终于到的问题以及改进措施，我相信我说的这些绝大多数成长中的公司都应该会遇到，不管是基础网络、系统、上层服务以及面向客户的业务层面。
1. 太过于相信我们的服务供应商的工程师(暂且以 S 表示这个群体)或者说其他人的经验
之前得知 S 处理的项目的经验不少，基本北京这边几个巨头都是他们的客户。最初咨询他们建议使用哪种 bonding mode 时，心安理得没有任何思考以及查证的情况下就相信了他们说的话。而这最终的结论是从哪里来的了？根据 S 的陈述，他们其实也不大了解，转而咨询 A 公司(收购我们的那家)的驻场工程师。当时非常幼稚脑子烧掉的认为这么大的公司都按照这套路来，我们肯定也没问题了。于是我们就是照猫画虎，没理解里面的细节，连 A 那边最基本的环境都不了解，就屁颠屁颠的用上去了，结果可想而知。
不要迷信厂商，厂商里面很少有技术过硬强烈责任感的工程师，大部分的都是油腔滑调满嘴跑火车(Redhat 除外)。我们这次如此不顺利的升级也是过分的听信了厂商的满嘴跑火车。所以，不管什么时候，首先阅读官方文档，这上面的绝大多数内容都是正确的，再配合实际操作。
2. 前期的准备测试工作准备的不够充分
除了第一条说的自己没有做深入的调研服务器端 bonding 的相关细节之外，还包括下面的一些情况:
1) 没有能够完全模拟出跟生产一模一样或者相接近的环境。在正式切换之前，我们只是在公司跑了一遍基本的协议以及服务器的互联互通，并没有做一些诸如丢包、延时、带宽吞吐等相对综合的测试。即使我们所有待升级的机器都拉到了现场，我们也仅仅是从线上选了两台服务器做了一些带宽吞吐方面的测试，并没花一个比较长的时间来观察后续的丢包情况。
2) 布线细节。752 之间的布线除了发现一个光模块有问题(对整个系统没有大影响) 之外其他的都比较顺利。但是到了接入层也就是我们众多的服务器连接交换机的这部分链路确出了很大的问题。最初我们的一对 2k 是对服务器做的是 vPC，这也意味着任意一台服务器的两条链路必须对应到各自的 2k 的端口，比如服务器第一个网卡插在 2k-a 的第三个口，那么服务器另外一个网卡也必须插在 2k-b 的第三个口，不能接到其他的接口上。这个由于我们事先没有跟布线的工程师交代清楚，在物理链路全部接通开始调试发现丢包其高的情况下，排查了两个多小时才发现了问题所在。最后发现如此简单弱智的问题之后，直接奔溃。这类问题总结起来就是我们把问题想的太简单，怎么样才能确认没有问题万无一失了。换位思考一下，如果你是现场布线的工程师，在没有任何书面操作流程或者文档的情况下，你能知道哪组机柜哪台服务器的哪个网口接哪个物理位置交换机的哪个端口吗？如果不能确认，整理一张完整的端口到端口的 Excel 表格打印下来交给他们再交代一下应该就能避免此类问题。
3) 升级步骤不够简化。后期回顾发现其实当晚完全没有必要把服务器的 bonding 也一次性搞定，当晚要做的事就是先保证基本的网络通畅，剩下的可以在保证 752 成功之后再一组一组的重启生效。但是在升级之前我们已经修改的所有服务器的网络配置包括加载 bonding 模块等，"万事具备只欠重启"。雪上加霜的是，除了基本的网络出了很大的问题之外(依然能 ping 通)，还有四十多台的服务器重启之后网络完全 ping 不通了，没办法，一台一台的接上显示器人肉查看，问题的原因是千奇百怪，包括下面几类，几十台机器还是比较有代表性的:
50% – 执行完 reboot 之后，kernel panic，后来通过 cold reboot 拔电源暂时解决
30% – 起来之后，OOM，机器直接 hang 住了
15% – 启动过程中磁盘检测未通过或者无法跳过检测，导致无法往下进行
5% – 系统起来之后，网络没起来的以及 ssh 没起得来的
而上面这些所有的问题完全是可以等包括远程卡在内的基础网络接通之后择日再重启的。如果按照上面的步骤，那么 18 日 10:00pm 开始的操作也不会耗到 19 日早上的 9:00am 才暂时结束。
3. 分工不够细化
一个人搞的优点是自己一手掌握整个系统的每一个细节，出任何的问题基本都能很快找到问题的根源并解决，缺点也是很明显，系统变大之后几乎不可能面面俱到，一个人的力量非常有限，更何况这几个晚上的操作只是整个升级的一小部分，前期的产品调研测试采购上架等工作也是相当不小的工作。既然分工，这里就存在工作职责划分以及划分到哪个层面的问题。比如细到端口到端口对应这类问题，我在分工的时候大意没有考虑到这个问题，真正操作的时候，我们的工程师同样没有料想到会出现这个问题，结果现场的布线工程师就真的发生了，付出的代价不比重布一套网线要小，想像一下，一台服务器两根网线，数百台的机器。所以，接下来要做的是分工需要更加的细化，细化到每一个不可以拆解的步骤，否则迟早还是会出问题。除了上面说到的主要问题之外，还有个小插曲，升级到次日凌晨两点多的时候我们 ne 才告诉我说身体不舒服，发烧了，这给当时已经不稳定的局面更加的雪上加霜，如果提前告诉我，哪怕是升级的前几分钟告诉我，我也会立即取消本次升级。以后这类重大的事件多嘴确认下团队人员的健康状况还是很有必要的，否则做到一半，骑虎难下，只能硬着头皮上了。
另外，本次升级又加深了之前的一个感受：同时熟悉多个领域，尤其是两个领域衔接的灰色地带，宏观把握问题的人太少，出了问题大家都是各扫门前雪，倒不是说大家都没有责任感，可能确实能做的事有限，既懂三层以下，又熟悉三层以上包含从系统到服务直至业务层面的少之又少。
Related Posts:
由 udpwork.com 聚合
|
评论: 0
|
要! 要! 即刻! Now!
