文档库 最新最全的文档下载
当前位置:文档库 › IBM P服务器故障检测

IBM P服务器故障检测

IBM P服务器故障检测
IBM P服务器故障检测

p系列、系统p预防性维护说明

国际商业机器(中国)有限公司

文档编号:

当前版本号: 3.1

最初发布日期2001年12月13日

最新修订日期:2011年9月2日

一、硬件维护部分:

1.检查机房环境:(请参照IBM机房条件及各机型的具体要求)

温度:室内温度建议保持在22±2℃

湿度:相对湿度应保持在50±5%

电源:根据不同机型使用的电源有:200~240V 交流单相;380~415V 交流三相;-48V±5% 直流,实测电压不应超出允许的范围。零线与火线不能反接,通常是面对插座的左边为零线,右边为火线。机器必须有良好的接地保护,地线的接地电阻要求小于1欧姆。因接地电阻测量需要专业仪器,因此以客户提供的测量数值为准,工程师只要确保机柜电源线的地线、机壳(接上电源线后)到建筑物接地端的电阻小于1欧姆就可以了。新版巡检报告中添加了记录事项为是否双电源(此处指的是双动力源供电,比如电力供给来自不同的发电厂,而不是指设备是不是有冗余电源),此外,需要记录如果是双动力源是否部署在了各自独立的PDU或者UPS上。

洁净度:机房应保持清洁且有良好的管理与维护。如机房太脏应提醒客户注意。

设备散热:设备进风口温度是否够低并有足够的气流。机房内设备的摆放是否符合冷热通道原则(绝对不能让设备排出的热空气排向其它设备的进风口)。

随机工具:对于59X/FHA这类高端机型,随机会附带一些R&V时需要用到的平台,滑轨等工具,巡检时应确认随机工具的当前存储状态,以备不时之需。

2.检查系统硬件情况:

先从外观上检查硬件情况,检查设备故障灯是否有亮。各种设备上都有故障指示灯,通常为橙色并有 标记。高端服务器,如p670/p690/p59x/FHA,应检查UEPO开关上的系统故障指示灯是否亮。同时检查BPC、BPD、BPR、DCA、MDA等电源子系统的Power-on、Power-in、Power-out、Enable Green LED 等是否长亮。还要检查部件故障灯,如I/O drawer、PCI卡,硬盘等。

检查是否有人改装过IBM设备(如拆掉面板、开口、拆掉过滤网、改变网络连接等)。这些改装可能会影响设备的稳定运行,甚至带来严重后果。

对于高端Power5/Power6服务器,还应检查其正面Lightstrip和背面Lightstrip。有安装的部件(如CPU book)所对应的绿色LED应长亮。任何故障指示灯(橙色)都应不亮。

同时注意主机的Operator Panel,高端Power5/Power6或其它由HMC管理的机器应检查HMC图形界面的虚拟Operator Panel。设备发生故障时通常伴有出错代码,必须把所有故障代码记录下来。除此以外还应注意有否其他异常情况(如硬盘、风扇异常的声音、电缆破损、系统出风是否顺畅、气流是否因为异物遮挡而影响散热效果等)。?

3.检查硬件错误报告error log:

无HMC管理的系统可登录到AIX,使用“errpt –d H”命令检查硬件错误报告。如有,则应使用“errpt –aj err_id |more”命令检查详细的日志。为了准确判断故障,可对硬件设备运行故障诊断程序,如运行“diag -ed hdisk1”。诊断程序可对故障记录中的SENSE DATA进行分析并给出SRN、SRC、FRU等。

注:如果故障记录太多,应将故障报告取回作进一步分析。可用命令:“snap –r; snap –gc”

用“mail”命令查看有否发给root用户的错误报告。

用“alog –ot boot”命令和“alog –ot console”命令检查系统的启动记录和主控台的出错信息。

对于Power5以前的主机,如果客户允许停机,则应shutdown主机,进入服务处理器(Service Processor)菜单检查故障记录。对于Power5、Power6、Power7主机,无须shutdown分区就可以进入ASMI菜单进行检查。

有HMC管理的系统,可进入Service Focal Point进行检查。

HMC V6 步骤如下:

在Service Focal Point目录下点击Manage Events打开Manage Serviceable Events窗口。

单击OK,进入Serviceable Events Overview窗口,里面记载了最近的错误日志。单击一条记录,再选择Selected菜单,选择View Details,察看错误详细信息。

里面的错误信息应详细记录并保存,不可疏忽。在错误被排除之后应该清除错误信息。选择Selected菜单,选择Close Event,关闭错误详细信息。

HMC V7 步骤如下:

登录后直接点击屏幕左下角的扳手图标,接下来的步骤就跟HMC V6一样了。

确认硬件问题解决后应关闭System Attention Light。无HMC管理的主机:进入AIX diag菜单,选择Task Selection -> 选择Identify and Attention Indicators -> 选择Set System Attention Indicator to Normal。有HMC管理的主机在图形界面下deactivate相关主机的Attention LED.

4.检查机器清洁度

检查机器的清洁程度,如面板上会不会有很多灰尘。如果机器比较脏,或金属部件有腐蚀的迹象,则需要提醒客户注意改善机房环境。有需要的话可以请IPR进行专业检测。

某些机型有空气过滤网,如7040/9119,长期使用可能需要更换,否则过滤网堵塞会影响散热效果。请根据实际情况决定是否更换。9119的过滤网安装在机柜前门,要确保3块过滤网都安装到位,并且机柜正面上下没有开口,所有冷却气流都应该经过滤网进入。

5.风扇转动情况:

从机器相应的散热口检查冷却气流的状态,特别需要注意是否风量小或者无冷却风。如有异常,应收集IQYY并开出对应PMH。

6.逻辑卷/硬盘检查

用“lsvg –o|lsvg –il |grep stale”检查是否有stale状态的逻辑卷。如有stale状态逻辑卷应立即进行同步修复。

7.是否有deconfig硬件资源:

Power5以前的主机用“bindprocessor –q”命令检查是否有CPU被disable。用“lsattr –El sys0”命令检查CPU GUARD是否设置正确。AIX 5.2 以前的版本CPU GUARD默认是disable的。通常系统/分区CPU数目≥3的就应该enable CPU GUARD(如果操作系统为AIX 5.2或以上则CPU≥2时就应该enable CPU GUARD)。内存用命令lsattr –El mem0查看。有分区的机器有一定内存overhead,具体计算参考pSeries Planning for Partitioned-System Operations SA38-0626-00

Power5、Power6、Power7主机登入ASM menu -> System Configuration -> Hardware Deconfiguration -> Processor Deconfiguration 和Memory Deconfiguration检查是否有被deconfigured的CPU或内存。同时检查有无其他部件被deconfigured并做相应记录。

8.DUMP信息(详细请参考《AIX操作系统DUMP设置及收集指南》):

系统DUMP设备应该有足够大的空间,可用“sysdumpdev –e”命令估计系统DUMP的大小以检验DUMP设备是否足够大。对于内存较大的机器,建议建立专用的DUMP设备(如果系统内存大于4GB,则AIX5L会自动建立专用的DUMP设备:/dev/lg_dumplv)。

检查DUMP的拷贝目录(文件系统)是否有足够的空间(如果使用非内存交换区作为Primary DUMP 设备,则无此要求)。如果要改变DUMP的拷贝目录(文件系统)则必须保证其建立在ROOTVG上。

为确保系统挂机时可以做强制DUMP,请把“always allow dump”设成“TURE”,可在线修改。DUMP压缩功能除了可以节省空间外,还可以大大缩短AIX做DUMP的时间,建议打开(默认是关闭),命令为sysdumpdev –C,可在线修改。

9.网络通信:

检查网卡状态、IP地址是否正常。通常不建议使用自适应速率(千兆以太网除外),网卡的设置应与交换机端口的设置匹配。用“ping”命令检查网卡通信是否正常,如是否丢包,速度是否正常等。用“netstat –rn”检查路由表是否正常。检查/etc/hosts文件或DNS设置是否正常。

10.SSA/SCSI/SAS RAID状态(IBM存储服务器请参考存储设备检查指南):

磁盘阵列通常采用RAID1/RAID5/RAID10等数据保护方式。不建议客户使用RAID0的方式,在RAID0方式下数据没有任何保护。检查磁盘阵列中的RAID盘是否有坏盘,是否有degrade的状况。检查磁盘阵列的cache是否打开。热备盘(hotspare)盘可以提高磁盘阵列的可靠性,强烈建议设置热备盘。以内置SAS RAID为例步骤如下:

检查Disk Array 状态:

#diag -> Task Selection -> RAID Array Manager -> IBM SAS Disk Array Manager -> List IBM SAS Disk Array Configuration

检查SAS通道状态:

#diag -> Task Selection -> RAID Array Manager -> IBM SAS Disk Array Manager -> Diagnostics and Recovery Options -> Show SAS Controller Physical Resources

检查cache电池状态:

#diag -> Task Selection -> RAID Array Manager -> IBM SAS Disk Array Manager -> Diagnostics and Recovery Options -> Controller Rechargeable Battery Maintenance -> Display Controller Rechargeable Battery Information

11.LIC版本信息

查看并且记录系统当前的微码版本以及HMC的版本信息(若是高端机器,还需查看并记录BPA的微码版本)

12.RIO连接状况

在HMC上查看RIO Topology状态,注意检查环路状态及速率。

13.磁带机是否需要清洗:

磁带机/磁带库是重要的数据备份设备,应定期清洗。不同的磁带机/磁带库有不同的清洗间隔,请查阅相关手册。某些磁带机可用"/usr/lpp/diagnostics/bin/utape -cd rmt0 -n"命令查看磁带机使用时数。

14.System readiness check检查(power5及以后机型)

Power5及以后机型需要做system readiness check并记录结果。

15.强制ECA信息

根据不同阶段发布的ECA列表,检查对应机器是否存在需要进行的强制ECA,应记录对应的ECA 号码及完成状态。

16.Service Agent是否设置:

我们建议给所有的保修期/MA客户都安装Service Agent,并激活其自动报修功能。Service Agent安装后应保持可以与IBM SDR服务器连接的状态。除callhome外,客户还可以设置email notification, SNMP

监控或者System Director监控。

17.下列数据是否已经收集:

AIX snap文件

ASMI errlog文件

RIO Topology文件

硬件dump文件

其他日志文件(iqyy等)

硬件检查完成后必须填写《RS/6000及p系列系统预防性维护服务报告单(硬件部分)》,对于检查中发现的问题必须及时解决。

二、软件维护部分(仅适用于有软件维护协议的客户):

1.软件错误报告:

用“errpt –d S”命令检查系统的软件出错报告。如果故障记录太多,应将故障报告取回,作进一步分析。用“mail”命令查看有否发给root用户的错误报告。用“alog –ot boot”命令和“alog –ot console”命令检查系统的启动纪录和主控台的出错信息。

检查HACMP、TSM等软件的LOG看有否不正常的地方。

2.检查文件系统

查看有没有“满”的文件系统。文件系统满可导致系统不能正常工作,尤其是AIX的基本文件系统。如/ (根文件系统)满则会导致用户不能登录。关键文件系统的使用率不应该超过80%(/usr除外),且剩余空间最好大于200MB。如果有“满”的文件系统则应删除不用的文件以释放空间,或扩展文件系统。如果系统有关于文件系统错误的报告则应用“fsck”命令对文件系统进行检查修复。

JFSLOG的大小与文件系统的比例应为:1个PP的LOG管理512个PP的文件系统。如果JFSLOG不够大则应扩大,但JFSLOG不应超过256MB。如果太多的文件系统使用同一个LOG则会影响性能,应考虑不同的文件系统使用不通的JFSLOG。

3.检查逻辑卷:

用“lsvg –o|lsvg –il |grep stale”检查是否有stale状态的逻辑卷。如有stale状态逻辑卷应立即进行同步修复。

4.内存交换区(paging space):

AIX4.3.3以后对内存交换区的使用机制与旧版本已经不一样。内存交换区的大小与物理内存的大小并没有一定的比例关系或计算的公式。客户应进行压力测试以确定内存交换区的大小,若内存交换区使用率超过70%,则需要扩大。某些数据库厂家或应用开发商可能对内存交换区有特殊要求,请咨询相关厂商或开发商。增加内存交换区并不会提高性能,内存交换区使用偏高通常是因为物理内存不足造成的,所以升级物理内存才是解决之道。

交换区不应设置在rootvg以外的卷组。从性能上考虑,每个硬盘上应该只有一个内存交换区,并且所有内存交换区的大小应该一致。如果rootvg是采用镜像保护的,则内存交换区也必须镜像。

如果rootvg有固态硬盘则建议把内存交换区放在固态硬盘上以提高性能。

5.boot image是否修改过而没有重启:

boot image修改过应该重启AIX,比如安装了新的补丁或者运行了bosboot命令等。有些案例,客户做了某些修改而没有重启AIX,等几个月之后重启AIX的时候才发现无法启动。这时候已经想不起来做过什么修改了,造成PD很困难。运行命令:uptime 和ls –l /etc/bosboot.sum,uptime应该小于

/etc/bosboot.sum文件日期到当前的时间,否则就代表boot image修改过后没有重启。

6.系统性能:

用vmstat、topas等命令进行简单的性能分析,检查是否有性能瓶颈。

7.数据备份:

数据备份是客户的责任,数据备份包括操作系统备份和用户数据备份。操作系统备份是指ROOTVG 的备份。系统备份要及时,它应能恢复操作系统崩溃前的正常工作状态。因此每当系统改变设置,安装PTF,调整应用程序等的前后都应做好系统备份。系统备份建议至少每季度做一次,手头至少保留两份系统备份带。

用户数据备份包括数据库备份、应用程序代码备份、用户文件系统备份、TSM数据库备份等。用户数据备份建议每天做一次。检查用户数据备份是否能满足硬盘数据丢失后的恢复要求。检查用户备份介质是否标签明确、保存妥善。

8.通信:

用“ping”命令检查通信是否正常。用“netstat –rn”检查路由表是否正常。检查/etc/hosts文件或DNS 设置是否正常。

9.数据是否已作保护

为保证系统高可用性,建议ROOTVG采用镜像保护方式。用“lsvg –l rootvg”检查是否ROOTVG上所有的逻辑卷已镜像。用“lslv –l lvname”命令检查逻辑卷的两份拷贝是否在不同的物理硬盘上。

用户数据也应采取适当的保护方式,如RAID1/5/10、逻辑卷镜像和逻辑卷0+1等。如果客户采用逻辑卷镜像或逻辑卷0+1的方式,则应检查其新建的逻辑卷是否设置正确。

10.系统DUMP设置(详细请参考《AIX操作系统DUMP设置及收集指南》):

系统DUMP设备应该有足够大的空间,可用“sysdumpdev –e”命令估计系统DUMP的大小以检验DUMP 设备是否足够大。对于内存较大的机器,建议建立专用的DUMP设备(如果系统内存大于4GB,则AIX5L 会自动建立专用的DUMP设备:/dev/lg_dumplv)。

检查DUMP的拷贝目录(文件系统)是否有足够的空间(如果使用非内存交换区作为Primary DUMP 设备,则无此要求)。如果要改变DUMP的拷贝目录(文件系统)则必须保证其建立在ROOTVG上。

为确保系统挂机时可以做强制DUMP,请把“always allow dump”设成“TURE”,可在线修改。DUMP压缩功能除了可以节省空间外,还可以大大缩短AIX做DUMP的时间,建议打开(默认是关闭),命令为sysdumpdev –C,可在线修改。

11.补丁程序(PTF)检查

检查的范围包括操作系统补丁、HACMP补丁、TSM补丁等。检查系统补丁是否符合客户Fixes策略要求。具体采用什么版本请参考最新的《Fixes Suggestion Letter》,并与客户协商决定。

12.收集snap package存档

运行“snap-r;snap –gfkbLc”,取回/tmp/ibmsupt/snap.tar.Z 或/tmp/ibmsupt/snap.pax.Z 文件存档。收集LVM信息(主要是LV MAPING信息)有助于日后系统出问题时数据恢复。

注意:检查/tmp文件系统剩余空间最好不要小于200M。

不同预防性维护周期建议的工作内容

不同的客户根据维护合同要求可能有不同的设备预防性维护周期,如有的客户是每季度检查一次,有的是每个月。不同的预防性维护周期建议采用不同的维护内容,具体入下表:

各机型建议的预防性维护时间(time reporting 时间)

注:以下建议的时间是按照做完本文档中所有硬件、软件预防性检查内容估算的时间。工程师填time report 的时候请注意。如果预防性维护过程中发现问题,则处理问题的时间应该用其它SC 填,不要用SC20。

十大X86服务器常见故障——硬件篇

十大X86服务器常见故障——硬件篇 ?摘要:由于X86服务器和台式机有着很多相似之处,从前期部署→中期维护→后期管理都有着异曲同工之妙。用得多了,遇到的故障自然不少,以下故障不知大家是否遇到过…… ?标签:X86服务器常见故障 说起X86平台的CPU,我们可能会如数家珍的报出N多种,Inter的至强5600、至强7500,AMD强劲的12核心x86处理器--“Magny-Cours”(马尼库尔)等等。在它的基础上,辅以带ECC、ChipKill、热插拔技术的内存;防止数据异常丢失的RAID硬盘;提供不中断电力供应的冗余电源等等共同构建出一个完整的X86服务器。 由于X86服务器和台式机有着很多相似之处,从前期部署→中期维护→后期管理都有着异曲同工之妙。因此,X86应该算是我们广为熟知的架构了。用得多了,遇到的故障自然不少,以下故障不知大家是否遇到过…… 硬件故障篇 Top10 网卡 服务器网卡 故障回放:近几日,内网用户通过代理服务器进行连接时不太稳定,ping的速度有时低于1ms,有时高达500多ms,数值相差之大也说明了网络时好时坏。起先判断是蠕虫病毒作祟,但经过详细筛查,确定非病毒引发的故障;再对网线进行测试,衰减、串扰、回波损耗等各项技术指标都在正常指标之内,最后更换网卡故障才得以解决。 解决方案:我们知道一款优秀的网卡除了拥有高速率外,还需要关注2个技术指标,TOE(TCPOffloadEngine,TCP减负引擎)技术和RSS(Receive-sideScaling接收端调节)技术,它们能大幅减轻CPU的资源,解决了输入/输出流(I/O)的瓶颈,使网络吞吐大幅提升,这两项技术可以使系统的响应指标的TPS值能提升2.1到2.5倍,所以一块好的网卡是保证服务器快速、稳定连接的保障。 一般来说,网卡出现故障的状况较低,即便是损坏也可以使用独立网卡代替,它的危害程度也不是很高。 危害程度:★★ 控制难度:★

服务器故障排除手册

服务器故障排除手册 相比PC而言,服务器出故障的机率是小多了,但是它出故障造成的损失可也大多了。作为服务器维修人员需要了解一些服务器故障恢复的基本知识,知道在维修时可以做些什么来最快速的解决问题也可以减少故障停机时间。 本文并不是一本服务器故障解决的完全手册,但如果能够认真的按照下面的步骤维修维护,它也许可以解决大多数问题,但当你做完所有的这一切仍不管用时,不用惭愧,去找维修专家吧,可以放心的是,这些维修步骤不会出现大的损害,最坏的情形是“It does not work at all”。 本文主要分三部分,第一部分讲的是服务器故障排除的基本原则性问题。第二部分讲述了一些服务器硬件故障排除的实例。第三部分讲述了一些服务器软件故障排除的实例。 第一部分服务器故障排除的基本原则性问题 一、服务器开机无显示应怎么办 1.检查供电环境,零-火;零-地电压? 2.检查电源指示灯,如果亮,正常吗? 3.按下电源开关时,键盘上指示灯亮吗?风扇全部转动吗? 4. 是否更换过显示器,更换另一台显示器。 5. 去掉增加内存 6. 去掉增加的CPU 7.去掉增加的第三方I/O卡 8. 检查内存和CPU 插的是否牢靠 9. Clear CMOS 10. 更换主要备件,如系统板,内存和CPU 二、服务器故障排错的基本原则是什么 1. 尽量恢复系统缺省配置 a:硬件配置:去除第三方厂商备件和非标配备件; b:资源配置:清除CMOS,恢复资源初始配置; c: BIOS,F/W,驱动程序:升级最新的BIOS,F/W和相关驱动程序; d: TPL:扩展的第三方的I/O卡属于该机型的硬件兼容列表(TPL)吗? 2. 从基本到复杂 a:系统上从个体到网络:首先将存在故障的服务器独立运行,待测试正常后再接入网络运行,观察故障现象变化并处理。 b:硬件上从最小系统到现实系统:指从可以运行的硬件开始逐步到现实系统为止。 c: 软件上从基本系统到现实系统:指从基本操作系统开始逐步到现实系统为止。 3. 交换对比 a:在最大可能相同的条件下,交换操作简单效果明显的部件; b: 交换NOS载体,既交换软件环境; c:交换硬件,既交换硬件环境;

服务器维修故障诊断思路大全

前言: 相对PC机而言服务器出故障的机率是小多了,但是它的故障给企业也带来了一些影响。作为服务器工程师除要有服务器基础知识以外,还需要具备服务器故障的诊断思路,这样才能最快速的解决问题也可以减少故障停机时间。 本文并不是针对某个厂家服务器故障完全手册,而是根据个人经验总结出来的一些经验思路还有一些总结案例。按照下面思路和方法基本上能够解决目前服务器更换式维修的大多数问题。而且里面的一些操作风险性也不是很大,因为服务器本身就是坏的,最坏的情况下就是它一点都不能工作了呗,(主要确认是否有数据,数据无价啊)而且现在很多厂商都有自己的客服电话关于产品问题打个电话也很方便,所以安心做啦 当然如果服务器在保修期内就打电话让售后工程师上门服务,毕竟顾客就是上帝嘛,但是如果上帝比较着急使用,一般小故障自己解决一下就好了,因为一般报修最快都是第二天(大客户如银行等除外,一般当天还得是晚上才能停机解决) 目录: 一、服务器常见故障分类 二、服务器常见故障现象及其对应排错方法 三、服务器排错基本原则 四、服务器故障需要收集哪些信息 五、服务器硬件故障排错实例 六、服务器软件故障排错实例 七、服务器常见内存故障现象 一、服务器常见故障类型分类: A. 开机无显示 B. 加电BIOS自检阶段故障 C. 系统和软件安装阶段故障和现象 D. 操作系统启动失败 E. 系统运行阶段故障 二、服务器常见故障现象及其对应的排除方法

A.服务器开机无显示(加电无显示和不加电无显示) 1. 检查供电环境 2. 检查电源和故障指示灯(故障指示灯状态,目前很多厂商的服务器都有故障指示灯,或故障诊断卡等。) 3. 按下电源开关时,键盘指示灯是否亮、风扇是否全部转动 4. 是否更换过显示器,尝试更换另外一台显示器 5. 插拔内存,用橡皮擦擦拭一下金手指,如果在故障之前有增加内存,去掉增加的内存尝试 6. 是否添加了CPU,如果有增加CPU尝试去掉 7. 去掉增加的第三方I/O卡包括Raid卡等 8. ClearCMOS (记得使用跳线来清除,尽量不要直接拔电池,每款服务器清除跳线位置不一致,具体找不到电话联系一下厂商客服) 9. 尝试更换主板、内存等主要部件 10.清除静电,将电源线等外插在服务器上的线缆全部拔掉,然后轻按开机键几下 B.加电BIOS自检报错 1. 根据BIOS自检报错信息提示 2. 查看是否外插了第三方的卡或者添加部件,如果有还原基本配置重启 3. 做最小化测试 4. 尝试清除CMOS 5. 看能否正常进入BIOS C. 系统安装阶段故障和现象 1.查看服务器支持操作系统的兼容版本(从厂商能查到兼容性列表) 2.系统安装蓝屏(对蓝屏故障代码诊断) 3.安装在分区格式化的时候找不到硬盘 (阵列驱动没有安装或者没有配置阵列,可以尝试适应引导光盘安装) 4.大于2T的硬盘式应该如何分区(必须使用阵列卡才能实现或者有外插识别卡) (使用阵列卡配置阵列分成一个小于2T的空间,一个大于2T的空间,然后将系统安装在小于2T的上面,安装好系统后在使用GPT方式分区即可) 5.安装过程是死机 (检查兼容性列表---查看硬盘接口选择是否正确---阵列驱动安装是否正确---尝试最小化配置安装检查是否为内存和CPU等问题) 6.引导光盘安装失败

服务器及IT设备日常维护

服务器及IT设备常维护 一、服务器基本维护知识 ◆服务器硬件维护注意事项 请不要在服务器内扩配或改配未经厂商认证的部件 静电释放和静电释放保护措施:静电释放会对主板、硬盘、板卡和系统的其它部件造成损害,在您要对系统硬件进行设臵时,最好在防静电环境下进行,如果没有这个条件,操作人员尽量佩带防静电手环(一端接地)。 静电释放和板卡持拿:因为板卡上的芯片对静电特别敏感,持拿板卡必须小心,只能接触主板的边沿。当板卡暂时不用时,必须把它放回专用的防静电袋中(封闭),芯片朝上放在接地平台上。 机箱盖:为了系统正常散热和空气流通,在系统上电前一定要安装机箱盖,否则会对系统部件造成损害 ◆服务器维护通常步骤 (1)普通硬件部件检测 1、确保在机箱和主板之间不存在短路。 2、把和主板相连接的线缆断掉,包括键盘和鼠标。 3、移走所有的外插板卡。 4、安装一颗 CPU (确保安装牢固) 5、连接机箱面板控制连线和电源指示灯LED连线到主板 6、检查跳线设臵是否正确 (2)硬件级系统维护 1.请检查一下系统、BIOS设臵是否正确。许多问题都是由系统设臵不正确造成的。 2.请检查一下内存是否够用和硬件的兼容性。 3.通知客户退出网络,将服务器电源关闭,将机箱盖打开。 4.检查电缆和板卡插接是否正确。 5.将连接的硬件一件一件拆除下来,逐步发现问题的所在 ◆系统BIOS ?BIOS设臵又称CMOS设臵,是基本的输入输出系统,可以利用专门的设臵程序对系统参数和硬件参数进行调整。 ?由于BIOS对系统的运转和启动有重大影响,所以,设臵了不当的参数后可能会引起硬件资源之间的冲突,或者降低系统运行的性能,因此,了解BIOS的设臵对配臵您的服务器很重要,如果没有特殊的需要,建议您使用系统出厂时的默认值,不要随意改变BIOS。 二、服务器硬件故障诊断与排除 ◆主板 CMOS清除 除了可清除口令外,如果机器使用一段时间后,BIOS自检出现不正常的提示,可以先做CMOS清除试一下。有时系统出现一些提示,CMOS清除会起到意想不到的作用。 服务器开机无显,可能与主板有关,需要有经验的工程师作判断。 板卡、线缆与主板接触不好,会导致机器不启动。 在开机无显时,可以移去内存,开机如果有内存报警的声音(可以查服务器手册判断内存报警

服务器常见故障的判断与维修汇总

服务器常见故障的判断与维修 一、造成服务器无法启动的主要原因 市电或电源线故障(断电或接触不良) 电源或电源模组故障 内存故障(一般伴有报警声) CPU故障(一般也会有报警声) 主板故障 其它插卡造成中断冲突 二、服务器无法启动解决办法 检查电源线和各种I/O接线是否连接正常。 检查连接电源线后主板是否加电。 将服务器设为最小配置(只接单颗cpu,最少的内存,只连接显示器和键盘)直接短接主板开关跳线,看看是否能够启动。 检查电源,将所有的电源接口拔下,将电源的主板供电口的绿线和黑线短接,看看电源是否启动。 如果判断电源正常,则需要用替换法来排除故障,替换法是在最小化配置下先由最容易替换的配件开始替换(内存、cpu、主板) 三、系统频繁重启 电源故障(替换法判断解决) 内存故障(可从BIOS错误报告中查出) 网络端口数据流量过大(工作压力过大) 软件故障(更新或重装操作系统解决) 四、服务器死机故障判断处理 服务器死机故障比较难以判断,一般分为软件和硬件两个方面: * 软件故障 首先检查操作系统的系统日志,可以通过系统日志来判断部分造成死机的原因。 电脑病毒的原因。 系统软件的bug或漏洞造成的死机,这种故障需要在判断硬件无故障后做出,而且需要软件提供商提供帮助。 软件使用不当或系统工作压力过大,可以请客户适当降低服务器的工作压力来看看是否能够解决 * 硬件故障 硬件冲突 电源故障或电源供电不足,可以通过对比计算服务器电源所有的负载功率的值来作出判断。 硬盘故障(通过扫描硬盘表面来检查是否有坏道) 内存故障(可以通过主板BIOS中的错误报告和操作系统的报错信息来判断) 主板故障(使用替换法来判断) CPU故障(使用替换法) 板卡故障(一般是SCSI/RAID卡或其他pci设备也有可能造成系统死机,可用替换法判断处理) 注意:系统死机故障需要在处理完后需要在一段时间内进行一定压力的拷机测试来尽一步检查故障是否彻底解决。 五、安装操作系统时提示找不到硬盘 无物理硬盘设备

故障分析报告

关于柳州海事局远程视频监控系统的故障分析报告 ――2011年10月至2012年5月 一、故障基本信息 二、故障现象及处理过程 1、第一次故障 υ故障现象:2011年11月13日接到柳州海事的报障,无法 连接服务器,客户端无法ping通服务器IP。 υ处理过程:接到报障通知后,我公司立即组织人员进行处 理,局域网内可与前端设备通信,问题初步定为平台服务器 故障。次日测试人员到达现场;经过测试,发现平台服务器 操作系统崩溃;与设备厂商联系,于16日将平台系统及所有 前端系统进行重新布署,故障解决。 υ故障分析:经过系统测试工程对系统日志进行分析,于11 月12日晚,因多个IP地址向平台服务器发起的恶意重复登录 请求导致平台服务器处理超载,并造成操作系统文件损坏。 2、第二次故障 υ故障现象:2011年12月06日接到柳州海事的报障,三江 支线画面无法显示。

υ处理过程:当日经测试维护人员检查,由于三江支线的传输线路中断所至,为此马上与传输机房进行故障确认,并告知协助处理,于次日中午故障解决。 υ故障总结:由于三江网络传输点断电,导致传输线路不断,经协调后解决。 3、第三次故障 υ故障现象:2012年3月26日接到柳州海事的报障,无法连接服务器,客户端无法ping通服务器IP。 υ处理过程:接到报障通知后,我公司立即组织人员进行处理,局域网内可与前端设备通信及平台服务器进行通信。故障定为网络传输质量问题。当时与传输机房联系协助排查故障;经过测试排查,发现由于网络传输出现波动或延时现象较为严重导致系统自动判定为网络中断,不断的向前端设备发送重启命令导致;通过机房对线路进行优化配置后重启系统后恢复。 υ故障总结:由于网络传输出现波动或延时现象较为严重导致系统自动判定为网络中断,不断的向前端设备发送重启命令导致。 4、第四次故障 υ故障现象:2012年4月13日接到柳州海事的报障,红花电站支线画面无法显示。。 υ处理过程:接到报障通知后,我公司立即组织人员前往红

服务器常见的十四个故障 分析解决方案

服务器常见的十四个故障分析解决方案 一、造成服务器无法启动的主要原因 : 市电或电源线故障(断电或接触不良) 电源或电源模组故障 内存故障(一般伴有报警声) CPU故障(一般也会有报警声) 主板故障 其它插卡造成中断冲突 二、服务器无法启动 ? 检查电源线和各种I/O接线是否连接正常。 检查连接电源线后主板是否加电。 将服务器设为最小配置(只接单颗cpu,最少的内存,只连接显示器和键盘)直接短接主板开关跳线,看看是否能够启动。 检查电源,将所有的电源接口拔下,将电源的主板供电口的绿线和黑线短接,看看电源是否启动。 如果判断电源正常,则需要用替换法来排除故障,替换法是在最小化配置下先由最容易替换的配件开始替换(内存、cpu、主板) 三、系统频繁重启 ? 造成系统频繁重启的原因: 电源故障(替换法判断解决) 内存故障(可从BIOS错误报告中查出)

网络端口数据流量过大(工作压力过大) 软件故障(更新或重装操作系统解决) 四、服务器死机故障判断处理: 服务器死机故障比较难以判断,一般分为软件和硬件两个方面: 软件故障 硬件故障 软件故障 首先检查操作系统的系统日志,可以通过系统日志来判断部分造成死机的原因。 电脑病毒的原因。 系统软件的bug或漏洞造成的死机,这种故障需要在判断硬件无故障后做出,而且需要软件提供商提供帮助。 软件使用不当或系统工作压力过大,可以请客户适当降低服务器的工作压力来看看是否能够解决 硬件故障 硬件冲突 电源故障或电源供电不足,可以通过对比计算服务器电源所有的负载功率的值来作出判断。 硬盘故障(通过扫描硬盘表面来检查是否有坏道) 内存故障(可以通过主板BIOS中的错误报告和操作系统的报错信息来判断) 主板故障(使用替换法来判断) CPU故障(使用替换法)

相关文档
相关文档 最新文档