Mat*_*hew 11 disaster-recovery small-business high-availability
在对某天早上无法启动的服务器感到有些恐慌之后，高层决定业务需要高可用性/故障转移设置。
我们有 5 台主服务器（4 台 Linux，1 台 OpenBSD），所有这些服务器都需要运行，公司才能运营。其中三个服务器相当标准（文件/网络/数据库），第四个处理大多数网络路由和网络代理，而第五个支持我们的电话系统并具有非标准硬件。
我的老板说过，服务器故障的周转时间应该在 30 分钟以内。
我在这个领域的经验是不存在的（我只是一个被“晋升”的程序员），所以我想我的问题真的可以归结为：
谢谢。
我认为您应该首先将数字放在一起来描述与满足规定的“要求”相关的成本，看看它是否在预算范围内。如果您对用于满足要求的所有“常规”方法（故障转移群集、具有“热迁移”功能的虚拟机管理程序等）不满意，那么您可能最好找一位顾问帮帮忙。
可行性研究会产生一些成本，但发现一个好的解决方案不符合规定的要求（这意味着管理层需要更现实地设定期望——或者他们需要花更多的钱）而不是做一些半途而废的事情，最终根本无法满足要求并在此过程中花费大量资金。
听起来你的老板刚刚从空中提取了这个数字。也许他做了一些分析，知道与各种系统停机相关的每小时成本是多少，但我对此表示怀疑。这听起来像是一些与现实无关的天上掉馅饼的数字。如果您的所有系统都需要这种可用性，我会感到惊讶。在研究业务的过程中，您可能会发现只有一部分功能需要具有如此程度的正常运行时间和容错能力（因此，这样的解决方案最终成本会更低）。我确信电话和业务线应用程序都在那里，但您可能对其他一些系统的停机时间有一定的容忍度。
我的直觉是，您可能会发现使用虚拟化技术创建基于冗余硬件之间虚拟机迁移的故障转移系统会取得成功。它是否符合您的预算取决于您的业务，因为您肯定需要某种类型的 SAN 来使其有效工作。
不过，不要轻视“传统”故障转移集群。如果您的应用程序非常适合这样的配置，那么肯定也有“胜利”。
我想知道你的老板是否考虑过灾难性的故障场景（建筑物烧毁、洪水、龙卷风、盗窃等）。如果这还没有计划好，这将是进行一些一般业务连续性规划和灾难恢复应急工作的绝佳机会。
从可以进来研究您的业务并提出建议的人那里获得一些帮助。你不会后悔的。