Mesos 集群在使用 replicated_log 时无法选举 master
Mesos cluster fails to elect master when using replicated_log
- 测试环境：AWS上的多节点mesos 0.27.2集群（3 x masters，2 x slaves，quorum=2）。
- 用 zkCli.sh 测试了持久性，它工作正常。
- 如果我用
--registry=in_memory 启动大师，它工作正常，选出了大师，我可以通过马拉松启动任务。
- 如果我使用默认值 (
--registry=replicated_log)，集群将无法选举主节点：
https://gist.github.com/mitel/67acd44408f4d51af192
EDIT：显然是防火墙的问题。对我所有的安全组应用了允许所有类型的规则，现在我有了一个稳定的主控。一旦我弄清楚是什么阻碍了通信，我就会 post 在这里。
首先，让我为后代简要说明标志的含义。 --registry 不影响领导者选举，它指定了注册表的持久化策略（Mesos 跟踪应该在故障转移时携带的数据）。 in_memory 值不应在生产中使用，将来甚至可能会被删除。
leader 选举由 zookeeper 执行。根据您的日志，您使用了以下 zookeeper 集群：zk://10.1.69.172:2181,10.1.9.139:2181,10.1.79.211:2181/mesos.
现在，从你的日志来看，集群没有选主失败，实际上选了两次：
I0313 18:35:28.257139 3253 master.cpp:1710] The newly elected leader is master@10.1.69.172:5050 with id edd3e4a7-ede8-44fe-b24c-67a8790e2b79
...
I0313 18:35:36.074087 3257 master.cpp:1710] The newly elected leader is master@10.1.9.139:5050 with id c4fd7c4d-e3ce-4ac3-9d8a-28c841dca7f5
我不能说为什么领导者被选举两次，因为我还需要来自其他 2 个主人的日志。根据您的日志，最后选出的 master 在 10.1.9.139:5050，这很可能不是您提供日志的那个。
我在日志中看到的一件可疑的事情是相同 IP:port 的主 ID 不同。你知道为什么吗？
I0313 18:35:28.237251 3244 master.cpp:374] Master 24ecdfff-2c97-4de8-8b9c-dcea91115809 (10.1.69.172) started on 10.1.69.172:5050
...
I0313 18:35:28.257139 3253 master.cpp:1710] The newly elected leader is master@10.1.69.172:5050 with id edd3e4a7-ede8-44fe-b24c-67a8790e2b79
发现mesos masters也在5050上发起到其他masters的连接。在master的安全组中添加egress规则后，集群稳定，master选举如期进行。 firewall rules
更新：对于那些试图在 mesos/zk/.. 的各个组件之间建立内部防火墙的人 - 不要这样做。最好像 Mesosphere DCOS
那样设计安全性
- 测试环境：AWS上的多节点mesos 0.27.2集群（3 x masters，2 x slaves，quorum=2）。
- 用 zkCli.sh 测试了持久性，它工作正常。
- 如果我用
--registry=in_memory启动大师，它工作正常，选出了大师，我可以通过马拉松启动任务。 - 如果我使用默认值 (
--registry=replicated_log)，集群将无法选举主节点：
https://gist.github.com/mitel/67acd44408f4d51af192
EDIT：显然是防火墙的问题。对我所有的安全组应用了允许所有类型的规则，现在我有了一个稳定的主控。一旦我弄清楚是什么阻碍了通信，我就会 post 在这里。
首先，让我为后代简要说明标志的含义。 --registry 不影响领导者选举，它指定了注册表的持久化策略（Mesos 跟踪应该在故障转移时携带的数据）。 in_memory 值不应在生产中使用，将来甚至可能会被删除。
leader 选举由 zookeeper 执行。根据您的日志，您使用了以下 zookeeper 集群：zk://10.1.69.172:2181,10.1.9.139:2181,10.1.79.211:2181/mesos.
现在，从你的日志来看，集群没有选主失败，实际上选了两次：
I0313 18:35:28.257139 3253 master.cpp:1710] The newly elected leader is master@10.1.69.172:5050 with id edd3e4a7-ede8-44fe-b24c-67a8790e2b79
...
I0313 18:35:36.074087 3257 master.cpp:1710] The newly elected leader is master@10.1.9.139:5050 with id c4fd7c4d-e3ce-4ac3-9d8a-28c841dca7f5
我不能说为什么领导者被选举两次，因为我还需要来自其他 2 个主人的日志。根据您的日志，最后选出的 master 在 10.1.9.139:5050，这很可能不是您提供日志的那个。
我在日志中看到的一件可疑的事情是相同 IP:port 的主 ID 不同。你知道为什么吗？
I0313 18:35:28.237251 3244 master.cpp:374] Master 24ecdfff-2c97-4de8-8b9c-dcea91115809 (10.1.69.172) started on 10.1.69.172:5050
...
I0313 18:35:28.257139 3253 master.cpp:1710] The newly elected leader is master@10.1.69.172:5050 with id edd3e4a7-ede8-44fe-b24c-67a8790e2b79
发现mesos masters也在5050上发起到其他masters的连接。在master的安全组中添加egress规则后，集群稳定，master选举如期进行。 firewall rules
更新：对于那些试图在 mesos/zk/.. 的各个组件之间建立内部防火墙的人 - 不要这样做。最好像 Mesosphere DCOS
那样设计安全性