我正在尝试找出如何测量 LSI 控制器后面的几个 RAID 阵列的总写入字节数（或预期最大值的百分比，两者都可以）。这些控制器都是 LSI MegaRAID SAS 9271-8i 控制器。我尝试使用 MegaRAID Storage Manager 和 MegaCLI，但似乎都没有显示我需要的信息。我在网上找到了几个解决方案，但它们似乎只适用于 Linux，您可以在其中修补内核或以非常规方式使用 smartctl。这在 Windows 上对我来说不起作用。
我非常希望避免拔出驱动器，将它们放入另一台机器，使用 SMART 进行测试，然后再将它们放回去。这真的很麻烦。如果这很重要，每个控制器都有两个虚拟驱动器组，每个组有 4 个磁盘，采用 RAID10，由 SAS SSD 组成。
答案1
我不会费心观察硬件 RAID 控制器后面的 SSD 磨损情况。您使用 RAID 是有原因的，因此让控制器来处理吧。
使用企业级 SAS 驱动器运行是一大优势。如果 SSD与工作量相匹配（写入密集型/读取优化/等等），不需要深入研究。
在这种情况下，您的 LSI 9271 控制器具有其SSD Guard™技术（由您寻求的 SMART 数字触发），如果您担心快速磨损或某些过早出现故障的情况，它可以利用热备用 SSD。
答案2
megacli我在smartctlUbuntu Linux 中使用。
首先获取设备ID其中一个 SSD 驱动器：
megacli -pdlist -aALL -NoLog | egrep '(Raw Size|Inquiry Data|Device Id)'
例如设备 ID 5。然后执行：
smartctl -x -d megaraid,5 /dev/sda
这显示了连接到 Broadcom / Avago / LSI MegaRAID 控制器的 SSD 驱动器的详尽 SMART 报告。
答案3
在 CentOS 上，我当然会使用 smartctl 监控 SSD，对于读取大部分随机档案，我运行戴尔第 12、13 和 14 代，以及非戴尔三星 EVO 840、850 和 860。不要选择三星 PRO，虽然它们更贵，但正如戴尔论坛上所报告的那样，它们会随机地影响不少人，并毁掉整个卷。EVO 持续了 3 年，甚至 RAID 5 仍然幸存下来。~3 突然因增长约 66 个磁盘批次而死亡。
在 CentOS 上，我每隔 x 小时通过 Python 脚本和 SSH 对基于 Dell R720/730/740xd LSI 的 PERC RAID 从 0 到 23 循环运行一次，并使用如下命令 + 此输出的自定义解析器和用于存储日期的数据库 + 用于跟踪偏差的值来比较重要值的偏差：
smartctl -a -d sat+megaraid,0 /dev/sda
我发现观察我是否接近三星保证的通过“241 Total_LBAs_Written”写入的 TB 数很重要，因为如果用户滥用写入限制，它们可能都会突然死亡，而 RAID 将无济于事，以及重新分配可能会提示您很快就需要备用。