本期主题：运维服务之【基础环境】

<暑期学校故障少，七夕老师过得好！>

随着云计算、VMware虚拟化、存储云化等技术的发展，为了满足多样的服务，底层硬件架构与上层应用部署架构都逐渐复杂化。纵然发现系统异常，也难以快速定位到问题出在哪？软硬件的复杂化让学校在故障定位上的效率越来越低。

本期【干货攻略】小智带来的是某211高校业务访问缓慢处理分析真实案例，希望能在故障排查思路方面带来一点思考和启示。

▼

“OA系统突然访问慢了!”

“喂，邮件怎么打不开了？！”

一阵抱怨、质问、压力如洪水般向信息中心袭来...

在这之前，该校信息中心领导反馈，学校虚拟化的ESXI主机经常无响应，虚拟机业务也不能访问；紧接着就是各业务部门的反馈声音蜂拥而至，此时，故障排查一刻不能耽搁，需尽快处理！

学校虚拟化环境一览

总体：200多个虚拟机，38台ESXi主机，3套vCenter，不间断使用

细节：目前有三箱刀片服务器，连接至统一存储，提供高效高可用的虚拟化环境。刀片服务器上联到汇聚交换机。其中有一箱刀片服务器运行数字化校园业务，另外两箱运行一卡通、邮件、托管业务（这也是大部分学校的配置思路）。

<该高校当前环境拓扑>

▼

1.全局分析检查

用户的反馈是访问慢，那么这时候需要了解：哪些业务慢，什么时间段慢，是加载页面慢还是卡在认证或者表单上？通常用户给的信息是全都反应慢！查看一卡通、邮件、数据库、数字化校园业务全都慢！而时间不定时。

反应如果是全局，就需要找到共性的点，而在上面的拓扑图中，很容易看到最终3个刀箱的共性点为存储。查看虚拟化平台日志，也看到很多关于丢失存储卷访问权的报错；

查看几个重点虚拟机的磁盘性能，在滞后时间的图表中，最大达到了8000ms以上，这代表着从存储读写有大概8秒左右的延迟；

查看存储，没有任何硬件问题，电池在有效期内，没有读写透传。另外一份来自EMC的分析报告中显示读取百分比较高且SAS和SATA盘IO较高；

查看虚拟化平台、刀片服务器平台没有任何硬件错误；

查看光纤交换机有部分错误包，但观察一段时间无明显增长，不能判断是历史累计还是近期增加。

2.阶段故障处理

基于虚拟化平台普遍对于存储读写延迟过大，且SAS磁盘IO达到90%，其他平台没有明显报错的现状，决定先重启存储，释放缓存资源，并且让底层硬件、系统重新自检。

在制定了完整的重启方案，保证业务数据有效备份后，重启存储。

存储顺利重启后，查看存储平台，各部分运行正常。再查看光纤交换机，清空所有错误包日志，启动业务过程中持续观察，并无错误包增长；查看虚拟化平台无存储卷访问权丢失及延迟过大报错。所有业务启动完成后，再次观察各个平台，所有均显示正常，且业务访问速度恢复。

3.重新分析检查

本以为处理到此结束，但就在全部工作人员都回家补觉时，故障又传来：访问又开始变慢。攻城狮又从梦乡回到电脑前，查看虚拟化平台，果然报错又出现了：丢失访问权、磁盘滞后时间变大。再查看光纤交换机，错误包集中在1、2号端口和6，7号端口，且还在增加错误包。

查看端口连线表，1、2号端口分别连接到存储的两个控制器，6、7号端口连接到第三号刀箱。

存储重启无任何硬件报错，那么剩下问题可能出现在从光纤交换机到刀箱的链路。为了证明存储确实无问题，且查看是光纤交换机故障还是刀箱，或者刀箱到光交之间的链路之间的故障，决定先把刀箱三中的业务迁移出去。

利用虚拟化平台的迁移，把所有刀箱三中的虚拟机在不影响使用的前提下，动态迁移到另外两箱刀箱，关闭第三箱刀片中的所有服务器，然后清空光纤交换机的计数器，重新观察错误包及业务运行状态。

4.阶段故障处理

这时，问题节点已经被隔离，因此可在现场放心处理不会影响业务的正常运行。首先升级刀箱三的所有固件，包含：刀箱IMM管理模块固件、FC交换机固件、SW交换机固件。目的是排除刀箱到光纤交换机之间的链路。

在升级完所有固件后，再次清除因关机引起的链路丢失的错误数据，对所有服务器开机后观察错误包。在观察数小时后无错误包。此时迁移部分业务到此刀箱中，再次观察，依然无错误包。

5.虚拟化深度优化

经过1天的观察，错误包已经完全消除；ESXI主机无响应已经得到了解决，但业务访问慢的问题依然存在，经过现场的环境分析以及现场项目经理的业务使用分析，针对学校业务进行以下优化步骤：

版本升级与驱动更新

学校目前虚拟化平台存在多种版本（5.1、5.5等），并且采用多套的vCenter虚拟化管理平台进行管理，这对于日常的管理以及计算资源的分配上会造成很大的影响；同时虚拟化版本与硬件驱动的不匹配还会直接影响虚拟机的稳定性（前面处理的版本问题就是其中一个刀箱不稳定因素）；

至此，本次统一将学校5.1和5.5的虚拟化环境根据VMware的官方兼容性建议升级至5.5 U3（该硬件型号暂时不建议升级到6.0）；

统一管理平台及动态策略

多套虚拟化管理平台会对资源的分配造成很大的阻碍，这会直接影响虚拟机的计算性能；同时现有的3套vCenter平台都是使用系统自带的数据库，对于200多台甚至未来更多的虚拟机业务，在动态分配、分布式交换机等使用效率大大降低。

本次部署全新的vCenter 5.5 U3平台及独立的SQL Server 2008企业版；在动态资源分配上，根据业务类型划分集群，制定资源策略，合理分配现有的CPU和内存资源，避免两个相同业务（例如OA系统）在同一台机器上，同时对于2个高并发业务也分散到两台服务器中。

<优化后的环境拓扑>

网络资源调配

目前的网络是采用vSwitch和VDS分布式交换机混合的方式，在网络的资源使用上会造成很大的影响，该学校在业务使用上明显感觉OA系统、邮件系统、就业系统等使用缓慢，存在其他虚拟机的资源抢占的几率，我们采取port-group分组的方式将OA、邮件、就业等业务划分，将关键的业务绑定独立网卡，保证带宽。

磁盘权重调整

最后从本次学校的存储数据上可以看出整体的磁盘使用是比较高的，除了已经提交的存储性能整改方案之外，对于虚拟化平台中也需要对磁盘做整体性能保证，目前的做法是根据磁盘的使用情况对现有应用进行分级，将门户、OA、人事、学工、邮件、移动等关键业务作为高优先、其他科研、社科、就业等关键业务做为中优先，院系系统、查询类的作为低优先；分别按照3000、2000和1000权重值分配磁盘权重，提高磁盘读写效率。

6.问题解决

经过上述的全局分析---阶段处理---重新分析---阶段处理---深度优化逐步对学校的问题进行排除和根治，最初解决显像出来的故障，再逐步根据业务进行优化，解决隐患。

经过1周的观察，目前访问慢的问题已经得到了根本性控制，同时访问速度相比之前得到了明显提升。

▼

本次故障最终判断为刀箱交换机模块的微码问题，造成虚拟主机无响应，同时将学校虚拟化平台潜在的版本问题、管理问题以及性能问题都查找出来并且进行了有效的控制，找到访问慢的根本原因。

随着应用的不断深入，业务系统联接了全校师生的参与和关注，与他们的日常生活及工作息息相关，其影响力无出其右。现在成千上万的师生用户几乎7*24小时不间断的在使用业务系统，在使用体验上存在刚性需求。

虚拟化平台作为智慧校园至关重要的底层平台，除了覆盖网络、计算、存储等硬件设备之外，还涵盖了操作系统、中间件、应用系统等；看似操作简单，但出故障后定位难度远远超出预期。并且定位过程中，需要从硬件、平台、业务逐一排查以及根据业务使用情况进行分析。