下载文档原格式
ARECA RAID卡故障分析报告测试配置：机箱：SC836E1-R800B主板：X8DTL-iF(PCB Ver:2.01 / BIOS Ver:2.0C)CPU: INTEL XEON E5620 x2MEMORY: Hynix 8GB DDR3/1333 x4DISK: SEAGATE ST32000644NS x14RAID CARD: ARC-1889IX-16 & ARC-1889IX-16RAID级别：RAID0(14块盘)OS: Windows 7Test software: Burinitest(设置cpu、mem、hdd 压力100%)RAID 型号：ARC-1889IX-16 SN号：E107CACR600135原始故障：areca日志信息频繁报出所有硬盘不断掉线并自动加载后导致系统下硬盘频繁报错，怀疑RAID卡无法承受高负荷压力导致硬盘掉线，做更换RAID卡处理。
测试结果：Burinitest(设置cpu、mem、hdd 压力100%)测试运行6个小时后，RAID丢失，所有磁盘不断掉线，进RAID卡BIOS配置界面，无法找到连接磁盘。
详见下图：RAID型号：ARC-1261D-16 SN号：A109CAAYAR600027原始故障：服务器在POST过程中检测到RAID卡过不去，自动重启，重插、更换插卡槽位均无法解决故障，做更换RAID卡处理.测试结果：做好RAID后，重启机器15次，断电开机操作5次，未发现原始故障现象，RAID 卡工作状态正常；Burinitest(设置cpu、mem、hdd 压力100%)测试运行30个小时以上，RAID卡工作状态均正常，将RAID卡从主板SLOT3移插到SLOT4，RAID卡工作状态正常。
结论：ARC-1889IX-16 RAID卡故障复现，确实为坏卡，建议返厂分析。
ARC-1261D-16 RAID卡故障未能复现。
故障处理报告近期，我所在的公司遇到了一个严重的故障问题。
由于故障的原因比较复杂，影响面广，导致了很多工作无法正常进行。
为了及时解决问题，我负责制作了一份故障处理报告，以便全体员工对问题有更清晰的认识并能够共同参与解决。
一、问题描述故障出现的时间是在6月1日上午9点30分左右，当时公司的邮箱服务器突然宕机。
这导致了公司所有员工无法正常收发邮件，直接影响了我们的工作效率。
二、分析原因经过初步调查，我们发现故障是由于服务器硬件设备出现故障导致的。
问题出现的原因是由于硬盘故障，导致硬盘上的重要数据无法正常读取，最终导致服务器宕机。
经过初步分析，我们认为这也与近期公司网络管理方面略有不足有关。
三、解决方案为了尽快解决问题，我们采取了以下措施：1. 全面备份数据：为了保证数据的安全性，我们在故障排除之前立即对服务器中的所有数据进行了备份。
在服务器重启之前，我们还特意对备份数据进行了全面测试，以确保数据的完整性。
2. 更换硬盘设备：为了解决硬盘故障问题，我们采取了更换硬盘的措施。
我们找来最专业的网络维护人员来完成硬盘更换工作，并且在更换过程中进行了全面测试。
3. 加强网络管理：为了避免类似问题再次出现，我们会加强公司的网络管理，对服务器进行全面监管，并且对硬件设备进行定期维护，提高设备的使用寿命和稳定性。
四、总结在排除故障的过程中，我们遇到了很多困难。
但是通过全体员工的共同努力，我们最终还是成功地解决了这个问题。
我想说，只有在大家的共同努力下，公司才能更好的发展。
今后，我相信我们会在遇到问题时更加沉着冷静，更加主动地采取行动。
一般问题下表说明您可能遇到的一般问题，以及建议的解决方案。
BIOS 启动错误消息
下表说明有关启动时可能显示的 BIOS 错误消息、其问题以及建议的解决方案。
SCSI 电缆和连接器问题
如果您的 SCSI 电缆或连接器发生问题，请先检查电缆连接。
如果问题仍然存在，请访问 Dell 网站 ，以获得有关合格的小型计算机系统接口 (SCSI) 电缆及连接器的信息，或与您的 Dell 代表联系以获得信息。
系统 CMOS 启动顺序
系统启动顺序是由系统 CMOS 公用程序决定。
请按照下列说明更改启动顺序：
1.系统启动时，按。
2.从 System（系统）菜单左方，选择 Boot Sequence（启动顺序）。
3.突出显示您要更改的设备，并使用 Shift-Up/Down 箭头来更改设备的顺序。
4.按返回窗口左方。
5.务必按以确认启动顺序。
如果您按而非，将不会保存您的更改。
6.按 Save/Exit（保存/退出）。
7.系统将重新启动。
预测性故障报告
自我监控、分析及报告技术 (SMART) 用于检查硬盘驱动器，寻找潜在驱动器故障的早期征兆。
SMART 是硬盘驱动器本身的一项功能，不受 RAID 控制器的控制。
所有传送到驱动程序的 SMART 消息都会传送到操作系统中。
操作系统问题
下表说明您可能遇到的操作系统问题，以及建议的解决方案。
RAID磁盘阵列常见故障以及修复方法RAID磁盘阵列常见故障以及修复方法服务器资料安全有着至关重要的意义，目前大多数服务器都采用了RAID磁盘阵列技术。
受服务器自身硬件局限和技术人员的操作因素，服务器无阵列无法做到100%的无故障发生。
那么RAID磁盘阵列故障有哪些？RAID磁盘阵列如何进行资料恢复？导致磁盘阵列RAID资料丢失的故障原因分为RAID逻辑层故障，RAID物理层故障以及RAID坏道层故障。
对于逻辑层故障，例如误删除，误格式化，误分区，RAID阵列信息丢失, RAID阵列信息混乱, 重新配置RAID阵列信息导致资料丢失, RAID阵列内磁盘顺序出错等，可以使用专业的RAID磁盘阵列资料恢复工具，全面支RAID 0，RAID 5，Raid 5E, Raid 5EE及Raid 6，只要没有对磁盘阵列做初始化和非常规的Rebuild操作，就可以保证100%恢复出磁盘阵列的资料。
对于服务器物理层故障，主要是指服务器阵列SAS、SCSI硬盘由于硬盘内部磁头或者电机原因引起的故障。
主要表现是硬盘通电敲盘，硬盘通电不转，硬盘通电不识别。
这种情况，一般公司技术人员没办法恢复，需要专业资料恢复人员进行恢复，可能还涉及到硬盘开盘恢复，建议不要自行操作，可以联系资料恢复中心，由工程师诊断故障原因在制定恢复方案。
对于RAID坏道层故障，主要是指磁盘阵列中SCSI、SAS硬盘由于一块或者多块有坏道引起操作系统产生如无法启动，启动操作系统蓝屏，启动操作系统死机等故障。
坏道里的资料无法读取，有坏道的硬盘需要做全盘镜像，只有镜像完成之后，才能着手去重组硬盘阵列，然后导出资料。
为了获得较高的资料恢复成功率，有三点需要注意。
一是，当服务器发生故障后，大家切忌再对服务器进行任何操作，也切忌随意取出硬盘，以免弄乱顺序增加后期资料恢复的难度。
二是如果已经取出硬盘，一定要标记好硬盘的顺序。
三是服务器资料恢复公司的专业服务器资料恢复工程师，有技术设备保障，资料恢复更安全。
X电子政务平台故障处理报告X年5月2日目录一、事件经过 (3)二、事件原因分析 (5)三、后期预防措施 (5)一、事件经过4月8日9:10接到网络运维商中软运维人员汇报，政务网电子政务平台数据库所在存储阵列出现异常告警、遂即与应用开发商X人员进行确定，并进行手工测试，9：45经X人员与中软人员共同确认存储整列发生异常、电子政务平台不可用10：50 经过与运维商、开发商共同评估并致电存储阵列原厂商后，初步判定此故障为不可逆的灾难性故障，在请原厂商工程师到现场支持的同时，商定故障恢复方案及备用方案15：30 经过2家代理商与存储整列原厂商工程师共同确认，此故障为灾难性故障、恢复几率性非常小，且风险较大。
16：00 经与几家公司共同协商评估后，决定先不进行原有存储阵列的数据恢复，采用搭建备用的存储整列、由X公司将之前备份到磁带中的数据恢复至新平台中21：50 新平台的存储阵列及服务器环境搭建完成，并进行另一台单独的存储阵列系统的搭建工作，用以恢复较早之前的备份数据与现有作业并发进行22：30开发商XDBA进行新环境的调试工作，并于9日凌晨3点调试完成4月9日03：00X人员开始备份环境的调试工作，并于06：00开始恢复作业15：30 数据恢复完成，经XDBA与X人员共同调试、确认后19：40开始恢复缺失的备份数据至10日凌晨3：30完全备份的数据恢复完成4月10日03：30 XDBA开始恢复最近时间段内的增量数据，至07：30全部恢复完成，但尝试启动数据库失败，经几个公司多名DBA一起排查、解决，直至中午12：00，最终以失败告终19：30 新的存储平台搭建完成，由X将磁带中的数据重新恢复至新的存储平台中，并同时由XDBA将较早之前自行备份的数据恢复4月11日02：30 X将1月5日的全备数据恢复完成，并启动了数据库，此时为1月5日的的数据04：00 X对1月5日的数据进行了检查，确认了可以正常使用19：00 沈主任召集会议，对下一阶段完整数据的恢复工作进行了讨论。
故障问题分析报告⼀、故障概述时间：2024年9⽉24⽇22:06主机：192.168.x.x 问题现象：存储池 A 和 B 未挂载，导致部分虚拟机⽆法访问其存储资源。
CPU 使⽤率 99.5%，内存占⽤率达到 84%。
⽆法通过 SSH 、KVM 和 BMC 远程连接节点。
其他 ⼏ 个节点运⾏正常，磁盘阵列⽆报警。
通过 ping 可以连接节点，但远程管理⼯具⽆法访问。
⼆、故障现象详细分析1. 存储池未挂载的连锁反应存储池 A 和 B 未能成功挂载，导致虚拟机进程⽆法访问磁盘数据。
虚拟机在尝试 I/O 操作时陷⼊阻塞状态，导致 CPU 和内存资源耗尽。
2. 系统⾼负载与 SSH/KVM 失效CPU 使⽤率 99.5%：表明系统中的⽤户进程或内核进程出现资源竞争。
内存使⽤率 84%：可能由于阻塞进程堆积，内存压⼒上升，触发 OOM （内存不⾜）⾏为。
系统在⾼负载下暂停 SSH 和 BMC 进程，使管理员⽆法通过远程访问登录系统排查问题。
3. dmesg 中的 BAR 13 分配失败关键⽇志信息如下：这条⽇志表明 PCI 资源分配不⾜，可能影响某些存储设备（如 HBA 卡或 RAID 控制器）正常⼯作。
4. crontab 任务过多导致系统资源耗尽通过⽇志分析，发现有⼤量 ⾃动任务被频繁触发，导致系统在短时间内创建⼤量会话：在 CPU 和内存接近饱和的情况下，这些任务进⼀步恶化了系统性能。
三、核⼼原因分析PCI: BAR 13: No available resource for PCI bridgesession_start: 400 sessions activeNo. 1 / 4三、核⼼原因分析1. 存储池挂载失败的具体原因PCI BAR 分配失败直接导致某些 PCI 设备（如 RAID/HBA 卡）⽆法正常注册资源，进⽽导致存储设备不可⽤：PCI: BAR 13: No available resource for PCI bridgeBAR（Base Address Register）是 PCI 设备⽤于内存映射的地址寄存器，分配失败意味着系统未能为该设备提供必要的地址空间，导致存储池不可访问。
磁盘阵列实验报告1. 引言磁盘阵列是一种由多个硬盘组成的存储系统，通过组合多个硬盘的存储容量和性能，提供了更高的数据可靠性和读写速度。
在本次实验中，我们搭建了一个磁盘阵列系统，进行了性能测试，并对其性能进行了评估和分析。
2. 实验目的本次实验的主要目的包括：1. 掌握磁盘阵列的组建和配置方法；2. 测试磁盘阵列的读写性能，并分析其性能表现；3. 评估磁盘阵列在不同工作负载下的性能表现。
3. 实验环境本次实验的实验环境如下：- CPU：Intel Core i7-9700K；- 内存：16GB DDR4；- 硬盘：8块SATA硬盘(容量为2TB，转速为7200RPM)；- 操作系统：Ubuntu Linux 20.04.1 LTS。
4. 磁盘阵列配置在实验中，我们选择了一种常见的磁盘阵列配置方式：RAID 0。
RAID 0使用条带化（striping）的方式将数据均匀分布在多个硬盘上，从而提高了读写性能。
然而，由于数据没有冗余备份，RAID 0无法实现数据的冗余和容错。
我们通过软件配置方式实现了RAID 0。
首先，我们使用Linux提供的`mdadm`工具将物理硬盘建立为RAID设备，然后进行格式化和挂载。
5. 性能测试与分析我们对磁盘阵列进行了一系列性能测试，包括顺序读写、随机读写以及不同读写负载下的性能测试。
5.1 顺序读写性能测试在顺序读写性能测试中，我们使用了`dd`命令进行测试。
对于顺序读测试，我们从磁盘阵列中读取了一个大文件，并计算了读取速度。
对于顺序写测试，我们向磁盘阵列中写入一个大文件，并计算了写入速度。
5.2 随机读写性能测试在随机读写性能测试中，我们使用了`fio`工具进行测试。
我们设置了一系列随机读写的负载，包括不同的队列深度和线程数，并分别测试了随机读和随机写的性能。
通过分析测试结果，我们评估了磁盘阵列在不同负载下的性能表现。
5.3 不同读写负载下的性能测试在不同读写负载下的性能测试中，我们使用了`iozone`工具进行测试。
@@@@@@磁盘阵列
故障分析处理报告
报告提交人:@@@
现场工程师:@@@@@@
提交日期:2009年03月31日——————————————————————————一、故障描述
2009年3月22日@@@@平安城市项目使用的两台NAS存储服务器,其中有一台设备出现物理磁盘丢失现象,我方与海康威视技术人员及相关人员到现场进行调试了解,具体情况如下:
@@@@平安城市项目所使用的存储服务器的型号是:
DS-A1016R;采用RAID 5 冗余磁盘阵列;磁盘存储阵列和存储管理服务器通过ISCSI 协议做IP SAN网络数据存储;其中有一台NAS存储服务器设备出现磁盘丢失阵列报错现象。
二、处理过程
3月22日晚上10点,出现磁盘阵列无法读写数据的情况。
现场通过查找NAS 存储服务器事件日志记录发现第二块阵列控制卡的第3块和第8块物理磁盘有扇区坏道报错记录,导致NAS存储服务器出现磁盘丢失阵列报错现象;出现两块物理磁盘有坏道扇区情况下必须将有坏道的磁盘扇区
克隆到无坏道的磁盘扇区下,才能重新重构阵列恢复丢失的数据;
第 1 页共 5 页
3月23日将第3块硬盘克隆到新硬盘,整个克隆过程大概需要6个小时。
克隆完毕后,将克隆好的新硬盘装回磁盘阵列柜,重启磁盘阵列柜,磁盘阵列自动启动阵列重构。
阵列重构是根据RAID5的冗余校验信息,自动修正磁盘的错误数据。
因为磁盘阵列空间比较大,重构需要大概2天半时间。
但3月24日凌晨1点半,重构进度达9%的时候,访问第2张控制卡的第7块硬盘报错,重构中止。
查看硬盘状态,并没有显示第7快硬盘有坏道。
但查看日志时,发现访问第7块硬盘时,多次出错。
因此初步判定第7块硬盘校验数据出错,硬盘有损坏的征兆,但不明显。
3月24日将第7块硬盘克隆到新硬盘。
克隆完毕后,将克隆好的新硬盘装回磁盘阵列柜,重启磁盘阵列,磁盘阵列自动启动重构。
但3月25日凌晨2点半,重构进度达17%
的时候,访问第2张控制卡的第8块硬盘报错,重构中止。
第8块硬盘有多个坏扇区,需对第8块硬盘进行克隆。
3月25日将第8块硬盘克隆到新硬盘。
克隆完毕后,将克隆好的新硬盘装回磁盘阵列柜,重启磁盘阵列,磁盘阵列自动启动重构。
此次重构比较顺利,到3月27日中午重构完毕。
因3月26日系统终验,而磁盘阵列在重构的过程中,能同时读写数据,因此,3月26日凌晨0点开始把数据备份到另一台磁盘阵列。
3月27日中午重构完成时,虽然阵列状态显示正常,数据能正常读写,系统依然报“盘位丢失”错误。
海康威视技术人员通过阵列系统命令行界面,修复了系统错误。
NAS存储服务器数据文件已得到恢复,并显示系统正常。
考虑到数据的重要性,我们把数据全部备份到另一台磁盘阵列,并在刚修复的磁盘阵列柜上重建阵列。
三、故障情况分析
RAID5多用于OLTP(联机事务处理系统),其基本特征是支持大量并发用户添加和修改数据。
但存取数据一般是数十条记录,其工作单位是简单的事务。
因此
RAID5适合大文件的存储。
但在此次系统应用中,将磁盘阵列用于卡口的图片存
储。
图片小文件读写非常频繁,而且是逐张读写,非批量读写,因此,容易引起硬盘损坏。
在系统维护过程中,偶尔出现手动强制关机情况。
硬盘在高速运作的过程中,
突然停电,可能会引发磁盘坏扇区。
通常磁盘在读写时发生坏扇区的情况即表示此磁盘故障,不能再作读写,甚至
有很多系统会因为不能完成读写的动作而死机,但若因为某一扇区的损坏而使工作不能完成或要更换磁盘,则使得系统性能大打折扣,而系统的维护成本也未免过高。
坏扇区转移是当磁盘阵列系统发现磁盘有坏扇区时,以另一空白且无故障的扇区取代该扇区,以延长磁盘的使用寿命,减少坏磁盘的发生率以及系统的维护成本。
所
以坏扇区转移功能使磁盘阵列具有更好的容错性,同时使整个系统有最好的成本效益比。
该磁盘阵列柜出现磁盘坏扇区时,会出现系统错误,而无法读写数据。
因此,该磁盘阵列柜的坏扇区修复功能不强。
为了加强容错的功能以及使系统在磁盘故障的情况下能迅速的重构数据,以维持系统的性能,一般的磁盘阵列系统都可使用热备份的功能,所谓热备份是在建立磁盘阵列系统的时候,将其中一块磁盘指定为后备磁盘,此一块磁盘在平常并不操作,但若阵列中某一块磁盘发生故障时,磁盘阵列即以后备磁盘取代故障磁盘,并自动将故障磁盘的数据重构在后备磁盘之上,因为反应快速,加上快取内存减少了磁盘的存取,所以数据重构很快即可完成,对系统的性能影响不大。
在此次系统应用中,没意识到热备盘的重要性,没使用热备盘。
因此系统出现错误的时候,手动添加热备盘,并进行重构。
在故障处理过程中,发现重构过程缓慢。
尽管在重构时,仍能读写数据,但不能大量的读写数据,影响了系统的正常使用。
因此,该磁盘阵列柜的重构功能需进一步优化。
3月27日中午重构完成时,虽然阵列状态显示正常,数据能正常读写,系统依然报“盘位丢失”错误。
海康威视技术人员通过阵列系统命令行界面,修复了系统错误。
因此,
此次故障,可能由硬盘损坏以及磁盘阵列柜控制系统故障共同引起。
由于磁盘阵列目前使用的是希捷SV35.3系列硬盘非存储专业级硬盘,在阳江平安项目中要求是24×7小时不停地保存读写数据,对硬盘的性能、质量要求都非常高,从硬盘的长时间工作可靠性、抗震性能(因为磁盘阵列的盘工作在狭小的空间里,特别是抗共振能力尤为重要)、磁盘阵列多硬盘并发读写一起工作的固有技术设计角度考虑,应采用专业存储级硬盘。
四、经验总结
1、RAID5不太适合小文件的频繁读写。
因此可在应用系统使用缓存机制,进行文件批量读写。
2、在日常维护过程中,尽量避免强制关机。
3、添加热备盘,当阵列出现其中一块磁盘有物理坏道后NAS存储服务器能够自行的重构阵列恢复数据。
可避免晚间或无人守护时发生磁盘故障所引起的种种不便。
4、建议采用希捷专业级存储硬盘Barracuda ES系列。
