我的一台OpenStack物理机故障排查追踪实录

　　一、问题现象
　　一大早刚上班来，团队的同事说客户的一个私有云主机故障了，一个节点无法启动，于是赶紧跟进了解了一下情况：
　　这个私有云是我们给客户构建的，基于openstack实现的一个IaaS基础设施服务，出现故障的这个节点是存储节点，客户说由于此节点突然无法分配存储资源，就重启了节点上的服务，可服务始终无法重启，于是，客户就放了个大招，重启了操作系统，没想到，系统重启后，再也起不来了。
　　出故障的服务器节点使用的操作系统是centos6.9的版本，这个私有云也在线上运行了2年多时间了，还算稳定，怎么就无缘无故的无法启动了呢，客户是百思不得其解，带着疑问，登上服务器深入了解下情况。
　　这是个DELL服务器，配置为28C/64G/42T HDD10k，服务器自带了SD卡，这个SD卡其实就是个小硬盘，主要用来安装操作系统，而centos6.9就安装在这个100GB左右的SD卡上，既然是系统无法启动，就从系统开始查起。二、问题排查
　　想远程ssh登录系统查看，结果发现这个故障节点的ip根本无法ping通，只能连上显示器在服务器上直接查看现象了，连上显示器，就发现了如下信息：
　　这里重点看红框里面的内容，提示无效的用户＂root:disk＂、＂root:lp＂，这是系统启动过程中执行chown命令时发现的错误，这里面涉及到root、disk、lp三个用户，具体是哪个无效呢，继续往下看这张图，看第二个红框的内容，基本可以断定是root用户无效，怎么root用户会无效呢？这个有点异常。
　　那么首先查看一下root用户的相关信息吧，由于系统无法正常启动起来，只能出绝招了，可选方法很多，常用的招数有两个：
　　（1）、重启系统，然后进入单用户，看看能不能正常进入，如果可以，那么下面的事情就好办了。
　　（2）、通过操作系统的引导盘，进入rescue模式，然后挂载上SD卡对应的分区，最后查看root账号的配置信息。
　　首选尝试第一种方法，重启系统后，选择进入单用户模式（进入单用户方法本专栏前面已经介绍过，这里省略），发现无法进入，仍然卡在上图所示的界面中，看来进入单用户这招不灵了。
　　那就使用终极大招吧，使用第二种方式，通过操作系统的引导盘，进入rescue模式（此方法本专栏前面也已经介绍过，这里省略），这个方法应该好使，不错，顺利进入，进入rescue模式命令行后，首先查看下这个系统的/etc/passwd文件，此文件记录了每个用户的属性信息，看看root用户的属性是否正常，由于是在rescue模式下，所以查看passwd文件的路径应该是/mnt/sysimage/etc/passwd,内容截图如下：
　　从图中可以看出，压根没有root用户的属性信息，这肯定不正常。
　　接着，又查看了/mnt/sysimage/etc/shadow，发现有如下信息：root:$6$.fPn3lem$EAtGRqd2MqR8kDzpHIYxGfjMhjHp1C0:17364:0:99999:7:::
　　shadow文件中记录的是root用户的密码以及过期时间等属性信息，发现root密码是存在的，并且永不过期。
　　到这里，基本清楚是怎么回事了，应该是用户有意删除了passwd文件里面root的属性信息。既然知道是这个问题了，那就尝试在passwd文件中添加root属性信息，看看是否能够正常启动，root用户在passwd文件里面的属性信息时这样的：root:x:0:0:root:/root:/bin/bash
　　其实，就是指定root的属主和组，以及根目录和默认shell，将上面这段信息添加到/mnt/sysimage/etc/passwd文件中，保存退出。
　　下面再次重启系统，看看能否正常启动，去掉引导镜像盘，正常启动系统，看似一切正常了，如下图所示：
　　看到绿色的OK字样，感觉问题已经解决了，可是左等右等，一直在这个界面静止了10分钟，仍然没有继续引导的意思，看来还有其他问题。一直等了半个小时，还是这个界面，没有任何报错信息，这就比较郁闷了，因为没有任何报错信息，所以无从下手（此时才知道报错信息对排错是多么重要啊）。
　　干等也不是办法，与其等着报错信息出现，不如另寻思路，从上面图中可以看出，系统正在逐个启动服务，系统磁盘分了两个区，都挂载正常，最后一个启动成功的是iptables服务，而接下来要启动的服务，应该出现了问题，导致导致系统卡住了。
　　为什么有这样的思路呢，这要从linux的启动机制谈起了：
　　Linux操作系统的启动首先从BIOS开始，接下来Linux引导程序将内核映像加载到内存，进行内核初始化，内核初始化的最后一步就是启动PID为1的init进程。这个进程是系统的第一个进程，它负责产生其它所有用户进程。大多数Linux发行版的init系统是和System V相兼容的，因此被称为sysvinit，这是最早也是最流行的init系统，在RHEL7.x/Centos7.x发行版本之前的系统中都采用sysvinit。
　　sysvinit概念简单清晰，主要依赖于Shell脚本，它的主要特点是：一次一个串行地启动进程和服务，这里面一个重要的概念是串行，也就是说服务的启动时一个接一个完成的，上一个启动成功，下一个才能开始启动，而如果上一个服务由于某种原因无法成功启动，那么整个系统服务的启动就卡住了。
　　那么，各个服务的启动顺序是怎么规定的呢，在init管理机制下，首先有系统运行级的概念，init可以根据使用者自订的执行等级(runlevel)来唤醒不同的服务，以进入不同的操作模式。基本上 Linux 提供7个执行等级，分别是0, 1, 2...6。而各个执行等级的启动脚本是通过 /etc/rc.d/rc[0-6]/SXXdaemon 链接到 /etc/init.d/daemon下。daemon为各个不同服务的管理脚本。
　　链接文件名 (SXXdaemon) 的命名和定义是有不同含义的： 其中，S为启动该服务，XX是数字，表示启动的顺序。数字越小，越早启动服务，反之，越晚启动服务，由于有SXX的设定，因此在开机时系统可以根据这个数字顺序，从小到大依次启动需要开机启动的服务。
　　很明显，我们这个案例中，应该就是这种情况。
　　明白了系统的启动机制后，要解决这个问题，方法就很多了，这里我们捋一下思路：
　　（1）、首先，检查一下在iptables服务启动后，下面要启动的是哪个服务，因为就是这个服务卡住了系统无法启动。
　　（2）、接着，找到这个服务后，可以暂时关闭这个服务的开机启动，也可以找到无法启动的原因，让他能够正常启动，这样系统不就可以启动起来了吗！
　　思路一旦形成，就可以马上动起来了，要查看iptables服务启动后，接下来要启动的是哪个服务，必须要登录到系统中，所以，还是通过操作系统的引导盘，进入rescue模式，然后进入到/mnt/sysimage/etc/rc3.d/（这里因为我的系统运行在init 3等级下，所以是进入rc3.d目录，如果你的系统运行在init 5运行级下，那么就进入rc5.d目录）下，发现如下内容：
　　从图中可以看出，启动iptables服务的是S08iptables这个软连接，那么紧接着要启动的服务序号肯定是S09，也就是红框中的S09mysqld，此链接对应的竟是mysql服务的启动脚本，也就是说，在启动mysql服务的时候，发生了问题，导致mysql无法启动，进而导致系统无法启动。罪魁祸首好像找到了。
　　那么为什么mysql服务无法启动呢，显然，这不是目前我们关注的重点，我们现在急需要解决的是让服务器启动起来，其它问题，随后在解决也不迟。
　　既然如此，那就先关闭mysql服务的开机自启吧，仍然在rescue模式下，执行如下命令：bash-4.1# chroot /mnt/sysimage/   #表示将/mnt/sysimage/目录下的文件移动到根目录 sh-4.1# chkconfig --level 35 mysqld off    #关闭mysql服务在运行级3、5下的开机自启动
　　执行完毕，再次查询，mysql自启动服务已经不存在了，如下图所示：
　　好吧，最后，再来一次重启吧，重启系统后，又发现了新的情况：
　　重点看红框里面的内容，已经提示的很明显了，磁盘空间不足！！！，what！！！瞬间，我淡定了。
　　原来这里所发生的一切，都是磁盘空间问题导致的。监控哪里去了？？
　　不过好在这次系统终于正常启动起来了，虽然报了磁盘空间不足的错误，启动起来后，通过ssh远程登录，输入root密码登录系统，然后查看磁盘空间，如下图所示：
　　看到了吗，系统根分区100%，无一点剩余空间。简单搜索了一下系统大文件，发现了如下日志文件：[root@234server nova]# pwd /var/log/nova [root@234server nova]# ls -sh nova-network.log  88G nova-network.log
　　这个log文件达到88G，肯定是这个文件塞满了磁盘，先清除再说。清除此日志文件后，再次重启系统，一切恢复正常。三、问题总结：
　　此案例中，主要有两个问题：
　　（1）、第一个问题是root用户为何无故被删除，最后询问了客户，客户说但是root登录不安全，就从网上摘抄了一个方法，从passwd文件中删除了root配置的那行内容。
　　（2）、此系统已经运行很久了（超过2年），而系统是安装在了SD卡这个小硬盘上的，所以忽略了磁盘空间问题。在这个SD卡上，日志数据日积月累，终于塞满了小磁盘，而客户那边也没有对系统磁盘做监控，最终导致了此次事故的发生。
　　经过这个案例，我们想说的是：
　　（1）、禁用root远程登录的思路是对的，但是方法不对，linux下面提供了很多种普通用户和root之间协助的方式，下面会重点介绍下这个思路，而客户这个删除root配置属性的做法显得太拙劣，因为他不知道root用户不仅仅是一个用户而已。root用户是系统中唯一的超级管理员，它具有等同于操作系统的权限。一些需要root权限的应用，是需要root账户来执行。而系统在开机启动的时候，是会进行很多初始化和启动服务的操作的，而这个过程，有些系统服务是必须通过root用户来启动和运行，而一旦删除了root用户，这些系统服务就会启动失败，导致系统无法正常完成启动。
　　可能有同学要问了，那我创建一个跟root用户一样权限的用户，能否替换root呢，答案是不行的，因为很多服务默认已经指定了通过root用户来启动。所以root用户不能删除，它不是一般意义上的用户。
　　（2）、DELL服务器提供的SD卡，是给虚拟化使用的。也就是说将虚拟化软件可以直接安装到这个SD卡上，例如VMware ESXi Server或者Microsoft Hyper-V Server，感觉这个功能很鸡肋，因为一个SD卡可靠性很低，要安装到SD卡上，至少要双SD卡，用来作为冗余，而单SD卡还不如直接将系统安装到服务器的大磁盘上做raid保护。
　　另外，将操作系统安装到SD卡上，真的没有任何意义。