在一个早上不会出现的服务器有点恐慌之后，高层决定业务需要高可用性/故障切换设置。
我们有5个主要服务器（4个Linux，1个OpenBSD），所有这些服务器都需要运行以供公司操作。 三个服务器是相当标准的（文件/networking/数据库），第四个处理大多数networking路由和networking代理，而第五个支持我们的电话系统，并具有非标准的硬件。
我的老板曾经说过，服务器故障的周转时间应该在30分钟以内。
我在这个领域的经验是不存在的（我只是一个“提升”的程序员），所以我想我的问题可以归结为：
谢谢。
我认为你应该先把数字合起来描述与履行所述“要求”有关的成本，看它是否在预算之内。 如果你不习惯所有用于满足要求的“正常”方法（故障转移集群，具有“热迁移”function的pipe理程序等），那么你可能会find一个能够帮忙
可行性研究会有一些相关的成本，但是发现一个好的解决scheme不符合规定的要求将会花费很多成本（这意味着pipe理层需要更加现实地设定期望值）需要花更多的钱），而不是花费大量的时间去完成一些没有达到要求的事情，并在这个过程中花费大量的金钱。
这听起来像是你的老板把这个数字从空中拉出来了。 也许他已经做了一些分析，并知道与各种系统的停机时间相关的每小时成本是多less，但是我对此表示怀疑。 这听起来像是一些与现实无关的天才号码。 如果你所有的系统都需要这种可用性的话，我会感到满意的。 在研究业务的过程中，您可能发现只有一部分function需要具有这样的正常运行时间和容错能力（因此，这样的解决scheme最终成本会更低）。 我确定手机和业务线应用程序都在那里，但是您可能会对某些其他系统的停机时间有一定的容忍度。
我的直觉说，你可能会发现使用虚拟化技术创build一个基于冗余硬件之间的虚拟机迁移的故障转移系统。 是否适合您的预算将取决于您的业务，因为您一定需要某种types的SAN才能有效地工作。
不过，不要打折“传统”故障转移群集。 如果您的应用程序非常适合这样的configuration，那么肯定也有“胜利”。
我想知道你的老板是否想过灾难性的失败情景（build筑烧伤，洪水，龙卷风，盗窃等）。 如果还没有计划好的话，这将是在一些业务连续性计划和灾难恢复应急方面工作的好机会。
从可以进来的人那里得到一些帮助，并研究你的业务并提出build议。 你不会后悔的。
“这条路导致很多痛苦和伤害…”
那么，您的业务连续性计划是什么？ 你的灾难恢复计划？
你有讨论过吗？ 写下来？ testing过的IT？
您需要与“更高层”进行适当的对话，并且真正达到高可用性要求的底层，因为对于不同的服务来说这是不同的。
那么早上他们感觉到的是什么“痛点”呢？
是吗？
我假设你已经为主系统购买了高质量的硬件？ 好，因为在硬件上廉价出来是一个虚假的经济，因为这些服务器与“双”的一切都在盒子里。
我也会假设你知道如何重build一个服务器，交换风扇，电源，机架服务器，configuration双pathnetworking到冗余交换机？ 你已经做了足够多的时间去理解什么是有效的，哪些是不正常的，什么是正常的，什么是错误的？ 如果没有，那么得到帮助和培训（或者至less是实践和经验）。
也许很多问题是恐惧。 他们不知道会发生这样的问题（以及服务器对他们的业务有多重要），而且你不知道自己在做什么（？）信心问题？
在进入非常昂贵的HA路线之前，您需要获得上述所有权利。 企业是否可以负担这种昂贵的设备（根据定义，大部分设备只能用于故障，通常不会使用！）
埃文打了一些好点，但这可能是一些具体的成本效益的方式来获得1小时以上的故障恢复时间。
小型企业可能意味着小硬件，所以做一些简单的事情可能不是很多的成本，在面对问题时实际上增加了大量的弹性。 主要的想法是有额外的硬件准备好去。
首先，对虚拟IP的想法感到舒服。 这是用户可以与之通话的IP地址，但可以驻留在您提供的任何服务器上。 这是您的用户的IP地址，应用程序将要与之通话。 这将是最有利于最终解决任何解决scheme。 有一个VIP意味着你不应该重新configuration任何应用程序时，故障。 另外，请记住，拥有冗余硬件也会增加pipe理开销，执行两次configuration更新而不是1次。
如果我们从路由/networking代理服务器开始，那么这可能是最简单的，因为它们不会有任何需要存储在盒子上的真实状态。 所以只需要获得同一个盒子的副本，并且configuration相同。 我会保持两个插在局域网段，并假设你是互联网在另一个接口，交换电缆，如果他们是一个失败。 从路由的angular度来看，您将所有的lan客户端设置为将.1地址（VIP）作为其默认路由的目标，代理服务器将服务器A的.2地址和服务器B的.3地址。 这样他们都可以pipe理configuration更新（适用于两者）。 所有你需要做的故障转移是从0.2中删除.1 IP分配，并将其移动到.3，并将互联网连接移动到其他接口。 这不是很复杂，很容易做到和理解，并花费第二个盒子的额外硬件。 如果你可以在互联网上获得冗余，你可以增加一些复杂性，并使用类似VRRP的自动故障转移。
没有具体细节，很难说，但你是Web服务器可能是一样简单。 添加具有相同configuration的第二台服务器，在两者之间创build一个vIP，并在发生故障时将VIP移动到备份。 我一般不介意会话状态在故障转移时是否丢失（这是导致故障转移的关键问题）。 所以如果用户不得不重新login，没有什么大不了的。 同样，vrrp可能可以用于自动故障转移。
移到你的DB，这是非常复杂的。 大多数数据库都有一些主要/辅助模型，您可以将原始数据库备份到辅助数据库，然后将所有事务日志或数据库更改复制到辅助数据库。 再次，您可以将其与VIP实际访问数据库的应用程序/用户结合使用。 但是，故障转移更为复杂。 根据主服务器的故障，您可能需要启动并运行驱动器来复制和保留事务日志。 然后使辅助活动。 如果您可以容忍一些丢失的数据，那么您可以立即启用辅助活动。 在故障转移之后，服务器B现在是您的主要工作，而您的工作将是恢复服务器A，并将其转换为新的备份，以便在服务器b最终出现问题时准备好失败。
文件服务器始终是最难的部分，因为不像数据库那样，获得文件系统的内置function并不那么困难。 但是，通过拥有第二台服务器可以实现一定程度的弹性，并且可以简单地编写一个脚本来扫描文件系统的更改，并将任何新文件复制到次要服务器上。 你基本上可以运行一个cron的rsync我相信这样做。 再次，您使用您提供给用户的VIP，如果您进行故障转移，则可以移动。 在您的脚本中，我强烈build议您在传输文件之前检查以确保系统是VIP的拥有者。 你真的真的不希望rsync在错误的方向执行，并覆盖你正在做的任何改变。 如果失败，这可能会丢失一些文件，也不会再保护用户自己删除文件。
我不知道你可以做什么关于你的电话系统…这真的取决于供应商，以及如何设置。 供应商可能有一些现成的弹性解决scheme。
一些最后的警告。 确保你彻底的testing你要去的任何设置。 确保你知道如何在不丢失重要信息的情况下让它失败。 testingtestingtesting，以确保它在您需要时能够正常工作。 确保你有configuration变更，软件更新等适当地应用到主要和备份的进程。 好消息是，当您想要升级服务器时，您可能会执行受控的故障转移function。这不是主动 – 主动设置，所以您不知道在需要的情况下，辅助服务器是否可以正常工作。
我在电信方面工作，我们的设备非常冗余，在大多数情况下，包括地理冗余。 我们的第一个故障点是冗余，在更改后没有经过testing，用户进行了不知道冗余模型如何工作的更改。 但是，我们还有一个额外的问题，就是我们所有的设备都需要在几秒钟内支持自动故障切换。 如果您只需要在30-60分钟内启动并运行，则可以容忍手动干预您的故障转移。 你只需要做好准备。 祝你好运。
每个人都是非常好的，所以只是一些评论。
30分钟是不可能保证的，尤其是对于一切。 你可以说它的目标，但是没有办法可以保证，因为总是有X的因素。 你可能会有两条ISP线路和一辆卡车撞向build筑物，并把它们都拿出来，因为你不认为从build筑物的两端引出它们是非常重要的。
作为成本计算的开始，加倍一切。 你有5台服务器，所以你需要加倍。 它不需要全部硬件上，你可以虚拟化，但你明白我的意思。 最重要的是，一切都必须HA知道，这也将增加成本，你可能会发现你将不得不用一个新的replace你的路由器，哦，你需要其中2。 不要忘记把电源加倍并得到发电机，因为你不能保证电力公司在30分钟内就能恢复。
这些例子或多或less是一个热备份设置，这是我怀疑你的老板所想的。
对于小企业来说，我觉得更好的是devise一个恢复和分类一切的计划。
找出哪些服务是
关键（业务停止）
重要的（业务放缓）
例行公事（生意可以没有它一段时间）。
例如，你的呼叫中心电话是关键的，所以也许这是值得购买第二台服务器和第二个ISP，你的平均停电时间大约是15分钟，所以我们会得到一个UPS将持续60分钟（不忘记工作站）。 现在让我们说ERP只是重要的，这意味着你可以在没有它的情况下运作一下。 也许你的呼叫中心的人使用它，但如果它停下来，他们可以恢复到笔或纸或记事本，然后更新ERP。 如果发生这种情况，那么这个程序可能会比较便宜，然后试图使其成为关键服务。 而常规的打印机可能就像打印机一样，确实是一件痛苦的事情，但是如果它们全都瘫痪的话，我们可以做几天。
这也给你的命令来解决的东西，如果s ** t真的有一天击中粉丝:)
可能吗？ 当然。 它是负担得起的？ 可能不是一个“小企业”，特别是如果你有一个老板给你任意数字的工作，他要求IT部门的高可用性，由一个deputized程序员组成（在其他地方看过很多次，永远不会漂亮的压力水平，如果你的情况是他们的）。
故障转移是可能的，但通常需要冗余硬件，SAN在服务器之间共享数据等等。换句话说，如果不聘用专门的pipe理员来处理，运气好的话可以获得资金。
您提到的呼叫系统硬件是专用硬件，您提到的是呼叫中心。 您应该与供应商谈谈选项，以使冗余。 如果这样做，首先会失去支持。
其他系统可能通过投资VMWaretypes的解决scheme（或Hyper-V或XenServer，但我首先看VMware和XenServer）来获得一些冗余。 然后，您可以考虑获得一台SAN，一台带有快速networking交换机的强大服务器，并在出现故障时使用LiveMotion在硬件服务器之间迁移虚拟化服务器，并根据需要平衡服务器之间的部分负载。
你提到你在这些系统上运行Linux。 有了钱可以获得多个服务器，您可以用心跳程序和STONITH来设置DRBD，以在服务器之间复制数据，并在不可用时接pipe; 你需要设置一个系统，使每个服务器都复制一份，同时在服务器机房（如果你有一个服务器机房的话），你的功耗和散热也会增加一倍。 这可以做硬件的成本和你的理智。 另外，您必须对其进行testing，对其进行configuration时会出现停机时间，而且您仍有可能无法正常工作，因为仍有可能出现问题，必须予以处理（拆分大脑），例如）。
最后是让一对系统充当空白系统的计划，并且有一个非常好的备份计划，以便在服务器死亡时允许您将数据恢复到“空白”系统之一。 有现场硬件会给你一些select，如果/当一个服务器死亡; 但在恢复数据时仍然会出现一些停机时间，并且需要有关如何正确地将应用程序安装到新服务器的说明。 根据你工作的速度和数据的大小，你可能会有几小时到一两天的停机时间。 你有一个工作，已知的良好的备份为您的服务器，有一个恢复计划，是吗？
你应该尝试吗？ 我的第一反应是，如果你对任何build议都摸不着头脑，或者试图想出这些东西，那么你就不应该这样做。 你需要一个咨询公司来研究这个问题并计算成本并实施它，或者你需要雇佣一个专门的系统pipe理员来为你的公司做这件事。
他们告诉你这样做的事实，你说你只是一个被“提升”的程序员，而你有一个PHB告诉你在最大失败时间为30分钟时给予冗余，一条小溪。