协调多云基础架构以最大限度地减少服务停机时间

时间:2017-01-07 10:27:38

标签: azure amazon-web-services

我们有一项服务,我们希望尽可能减少停机时间。我们计划的策略是:跨多个云部署多个服务实例,如AWS,Google Cloud Platform,Microsoft Azure等。大多数情况下,该服务在其中一个云上运行,例如AWS,以防AWS进入我们希望通过机器检测到这一点,并在Google Cloud Platform中打开实例,依此类推。

这听起来像是一种可行的方法吗?什么是最佳实践,工具,软件,书籍?

注意:在线的一些文章指出,多云提供供应商锁定避免,最佳混合等,这是真的。但我们的目标很简单:尽量减少停机时间。

2 个答案:

答案 0 :(得分:1)

答案 1 :(得分:0)

有趣的架构问题......

我将您的查询解释如下:

  1. 3个系统的解决方案,每个系统提供相同的服务
  2. 在任何给定时间,只有一个系统可以拥有该服务的活动实例
  3. 每个系统必须“了解”其他系统的功能状态
  4. 每个系统必须能够在任何给定时间根据一个或多个其他系统的功能状态采取行动
  5. 因此,我会采取以下方法:(我知道很多事情是显而易见的)

    1. 在每个云平台上站起来/测试服务实例
    2. 利用每个平台的最具成本效益的HA配置。这是为了确保您在每个平台
    3. 上端到端地应用最佳实践
    4. 使用相应的云提供商的自动化解决方案或服务结构,配置每个云平台上存在的系统和服务完全启动和关闭。实际上,您应该能够从计算机上的命令行启动或停止AWS,GCP或Azure中的服务。这可能会导致您需要修改服务应用程序启动的方式或在操作系统或Web服务中运行某些内容,以便能够从相应的云提供商的自动化/服务结构中进行编排。
    5. 针对特定的启动和关闭行为展开自动化/服务结构构造的配置,如下所示......
    6. 启动行为必须包括其他两项服​​务的预服务/应用启动检查。它必须确定您的服务/应用程序是否在其他两个环境中运行。如果在其中任何一个中检测到,则此实例将无法启动。 (这应该记录在某个地方......最好是在另一个实例上本地尝试另一个启动。)如果它可以检测到其他服务/应用但是它们不是'运行,然后这个实例启动。如果它无法连接到其他服务/应用程序实例以确定它们是否正在运行,则判断您是否启动此服务。我不会开始并标记手动干预。 ...此逻辑(更详细)也将应用于其他服务/应用实例。
    7. 关机行为应该是对其他云计划表服务/应用实例的通知。将有至少两种类型的关机通知。 1)关闭并且不触发另一个服务/应用实例的启动2)关闭并触发另一个服务/应用实例启动的“选举”......或下一个首选服务/应用实例启动。该决定可能基于成本/性能。两种关闭类型是允许您在需要时干净地关闭所有实例。
    8. 以上,应用了一些额外的逻辑,将主要关注服务/应用程序的可用性。然而,这种架构固有的是服务/应用程序设计的必要性,它允许在“云故障转移/故障恢复”期间保持数据的一致性以及服务本身从一个平台到另一个平台的传递性。

      当然还有更多,但这需要我提出许多更多问题。

      希望以上内容很有用。要做到这一点,你不应该要求第三方软件,因为你引用的每个云都有能力做我上面描述的......虽然它可以使事情变得更容易。具有讽刺意味的是,您将无法使用云托管的第三方软件,因为它会通过在解决方案设计中插入[可能]单个云单点故障来使设计无效。 ...基本上,第三方组件本身必须在每个服务/应用程序实例环境中完全原子化本地化。

      -Eric