在对一天内不会出现的服务器感到恐惧之后，高层领导决定该企业需要高可用性/故障转移设置。
我们有5台主服务器（4台Linux，1台OpenBSD），所有这些服务器都需要运行才能使公司正常运行。其中三台服务器相当标准（文件/ Web /数据库），第四台处理大多数网络路由和Web代理，而第五台支持我们的电话系统并具有非标准硬件。
我的老板说，服务器故障的周转时间应少于30分钟。
我在该领域的经验不存在（我只是一个“晋升”的程序员），所以我想我的问题真的可以归结为：
谢谢。
Answers:
我认为您应该首先汇总数字以描述与满足规定的“需求”相关的成本，以查看其是否在预算之内。如果您不满意用于满足要求的所有“常规”方法（故障转移群集，具有“热迁移”功能的虚拟机管理程序等），那么您最好找一位能够帮帮忙。
可行性研究会涉及一些成本，但要发现一个好的解决方案不符合既定要求（这意味着管理层需要更现实地设定期望），要花费更少的钱。需要花更多的钱），而不是半途而废，最终根本无法满足要求，并且在此过程中浪费了大量资金。
听起来您的上司刚刚把那个数字弄空了。也许他已经进行了一些分析，并且知道与各种系统的停机时间相关的每小时成本是多少，但是我对此表示怀疑。听起来像是一些与现实不相关的“天空中的馅饼”。如果您所有的系统都需要这种可用性，我会感到惊讶。在研究业务的过程中，您可能发现只有一部分功能需要具有一定程度的正常运行时间和容错能力（因此，这样的解决方案最终将花费更少的钱）。我确定电话和行业应用程序都在那儿，但是您可能对某些其他系统的停机时间有一定的容忍度。
我的直觉是，使用虚拟化技术来创建基于冗余硬件之间的虚拟机迁移的故障转移系统，您可能会找到一个胜利。是否适合您的预算取决于您的业务，因为您肯定需要某种类型的SAN才能使其有效运行。
但是，请勿打折“传统”故障转移群集。如果您的应用程序非常适合这种配置，那么肯定也有“胜利”。
我想知道您的老板是否考虑过灾难性的失败情况（建筑物烧毁，洪水，龙卷风，盗窃等）。如果尚未计划，那么这将是在一些常规业务连续性计划和灾难恢复应急计划中进行工作的绝好机会。
从可以进来研究您的业务并提出建议的人那里获得一些帮助。你不会后悔的。
“这条道路导致很多痛苦和伤害……”
那么，您的业务连续性计划是什么？您的灾难恢复计划？
你讨论过了吗？写下来吗？测试过了吗？
您需要与“高层”进行适当的交谈，并真正达到高可用性要求的底线，因为对于不同的服务它是不同的。
那么他们那天早上感觉到的“痛点”到底是什么？
是吗
我认为您已经为主要系统购买了高质量的硬件？好的，因为廉价地购买硬件是不正确的，因为这些服务器附带了“双重”功能。
我还将假设您知道如何重建服务器，交换风扇，电源，机架服务器，将双路径网络配置为冗余交换机？您已经完成了足够的时间，以了解哪些有效，哪些无效，什么是正常的以及什么是错误的？如果没有，请寻求帮助和培训（或至少要有实践和经验）。
也许很多问题是恐惧。他们不知道可能会发生这样的问题（以及服务器对他们的业务有多重要），您真的不知道自己在做什么（？）信心问题？
在采取非常昂贵的HA路线之前，您需要获得上述所有权利。企业能否负担得起这种昂贵的设备（根据定义，大多数设备只会在出现故障时使用，而且往往永远不会使用！）
Evan取得了一些不错的成绩，但是在遇到故障时，这里可能是一些节省成本的特定方法，可以使故障恢复时间少于1小时。
小型企业可能意味着小型硬件，因此，面对一些问题，做一些简单的事情实际上可以增加很大的弹性，可能并不会增加很多成本。主要思想是准备好其他硬件。
首先，对虚拟IP的想法感到满意。这是用户将与之交谈的IP地址，但是可以驻留在您与之交谈的任何服务器上。这是您的IP地址，应用程序将要与之对话。这将是您最终寻求任何解决方案的最有帮助的方法。拥有VIP意味着您无需在故障转移时重新配置任何应用程序。此外，请记住，拥有冗余硬件也会增加管理开销，而不是执行两次配置更新，这会带来影响。
如果我们从路由/ Web代理服务器开始，那可能是最简单的，因为它们不会是需要存储在盒子本身的任何真实状态。因此，只需复制同一框，然后将其配置为相同即可。我将两者都插入LAN网段，并假设您在另一个接口上连接互联网，如果电缆出现故障，请交换电缆。从路由角度来看，您将所有局域网客户端设置为其默认路由的目标.1地址（VIP），并且代理服务器为服务器A提供.2地址，为服务器B提供.3地址。这样，它们都可以被管理以进行配置更新（两者都适用）。故障转移所需要做的就是从.2中删除.1 IP分配并将其移至.3，然后将Internet连接移至另一个接口。它不是很复杂，易于操作和理解，并花费第二个盒子的额外硬件。如果您可以在Internet端获得冗余，则可以增加一些复杂性，并使用VRRP之类的功能进行自动故障转移。
没有细节，很难说，但是您的Web服务器可能就这么简单。添加具有相同配置的第二台服务器，在两者之间创建一个vIP，并在出现故障时将VIP移至备份。我通常不介意在故障转移时会话状态是否丢失（这是导致故障转移的关键问题）。因此，如果用户必须再次登录，没什么大不了的。同样，vrrp可能可以用于自动故障转移。
进入数据库，这要复杂得多。大多数数据库具有某种主数据库/辅助数据库模型，您可以在其中将原始数据库备份到辅助数据库，然后将所有事务日志或数据库更改复制到辅助数据库。同样，您可以将其与VIP结合使用，以实际访问数据库的应用程序/用户。但是，故障转移更加复杂。根据主数据库的故障，您可能实际上需要启动并运行驱动器以复制和保留事务日志。然后将辅助设备激活。如果您可以容忍一些丢失的数据，则可以立即启用辅助数据。故障转移之后，服务器B现在是您的主要服务器，而您的工作就是还原服务器A，然后将其转换为新的备份，以便在服务器b最终出现问题时可以随时进行故障处理。
文件服务器始终是最难的部分，因为与数据库服务器不同，要获得文件系统的内置功能要困难得多。但是，可以通过拥有第二台服务器来实现某种程度的弹性，并只需编写一个脚本来扫描文件系统中的更改，然后将任何新文件复制到您的辅助服务器上。您可以基本上在我相信的cron上运行rsync。同样，您使用提供给用户的VIP，如果进行故障转移，则可以转移给VIP。在您的脚本中，我强烈建议您在传输文件之前检查以确保系统是VIP的所有者。您确实真的不希望rsync在错误的方向执行并覆盖您用户所做的任何更改。如果文件失败，可能会丢失一些文件，
我不知道您该如何处理电话系统……这实际上取决于供应商及其设置方式。卖方可能有一些现成的解决方案以提高弹性。
最后几句话警告。确保彻底测试将要使用的任何设置。确保知道如何进行故障转移而又不会丢失关键信息。测试测试以确保它在您需要时可以正常工作。确保您具有适当的流程，可以将配置更改，软件更新等正确地应用于主数据库和备份数据库。好消息是，当您想关闭服务器进行升级时，您可以进行受控的故障转移。这不是一个主动-主动设置，因此您不知道辅助服务器在需要时是否可以工作。
我在电信部门工作，我们的设备非常冗余，包括大多数情况下的地理冗余。我们的第一个故障点是，更改后未测试冗余，并且用户进行更改时不知道冗余模型如何工作。但是，还有一个问题，就是我们所有的设备都需要在不超过几秒钟的时间内支持自动故障转移。如果您只需要在30-60分钟内启动并运行，则可以容忍对故障转移进行手动干预。您只需要做好准备。祝好运。
其他人的观点都很好，因此只提出几点意见。
30分钟是不可能保证的，尤其是对于一切。您可以说它是一个目标，但它不可能得到保证，因为总有X因子。您可能有2条ISP线路，一辆卡车撞入建筑物，并将它们都带出，因为您不认为让它们从建筑物的相对两端布线很重要。
首先，将成本加倍。您有5台服务器，因此需要加倍。它并不需要全部在硬件上，您可以进行虚拟化，但是您明白我的意思了。最重要的是，所有内容都必须了解HA，这也会增加成本，您可能会发现自己将不得不用新的路由器替换路由器，哦，您需要其中2台。不要忘记加倍供电并获得发电机，因为您不能保证电力公司会在30分钟内恢复正常。
这些示例都认为它或多或少是热备用设置，这是我怀疑您的老板正在考虑的设置。
对于小型企业，我发现更好的方法是设计一个计划，以对所有内容进行恢复和分类。
找出哪些服务是
严重（业务停止）
重要（业务放慢）
例行的事务（一段时间后企业可以做）。
例如，您的呼叫中心电话非常重要，因此也许值得购买第二台服务器和第二台ISP，而您的平均断电时间约为15分钟，因此我们将获得一台可以持续使用60分钟的UPS（请勿要么忘记工作站）。现在说ERP仅是重要的，这意味着您可以在没有它的情况下稍作操作。也许您的呼叫中心人员会使用它，但是如果它掉了，他们可以还原为笔和纸或记事本，然后再更新ERP。如果它宕机了，那么这样做的过程可能会比较便宜，然后尝试使其成为一项关键服务。常规的打印机可能像打印机，这很痛苦，但是如果它们全部掉了，我们可以待几天。
如果某天真的击中了粉丝，那也可以给您命令修复东西：)
可能吗？当然。负担得起吗？可能不适合“小企业”，尤其是如果您有一个老板给您任意数量的工作依据，并且他要求由代表程序员组成的IT部门提供高可用性（在其他地方多次看到，从来没有如果您的情况与他们的情况相同，则可以很好地缓解您的压力）。
可以进行故障转移，但是通常需要冗余硬件，SAN在服务器之间共享数据等，换句话说，如果他们不雇用专门的管理员来照顾它，那么很幸运。
您提到的呼叫系统硬件是专用硬件，并且暗示您是呼叫中心。您应该与供应商讨论使该冗余成为可能的选项。这样做会首先使支持无效。
通过投资于VMWare型解决方案（或Hyper-V或XenServer，但我先来看VMware和XenServer），您很可能会在其他系统上获得一些冗余。然后，您可以查看如何获得SAN，几台功能强大的服务器以及快速的网络交换机，并使用LiveMotion在发生故障的硬件服务器之间迁移虚拟化的服务器，并根据需要平衡服务器之间的一些负载。
您提到您正在这些系统上运行Linux。有了钱来获得多台服务器，您可以考虑使用心跳程序和STONITH来设置DRBD，以在服务器之间复制数据并在服务器不可用时接管数据。您可能正在考虑建立一个系统，在该系统上您实际上要复制每台服务器，并使服务器机房（如果有服务器机房）的功耗和散热量增加一倍。可以为此付出硬件成本和理智的代价。另外，您还必须对其进行测试，在配置它时会停机，并且仍然有可能有时无法正常工作，因为仍然有很多问题需要解决（拆分）例如大脑）。
最后一个计划是让几个系统充当空白系统，并且有一个非常好的备份计划，如果服务器死机，则允许您将数据还原到“空白”系统之一。如果服务器死机，则现场配备硬件将为您提供一些选择。但是还原数据时仍然会有一些停机时间，并且您需要有关如何将应用程序正确安装到新服务器的说明。根据您的工作速度和数据量，您的停机时间可能会持续数小时至一两天。您的服务器确实有一个工作正常且性能良好的备份，并且已制定恢复计划，是吗？
你应该尝试吗？我的第一个反应是，如果您对任何建议都suggestions之以鼻，或者想尝试一下这些东西而感到肚子有点不适，那您就不应该这样做。您需要一家咨询公司来研究问题并确定成本并实施，或者需要聘请专门的系统管理员来为您的公司做这件事。
他们告诉您要执行此操作，而您却说您只是“被提升了的程序员”，而您有一个PHB告诉您提供冗余（最多30分钟的故障时间）的事实是，您很友善一条小河。