服务器硬盘故障前的表现

硬盘，这是服务器内最重要的东西，它也可能会出现故障，那么硬盘故障前的表现是怎么样的呢

1、故障提示。也就是我们常说的，硬盘自我监测、分析错误报告。在其控制的磁头、磁盘、电路等部件发生与预存的安全值发生冲突的时候，就会自动发生警告信息。而当出现这个故障提示的时候，我们就改引以为戒，尽快分析和处理。

2、硬盘无法识别。启动时，时不时的显示硬盘无法识别，或者即便能识别，但是系统显示无法显示硬盘，这就是物理故障的前兆。这个时候，我们就需要对重要数据进行转移，而后进行检测维修。

3、系统运行出错。服务器运行过程中，不断出现程序错误的状况，而且磁盘扫描问题，停滞、甚至死机。这个时候，就代表硬盘发生故障了，当然了，也可能是因为安装系统故障的原因，在我们排除软件问题后，就能确定是硬盘故障，需要进行检修。

4、运行报错。扫描磁盘，发现错误，甚至显示出现坏道。这个时候则表示硬盘部件问题，出现了坏道，我们需要将其进行隔离，保证正常使用。

5、初始化死机。初始化即死机，虽然不排除其他部件发生问题的可能性，比如内存问题、风扇问题、系统中毒等等，但是，最可能还是因为硬盘故障的问题，需要进行相关分析

Web of Science是一种基于广泛的学术文献数据库的出版物检索和引文分析工具。但是，当遇到服务器内部错误时，可能是由于服务器出现故障或软件错误等问题导致的。另外，高负载量和网络问题也可以引起服务器错误。为解决此问题，可以尝试清除浏览器缓存、更改网络环境或重新启动服务器等方法，或者联系技术支持以寻求帮助。

常见的网络排障思路如下：

第一步：识别并描述故障现象。分析网络故障时，首先要清楚故障现象，应该详细了解故障的症状和潜在的原因。例如，服务器不响应用户的请求，可能的故障原因是服务器配置问题、接口卡故障或路由器配置命令丢失等。收集需要的用于帮助隔离可能故障原因的信息，如广泛地从用户、网络管理系统、协议分析跟踪、路由器诊断命令的输出报告、软件说明书中收集。

第二步：制定诊断方案，列举可能导致故障的原因。可以根据有关情况排除某些故障原因。例如，根据某些信息可以排除硬件故障，从而把注意力放在软件上。

第三步：排除故障。认真做好每一步测试和观察，每改变一个参数都要确认其结果，确定问题是否解决。如果没有解决，继续下去，直到故障症状消失。

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

网络故障诊断的概述

计算机网络遍及世界各个角落，在给人们带来诸多便利的同时也带来了很多烦恼，下面是我搜索整理的关于网络故障诊断的概述，欢迎参考阅读，希望对大家有所帮助!想了解更多相关信息请持续关注我们应届毕业生培训网!

一、网络故障

1网络故障诊断

网络故障诊断以网络原理、网络配置和网络运行的知识为基础。从故障现象出发，以网络诊断工具为手段获取诊断信息，确定网络故障点，查找问题的根源，排除故障，恢复网络正常运行。

网络故障通常有以下几种可能：物理层中物理设备相互连接失败或者硬件及线路本身的问题;数据链路层的网络设备的接口配置问题;网络层网络协议配置或 *** 作错误;传输层的设备性能或通信拥塞问题;上三层网络应用程序错误。诊断网络故障的过程应该沿着OSI七层模型从物理层开始向上进行。首先检查物理层，然后检查数据链路层，以此类推，设法确定通信失败的故障点，直到系统通信正常为止。

2局域网或广域网分析仪在内的多种工具

网络故障以某种症状表现出来，故障症状包括一般性的(象用户不能接入某个服务器)和较特殊的(如路由器不在路由表中)。对每一个症状使用特定的故障诊断工具和方法都能查找出一个或多个故障原因。

3一般故障排除

一般故障排除模式如下：第一步，当分析网络故障时，要确定故障的具体现象，然后确定造成这种故障现象的原因的类型。第二步，广泛的从网络管理系统、协议分析跟踪、路由器诊断命令的输出报告或软件说明书中收集有用的信息。第三步，根据收集到的情况考虑可能的故障原因。第四步，根据最后的可能的故障原因建立一个诊断计划。第五步，执行诊断计划，认真做好每一步测试和观察，直到故障症状消失。第六步，每改变一个参数都要确认其结果。

二、网络故障分层诊断技术

1物理层及其诊断

物理层的故障主要表现在设备的物理连接方式是否恰当;连接电缆是否正确;MODEM、CSU/DSU等设备的配置及 *** 作是否正确。

2数据链路层及其诊断

查找和排除数据链路层的故障，需要查看路由器的配置，检查连接端口的共享同一数据链路层的封装情况。每对接口要和与其通信的设备有相同的封装。通过查看路由器的配置检查其封装情况。

3网络层及其诊断

排除网络层故障的基本方法是：沿着从源到目标的路径，查看路由器路由表，同时检查路由器接口的IP地址。如果路由没有在路由表中出现，应该通过检查来确定是否已经输入适当的静态路由、默认路由或者动态路由。然后手工配置一些丢失的路由，或者排除一些动态路由选择过程的故障，包括RIP或者IGRP路由协议出现的故障。

三、路由器接口故障排除

1串口故障排除

串口出现连通性问题时，分析它的屏幕输出报告内容。串口报告可能组合有以下几种：1串口运行、线路协议运行，这是完全的工作条件。该串口和线路协议已经初始化，并正在交换协议的存活信息。2串口运行、线路协议关闭，这个显示说明路由器与提供载波检测信号的设备连接，表明载波信号出现在本地和远程之间，但没有正确交换连接两端的协议存活信息。可能的故障发生在路由器配置问题、调制解调器 *** 作问题、租用线路干扰或远程路由器故障，数字式调制解调器的时钟问题，通过链路连接的两个串口不在同一子网上，都会出现这个报告。3串口和线路协议都关闭，可能是电信部门的线路故障、电缆故障或者是调制解调器故障。4串口管理性关闭和线路协议关闭，如果信息包丢失有规律性增加，表明通过该接口传输的通信量超过接口所能处理的`通信量。解决的办法是增加线路容量。查找其他原因发生的信息包丢失，查看输出报告中的输入输出保持队列的状态。

2以太接口故障排除

以太接口的典型故障问题是：带宽的过分利用;碰撞冲突次数频繁;使用不兼容的类型。可以查看该接口的吞吐量、碰撞冲突、信息包丢失、和类型的有关内容等。

1)通过查看接口的吞吐量可以检测网络的利用。如果网络广播信息包的百分比很高，网络性能开始下降。光纤网转换到以太网段的信息包可能会淹没以太口。互联网发生这种情况可以采用优化接口的措施，禁用快速转换，并且调整缓冲区和保持队列。

2)两个接口试图同时传输信息包到以太电缆上时，将发生碰撞。以太网要求冲突次数很少，不同的网络要求是不同的，一般情况发现冲突每秒有3、5次就应该查找冲突的原因了。碰撞冲突产生拥塞，碰撞冲突的原因通常是由于敷设的电缆过长、过分利用、或者“聋”节点。以太网络在物理设计和敷设电缆系统管理方面应有所考虑，超规范敷设电缆可能引起更多的冲突发生。

3)如果接口和线路协议报告运行状态，并且节点的物理连接都完好，可是不能通信。引起问题的原因也可能是两个节点使用了不兼容的类型。解决问题的办法是重新配置使用相同类型。如果要求使用不同类型的同一网络的两个设备互相通信，可以在路由器接口使用子接口，并为每个子接口指定不同的封装类型。

四、物理故障与逻辑故障

1物理故障

物理故障指的是设备或线路损坏、插头松动、线路受到严重电磁干扰等情况。比如说，网络管理人员发现网络某条线路突然中断，首先用ping或fping检查线路在网管中心这边是否连通。

另一种情况，比如两个路由器Router直接连接，这时应该让一台路由器的出口连接另一台路由器的入口，而这台路由器的入口连接另一路由器的出口才行。当然，集线器Hub、交换机、多路复用器也必须连接正确，否则也会导致网络中断。

2逻辑故障

逻辑故障中最常见的情况就是配置错误。配置错误可能是路由器端口参数设定有误，或路由器路由配置错误以至于路由循环或找不到远端地址，或者是路由掩码设置错误等。

逻辑故障的另一类就是一些重要进程或端口关闭，以及系统的负载过高。这时只需重新启动该端口，就可以恢复线路的连通了。还有一种常见情况是路由器的负载过高，表现为路由器CPU温度太高、CPU利用率太高，以及内存剩余太少等，如果因此影响网络服务质量。

五、结论

网络发生故障是不可避免的。网络建成运行后，网络故障诊断是网络管理的重要技术工作。搞好网络的运行管理和故障诊断工作，提高故障诊断水平需要注意以下几方面的问题：认真学习有关网络技术理论;清楚网络的结构设计，包括网络拓朴、设备连接、系统参数设置及软件使用;了解网络正常运行状况、注意收集网络正常运行时的各种状态和报告输出参数;熟悉常用的诊断工具，准确的描述故障现象。

;

可能的原因：
一、内存错误
二、某个定时的服务引起死锁
三、病毒残留或者黑客攻击
四、诺顿的文件检查功能
检查及处理过程：
一、由于这是第一次出现类似重启，先不考虑硬件故障。 但内存错误仍有另外一个可能性就是对磁盘上的虚拟内存访问出错。先检查虚拟内存所在磁盘，未发现错误。但磁盘中有比较多的文件碎片，考虑到内存文件过于分散有可能会引起偶尔的读错误。所以在凌晨1时左右进行一次全盘的文件碎片整理。
二、根据原因代码，网络上有关于定时服务引起文件死锁的记录，而查询登录日志，离重启最近的访问来自于另一台服务器B，加上出现故障时间与整点比较接近，有可能与某些系统服务有关，所以，将B中的DNS、DHCP等服务关闭，因为这些服务会与故障服务器通讯同步，或者进行某种查询。更进一步地，将服务器和B服务器上的文件跨网络定时复制备份等功能删除。
三、从微软的网站找到有关病毒也会引发类似故障的说明（相关网址），按说明查询后排除可能性，然后，再检查可疑的设备驱动，也未发现任何可疑之处。另外，通过查询防火墙日志，在19：03前也未发现有异常的攻击事件。
四、通过网络上上报的事故报告（相关网址）中提到Symantec的版本有关，在Symantec的技术支持网站看到相类似的报告。考虑到离最近的故障时间登录者是B服务器，而我们的B服务器上恰恰安装了Symantec的100版，怀疑与故障服务器上的90版在升级病毒库时产生了冲突，所以将B上的Symantec杀毒软件删除，然后安装了一个客户端，由故障服务器统一管理。
进一步分析
用WinDbg对系统崩溃时的内存Dump文件分析，发现系统重启时的直接引发文件为RapDrvsys。
这个文件为BlackICE的系统文件，它包括了监视应用程序的变化的相关模块，可参见BlackICE的在线说明
检查RapDrvsys，文件没有被改变的迹象，可排除被黑客和病毒修改文件的可能性。
对Dump文件进行调试，找到RapDrvsys出错时的堆栈情况，具体内容如下：
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx" "0x%08lx" "%s"
FAULTING_IP:
RapDrv+9785
f535e785 894104 mov dword ptr [ecx+4],eax
TRAP_FRAME: f4c0bb54 -- (trap fffffffff4c0bb54)
ErrCode = 00000002
eax=858b8b4c ebx=00000000 ecx=00000000 edx=00000000 esi=858b5000 edi=84e2660c
eip=f535e785 esp=f4c0bbc8 ebp=f4c0bbdc iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
RapDrv+0x9785:
f535e785 894104 mov dword ptr [ecx+4],eax ds:0023:00000004=
Resetting default scope
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: blackiceexe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 8085b4b3 to 8087b6be
STACK_TEXT:
f4c0b720 8085b4b3 0000008e c0000005 f535e785 nt!KeBugCheckEx+0x1b
f4c0bae4 808357a4 f4c0bb00 00000000 f4c0bb54 nt!KiDispatchException+0x3a2
f4c0bb4c 80835758 f4c0bbdc f535e785 badb0d00 nt!CommonDispatchException+0x4a
f4c0bb6c f5355b93 850ab630 84e2660c 858b5001 nt!Kei386EoiHelper+0x186
WARNING: Stack unwind information not available Following frames may be wrong
f4c0bbdc f535aa20 85897900 84e2660c 00000028 RapDrv+0xb93
f4c0bc08 f535b282 00222034 84e26608 00000058 RapDrv+0x5a20
f4c0bc28 f535b2f3 865b5ba0 00000058 86043a70 RapDrv+0x6282
f4c0bc4c 8092d3b9 84ad79d8 858e9028 84ad7968 RapDrv+0x62f3
f4c0bc60 8092e81b 865b5ba0 84ad7968 858e9028 nt!IopSynchronousServiceTail+0x10b
f4c0bd00 80940844 00000160 00000000 00000000 nt!IopXxxControlFile+0x5db
f4c0bd34 80834d3f 00000160 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f4c0bd34 7c95ed54 00000160 00000000 00000000 nt!KiFastCallEntry+0xfc
0012d688 00000000 00000000 00000000 00000000 0x7c95ed54
STACK_COMMAND: kb
FOLLOWUP_IP:
RapDrv+9785
f535e785 894104 mov dword ptr [ecx+4],eax
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: RapDrv
IMAGE_NAME: RapDrvsys
DEBUG_FLR_IMAGE_TIMESTAMP: 3f99bc4f
SYMBOL_NAME: RapDrv+9785
FAILURE_BUCKET_ID: 0x8E_RapDrv+9785
BUCKET_ID: 0x8E_RapDrv+9785
Followup: MachineOwner
从上面可以看出，在系统崩溃时，RapDrv正试图作一个IO *** 作，在IopSynchronousServiceTail调用时出错。在网上查寻相关资料，发现DapDrv有一个系统漏洞（相关资料），这个漏洞目前并没有相关补丁和解决方案，好在它发生的条件比较苛刻，如果是攻击，必须是已经攻入系统，在试图修改应用程序时才会触发。也就是说，如果想用这个漏洞进行攻击，对方必须是已经攻入系统才能利用这个漏洞。
综合上述，原来推测的四个可能性，只有最后一个Symantec的版本问题最有可能，因为其它的文件传输，只要不修改服务器上的可执行程序，是不会引发错误的。而Symantec在B服务器上安装的也是服务器版，它的升级过程中，可能会试图替换故障服务器上Symantec的上的90版程序。这才会触发RapDrv对文件进行监控。
目前最终处理方案是：
考虑到这种事故发生时造成的影响较小，在基本排除硬件故障后，决定暂时只处理Symantec的版本问题，然后继续观察服务器的状态，如果不再发生类似事件，则不予理会。如果再一次发生类似情况，就将BlackICE中的文件保护功能关闭，这样可以一劳永逸地解决这类事故。

---