8

我正在使用 DC/OS 编排器对 ACS 进行一些试验，虽然在单个区域内启动集群似乎很简单，但我不太确定跨多个区域进行部署的最佳实践是什么。

Azure 本身目前似乎不支持部署到多个区域。有了这个假设，我想我唯一的其他选择是在我希望可用的所有区域中创建多个相同的集群，然后使用 Azure 流量管理器将传入流量路由到最近的可用集群。

虽然此解决方案有效，但它也会导致一些问题，我不能 100% 确定我应该如何解决。

  1. 在部署新版本的服务时，我们的部署管道必须确保部署到所有区域。如果我们有美国东部和北欧地区，在从我们的 CI 工具进行部署期间，我必须连接到这两个地区的 Marathon API 以触发新部署。如果部署在一个区域失败，而在另一个区域成功，我会突然在两个区域之间产生差距。
  2. 如果我有一个使用本地持久卷部署的服务，比如 PostgreSQL 或 ElasticSearch，它需要在两个区域都有实例，因为服务发现只会找到该区域本地的服务。这带来了区域之间复制的问题，以保持所有区域中的所有状态；这似乎需要一些/很多手动配置才能开始工作。

有没有人使用过类似这样的设置，使用 Azure 容器服务（或真正的亚马逊容器服务，因为我认为在那里可以找到相同的挑战）并且对如何解决这个问题有一些指示？

4

2 回答 2

1

您有多种选择可以跨地区进行旋转。我会为它们中的每一个使用自定义安装和 terraform。这是一个很好的起点：https ://github.com/bernadinm/terraform-dcos

跨不同区域分发代理应该没有问题，确保您的服务即使出现故障也能继续运行。

分配 master（让您在故障期间控制服务）有点困难，因为它涉及跨高延迟链接分配 zookeeper quorum，因此您应该小心选择区域之间的“距离”。

查看文档以获取更多详细信息。

于 2017-08-30T18:03:23.387 回答
0

您是正确的 ACS 当前不支持多区域部署。

您的第一个问题特定于 DC/OS 中的 Marathon，我将联系那里的一些工程人员，看看他们是否对最佳实践有任何意见。

您的第二点是我们（我是 ACS PM）正在关注的问题。您可以在某些场景中使用一些解决方案（例如，ArangoDB 位于 DC/OS 领域，将提供复制）。DC/OS 团队在这里也可能有话要说。在 ACS 中，我们正在评估为这个用例提供解决方案的最佳方法，但恐怕我无法给出任何时间表的指示。

另一种解决方案是将您的数据库放在 SaaS 产品中。这消除了管理冗余和复制的所有复杂性。

于 2017-01-10T00:43:58.337 回答