【IT168 评论】现代数据中心基础设施愈发复杂、各组件之间的依赖关系也更加紧密，我们很难预先判断某一组件出现故障时会对全局造成何种影响。

　　随着现代基础设施技术在性能上的不断攀升，其复杂性与各组件之间的依赖关系也变得更加紧密。这种变革一方面使IT部门的日常工作更加轻松高效，却也同时令故障更加难以梳理与排查——某些故障甚至可能需要经过数月甚至数年才被检测出来。

　　过去，一套典型的企业数据中心可能包含多台服务器、某些机顶式及机底式网络交换机设备外加一些大型存储阵列。这类环境中各设备间的关联性显而易见：服务器的正常运作依赖于网络与存储机制的可用性。而网络与存储(及存储相关网络)则相对较为独立。

　　如今，情况则完全不同。服务器虽然依旧存在，但刀片式机架的广泛普及为我们带来内置融合型网络体系、且将局域网与存储的连通工作纳入其中。而存储机制则作为附加设备直接接入整个体系。除此之外，融合型网络的某些关键性功能还可能需要借助刀片服务器上运行的软件方可正常起效。更为复杂的是，如果使用基于IP的存储方案，即使是访问存储内容这样简单的诉求也需要涉及数据中心内的所有组件。

　　大家很可能在尚未明确认知的情况下建立起这样一套环环相扣的循环依赖体系。如果运气不好，我们往往会在大量组件出现问题后才意识到设计中存在的严重缺陷。要想真正避免这种循环依赖性的出现，我们需要拿出大量时间阅读说明文档、通过图表理解设备的依赖关系，并通过严格测试验证自己的构思。

　　真实案例

　　尽管我在实际工作中已经见识过很多此类状况，但其中最具代表性的例子当数EMC VMware vSphere环境下的思科Nexus 1000V虚拟交换机。需要强调的是，我可算是软件定义网络的坚定拥护者。虽然软件定义网络尚不完美也称不上无法替代，但Nexus 1000V仍然是我所接触过的最强大的产品之一。不过虚拟方案与采用物理交换机存在诸多差异，而且它与大量外部及内部组件构成了严密的依赖关系。

　　在这次的实例中，vSphere主机配备有两块铜缆1Gbps网卡作为流量管理前端、另有两块传统(非nPAR/CNA)10Gbps网卡作为虚拟设备网络接入及访问业务环境中NFS存储的连通机制。

　　对于不熟悉这款产品的朋友，我在这里做一点简单说明。Nexus 1000V由两大基本组件构成：虚拟监控模块(简称VSM)与虚拟以太网模块(简称VEM)。VSM充当模块化交换机中的监控模块，而VEM则作为接口卡。控制层与管理层由VSM实现，但数据层的交换工作则主要由VEM负责。

　　从实践角度看，VMS被作为主机上运行的虚拟设备装置(作为高可用性需求下的可选次要装置)。VEM则作为软件模块被安装在每台主机上的vSphere管理程序当中。当然，VSM与VEM之间的通信也很重要，这是因为VEM只有在VSM的辅助下才能了解需要执行的任务以及具体配置方式。这中间显然存在强烈的依赖关系。另外，VSM与VMware vCenter之间同样存在强烈的依赖关系，后者的作用在于协调各vSphere主机之间的交互活动。

　　一旦VSM与VEM之间无法完成通信，VEM也就失去了对流量的交换能力。而如果VSM与vCenter之间无法完成通信，用户对虚拟机网络配置进行的变更将无法生效(由双方同时触发)。相比之下，在外部搭配两台物理交换机就要简单得多，只不过虚拟化方案的可管理性更出色。

　　在此次部署工作中，我还犯下了一些严重的错误——而且直到引发恶劣影响才被发现。那是一个假日，整套基础设施突然遭遇供电中断;虽然电力供应很快恢复，但技术人员发现很多组件明显无法正常工作。最终我们花了八个小时来定位故障原因并找出解决办法。

　　最终我们将故障原因归结为两项关键性疏漏：追踪监控缺失与依赖关系规划不足。先说第一条，Nexus 1000V的任务是打理vSphere服务器上的两块10Gbps网卡——两块网卡还负责访问保存在存储设备中的虚拟机系统。我估计自己在部署时可能一时走神，导致在将Nexus 1000V VSM导入SAN存储后竟然忘了将其移动到本地存储当中。

　　正因为在VEM未激活的情况下无法访问存储机制，所以VSM在停电后不能正常启动——反之亦然。直到调整之后，VSM才恢复了正常运作，而其它虚拟机也随着VSM的启动而陆续上线。

　　上述问题解决之后(需要利用一些前端网卡来访问存储设备)，整体情况仍未恢复正常。虽然vCenter虚拟机使用的是1Gbps网卡上的基本虚拟交换机(意味着与Nexus 1000V不存在依赖关系)，但该虚拟机运行所必需的甲骨文数据库却无法脱离1000V独立起效。更糟的是，虚拟机由于包含有需要访问10Gbps网卡的生产用数据库而无法被迁移至1Gbps网卡这边。虽然只是为了快速使体系恢复正常而对配置做出临时变更，但数据库最终还是被迁移到另一套虚拟机系统当中。

　　与技术无关：两大关键教训

　　此次事故给我和其他技术人员上了一课，大家意识到将Nexus 1000V部署在生产环境中实在很不明智。(顺带一提，只要将1000V与vCenter组件运行于二者的管理环境之外，以上难题根本不会发生。)不过在具体技术之外，我们还应该从中总结出一些更具广泛意义的教训——无论是否实际使用1000V交换机。

　　第一条关键教训在于，我们需要有条不紊对配置部署加以严格检查、而后才能将其纳入生产环境——这一点非常重要。很多技术人员习惯于“知道了，过会儿就来处理”这类态度，但随着IT工作强度的日益增大、我们真有空闲回头对已经完成的工作进行重新审视吗?在这次事故之后，我会在每个项目中创建一份提示清单，借以提醒自己在项目后期切实将遗留问题逐一解决。如果做不到这点，我们很可能在项目中留下致命隐患、而自己却全不知情。

　　第二项关键教训在于重视测试环节。在前面的案例中，我们本应该在实际投付生产之前对全局基础设施进行大规模停电及恢复供电测试(一旦进入正常运行，我们将无法根据需求随意关闭基础设施)。在很多人眼中，这种严格测试似乎是在浪费时间;但大家完全可以利用假期拉下电闸、再在下次上班时恢复供电，这不仅能够切实完成测试工作、而且也不至于给员工带来额外负担。

　　归根结底，态度决定一切。尽管不少人认为IT部门在企业中的重要性已经被大大削弱，但身为技术人员、我们的小失误仍然会在基础设施复杂性与依赖关系日益增强的今天给全局业务带来严重影响。如今单一组件的作用远大于以往，一个简单的错误就能让整套基础设施陷入瘫痪。而随着数据中心基础设施边界融合趋势的普及，这种牵一发而动全身的难题将越发常见。