热备用主机与冷备用主机？

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

我觉得拥有一个热备用主机会浪费电力，而且浪费时间来维护它，并且由于在发生故障转移时需要修改配置，因此我想提出以下问题：

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

与其拥有一个热备用主机，不如将其变成一个冷备用，取下硬盘驱动器并将其放入主主机，并将RAID从1更改为1 + 1。万一发生故障，我所要做的就是更换网络电缆，更新DHCP服务器，取出硬盘驱动器并将它们插入冷备用中并打开电源。如我所见，这样做的好处是2x2磁盘始终保持同步，因此故障转移时仅需维护一台主机，无需更改配置。

这是一个好主意吗？

Sobrique解释了手动干预如何使您提出的解决方案达到最佳状态，而ewwhite谈到了各种组件的故障概率。这两个海事组织都提出了很好的观点，应予以认真考虑。

但是，到目前为止，似乎还没有人评论过一个问题，这让我有些惊讶。您建议：

将[当前的热备用主机]用作冷备用，取出硬盘驱动器并将其放入主主机，然后将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之类的东西在某些方面可能会有所改善，而在其他方面则根本没有改善。

对我来说，如果意图是某种灾难故障转移，那么这将使您从一开始就不建议采用这种方法。

是的，这是一所古老的学校。现代硬件并不会经常失败。要么专注于使应用程序具有更高的可用性（并非总是可能），要么专注于使您的单个主机更具弹性的项目。

对于主机：

• 购买更好的硬件。
• 确保您有支持合同。
• REGISTER您的服务器的支持合同（备件是基于登记数据本地库存！）
• 使用冗余电源，（硬件？）RAID，冗余风扇。
• 如果服务器不具备上述冗余功能，请保留备用机箱或组件以备故障时进行自我修复。

以降低故障频率的顺序，我看到：磁盘，RAM，电源，风扇最多……有时是系统板或CPU。但是，这最后两个是您的支持合同应加入的地方。

它的效率很低-尤其是因为要进行切换需要手动干预。

我曾在运行热门DR站点的地方工作过-实际上，与主服务器相同的服务器可以立即使用。但是，DR切换是一个自动化的过程-我们不是在谈论电缆，一点摆弄和切换，而是当我们按下按钮时将所有内容从一个站点切换到另一个站点的过程。

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

但这确实是您的问题。什么是你的恢复时间目标，什么是实现它的最有效的方法。等待服务器启动将花费几分钟。凌晨4点，某人花了多长时间进行调整和“恢复任务”？

可接受的中断时间有多长？

我建议，如果您正在执行“热恢复”，则需要考虑集群。充分利用VMWare，在群集上可以算是便宜的-“故障转移”到VM（甚至从物理上）到VM，这意味着您没有运行冗余硬件。（好吧，N + 1，而不是2N）。

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

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

您主要关心的是基本原理，所面临的风险是什么以及运行热备份如何减轻这些风险。因为据我所知，您的热备件仅解决硬件故障（虽然这并不罕见），但它既不是您运行的唯一操作风险，也不是最有可能发生的操作风险。第二个关注点是替代策略是否可以提供更多的风险降低或可观的节省。

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

另一件事是，在发生本地灾难的情况下，同一位置的热备用或冷备用不能提供业务连续性。

具有热备件或什至冷备件的概念首先取决于如何构建应用程序。

我的意思是，如果应用程序的构建方式使数据和服务负载分散在多台计算机上，那么任何一台使系统瘫痪的计算机都应该消失。在这种情况下，您不需要热备用。相反，当单个机器/组件死亡时，您需要足够的额外容量来处理。

例如，标准的Web应用程序通常需要Web服务器和数据库服务器。对于Web服务器，只需负载平衡2个或更多。如果一个人死了，那就没什么大不了的了。数据库通常更困难，因为必须将其设计为多主数据库，并在参与机器之间同步所有数据。因此，最终只有2个（或更多）而不是单个数据库服务器，它们都可以满足您的数据需求。大型服务提供商（例如Google，Amazon，Facebook等）已经走了这条路。开发时间有更多前期成本，但是如果您需要扩展，它会带来红利。

现在，如果您的应用程序不是以这种方式构建的，或者只是简单地禁止重新安装该应用程序，那么是的，您可能需要热备用。