在某天早上服务器无法启动，有点担心之后，高层决定企业需要高可用性/故障转移设置。
我们有 5 台主服务器（4 台 Linux、1 台 OpenBSD），公司运营需要所有服务器都运行。其中三台服务器相当标准（文件/Web/数据库），第四台服务器处理大多数网络路由和 Web 代理，而第五台服务器支持我们的电话系统，并且具有非标准硬件。
我的老板说过服务器故障的解决时间应该在 30 分钟以内。
我在这个领域没有任何经验（我只是一个被“提拔”的程序员），所以我想我的问题实际上可以归结为：
- 即使是具有一般服务器管理技能的人也应该尝试这样做吗？如果是，我应该阅读什么？我应该与谁交谈？
谢谢。
答案1
我认为您应该首先汇总一些数字，以描述满足所述“要求”所需的成本，看看它是否在预算之内。如果您对用于满足要求的所有“常规”方法（故障转移群集、具有“热迁移”功能的虚拟机管理程序等）不满意，那么最好找一位可以提供帮助的顾问。
可行性研究会产生一些相关成本，但是发现一个好的解决方案不符合规定的要求（这意味着管理层需要更现实地设定期望 - 或者他们需要投入更多资金）的成本要比做一些半心半意的事情最终根本无法满足要求并在此过程中浪费大量资金的成本要低得多。
听起来你的老板只是凭空捏造了这个数字。也许他已经做了一些分析，知道各种系统停机每小时的成本是多少，但我对此表示怀疑。这听起来像是一个与现实无关的空想数字。如果你的所有系统都需要这种可用性，我会感到惊讶。在研究业务的过程中，你可能会发现只有一小部分功能需要具有这种程度的正常运行时间和容错能力（因此，这种解决方案最终会降低成本）。我确信电话和业务线应用程序是其中之一，但你可能对其他一些系统的停机时间有一定的容忍度。
我的直觉告诉我，使用虚拟化技术创建一个基于冗余硬件之间虚拟机迁移的故障转移系统可能会对你大有裨益。它是否符合你的预算取决于你的业务，因为你肯定需要某种类型的 SAN 才能有效地工作。
但不要低估“传统”故障转移群集。如果您的应用程序非常适合这种配置，那么它肯定也有“优势”。
我想知道你的老板是否考虑过灾难性故障场景（建筑物燃烧、洪水、龙卷风、盗窃等）。如果还没有计划，这将是进行一些一般业务连续性规划和灾难恢复应急工作的绝佳机会。
向可以研究您的业务并提出建议的人寻求帮助。你不会后悔的。
答案2
“这条路会带来很多痛苦和伤害……”
那么，你的业务连续性计划是什么？你的灾难恢复计划是什么？
你们讨论过它吗？写下来了吗？测试过了吗？
您需要与“上级”进行适当的对话，并真正了解高可用性的要求，因为不同的服务要求不同。
那么那天早上他们感受到的“痛点”到底是什么呢？
是吗？
- 电话停止工作了？相当严重（而且明显）的问题。是的 - 这需要一个“解决方案”，但希望这是在支持协议下？
- 网站故障？可以 - 相当明显，但并不意外，除非您拥有庞大的网络影响力，否则并不那么重要。让此服务器停机几个小时是可以的。
- 数据库服务器宕机了？真可怕……希望你有好的备份！不要丢失数据，否则你的生意就会失败。但是，只要数据是安全的，那么服务器就是重要的，应该有一个恢复计划。
- 文件和打印（以及内部应用程序等）。对于大多数人来说，这是一件非常麻烦的事情，因为他们会坐在那里，什么也不做，等你修复它。
我假设您已经为主系统购买了高质量的硬件？很好，因为硬件太便宜是一种错误的节约，因为这些服务器在包装盒中配备了“双重”所有东西。
我还假设您知道如何重建服务器、更换风扇、电源、安装服务器、将双路径网络配置为冗余交换机？您已经做过很多次了，知道什么有效、什么无效、什么是正常的、什么是错误的？如果不知道，请寻求帮助和培训（或至少练习和经验）。
也许很多问题都是因为恐惧。他们不知道这样的问题会发生（以及服务器对他们的业务有多重要），而且你真的不知道你在做什么（？）信心问题？
在选择非常昂贵的 HA 路线之前，您需要先做好上述所有准备。企业能否负担得起这种昂贵的设备（而且根据定义，大多数设备只会在发生故障时使用，而且通常永远不会使用！）
答案3
埃文提出了一些很好的观点，但这里也许有一些具体的、经济有效的方法可以在发生故障时将恢复时间缩短至 1 小时以内。
小型企业可能意味着硬件规模较小，因此做一些简单的事情可能不需要花费太多成本，但实际上这些事情在遇到问题时可以增加大量的弹性。主要想法是准备好额外的硬件。
首先，要熟悉虚拟 IP 的概念。这是用户将与之通信的 IP 地址，但可以驻留在您提供的任何服务器上。这是您的用户和应用程序想要与之通信的 IP 地址。对于您最终选择的任何解决方案，它都是最有帮助的。拥有 VIP 意味着您在故障转移时不必重新配置任何应用程序。此外，请记住，拥有冗余硬件也会增加管理开销，需要进行两次配置更新而不是一次。
如果我们从您的路由/ Web 代理服务器开始，这可能是最简单的，因为它们不会有任何需要存储在盒子本身上的真实状态。因此，只需获取同一个盒子的副本，并对其进行相同的配置。我会将两者都插入 LAN 段，并假设您的互联网在另一个接口上，如果发生故障，请交换电缆。从路由的角度来看，您将所有 LAN 客户端设置为以 .1 地址（VIP）为目标作为其默认路由，代理服务器为服务器 A 提供 .2 地址，为服务器 B 提供 .3 地址。这样，它们都可以进行配置更新管理（适用于两者）。而您要做的就是从 .2 中删除 .1 IP 分配并将其移动到 .3，然后将互联网连接移动到另一个接口。它不是很复杂，易于操作和理解，并且需要第二个盒子的额外硬件。如果您可以在互联网端获得冗余，则可以增加一些复杂性，并使用 VRRP 之类的东西实现自动故障转移。
如果没有具体细节，很难说，但您的 Web 服务器可能同样简单。添加具有相同配置的第二台服务器，在两者之间创建一个 vIP，并在发生故障时将 VIP 移至备份。我通常不介意在故障转移时丢失会话状态（这是导致故障转移的关键问题）。因此，如果用户必须再次登录，也没什么大不了的。同样，vrrp 可能可用于自动故障转移。
转到您的数据库，这要复杂得多。大多数数据库都有某种主/辅助模型，您可以将原始数据库备份到辅助数据库，然后将所有事务日志或数据库更改复制到辅助数据库。同样，您可以将其与 VIP 相结合，用于实际访问数据库的应用程序/用户。但是，故障转移更加复杂。根据主服务器的故障，您可能需要实际启动并运行驱动器以复制和剩余的事务日志。然后使辅助服务器处于活动状态。如果您可以容忍一些数据丢失，那么您可以立即使辅助服务器处于活动状态。故障转移后，服务器 B 现在是您的主服务器，您的工作是恢复服务器 A，并将其转变为新的备份，以便在服务器 b 最终出现问题时准备好进行故障转移。
文件服务器始终是最难的部分，因为与数据库不同，获得文件系统的内置功能要困难得多。但是，通过使用第二台服务器，并简单地编写一个脚本来扫描文件系统的更改并将任何新文件复制到辅助服务器，可以实现一定程度的弹性。我相信，您基本上可以在 cron 上运行 rsync 来执行此操作。同样，您使用提供给用户的 VIP，如果执行故障转移，则可以将其转移。在您的脚本中，我强烈建议您在传输文件之前检查以确保系统是 VIP 的所有者。您真的真的不想让 rsync 以错误的方向执行并覆盖用户所做的任何更改。如果发生故障，这可能会丢失一些文件，并且也无法再次保护用户自己删除文件。
我不知道你能对你的电话系统做些什么……这真的取决于供应商及其设置方式。供应商可能有一些现成的弹性解决方案。
最后要提醒大家的是，一定要彻底测试您要采用的任何设置。一定要知道如何在不丢失关键信息的情况下进行故障转移。要不断测试，确保在需要时可以正常工作。一定要制定流程，确保配置更改、软件更新等都能正确应用于主服务器和备份服务器。好消息是，当您想要关闭服务器进行升级等时，您可能可以进行受控故障转移。这不是主动-主动设置，因此您不知道在需要时辅助服务器是否会正常工作。
我从事电信行业，我们的设备具有极高的冗余度，在大多数情况下包括地理冗余度。我们的首要故障点是冗余度在更改后没有经过测试，并且用户在不知道冗余模型如何工作的情况下进行更改。但是，我们还有一个额外的问题，即我们所有的设备都需要在几秒钟内支持自动故障转移。如果您只需要在 30 - 60 分钟内启动并运行，那么您可以容忍手动干预故障转移。您只需要做好准备。祝您好运。
答案4
有可能吗？当然有可能。价格合理吗？对于“小型企业”来说可能不太现实，尤其是如果你的老板给你随意规定的工作数字，并且他要求 IT 部门（包括一名代理程序员）提供高可用性（这种情况在其他地方经常出现，如果你的情况与他们一样，你的压力水平肯定不会好到哪里去）。
故障转移是可能的，但通常需要冗余硬件、SAN 在服务器之间共享数据等...换句话说，如果他们不聘请专门的管理员来处理此事，那你就很难获得资金了。
您提到的呼叫系统硬件是专用硬件，您暗示它是呼叫中心。您应该与供应商讨论如何让其变得多余。首先，搞砸它可能会导致支持失效。
对于其他系统，您很可能通过投资 VMWare 类型的解决方案（或 Hyper-V 或 XenServer，但我会首先考虑 VMware 和 XenServer）来获得一些冗余。然后，您可以考虑获得 SAN、几台配备快速网络交换机的强大服务器，并在发生故障时使用 LiveMotion 在硬件服务器之间迁移虚拟化服务器，并在需要时平衡服务器之间的部分负载。
您提到您在这些系统上运行 Linux。如果有足够的资金购买多台服务器，您可以考虑设置带有心跳程序和 STONITH 的 DRBD，以便在服务器之间复制数据，并在其中一台服务器不可用时接管；您将考虑设置一个系统，其中您实际上复制了每台服务器，并且服务器机房的功耗和散热量增加了一倍（如果您有服务器机房）。这可以通过硬件成本和您的理智来实现。此外，您必须对其进行测试，在配置它时会有停机时间，并且您仍然有可能无法工作，因为仍然有可能出现需要处理的问题（例如，裂脑）。
最后，计划让几个系统充当空白系统，并制定一个非常好的备份计划，以便在服务器死机时将数据恢复到其中一个“空白”系统。如果/当服务器死机时，现场有硬件会给你一些选择；但在恢复数据时，你仍然会有一些停机时间，你需要指导如何正确地将应用程序安装到新服务器上。根据你的工作速度和数据量，你的停机时间可能会持续几个小时到一天或两天。你做为您的服务器准备一个有效、已知良好的备份，并且制定一个恢复计划，是吗？
你应该尝试一下吗？我的第一反应是，如果你对这些建议感到困惑，或者在试图想出这些事情时感到很沮丧，那么你就不应该尝试。你需要一家咨询公司来研究这个问题，计算出成本并实施它，或者你需要雇佣一个专门的系统管理员来为你的公司做这件事。
事实上，他们告诉你这么做，而你说你“只是一个被提拔的程序员”，你有一个 PHB 告诉你要提供冗余，最大故障时间为 30 分钟，这说明你有点陷入困境。