Mesos master 是否需要联系 Mesos slave？
Does a Mesos slave needs to be contacted by a Mesos master?
Apache Mesos 'slave' 节点是否可以位于与 Mesos 'master' 节点不同的网络中？同样（对于高可用性 (HA) 部署），Mesos 'master' 选举中使用的 Apache Zookeeper 节点是否可以部署在与 Mesos 'slave' 节点不同的网络上？
目前我在云端有3个master+slave节点，我想在本地子网中添加一个slave。
如果这样的设置可行，那么这样的设置有哪些pros/cons？
我认为 https://www.stratio.com/blog/mesos-multi-data-center-architecture-for-disaster-recovery/ 是一本很好的读物，它介绍了完成这项工作所需的几件事。如果 DC 宕机，有一些关于如何处理东西的场景。
优点：
- 您可以在 DC 为 down/unreachable
的情况下进行故障转移
缺点：
- 两个 DC 都必须能够 运行 环境本身（活跃的，或者你应该能够快速扩展），这样会产生管理费用
- 复杂性增加（网络，mesos/application 配置）
关于网络：它们必须能够以某种方式连接，所以 public（但加密和防火墙，我也认为每个节点都需要一个 public IP）或通过 ipsec 隧道或link 提到的另一个选项。
我不认为在没有隧道的情况下通过互联网进行操作（所以我提到的第一个选项）是一个很好的选择。
Apache Mesos 'slave' 节点是否可以位于与 Mesos 'master' 节点不同的网络中？同样（对于高可用性 (HA) 部署），Mesos 'master' 选举中使用的 Apache Zookeeper 节点是否可以部署在与 Mesos 'slave' 节点不同的网络上？
目前我在云端有3个master+slave节点，我想在本地子网中添加一个slave。
如果这样的设置可行，那么这样的设置有哪些pros/cons？
我认为 https://www.stratio.com/blog/mesos-multi-data-center-architecture-for-disaster-recovery/ 是一本很好的读物，它介绍了完成这项工作所需的几件事。如果 DC 宕机，有一些关于如何处理东西的场景。
优点：
- 您可以在 DC 为 down/unreachable 的情况下进行故障转移
缺点：
- 两个 DC 都必须能够 运行 环境本身（活跃的，或者你应该能够快速扩展），这样会产生管理费用
- 复杂性增加（网络，mesos/application 配置）
关于网络：它们必须能够以某种方式连接，所以 public（但加密和防火墙，我也认为每个节点都需要一个 public IP）或通过 ipsec 隧道或link 提到的另一个选项。 我不认为在没有隧道的情况下通过互联网进行操作（所以我提到的第一个选项）是一个很好的选择。