Cloud foundry CF Bosh控制器多DC高可用性

我正在研究一种新的云铸造体系结构部署，它使用多cpi和一个BOSH控制器部署。如果BOSH控制器部署在DC-A中，并管理两个vCenter，一个在DC-A中，另一个在DC-B中，如果DC-A脱机，BOSH有哪些选项可以在DC-B中运行active/standby（主/备用），以便它可以立即接管部署，而无需执行备份和恢复？

是，具有多个CPI BOSH的多DC BOSH部署非常有效！当人们想到这种多DC设计时，经常会提出您的问题

BOSH控制器没有高可用性（HA），我现在也不知道有什么主动/被动设置。原因是，失去一个专横的导演并不是什么大问题。此控制器管理的节点仍将在基础结构上运行。在你把你的主管带回来之前，他们是无法“管理”的

但如果我们考虑这种主动/被动设置的要求，我会想到以下几点：

他们必须共享完全相同的CPI安装和设置。没什么大不了的

它们必须共享相同的SQL数据库和相同的blobstore（对象存储）。这不是什么大问题，但这会导致同时使用外部SQL存储和外部blobstore。然后“被动”BOSH控制器至少必须禁用其Resurector插件，以避免与来自“主动”BOSH控制器的Resurector竞争。（事实上，被动波什主管必须完全停止，见下文。）

它们必须共享相同的NATS消息总线，该总线通常位于BOSH控制器上，因此专用于该控制器。从控制器中提取此NAT并使用高可用性设置单独运行很容易。但问题是：哪个控制器使用NATS消息？两个控制器不能在使用这些消息方面进行竞争。这就是为什么“被动”BOSH控制器会要求其进程是

monit-stop

-ed，或者整个实例

BOSH-stop

-ed

使用

bosh

CLI（v2，包括该

bosh init

组件，该组件可以像本地精简的bosh控制器一样工作）无法实现此

bosh停止

要求。因此，这两个BOSH控制器必须由一个“bootstrap”BOSH控制器部署（这是很常见的，在一些客户生产环境中，我甚至看到了这种bootstrap控制器模式的四个阶段！）

现在想象你拥有了一切。一个bootstrap BOSH控制器，部署一个单独的HA NAT和两个控制器，具有相同的CPI设置、相同的外部SQL数据库和相同的外部blobstore。那就行了！每当你松开主动的，你就会启动被动的，它就会接管。但是，您应该注意，以前活动的一个不会突然弹出，否则它将在使用NATS消息方面竞争，并可能扰乱数据库和blobstore。这就是BOSH缺少一些“锁定”功能的地方，一次只允许一个活动的控制器。在这里，可以基于一些数据库记录实现一些非常简单的功能，这些数据库记录将指定哪一个是主动的，哪一个是被动的。手动切换此记录将触发被动控制器变为主动控制器

这是一个非常好的主意，为下一个云铸造hackathon