主页 / server / 问题 / 581524
Accepted
symcbean
Asked: 2014-03-13 03:31:14 +0800 CST

BBWC：理论上是个好主意，但有人保存过你的数据吗？

  • 772

我很熟悉 BBWC（电池支持的写入缓存）的用途 - 并且以前在我的服务器中使用过它们，即使是好的 UPS 也是如此。显然存在它不提供保护的故障。我很想知道它是否真的在实践中提供了任何真正的好处。

（注意，我专门寻找那些有 BBWC 并且发生过崩溃/故障的人的回应，以及 BBWC 是否有助于恢复）

更新

在这里得到反馈后，我越来越怀疑 BBWC 是否会增加任何价值。

为了对数据完整性有任何信心，文件系统必须知道数据何时被提交到非易失性存储（不一定是磁盘——我将回到这一点）。值得注意的是，很多磁盘都谎报数据何时提交到磁盘 ( http://brad.livejournal.com/2116715.html )。虽然假设禁用磁盘缓存可能会使磁盘更诚实似乎是合理的，但仍然不能保证情况确实如此。

由于 BBWC 中的缓冲区通常很大，因此屏障可能需要将更多数据提交到磁盘，因此会导致写入延迟：一般建议是在使用非易失性回写缓存时禁用屏障（并禁用 on-磁盘缓存）。然而，这似乎会破坏写操作的完整性——仅仅因为更多的数据保存在非易失性存储中并不意味着它会更加一致。事实上，可以说如果逻辑事务之间没有分界，那么确保一致性的机会似乎比其他方式少。

如果 BBWC 在数据进入其非易失性存储（而不是提交到磁盘）时确认障碍，那么它似乎满足了数据完整性要求而没有性能损失——这意味着仍然应该启用障碍。然而，由于这些设备通常表现出与将数据刷新到物理设备一致的行为（使用屏障显着变慢）以及禁用屏障的广泛建议，因此它们不能以这种方式表现。为什么不？

如果操作系统中的 I/O 被建模为一系列流，那么当写入缓存由操作系统管理时，就有一些范围可以最小化写屏障的阻塞效应 - 因为在这个级别上只有逻辑事务（单个流) 需要提交。另一方面，不知道哪些数据位构成事务的 BBWC 将不得不将其整个缓存提交到磁盘。内核/文件系统是否真正在实践中实现这一点需要比我目前愿意投资的更多的努力。

告诉fibs关于已提交的内容和突然断电的磁盘组合无疑会导致损坏 - 并且在中断后不执行完整fsck的日志或日志结构化文件系统不太可能检测到损坏更不用说试图修复它。

就故障模式而言，根据我的经验，大多数突然停电都是由于失去主电源而发生的（通过 UPS 和管理关机很容易缓解）。人们将错误的电缆从机架中拉出意味着数据中心卫生状况不佳（标签和电缆管理）。UPS 无法阻止某些类型的突然断电事件 - PSU 或 VRM 中的故障 带有屏障的 BBWC 将在此处发生故障时提供数据完整性，但是此类事件有多常见？从这里没有回应来看，非常罕见。

当然，在堆栈中将容错移到更高的位置比 BBWC 的成本要高得多——但是将服务器作为集群实现对于性能和可用性还有很多其他好处。

减轻突然断电影响的另一种方法是实施 SAN——AoE 使这成为一个实际的提议（我真的不明白 iSCSI 的意义），但成本也更高。

storage

5 个回答

  1. Best Answer

    当然。我有电池支持的缓存 (BBWC) 和后来的闪存支持的写缓存 (FBWC) 在崩溃和突然断电后保护飞行中的数据。

    在 HP ProLiant 服务器上，典型消息是：

    POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

    这意味着，“嘿，写入缓存中有数据在重新启动/断电后幸存下来！！我现在要把它写回磁盘！！ ”

    一个有趣的案例是我对在龙卷风期间断电的系统进行的事后分析，数组序列是：

    POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss
POST Error: 1779-Drive Array Controller Detects Replacement Drives
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

    1793 POST 错误是唯一的。- 系统在使用时，数据在阵列加速器内存中时电源中断。但由于是龙卷风，四天之内都没有恢复供电，所以阵列电池耗尽，里面的数据也丢失了。服务器有两个 RAID 控制器。另一个控制器有一个 FBWC 单元，它的使用寿命比电池长得多。该驱动器正确恢复。由空电池支持的阵列导致一些数据损坏。

    尽管该设施有充足的电池运行时间，但四天没有电力和危险条件使得任何人都无法安全关闭服务器。 在此处输入图像描述

    • 34

  2. 是的，有过这种情况。

    数据中心中“没有 UPS”的服务器（数据中心有 UPS）。PDU 故障 - 系统严重崩溃。没有数据丢失。

    基本上就是这样。BBWC 的好处在于它在机器中。有一个 UPS - 相信我，有时有人会做一些愚蠢的事情（比如拉错电缆）。UPS 是外部的。哦，那根电缆；）

    • 10

  3. 我有 2 个案例，其中硬件 RAID 控制器中的电池支持缓存完全失败（在 2 个不同的公司中）。

    BBC 依赖于电池工作这一不足为奇的想法。问题是控制器中的电池有时会发生故障，而具有破坏性的是，在许多硬件突袭控制器中，它会默默地发生故障。我们认为我们有一个缓存可以防止断电，但我们没有。

    断电时，RAID 阵列数据丢失如此广泛，以至于所有磁盘内容都无法恢复。一切都丢失了。其中一个案例涉及一台完全专用于测试的机器，但仍然如此。

    在那之后，我说“再也不会”，切换到 Linux 中基于软件的磁盘镜像 (mdadm) + 基于日志的 fs，它对断电 (ext4) 具有良好的恢复能力并且永不回头。当然，我已经在没有极高 IO 使用率的服务器上使用它。

    • 4

  4. 这似乎需要对这个问题进行第二次回答......

    我刚刚让一个独立的 VMware ESXi 主机丢失了 RAID 5 阵列中的一个驱动器。降级的阵列影响了 VM 和应用程序级别的性能。

    Smart Array P410i in Slot 0 (Embedded)    (sn: 5001438011138950)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)

      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
      physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
      physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)

    这家公司的 IT 人员不知道驱动器发生故障并硬重置服务器（以使其变得更好？）。

    对上面运行繁忙的虚拟机的受损阵列执行此操作的有趣效果是：

    缓存状态详细信息：当前阵列控制器在上次重置或上电时在其电池/电容器支持的写入缓存中存储了有效数据。这表明系统可能没有正常关闭。阵列控制器已自动将此数据写入或尝试将这些数据写入驱动器。此消息将继续显示，直到阵列控制器下一次重置或重启。

    因此，即使系统突然停止，飞行中的数据也受到 BBWC 的保护。虚拟机全部恢复正常，系统现在状态良好。

    • 4

  5. 除了“保存您的数据”之外，它们还有其他好处。它们还擅长缓冲写入（在缓存中），以便通过保持磁盘写入队列较低来提高 IO 子系统的性能。这对于交互式性能至关重要的服务器尤其重要——例如，Citrix XenApp 或 Windows 终端服务。

    这对于网络服务器或文件服务器来说不太重要。你可能没有注意到，甚至没有习惯，有点滞后。但是，当您单击 Office 应用程序中的图标时，您期望响应速度。你的 CEO 也是如此。

    • 3

相关问题