标签: software-raid

我发现了一个 Mumble 服务器的性能问题，我在上一个问题中描述了它是由未知来源的 I/O 延迟问题引起的。由于我不知道是什么导致了这种情况以及如何进一步调试它，因此我在询问您对这个主题的想法。

我正在运行Hetzner EX4S 根服务器作为 KVM 管理程序。该服务器运行 Debian Wheezy Beta 4，并通过 LibVirt 使用 KVM 虚拟化。

服务器有两个不同的 3TB 硬盘，因为在报告 SMART 错误后更换了其中一个硬盘。第一个硬盘是 Seagate Barracuda XT ST33000651AS（512 字节逻辑，4096 字节物理扇区大小），另一个是 Seagate Barracuda 7200.14 (AF) ST3000DM001-9YN166（512 字节逻辑和物理扇区大小）。有两个 Linux 软件 RAID1 设备。一个用于未加密的引导分区，另一个用作加密其余部分的容器，使用两个硬盘驱动器。

后一个 RAID 设备内部有一个 AES 加密的 LUKS 容器。在 LUKS 容器内有一个 LVM 物理卷。虚拟机管理程序的 VFS 在描述的 LVM 物理卷上分为三个逻辑卷：一个用于 /，一个用于 /home，一个用于交换。

下面是块设备配置栈的示意图：

sda (Physical HDD)
- md0 (RAID1)
- md1 (RAID1)

sdb (Physical HDD)
- md0 (RAID1)
- md1 …

我试图了解 ZFS 在特定条件下的行为，但文档对此不是很明确，所以我只能猜测。

假设我们有一个具有冗余的 zpool。采取以下事件顺序：

1. 设备 D 与服务器之间的连接出现问题。这会导致大量故障，并且 ZFS 会导致设备出现故障，从而使池处于降级状态。

2. 当池处于降级状态时，池会发生突变（数据被写入和/或更改。）

3. 连接问题已得到物理修复，设备 D再次可靠。

4. 知道 D 上的大多数数据都是有效的，并且不想通过重新同步给池带来不必要的压力，管理员改为运行zpool clear pool D。Oracle 文档指出，当故障是由于暂时性问题引起且已得到纠正时，这是适当的操作。

我读过，这只zpool clear清除错误计数器，并将设备恢复到在线状态。然而，这有点麻烦，因为如果这就是它所做的一切，它将使池处于不一致的状态！

这是因为步骤 2 中的突变不会成功写入 D。相反，D 将反映连接失败之前池的状态。这当然不是 zpool 的规范状态，并且可能会在另一个设备发生故障时导致硬数据丢失 - 但是，池状态不会反映此问题！

我至少会假设基于 ZFS 强大的完整性机制，尝试从 D 读取变异数据会捕获错误并修复它们。然而，这会带来两个问题：

1. 除非完成清理，否则不能保证读取命中所有突变；和

2. 一旦 ZFS确实命中了变异数据，它（我猜测）可能会再次使驱动器出现故障，因为 ZFS 会认为它正在损坏数据，因为它不记得以前的写入失败。

理论上，ZFS 可以通过跟踪降级状态期间发生的突变并在清除时将它们写回 D 来规避此问题。但出于某种原因，我怀疑事实并非如此。

我希望对 ZFS 有深入了解的人可以在这方面提供一些启发。

当我重新启动系统时，我的四个 Linux 软件 raid 阵列之一丢弃了它的两个设备之一。其他三个阵列工作正常。我在内核版本 2.6.32-5-amd64 上运行 RAID1。每次我重新启动时， /dev/md2 只出现一个设备。我可以通过说 $ sudo mdadm /dev/md2 --add /dev/sdc1 来手动添加设备。这工作正常，并且 mdadm 确认设备已重新添加如下：

mdadm: re-added /dev/sdc1

添加设备并允许阵列重新同步后，$ cat /proc/mdstat 的输出如下所示：

Personalities : [raid1] 
md3 : active raid1 sda4[0] sdb4[1]
      244186840 blocks super 1.2 [2/2] [UU]

md2 : active raid1 sdc1[0] sdd1[1]
      732574464 blocks [2/2] [UU]

md1 : active raid1 sda3[0] sdb3[1]
      722804416 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      6835520 blocks [2/2] [UU]

unused devices: <none>

然后在我重新启动后，这就是 $ cat /proc/mdstat 的输出：

Personalities …

我们最近买了一台塔式服务器，我想在上面安装 Debian。我认为该设备具有硬件 RAID，因为我可以看到 BIOS 屏幕。事实证明，它仍然是一个软件 RAID。当我通过该固件配置 RAID 驱动器时，我仍然可以在 Debian 安装程序中看到两个硬盘驱动器。当我尝试从安装程序中重新分区时，Debian 警告软件 RAID 驱动器将丢失。

我对此有点失望，因为我一直认为硬件 RAID 会产生更好的性能。但无论如何，我现在的问题是我是否应该使用 Debian 安装程序来配置 RAID 驱动器，并从主 BIOS 禁用这个“固件”RAID？或者我应该使用这个固件创建单独的驱动器，而不是使用安装程序？使用固件是否有任何可靠性优势？

此固件版本为：

LSI MegaRaid Software RAID BIOS Version A.10.10211615R
LSI SATA RAID Found at PCI Bus No:00 Dev No:1F

更新 我可以从评论中看到其他人也对我是否在处理硬件 RAID 感到困惑。我的机器是联想 ThinkServer TS 440。在它的数据表中，它说有

Integrated SATA SW RAID 0/1

据我了解，主板上的芯片中包含一个硬件组件（这就是它具有 PCI 地址的原因？），但不是典型的硬件 RAID。

我目前正在寻找一个新的备份服务器。它将运行带有直连存储的 Windows Server 2012 R2，我正在考虑使用存储空间而不是使用 RAID 卡。（作为 ZFS 的粉丝，如果做得好，我绝对可以看到取消硬件 RAID 的优势。）

我希望我的性能关键工作负载主要是顺序的。由于这是顺序数据的大容量存储，读取（备份恢复）的性能比写入（进行备份）的性能更重要，我认为奇偶校验将非常适合获得密集且低成本的备份数据存储。

我见过一些博客有关的结果，当谈到写奇偶校验磁盘，如在性能本文通过公测的消息的德里克Wlodarz，以及在从Fujutsu本白皮书。

根据这篇 TechNet 文章，在对此进行更多研究时，似乎该博客文章没有使用专用日志磁盘进行测试，这显然可以显着提高奇偶校验存储空间的写入性能。不幸的是，我之前提到的两个基准测试都没有测试日志磁盘的影响，但微软声称他们已经看到了 150% 的性能提升，对于我的应用程序，我认为这将把它放在我想要的地方.

这些都是很好的信息，但有一个我无法找到的谜题。有问题的 SSD 仅用于镜像中的日志记录，据我所知，它们只是为了提供短期稳定的写入存储。因此，我不希望它们必须非常大。至少，这是我从使用 ZFS 和 ZIL 磁盘得出的结论 - 大小并不重要，尽管在这种情况下，较大的磁盘在密集的写入负载下可能会持续更长时间，因为写入分布在较大的磁盘上。

我已经明白，由于写入数组的所有内容也将写入日志，因此它们需要能够以所需的速率写入。正如微软所说：

请注意，日志磁盘的吞吐量现在将是在此特定存储池上创建的所有奇偶校验空间的总体吞吐量限制，您可能会用额外的容量来换取性能。换句话说，确保专用日志磁盘非常快，并根据池上的奇偶校验空间数量扩展日志磁盘的数量。

然而，我找不到什么，我希望 Server Fault 能够帮助我的是：是否有任何最佳实践专门用于选择适当大小的 SSD 用作存储空间奇偶校验的日志磁盘大批？

我正在尝试设置一个可启动的软件 RAID，该 RAID 将包含根文件系统并启动 Linux Mint Qiana。它将用于在小型数据中心运行一些图形监控应用程序，以及访问其他 LAN 节点的简单终端。

我有两个 500GB SATA 驱动器（/dev/sda和/dev/sdb），我将用它们来构建 RAID 1 阵列。似乎有很多方法可以做到这一点，但我有点不清楚如何创建md0可启动的设备。

我的第一种方法是使用 Live Linux Mint 安装 CD 启动。然后我会切换到 bash 提示符并/dev/sda使用sfdisk. 我创建了一个简单的分区表，其中包括一个主分区和一个交换分区。然后我简单地将分区表从/dev/sda到/dev/sdb：

sfdisk -d /dev/sda | sfdisk /dev/sdb

好的，现在我有两个驱动器可以组装成一个 RAID 阵列。我首先通过说创建数组：

mdadm --create --verbose --metadata=0.90 /dev/md0 --level=mirror 
   --raid-devices=2 /dev/sda /dev/sdb

大约一个小时后，阵列完成同步。

我现在可以/dev/md0通过给它一个文件系统来初始化：

mke2fs -t ext4 /dev/md0

好的，现在一切看起来都很好。因此，我切换回 Live CD 安装，并将 Linux 安装到/dev/md0. 一切正常，直到安装程序尝试运行grub-install，然后它收到一个致命错误。

所以，我一直在研究，试图了解这里的原因。我不完全确定为什么会发生这种情况，但我的理解是它与“一个人不能简单地从 …

这个问题与没有奇偶校验的 RAID 级别上的 SSD（如 RAID 0、1、10）有关。

FastPath 的推荐设置是将Write Policy设置为Write Through，将Read Policy 设置为No Read Ahead，将IO Policy 设置为Direct。这会禁用 RAID 控制器上的缓存，请求会直接命中 SSD。

软件 RAID 不是已经在做同样的事情了吗？FastPath 与它有何不同？

编辑：

这个问题似乎是软件与硬件 RAID 性能和缓存使用的重复，但这个问题很广泛，一般讨论软件与硬件 RAID。几乎所有的答案都说没有缓存的硬件 RAID 是无用的。

这个问题是关于为什么在涉及 SSD 时，带 FastPath（和不带缓存）的硬件 RAID 比软件 RAID 更好。

如果我在 RAID 1 中有 2 个驱动器，并且 Raid 控制器出现故障，这是否意味着服务器上的网站将在更换控制器之前停机？或者在更换有故障的raid卡之前，一切仍会自动作为软件raid进行吗？

我目前正在尝试不同的方法来使用快速 NVMe 设备提高 Debian 上相当大的、基于旋转磁盘的软件突袭 (mdadm) 阵列的写入速度。

我发现使用一对这样的设备（raid1，镜像）来存储文件系统的日志会产生有趣的性能优势。我用来实现这一点的安装选​​项是noatime,journal_aync_commit,data=journal.

在我的测试中，我还发现添加该barrier=0选项在写入性能方面提供了显着的好处。但是，我不确定在我的特定文件系统配置中使用此选项是否安全。这是内核文档关于 ext4 写屏障的说明：

写屏障强制对日志提交进行适当的磁盘排序，使易失性磁盘写入缓存可以安全使用，但会降低一些性能。如果您的磁盘以一种或另一种方式由电池供电，则禁用屏障可以安全地提高性能。

我使用的特定 NVMe 设备是Intel DC P3700，它具有内置断电保护功能，这意味着在意外关机的情况下，由于储备能量，临时缓冲区中仍然存在的任何数据都可以安全地提交到 NAND 存储贮存。

所以我的问题是，如果日志存储在具有电池后备缓存的设备上，而文件系统的其余部分本身位于没有此功能的磁盘上，我是否可以安全地禁用 ext4 写屏障？

我的 RAID 1 镜像中有一个特定的硬盘驱动器，它在重负载下会发生故障，通常是在我运行完整备份时。

驱动没有问题。好的，在写入超级块时出现一个错误，但仅此而已。每次运行备份过程时，始终需要手动重新添加同一磁盘和同一阵列。

是否有任何设置可以md更好地容忍导致该驱动器在负载下发生故障的原因？

这是 Debian 上的 Linux 软件 RAID。

更新：根据要求，DMSG失败时的输出：

[2347429.116507] print_req_error: I/O error, dev sda, sector 15751347328
[2347429.116511] sd 1:0:0:0: [sda] tag#1058 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK
[2347429.116516] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
[2347429.116518] sd 1:0:0:0: [sda] tag#1058 CDB: Write(16) 8a 08 00 00 00 00 00 00 00 28 00 00 00 08 00 00
[2347429.116522] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
[2347429.116523] print_req_error: I/O error, dev sda, sector 40
[2347429.116526] mpt2sas_cm0: …