外部架构师为面向服务的架构环境devise了一个架构。 他们将可用性确定为99.9％，相当于每年最多9小时的停机时间。
我在哪里可以find有关如何将其映射到物理体系结构的资源 ？
我们认为到目前为止我们需要的主要组件是：
一个Drupal CMS与其数据库（一台机器）
API：授权，authentication，logging，pipe理，PubSub和学习logging存储LRS :(一台应用程序服务器）
一台用于存储的数据库服务器（LRS，日志，configuration文件）
这是一个500万个城市的市政环境。 没有关于并发访问要求和类似的东西的数据，但我宁愿不要在这个问题上走高端。 战略是开始精益，但强劲，如果需要扩大。
请您非常欢迎您提供更多的信息，或者对组件架构的第一步进行评论 – 或者您可能认为相关的任何内容。 谢谢。
99.5是相当（非常）蹩脚和容易做 – 记住，一台机器的正常运行时间为99.9％，所以在技术上，你只需要保持一个单独的服务器可用，configuration到位，备份每隔几分钟。
如果设置正确，你应该可以在最多10分钟的时间内完成备用机器的设置。
除了数据中心的中断之外，它可以处理所有的事情，但是这些都是SLA级别的，然后你可以在第二个数据中心上安装第二台机器，就像azure / amazon一样。
作为BlackMesh的工程师，我做了高度可用的Drupal。 正如TomTom所说，任何99.9％（“三个九”）及以下的东西都非常简单。
如果你想花钱增加服务器和负载均衡器以及所有爵士乐，那么获得99.9％以上的费用就非常容易。 如果你不这样做，可能还有另一种方法。 我会把你的解决scheme重新构build到两台机器上，并且把缺乏第三台机器所节省的钱花在另外两台机器上。 也许与直觉相反，您也可以认真考虑牺牲某种程度的冗余性，例如，您可能会放弃物理机器上的辅助电源，而只是简单地将这两台机器连接到不同的总线上。
无论如何，你用这两台机器做的事情都是在适当的集群中设置的。 有HA IP地址在它们之间来回切换。*机器一是默认的Web机器，运行Drupal。 机器二是默认的DB和LRS机器。 在发生故障时，地址移动，使剩余的机器承担全部负载。 对于MySQL，这将需要主 – 主复制; 对于Drupal，它需要同步DocRoot（特别注意“文件”目录）; 对于您的LRS，可能需要手动故障转移过程。
通过这种types的configuration，硬件和功率等等，你应该看到五个九（99.999％）的操作系统正常运行时间（每年约五分钟的停机时间），接近于这个数字第7层可用性的条款。 既然你说你需要certificate你提出的数字是正确的，那么五个九就假设一个没有共享的环境，简单地说，单个服务器的失败率（ 1.0-99.75%==0.25% ）表示概率的两台服务器同时下线（ 1.0-0.25%*0.25%==99.999375% ），有一点1.0-0.25%*0.25%==99.999375%因素。
最后，我应该注意到，这些SLA是一种红鲱鱼。 请参阅https://serverfault.com/a/161141/46760了解我对此事的看法。 事实上，由于有人在本解决scheme的整个生命周期中点击Drupalpipe理员帐户（或类似的东西），您将失去DAYS的function可用性。 build立良好的变更控制和类似的stream程应该在硬件冗余的讨论中给予相等的计费，如果不是首先计费的话。
*：nb在任何偶数个成员的聚类中都有裂脑的可能性。 降低概率的更好方法之一是将健康检查stream量路由到公共接口。 如果你想成为真正的偏执狂，请查看STONITH系列。
在devise任何架构之前，我会检查你的环境：你有一个内部的IT部门，他们托pipe什么？
如果已经安装了数据库服务器，它也可以托pipe你的数据库。
你的系统pipe理员熟悉什么？ 如果您的微软商店，基于任何* nix的解决scheme可能会轻松地扰乱您的pipe理员（反之亦然）
关于停机时间，有关各方是否都承认，9小时的停机时间仅仅是计划外的停机时间， 不包括修补和升级的停机时间？ 需要多less数据才能恢复？ 您的备份系统可以在九个小时内恢复整个系统吗？