我们有几个主机，每个主机都有一个相同的热备用主机，该主机已打过补丁并进行了更新，因此几乎具有相同的软件和配置。如果发生故障，网络电缆会切换，DHCP 服务器会使用新的 MAC 地址进行更新。这是最好的情况，因为通常还有更多需要修改的地方。
我觉得拥有热备用主机既浪费电力，又浪费时间进行维护，而且由于在故障转移时需要修改配置，所以我想问以下问题：
热备用主机是否已经过时？现在有更好的方法吗？
与其使用热备用主机，不如将其设为冷备用，取出硬盘并将其放入主主机，然后将 RAID 从 1 更改为 1+1。如果发生故障，我只需更换网络电缆、更新 DHCP 服务器、取出硬盘并将其插入冷备用并打开电源。在我看来，这样做的好处是 2x2 磁盘始终保持同步，因此只需维护一台主机，并且在故障转移时无需更改配置。
这是一个好主意吗？
答案1
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 这样的系统在某些方面可能做得更好，但在其他方面却一点也不好。
对我来说，如果意图是任何类型的灾难故障转移，这会使您提出的方法从一开始就行不通。
答案2
是的，它有点老派。现代硬件不会只是失败经常如此。要么专注于提高应用程序的可用性（并非总是可能），要么专注于提高各个主机的弹性所需的项目……
对于主持人：
- 购买更好的硬件。
- 确保您拥有支持合同。
- 登记您的服务器的支持合同（备件根据注册数据在本地库存！）
- 使用冗余电源、（硬件？）RAID、冗余风扇。
- 如果服务器无法容纳上述冗余功能，请保留备用机箱或组件，以便在发生故障时能够自行修复。
按照故障频率降序排列，我看到的故障频率依次为：磁盘、RAM、电源、风扇……有时是系统板或 CPU。但最后两个才是您的支持合同应该发挥作用的地方。
答案3
它效率很低——尤其是因为依赖人工干预来进行切换。
我曾在运行热 DR 站点的地方工作过 - 确切地说，就是与主站点完全相同的服务器，随时可以投入使用。然而，DR 切换是一个自动化过程 - 我们说的不是布线、一些小麻烦和开关，而是当我们按下按钮时，将所有内容从一个站点切换到另一个站点的过程。
这种方法的成本高得令人难以置信，但这是一个商业决策——可接受的风险与实现目标所需的资金。一般来说，恢复时间目标呈指数曲线——越接近零，成本就越高。
但你的问题其实就是这个。是您的恢复时间目标，以及实现该目标的最有效方法是什么。等待服务器启动需要几分钟。当服务器在凌晨 4 点突然启动时，需要多长时间才能完成调整和“恢复任务”？
可接受的停电时间是多长时间？
我建议，如果您正在进行“热恢复”，则需要考虑集群。如果充分利用 VMWare，您可以相当便宜地进行集群 - “故障转移”到 VM - 即使是从物理机 - 也意味着您没有运行冗余硬件。（好吧，N+1 而不是 2N）。
如果您的 RTO 足够长，则关闭该盒子。您可能会发现 RTO 足够长，因此从备份进行冷重建是可以的。
答案4
热备用或冷备用的概念取决于如何首先构建应用程序。
我的意思是，如果应用程序的构建方式是将数据和服务负载分散到多台机器上，那么任何一台机器导致系统瘫痪的概念就应该消失。在这种情况下，您不需要热备用。相反，您需要足够的额外容量来处理单个机器/组件的故障。
例如，标准 Web 应用程序通常需要 Web 服务器和数据库服务器。对于 Web 服务器，只需平衡 2 个或更多服务器的负载。如果其中一个服务器崩溃了，也没什么大不了的。数据库通常更难处理，因为它必须被设计为多主机，所有数据在参与的机器之间同步。因此，您最终将拥有 2 个（或更多）数据库服务器，而不是单个数据库服务器，它们都满足您的数据需求。谷歌、亚马逊、Facebook 等大型服务提供商都走上了这条路。开发时间的前期成本更高，但如果您需要扩展，它会带来回报。
现在，如果您的应用程序不是以这种方式构建的，或者只是禁止对应用程序进行改造，那么您很可能需要一个热备用。