我正在研究Cloud Foundry的新架构部署，使用多cpi和单个BOSH控制器部署。如果 BOSH 导向器部署在 DC-A 中并管理 2 个虚拟中心，一个在 DC-A 中，另一个在 DC-B 中，如果 DC-A 脱机，BOSH 有哪些选项可以在 DC-B 中运行活动/备用，以便它可以立即接管部署，而无需执行备份和还原？
是的，具有多 CPI 的多 DC BOSH 部署运行良好！当人们想到这种多DC设计时，您的问题经常被提出。
BOSH 控制器没有高可用性 (HA(，我现在知道也没有主动/被动设置。这样做的原因是，失去BOSH董事并不是什么大不了的事。此控制器管理的节点仍将在基础结构之上运行。在你把你的导演带回来之前，他们不会是"可管理的"。
但是，如果我们考虑这种主动/被动设置的要求，我会想到以下：
-
它们必须共享完全相同的 CPI 安装和设置。没什么大不了的。
-
它们必须共享相同的 SQL 数据库和相同的 blobstore(对象存储(。这没什么大不了的，但这会导致同时使用外部 SQL 存储和外部 blob 存储。然后，"被动"BOSH 控制器至少必须禁用其复活器插件，以免与"主动"BOSH 控制器的复活器竞争。(事实上，被动的BOSH导演必须完全停止，见下文。
-
它们必须共享相同的 NATS 消息总线，该总线通常位于 BOSH 控制器上，因此专用于它。可以轻松地从控制器中提取此 NATS，并使用高可用性设置单独运行它。但问题是：哪个控制器使用 NATS 消息？两个董事不能竞争使用这些信息。这就是为什么"被动"的BOSH控制器会要求其流程
monit stop-ed，或者整个实例bosh stop-ed。 -
使用
boshCLI(v2，包括此bosh-init组件，它可以像本地精简的 BOSH 控制器一样工作(，无法实现此bosh stop要求。因此，这两个 BOSH 控制器必须由"引导"BOSH 控制器部署(这很常见，我什至在某些客户生产环境中看到了多达四个阶段的这种引导控制器模式！ -
现在想象一下你拥有一切。一个引导 BOSH 控制器，用于部署单独的 HA NATS 和两个控制器，具有相同的 CPI 设置、相同的外部 SQL 数据库和相同的外部 blob 存储。然后它就会起作用！每当你失去主动的，你
bosh start被动的，它就会接管。但是你应该注意，以前活跃的那个不会突然弹出，否则它会竞争使用 NATS 消息，并可能弄乱数据库和 blob 存储。这就是BOSH缺少一些"锁定"功能的地方，一次只允许一个活动的控制器。在这里，可以实现一些非常简单的东西，基于一些数据库记录，该记录将指定哪个是活动的，哪个是被动的。手动切换此记录将触发被动控制器变为活动状态。
对于下一次Cloud Foundry黑客马拉松来说，这是一个非常好的主意！