热备主机与冷备主机？

Question

我们有几个主机，其中有一个相同的热备用主机，该主机已打补丁和更新，因此非常接近具有相同的软件和配置。万一出现故障，网络电缆会被切换，DHCP 服务器会更新为新的 MAC 地址。这是最好的情况，因为通常还有更多需要修改的地方。

我觉得有一个热备主机很浪费电，浪费时间去维护它，而且因为在故障转移的情况下需要修改配置，所以我想问以下问题：

热备用主机是否过时，现在有更好的方法吗？

与其使用热备用主机，不如将其设为冷备用，将硬盘驱动器放入主主机并将 RAID 从 1 更改为 1+1 是否有意义。如果出现故障，我所要做的就是更换网线、更新 DHCP 服务器、取出硬盘驱动器并将它们插入冷备用并打开电源。在我看来，好处是 2x2 磁盘始终同步，因此在故障转移时只需要维护一台主机并且不需要更改配置。

这是一个好主意吗？

Answer 1

是的，这有点老派。现代硬件不仅经常失败。要么专注于使您的应用程序具有更高的可用性（并非总是可行），要么专注于使您的单个主机更具弹性所需的项目......

对于主机：

• 购买更好的硬件。
• 确保您有支持合同。
• 注册您的服务器的支持合同（备件根据注册数据在本地储存！）
• 使用冗余电源、（硬件？）RAID、冗余风扇。
• 如果服务器无法容纳上述冗余功能，请保留备用机箱或组件，以便在发生故障时能够自行修复。

为了降低故障频率，我经常看到：磁盘、RAM、电源、风扇……有时是系统板或 CPU。但是最后两个是您的支持合同应该开始的地方。

Answer 2

这是相当低效的 - 尤其是因为依赖于手动干预来进行切换。

我曾在运行热 DR 站点的地方工作过 - 从字面上看，与主服务器相同的服务器，可以立即运行。然而，DR 切换是一个自动化过程——我们不是在谈论布线、一些摆弄和开关，而是当我们按下按钮时，这个过程会将所有内容从一个站点翻转到另一个站点。

这种方法非常昂贵，但这是一个商业决策 - 可接受的风险与实现目标所需的资金。通常，恢复时间目标有一个指数曲线——它越接近零，成本就越高。

但这就是你的问题，真的。什么是你的恢复时间目标，什么是实现它的最有效的方法。等待服务器启动需要几分钟时间。当它在凌晨 4 点流行时，有人需要多长时间来进行调整和“恢复任务”？

可接受的中断时间是多久？

我建议，如果你在做“热恢复”，你应该考虑集群。通过充分利用 VMWare，您可以在集群上相当便宜 - “故障转移”到 VM - 即使是从物理机 - 意味着您没有运行冗余硬件。（好吧，N+1 而不是 2N）。

如果您的 RTO 足够长，请关闭盒子。您可能会发现 RTO 足以从备份进行冷重建。

Answer 3

Sobrique 解释了手动干预如何使您提出的解决方案达到最优，ewwhite 谈到了各种组件的故障概率。这两个 IMO 都提出了很好的观点，应该认真考虑。

然而，有一个问题到目前为止似乎没有人评论过，这让我有点惊讶。你提议：

将【当前热备主机】设为冷备，取出硬盘放入主主机，将RAID从1改为1+1。

这并不能保护您免受操作系统在磁盘上所做的任何事情。

它只能真正保护您免受磁盘故障的影响，通过从镜像 (RAID 1) 移动到镜像镜像 (RAID 1+1)，您可以大大降低开始时的影响。通过增加每个镜像集中的磁盘数量（例如，从 2 磁盘 RAID 1 到 4 磁盘 RAID 1），您可以获得相同的结果，同时很可能会提高普通操作期间的读取性能。

那么，让我们看看这可能会失败的一些方式。

• 假设您正在安装系统更新，并且某些原因导致该过程中途失败；可能是电源和 UPS 故障，或者可能是您发生了意外事故并遇到了严重的内核错误（现在 Linux 非常可靠，但仍然存在风险）。
• 也许更新会引入您在测试期间没有发现的问题（您测试系统更新，对吗？）需要在修复主系统时故障转移到辅助系统
• 也许文件系统代码中的错误会导致虚假的、无效的磁盘写入。
• 也许一个粗手指（甚至恶意）管理员使用rm -rf ../*或rm -rf /*代替rm -rf ./*.
• 也许您自己软件中的错误会导致它严重破坏数据库内容。
• 也许病毒设法潜入。

也许，也许，也许……（我敢肯定，您提出的方法可能会失败的方法还有很多。）但是，最终这归结为您的“两组总是同步的”“优势”。有时您不希望它们完全同步。

根据具体发生的情况，那时您需要准备好打开和切换的热备用或冷备用，或者进行适当的备份。无论哪种方式，如果故障模式涉及硬件存储设备故障（磁盘崩溃）之外的大部分内容，则镜像的 RAID 镜像（或 RAID 镜像）都无济于事。像 ZFS 的 raidzN 之类的东西在某些方面可能会做得更好，但在其他方面则完全没有。

对我来说，如果目的是任何类型的灾难故障转移，这将使您提出的方法从一开始就行不通。

Answer 4

它是老派的事实并不一定会使使用热备份成为一个坏主意。

您主要关心的应该是基本原理、您运行的风险是什么，以及运行热备份如何减轻这些风险。因为在我看来，您的热备件只能解决硬件故障，这虽然并不少见，但既不是您运行的唯一风险，也不是最有可能的。第二个问题是替代策略是否提供更多风险降低或显着节省。

运行具有多个手动故障转移步骤的热备件将花费很长时间并且可能会出错，但我似乎也看到了自动化故障转移，HA 集群套件变成了主要的集群f * cks。

另一件事是，在发生本地灾难时，同一位置的热备用或冷备用无法提供业务连续性。