磁盘阵列故障分析处理报告
ARECA RAID卡故障分析报告
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卡故障未能复现。
收费服务器磁盘阵列(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磁盘阵列常见故障以及修复方法服务器资料安全有着至关重要的意义，目前大多数服务器都采用了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 设备⽤于内存映射的地址寄存器，分配失败意味着系统未能为该设备提供必要的地址空间，导致存储池不可访问。
RAID 1 硬盘故障处理
Error code 0146（0142，etc）
Msg error code 200-0146
Msg: hard drive 0-self test log contains previous errors,the given error codeand message can be used by delltechnical support to help diagnose the problem.
当DELL售后服务人员将新的硬盘直接更换并Rebuild后会出现Drive 0和Drive 1硬盘上的数据均丢失，这样需要重新安装操作系统及CS3000等相关软件，给我们的工作带来相当大的麻烦；
此问题解决办法如下：
1、将DRIVE 0上已经损坏的硬盘拆卸下来，同时将DRIVE 1上的硬盘拆卸下来并安装在DRIVE 0的位置上；
2、将新的硬盘安装在DRIVE 1的位置上，然后重新启动电脑，电脑会自动将DRIVE 0的数据同步到DRIVE 1上；
这是因为RAID 1阵列数据镜像是有方向的，是从DRIVE 0 (主)向DRIVE 1（从）镜像，如果是DRIVE 1上的硬盘损坏则可以直接更换为新硬盘，重启电脑并同步后就不会出现数据丢失了。
(Know How Records)
横河电机（中国）有限公司
YokogawaChinaCo. Ltd.
Written By:Li qigui
磁盘阵列实验报告
磁盘阵列实验报告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`工具进行测试。
故障分析及处理报告
故障分析及处理报告一、故障背景在_____年_____月_____日，我们的_____系统在运行过程中突然出现了严重故障，导致整个业务流程陷入了停滞。
该系统是我们公司核心业务的重要支撑，其故障给公司带来了较大的经济损失和声誉影响。
因此，我们立即成立了故障应急处理小组，对此次故障进行深入的分析和处理。
二、故障现象故障发生时，系统出现了以下主要现象：1、用户无法登录系统，页面显示“连接超时”的错误提示。
2、正在进行的业务操作突然中断，数据丢失。
3、系统后台出现大量的错误日志，提示数据库连接异常。
三、故障影响范围此次故障影响范围较广，涉及到以下几个方面：1、公司内部的所有业务部门，包括销售、采购、财务等，无法正常开展工作。
2、外部客户无法访问系统进行下单、查询等操作，导致客户满意度下降。
3、与系统相关的接口服务也受到影响，与合作伙伴的数据交互中断。
四、故障分析过程（一）初步排查故障发生后，我们首先对系统的硬件设备进行了检查，包括服务器、网络设备等，未发现明显的硬件故障。
接着，我们对系统的软件环境进行了排查，包括操作系统、中间件、数据库等，发现数据库服务处于异常状态。
（二）深入分析为了进一步确定故障原因，我们对数据库的错误日志进行了详细分析。
发现数据库在处理大量并发请求时，出现了死锁现象，导致数据库连接资源被耗尽，从而引发了系统的故障。
同时，我们还对系统的代码进行了审查，发现部分业务逻辑存在缺陷，在高并发场景下容易导致数据库操作异常。
（三）原因确定综合以上的分析结果，我们确定此次故障的主要原因是：1、系统在设计时对高并发场景的考虑不足，数据库架构和索引设计不合理，无法承受大量的并发请求。
2、部分业务代码存在逻辑漏洞，在处理复杂业务时容易引发数据库异常。
3、系统的监控和预警机制不完善，未能及时发现数据库的异常情况，导致故障影响扩大。
五、故障处理措施（一）紧急恢复为了尽快恢复系统的正常运行，我们采取了以下紧急措施：1、重启数据库服务，释放被占用的连接资源。
Sun群集系统故障报告
XX市电视台Sun及oracle数据库系统故障报告编号：2007111507年11月四川XX信息产业有限责任公司目录第一章平台构成 (3)1.1硬件平台构成 (3)1.2操作系统平台: (4)1.3数据库平台: (4)1.4双机软件 (4)第二章故障现象与分析 (4)2.1现象描述 (4)2.2系统报错日志 (4)2.3现象分析 (7)第三章故障排查 (7)第四章故障定性与定位 (8)第五章故障预防、杜绝与实施条件 (13)前言2007年11月15日下午4时，系统工作不正常。
四川XX 信息产业有限责任公司与XX 电视台信息中心关技术人员一道对Sun 服务器、2套磁盘阵列，两套数据库、Sun cluster系统及RAC 做了详细的信息收集、故障分析、故障排查。
现小节如下：第一章 平台构成1.1 硬件平台构成包括2套Sun Fire 490服务器、2套Sun Storedge3310磁盘阵列构成。
拓扑图如下所示:服务器配置每台服务器Sun FireV490配置：CPU 个数: 2 CPU 类型: Sun UltraSparc IV 双核CPU 速度: 1050 Mhz ，L2 Cache16MB/CPU ，内存:8GB MB,内置2个72GB FC-AL 硬盘DVD 光驱，4个千兆以太网口、一块双通道Ultra320 SCSI 卡。
2个电源系统。
3310磁盘阵列 以态网IPMP V490服务器 V490服务器SCSI 电缆磁盘阵列配置：两套Sun StorEdge3310 SCSI盘阵，每套配置如下：512MB Cache的单阵列控制器，5X72GB 10 K rpm SCSI硬盘，分布通道0,ID号8~12,其中8~11做RAID5卷，12号盘为热备盘。
2个电源系统。
1.2 操作系统平台:系统运行64位Sun Solaris 9操作系统,Sun OS 5.9,OS内核版本Generic_118558-17。
磁盘阵列的故障诊断和维护
磁盘阵列的故障诊断和维护磁盘阵列是一种由多个磁盘组成的存储系统，通过将数据分散存储在多个磁盘上，提供了更高的容量、更高的性能和更好的数据冗余能力。
然而，由于硬件故障、软件问题或操作错误，磁盘阵列可能会出现故障，导致数据丢失或性能下降。
因此，及时的故障诊断和维护对于保证磁盘阵列的正常运行至关重要。
故障诊断是磁盘阵列维护过程中的关键步骤之一。
在发生故障时，首先需要确定故障的类型和原因。
常见的磁盘阵列故障包括磁盘损坏、磁盘控制器故障、电源故障、数据线松动等。
可以通过以下几种方式来进行故障诊断：1. 硬件检查：检查磁盘阵列的物理连接和电源是否正常。
确保所有磁盘和磁盘控制器都连接正确，并且电源供应稳定。
2. 日志分析：磁盘阵列通常会记录各种事件和错误信息的日志。
通过分析这些日志，可以确定故障的类型和出现的时间点。
可以使用专门的日志分析工具来加快诊断过程。
3. 软件工具：一些磁盘阵列厂商提供了专门的诊断工具，可以帮助用户检测和诊断故障。
这些工具通常会提供故障报告、错误代码解释和故障处理建议。
一旦确定了故障的类型和原因，就可以采取相应的维护措施来修复问题，以恢复磁盘阵列的正常工作状态。
以下是一些常见的磁盘阵列故障的维护方法：1. 磁盘更换：如果发现某个磁盘损坏，需要立即将其更换。
在更换磁盘之前，需要确保其他磁盘和磁盘控制器的正常工作。
在更换磁盘时，一定要按照相关的操作手册和指导进行操作，以确保数据的安全和完整性。
2. 控制器更换：如果发现磁盘控制器故障，需要将其更换。
更换控制器时，需要备份重要数据，并在更换后重新配置控制器。
3. 数据恢复：在某些情况下，磁盘阵列的数据可能会损坏或丢失。
在这种情况下，需要使用数据恢复工具或专业的数据恢复服务来尝试恢复丢失的数据。
注意，数据恢复过程可能是复杂且耗时的，因此务必确保在操作前备份重要数据。
4. 定期备份：为了防止数据丢失的风险，定期备份磁盘阵列中的数据是非常重要的。
备份可以包括完整备份、增量备份或差异备份等不同的备份方法。
PACS服务器硬盘阵列故障处理及其预防对策
服务 器年 代 久远 ，６ ３ Ｇ新 硬 盘早 已停 产无 处 购 买 ， 因 此 使 用 一 块 ７ Ｇ 的 新 硬 盘 替 换 。通 过 热 插 拔 的 方 ３ 式更 换 了新 硬盘 ， 错 消除 ， 报 硬盘 开始 重建 。但是 一
作者简介 ： 章晓 ， Ｅ—ｍ ｉ：ｚａｇｉｏｅｅ ６ ．ｏ ａｌ ｈｎ ｘａｈｈ＠１ ３ ｃｍ
取 出电池测 量 ， 现 电压 只 有 １ ８ 远远 低 于 额 定 发 ． Ｖ，
及， 它在医学影像信息 的录入、 查询 、 传递 和再利用 等 方 面给 工作 人 员 带 来 了 巨大 的便 捷 。但 是 ， 于 由
ＰＣ Ａ Ｓ是 一 个 新 生 事 物 ， 院在 对 其 进 行 管 理 和 人 医
Ｔ ｉ ｏ ｅ ｔ ｌ ｏｐｔ （ ａｚｏ ，１０ ０ ａ ｈ ｕＣ ｎｒ ｓｉ ｌ Ｔ ｉ ｕ ３８ ０ ） ｚ ａＨ ａ ｈ
【 ｂｔａｔ Ｔ ｉ ａｉ ｅｎ ｏｕｅ ｈｒ ｉ ｒ ｕ ｄ ｔｔ ａ ｅｔ ｆ Ａ Ｓｓ ｖ ｅｎｏｒ ｏ ｉｌ Ａ ｓ ｃ】 ｈ ｒｃ ｔｄ ｃｄ ａ ｄｓ ａ ａ ｆ ｌａ ｓｒ ｔ ｎ ｏ Ｐ Ｃ ｒ ｃ ｓ ｔ ， ｒ ｓ ｔｌ ｉｒ ａ ｄ ｋ ｒ ｙ ａ ｔ ｉ ｅ ｍ ｎ ｅ ｉ ｉ ｕ ｈ ｐａ
台 州市 中心 医院 （ 州 ，１００ 台 ３８０ ）
【 摘要】 介绍 了我院 Ｐ ｃ 服务器的磁盘故障及其处理方法， Ａｓ 并提出对医院 Ｐ Ｃ 服务器配置和管理上的一些建议。 ＡＳ
【 关键 词 】 Ｐ Ｃ Ａ Ｓ服务器 ； 障维修 ； 故 预防对策
【 中图分类号 】Ｔ ７７ Ｈ ８ 【 文献标识码 】 Ｂ 文章编号 ：６４—１４ （０ ０ ０ １７ ２ ２ ２ １ ）２—０２ ０ １３— ２
IT运维问题分析报告
IT运维问题分析报告为提高IT运维用户服务感知满意度，提高运维工作效率，完善运维基础设施建设，现对IT运维工作中存在的紧迫性问题进行分析总结，报告如下：一、运维现状******承担了我局****平台、****系统、****系统辅助审批、****系统的基础环境运维，涉及到了硬件、网络、系统、安全等各个方面。
详细信息见附件一《IT运维简介》。
二、问题分析根据IT运维现状，以及用户和中心各部对IT运维工作的意见和建议，参照《信息安全等级保护》三级标准，结合中心实际，对IT运维工作存在的问题分析总结如下：(一)制度保障缺失1.全局无《信息系统管理制度》，局用户没有信息化操作约束，运维团队无执行依据。
2.没有指导开展IT运维工作的保障制度，如《机房管理制度》、《密码管理制度》、《数据备份管理制度》、《系统管理制度》等。
不能有计划有目的地开展it运维工作。
(二)工作边界不清晰各IT运维相关部门岗位职责划分不够细，造成运维工作有交叉，工作边界不清晰。
例如：1.数据备份工作。
涉及到数据部和******，甚至全局所有用户。
2.信息系统涉密检查。
应有涉密主管部门牵头处理，涉及到IT运维的由运维团队配合处理。
3.系统安全运维。
涉及到运维管理和数据管理，工作界定不清晰，工作有交叉。
4.系统管理。
应用系统基础环境搭建、系统开发、测试、运维,会涉及业务运维和技术运维团队。
(三)基础运维环境不完善1.缺少统一的运维监控平台。
中心现已部署大量系统，每个系统都会涉及到一台甚至多台服务器，无统一的监控平台会导致服务器硬件、操作系统、应用服务、网络设备链路状态等关键部分出现故障时，无法第一时间发现并排查问题，运维的响应时间会变长。
同时也不能提前预防事件的发生。
2.缺少必要的安全防护。
专网缺少防火墙，所有用户和服务器处于同一网络中，服务器面临威胁。
没有漏洞补丁服务器，专网与因特网是隔离的，内网的计算机操作系统不能及时更新补丁。
缺少准入控制系统，本单位和外单位人员可以随意接入****专网，没有统一的用户身份认证，数据安全面临威胁。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
@@@@@@磁盘阵列
故障分析处理报告
报告提交人:@@@
现场工程师:@@@@@@
提交日期: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系列。