背景
本周，我司完成了一件大项目——完成核心机房网络架构升级改造。
此次网络架构改造涉及所有核心交换设备硬件升级，包括了：外网核心交换机、内网核心交换机以及接入层交换机扩容，稍微了解网络的同学应该都知道，在一个跑满线上业务的机房，动核心意味着什么。
我们简单举个栗子，一架飞机在天上飞，必须由飞机引擎不断提供动力，才能够保持稳定飞行，而我们这次做的变更，就相当于在飞机飞行的时候，更换了飞机引擎。然而，在换引擎的时候，不可避免的会造成飞机失去动力，导致飞机下降。所以，我们必须保证飞机在滑落到地平线之前，保证引擎更换完毕并保持正常运转，再次恢复之前的稳定飞行，从而完成整个更换操作。
那么，肯定有人会问了，飞机飞的好端端的，为啥要换引擎呢？不是自找麻烦吗？
我们当然不会平白无故去换机房核心交换机，肯定是遇到了不可抗拒问题，并且又无法快速修复，才会考虑本次核心机房网络架构升级操作。
P.S., 说让飞机降落再换引擎的同学就不要追问了，我们这里只是做个比喻，飞机如果真降落了也就意味着我们的线上服务都关停了，这种情况是不可能发生的。
改造原因
此次网络架构升级的主要原因是：
- 原内网核心交换设备CPU长期负载较高，业务高峰时期CPU甚至经常达到100%状态，已严重影响产线正常业务稳定性。为报障业务持续稳定性及后续可扩展能力，必须对其进行物理设备升级。
- 接入交换机均为单点状态，无堆叠无备份，一旦发生接入交换机故障，将会出现整个机柜的网络中断，且短时间内无法恢复
改造方案
具体对应网络设备升级方案：
- 升级内网核心交换机，由原先3750替换为N5K，以降低CPU利用率，提高交换机性能，保证稳定性
- 升级外网核心交换机，由原先3850替换为N3K-3172，以适配由于内网核心交换机吞吐能力提高所带来的性能压力
- 升级接入层交换机，由原先2960替换为N3K-3048，并使用VPC（Virual Port Channel）技术，保证接入层具备冗余能力，并且提高上联带宽值（由原先4G提高到现在的40G）
全员准备
既然决定要做，那么必须保证万无一失，而网络架构升级，影响的不仅仅是网络，牵一发而动全身，我们共有14个业务线产品部署在该机房，为了准备这次变更，我们花了将近半年的时间，来对机房网络架构以及各业务线调用情况进行梳理，以确保升级操作的有序进行，并且将业务影响减小到最低。
该项目由今年4月中旬开始立项，跨部门联系紧密，各部门开发、运维、测试及项管全员出动，共同为升级保驾护航。
前期准备工作
- 网络设备采购
- 核心网络设备、板卡采购（提前6周~7周左右）
- 服务器网卡采购（只对单网卡服务器进行采购，提前1个月左右）
- 光纤采购（交换机互联）
- 网线采购（机柜内接入交换机到服务器连接）
- 服务器Xen转KVM
Xen虚拟机无法做BOND绑定，无法完成平滑迁移，所以必须先将服务器迁移至KVM虚拟机 - 规范服务器网卡BOND模式
由于需要平滑迁移，需要对机房每台服务器都做BOND绑定，设置为主备模式，主网卡接老交换机，备网卡接新交换机，变更当日老交换机端口shutdown，新交换机端口启用，完成平滑迁移 - 业务梳理
- 应用服务中断预演
变更当日计划
- 前置工作
- 可以迁移至其他机房的业务迁移至其他机房，保证业务服务不中断
- 取消有状态服务故障切换策略，如MySQL、Redis等
- 关闭跨机房大数据同步操作
- 报警抑制，取消报警自动升级策略，如微信、电话呼叫等
- 停服
- 各类应用服务停服
- 停数据库
- 数据库只读
- 网络变更
- 切外网核心交换机
- 切与其他机房间专线
- 切各类网关层设备，如F5、防火墙等
- 切接入层交换机
- 切VPN设备
- 开服
- 数据库恢复可写
- 启动各类应用服务
- 先前切至其他机房的业务迁回本机房
- 恢复故障切换策略
- 开启跨机房大数据同步操作
- 恢复报警功能
具体实施
计划再缜密，也会有不确定因素出现，下面列举几个变更时遇到的幺蛾子，虽说略有惊险，但也没影响到主线计划：
-
保证机房内热点持续可用
在机房做变更的兄弟们都是WIFI连的某台笔记本联网，突然发现网断了，ping哪儿都不通，还以为是设备故障，后来才发现原来是提供热点的笔记本出了故障，重连了下就好了，把大家都吓了一跳。 -
测试外网核心交换机时出现意外
在切换外网核心交换机后做验证时，发现ping不通公网，还以为是交换机问题，后来才发现是测试机柜没划分VLAN导致无法连通，这点是实现没考虑到，也是吓了一跳。 -
salt-minion连接超时后进程消失，需重启服务
salt-minion在连接salt-master超时次数过多时，有可能会造成进程消失，进程挂掉之前salt-minion最后日志记录如下，此时需要下发salt-minion启动命令，或手工，或批量，我们这边是通过zabbix批量下发启动命令的。
2018-08-01 03:01:47,606 [salt.minion:650 ][ERROR ][29456] No master could be reached or all masters denied the minion's connection attempt.
2018-08-01 03:01:47,650 [salt.scripts:146 ][WARNING ][29456] Fatal functionality error caught by minion handler:
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/salt/scripts.py", line 144, in minion_process
minion.start()
File "/usr/lib/python2.7/site-packages/salt/cli/daemons.py", line 350, in start
raise SaltClientError('Minion could not connect to Master')
SaltClientError: Minion could not connect to Master
后记
周密的方案设计，夯实的技术功底，兄弟们的齐心协力，天时地利人和，使得这次升级操作圆满完成。
有了这次成功经验，相信以后我司再做类似变更操作时，大家心里就更加踏实有底了。
奋战在机房一线的兄弟
运维部彻夜值守的兄弟们
上海张江清晨6点的太阳
