分类： 服务器与存储
2014-08-08 13:04:51
在我们项目后期的维护中，经常会碰到各种场景下linux系统的引导故障。对于这一个故障以及其他故障问题的排查，在问题排查的思路方面，显得尤其重要。了解了项目现场的设备架构、原理、连接方式、系统故障现象后，要由故障现象反推，一步步排查，测试硬件、链路等是否存在问题，进而定位出问题的根源在哪里。
文章会结合具体项目中的故障现象，与大家分享排错思路。
1. 故障现象
公司的IDS（统一身份认证）应用所在的操作系统无法正常引导，故障现象：
可以看到，这个故障现象很抽象，没有报错，只是在硬件自检完后出现光标在闪烁。需要结合项目现场环境、架构等来进一步排查。
2. 项目设备架构
项目现场是采用典型的VCE架构（vmware虚拟化、cisco的UCS刀片服务器、EMC存储），并在cisco 的UCS服务器中采用boot from san的方式做配置。
FC SAN的架构下，服务器去连接存储空间，必须要基于光纤交换机（8G
FC SAN）的zone配置。
“Boot from san”顾名思义，就是将操作系统安装在存储空间中（刀片服务器不需要配置本地硬盘），以目标存储空间作为系统的引导源。结合故障现象，现场采用的设备架构等，可以初步判断故障是由于刀片服务器中的BIOS在加电后，没有找到目标存储空间。
下面我们就需要去定位哪一个环节的问题导致刀片BIOS无法找到目标存储空间。
3. 排查过程
a) 检查硬件
问题的排查，首先我们要检查硬件是否存在部件故障或损坏。在这个项目中，我们需要确认如UCS刀片服务器、UCS机头、光纤交换机、存储等设备。
在逐个检查了UCS、光纤交换机、存储等设备后，确认硬件没有故障。
b) 检查链路
i. Cisco的UCS刀片服务器的组成以及配置方式，与其他品牌服务器不一样。UCS刀片服务器对于刀片的配置，采用serviceproflie配置文件定义的方式，刀片本身的hba卡、网卡均通过一张融合虚拟卡来虚拟。注：hba卡用于服务器连接存储空间。
所以检查链路的第一步，先测试刀片服务器本身的虚拟hba卡是否有故障：
将该刀片的serviceproflie配置文件中的vhba卡删除，重新新建两个vhba卡
再次重启该刀片，依然还是无法引导操作系统。
ii. 检查该刀片的boot from san的boot order链路配置，一条一条排查，确认是否是连接路径存在的问题。
默认的boot from san的boot order链路配置如下：
将boot order链路配置里的4条路径逐条删除去测试，如第1次将最下面的一条路径删除，之后重启刀片，查看能否引导操作系统。
前后4次测试，结果还是无法正常引导操作系统。可以确认不是由于boot from san的boot order连接路径导致的问题。
c) 检查设备日志
登录到光纤交换机、存储，检查并确认了光纤交换机zone的配置是正确的。登录到存储中，发现有IDS-1操作系统的连接报错，通过报错信息可以知道是连接没被激活，主要还是因为存储没有读到，系统无法引导。
d) 进一步确认链路以及存储识别
上一步操作，在确认了整体的链路没有问题后，我们再进一步验证存储的识别是否可以。
尝试通过vmware esxi的iso镜像文件重新引导故障刀片，验证测试能否识别到存储：
上图的测试结果证实，故障刀片可以正常识别到存储，进一步确认链路没有问题。
e) 反推操作系统故障
结合上述的测试结果，既然整体的链路都没问题、存储的识别也没有问题、硬件也没有故障，怀疑是否是本身操作系统引导分区损坏导致无法引导。
通过在存储中新创建一个LUN，映射给故障刀片，然后在新划的LUN中安装操作系统，并测试重新引导是否能正常启动，来反推断是否是原有的操作系统故障导致的问题。
i. 在存储中新建一个LUN，大小为30G，并映射给IDS1的Storagegroup
ii. 开始在新划的LUN中测试安装vmware esxi5.5操作系统
可以看到刀片式可以正常识别到所有的存储，找到目标的30G存储LUN，选择下一步，开始安装esxi5.5虚拟化操作系统
直至系统安装完成，并且确认重启可以正常引导
至此，可以确认故障刀片的链路以及存储识别没有问题，是由于原有的操作系统故障导致无法正常引导。
f) 解决故障
重新在原有的存储LUN上安装linux操作系统，并确认重启可以正常引导，解决该问题。
4. 总结
操作系统的故障问题，在解决处理的过程中，不光要联想本身系统的问题，还要结合具体的设备架构环境，整体去考虑，按照正确的步骤去解决，往往效率会更高。
