![SOA 架构要求 99.9% 可用性->最大停机时间为 9 小时->物理架构映射?](https://linux22.com/image/628816/SOA%20%E6%9E%B6%E6%9E%84%E8%A6%81%E6%B1%82%2099.9%25%20%E5%8F%AF%E7%94%A8%E6%80%A7-%3E%E6%9C%80%E5%A4%A7%E5%81%9C%E6%9C%BA%E6%97%B6%E9%97%B4%E4%B8%BA%209%20%E5%B0%8F%E6%97%B6-%3E%E7%89%A9%E7%90%86%E6%9E%B6%E6%9E%84%E6%98%A0%E5%B0%84%EF%BC%9F.png)
外部架构师设计了一个面向服务架构环境的架构。他们将可用性设定为 99.9%,相当于每年最多 9 小时的停机时间。
我可以在哪里找到有关如何将其映射到物理架构?
我们认为目前需要的主要组件是:
一个 Drupal CMS 及其数据库(一台机器)
API:授权、身份验证、日志记录、管理、PubSub 和学习记录存储 LRS:(一台应用服务器)
一个用于存储(LRS、日志、配置文件)的数据库服务器
这是针对 500 万人口城市的市政环境。没有关于并发访问要求等的数据,但我宁愿不就这个问题进行高端探讨。策略是精简但稳健地开始,并在需要时进行扩展。
欢迎您索取更多信息或对组件架构的初稿发表评论 - 或者对任何您认为相关的内容发表评论。谢谢。
答案1
99.5 非常(极其)糟糕,而且很容易做到 - 记住单台机器的正常运行时间为 99.9%,因此从技术上讲,您只需要保持一个单独的服务器可用,配置到位,每隔几分钟备份一次。
通过适当的设置,您应该能够在最多 10 分钟内启动备用机器。
它处理除数据中心中断之外的所有问题,但这些都是 SLA 级别的,然后您可以在第二个数据中心的第二台机器上使用类似 azure / amazon 的东西。
答案2
我在 BlackMesh 担任工程师,主要从事高可用性 Drupal 的工作。正如 TomTom 所说,99.9%(“三个九”)及以下的任何可用性都非常直接。
如果您愿意花钱添加服务器和负载平衡器等,那么获得超过 99.9% 的效率是很容易的。但是,如果您不愿意,也许还有其他方法。我会将您的解决方案重新设计为两台机器,并将没有第三台机器的节省用于使另外两台机器更强大。也许与直觉相反,您也可以认真考虑牺牲一定程度的冗余度,例如,您可以放弃物理机器上的辅助电源,而只需将这两台机器分别连接到不同的总线即可。
无论如何,您要对这两台机器进行的操作是将它们设置为适当的集群。让 HA IP 地址在它们之间来回切换。*机器一是默认的 Web 机器,运行 Drupal。机器二是默认的 DB 和 LRS 机器。如果发生故障,地址会移动,以便剩余的机器承担全部负载。对于 MySQL,这将需要主主复制;对于 Drupal,它将需要同步 DocRoot(特别注意“文件”目录);对于您的 LRS,它可能需要手动故障转移过程。
有了这种配置,加上不错的硬件、良好的电源等,您应该可以看到五个九 (99.999%) 的操作系统正常运行时间(相当于每年大约五分钟的停机时间),并且第 7 层可用性也接近这个数字。既然您说您需要证明您得出的数字,那么五个九就假设了一个无共享环境,并且只是单个服务器的故障率 ( 1.0-99.75%==0.25%
) 的平方,以表示两台服务器同时离线的概率 ( 1.0-0.25%*0.25%==99.999375%
),带有一点模糊系数。
最后,我应该指出,这些类型的 SLA 有点儿像是一种转移注意力的花招。请参阅https://serverfault.com/a/161141/46760我对此事的看法。现实情况是,由于有人误点击了 Drupal 管理员帐户(或类似帐户),您将在本解决方案的整个生命周期内失去数天的功能可用性。设置良好的变更控制和类似流程应与硬件冗余讨论同等重要,如果不是首先重要的话。
*:注意:任何成员数为偶数的集群都可能出现裂脑。降低概率的更好方法之一是通过公共接口路由健康检查流量。如果您真的想谨慎一点,请查看串行上的 STONITH。
答案3
在设计任何架构之前,我都会检查您的环境:您是否有内部 IT 部门以及他们托管什么?
如果已经安装了数据库服务器,它也可以托管您的数据库。
您的系统管理员熟悉什么?如果您是 Microsoft 商店,那么基于任何 *nix 的解决方案都可能很容易让您的管理员不高兴(反之亦然)
关于停机时间,所有相关方是否都接受九小时的停机时间仅算作计划外的停机,不做不是包括修补和升级的停机时间?需要恢复多少数据?使用您的备份系统可以在 9 小时内恢复整个系统吗?