服务器常见故障处理

服务器常见故障处理

网络管理员90%的工作往往是诊断和解决各种各样的故障。为了说明诊断网络故障的一般过程，本文例举了几种故障情形，有的是常见的小问题，有的是比较艰巨的挑战。当你遇到类似的问题时，就可以按照本文例子的介绍，先问自己几个简单的问题，逐步隔离问题所在，最后找到真正的问题根源。

故障一、找不到验证密码的域服务器

毫无疑问，你也一定遇到过这样的情形：当你坐在一台工作站之前准备登录网络，Windows却报告说找不到用来验证密码的域服务器。要解决这个故障，首先要确定问题到底出在网络、工作站还是服务器上。从下面几个问题开始：

→哪些地方改变了?最近是否改动过网络，而这些改动可能导致当前的.问题?有没有添加新的服务器、拆除原有的服务器、改动过交换机或HUB?有没有添加或减少域控制器、将成员服务器提升为DC(域控制器)或者相反?

→其他工作站也存在类似的问题吗?

→服务器正在运行吗?

经过检查，你发现此前工作站一直顺利地运行，其他工作站没有遇到类似的问题，服务器也正常。根据故障现象，基本上可以确定故障出在工作站本身。接下来要确定工作站的那个地方出了故障，试试下面几个问题：

→工作站能够Ping到服务器吗?

→工作站获得了一个IP地址吗?

检测表明，工作站能够Ping到服务器，但Ping操作有时超时，这表明工作站和服务器之间只有断断续续的通信。在命令行上执行ipconfig/renew命令，多执行几次，工作站有时会更新IP地址，有时不会。这是工作站和服务器之间断续通信的症状。

现在将问题工作站的网络连接和另一台工作站的对换一下，新工作站在问题工作站的位置上也不能连接网络，而问题工作站却能从另一个网络位置顺利地连接网络。现在已经很清楚：问题工作站所在位置的电缆或Hub出了问题。

拆下故障位置上网络电缆连接Hub的那一端，将它接到另一个Hub上，故障依旧。现在可以肯定电缆就是引起故障的罪魁祸首了。

故障二、Windows服务不能启动

在一台Windows2000服务器上，部分服务设置成不用本地的系统帐户启动。一次重新启动Windows2000服务器之后，发现这些服务没有启动，必须手工打开服务，重新输入密码，然后启动服务。每次重新输入密码，都收到消息说：<用户名字>已被授予作为服务登录的权限。

要解决该故障，首先回答下面几个问题：

→哪些地方改变了?是否有人修改了服务器?

→这个服务以前能够启动吗?

→用户名称和密码正确吗?

查询修改记录发现，该服务器是一个DC，不久之前还是域控制器组织单元(OU，OrganizationalUnit)的成员。在移出该OU之前，这些服务一直能够顺利启动。另外，用来启动这些服务的用户名称和密码都是合法的。进一步研究发现，域控制器OU的成员有一些特殊的权限，其中包括作为服务登录的权限。当出现问题的服务器移出该OU时，服务器失去了那些权限。现在要做的是恢复服务器的权限。

要将权限授予服务器，请按照如下步骤操作：

→在管理控制台(MMC)中打开活动目录用户和计算机管理单元，再打开域控制器OU的“属性”对话框。

→在组策略页中，点击“默认域控制器策略”，然后点击“编辑”，打开组策略管理器。

→依次扩展计算机配置/Windows设置/安全设置，再扩展“本地策略”，然后点击“用户权利指派”。

→在右边的窗格中，右击“作为服务登录”，选择菜单“安全”。

→把用来启动服务的用户帐户加入到策略(图一)，完成后点击“确定”。

实例1：不能访问服务器

要先测试一下这一故障是否只影响一台工作站，这可以通过其他工作站访问服务器来证实。如果有类似故障的工作站出现在同一网段或连接在同一交换机上，那么就要分析这一网段子网掩码是否设置正确，交换机是否正常工作。除此之外，还要看一下服务器是否禁止了这一网段工作站的服务。

实例2：传输上百兆数据时出现“网络资源不足”的提示

按常规，网络故障一般不排除以下几点：网卡有问题、水晶头做得不规范、网线有问题、网卡驱动或网络协议有问题等。但是根据故障现象来看，以上猜测都可以排除，因为任何一个地方存在问题，就不可能在微机之间进行数据传输，从而可以判断问题应该出在环境因素上。由于大量的数据传输需要频繁的数据读取，这就要有一个相对平稳的传输环境，而网卡附近有干扰时，这种平稳的环境就会被破坏。一般要确保网卡不插在离显卡很近的插槽上，现在的显卡一般都带有风扇，而显卡风扇将影响到网卡的工作，尤其是显卡在频繁工作时，影响将更加明显。把网卡拔下来，插到离显卡一个较远的插槽上，即可解决大量数据传输时出现的问题。

案例：某客户服务器因机房断电，导致多台设备无法进入 Linux 操作系统，报错 XFS 文件系

统损坏。如图：

故障原因：

维护 Linux 服务器时会面临这样一种错误，即显示文件系统变成(Read Only System)，即

文件系统变成只读的方式，产生这一问题的原因可能有两种，一种是多机写入时同步机制出

现问题，另一种方式是单机写入时出现服务器掉电的情况

而本案例故障演员则为后者：单机写入时出现服务器掉电的情况。

名称解析:

XFS 文件系统:

            文件系统的定义：

                        文件系统是操作系统用于明确存储设备（常见的是磁盘，也有基于 NAND Flash

的固态硬盘）或分区上的文件的方法和数据结构；即在存储设备上组织文件的方法。

            xfs 文件系统：

                                是一个日志型文件系统

日志文件系统？加一个日志来记录文件系统的更改，即使在断电或者是操作系

统崩溃的情况下也能保证文件系统一致性

怎么保持的？

要向磁盘写数据的时候，肯定要改变元数据，日志就要在这之前记录要怎么去

改元数据的，当发生异常掉电或者文件系统崩溃后，进行修复时会检查文件系统的一致性，

当出现不一致时，可通过它来恢复。

故障处理方法:

第一步：使用#lsblk 查找挂载路径，用#umount 将其卸载；确保分区处于 umount 状态

(xfs_check /dev/sdb(盘符)echo $?返回 0 表示正常)，进行下一步；

第二步：检测文件系统是否损坏：执行 xfs_repair -n，检查文件系统是否损坏。

第三步：修复文件系统：

xfs_repair /dev/sdb 以本案例为例。

注: XFS 文件系统在异常断电后发生文件系统报错概率很高。若仅仅因为断电导致文件系统

报错，通常是可以通过命令修复的。执行以上 repair 操作不会对数据产生进一步损坏风险，

如发生修复失败是由于文件系统损坏严重，而不是此操作导致

第四步：强制修复（会造成文件丢失,需要与客户说明数据安全&得到客户允许下才能操作。）

先执行 xfs_repair -L /dev/sdb(清空日志，会丢失文件)，再执行 xfs_repair

/dev/sdb，再执行 xfs_check /dev/sdb 检查文件系统是否修复成功

说明：-L 是修复 xfs 文件系统的最后手段，慎重选择，它会清空日志，会丢失用户数据和文

件。

备注：在执行 xfs_repair 操作前，最好使用 xfs_metadump 工具保存元数据，一旦修复失败，

最起码可以恢复到修复之前的状态

注:仅用作经验分享。

参考文献：

https://blog.csdn.net/yuanfang_way/article/details/78700089

https://www.cnblogs.com/yuzhaoxin/p/4083582.html

---