Can you create a swarm with two manager nodes only?

Docker Engine Swarm
1

Is it possible to have a swarm of two nodes where both are swarm managers? So that you get fault tolerance in a swarm of only two nodes?

2

the managers would also have to be worked nodes. as worker is where the containers are deployed.

but yes


the idea however was to isolate the workers from the managers. workers drive the business application,
managers manage the docker infrastructure.

3

Thanks for the quick answer.

The architecture makes sense. But in this case the swarm is only used for development not production.

Currently the swarm has one worker and one manager.

To get from there to two managers one swarm the worker needs to leave and rejoin via a worker token, is that right?

4

see this post

2 Likes
5

Also note that, by default, swarm mode master nodes will also run container nodes alongside the worker nodes. To prevent that (so that the swarm masters are only managing the cluster/scheduling duties), you’ll need to log onto a master node and run docker node update --availability drain <NODE> for each of the manager nodes. Maybe not necessary in a development environment but is recommended when running production workloads.

1 Like
6

Hi all,
moving on this possible architecture.

I have two servers (bare metal) and in Docker Cloud I have dockercloud/haproxy as loadbalancer, one instance in each server. For every domain, we use a DNS Round Robin to route traffic to the two servers for the same domain(s).
With docker swarm, dockercloud/haproxy and its possible alternatives (Traefik and Dockerflow) needs to run on nodes of type “Manager”.

So, I need to have two manager nodes but it implies that if one manager fails, all fails.

Is there a solution (docker machine and something???) to have two load balancer (with published port on each of the two server) and a much more stable infrastructure?

2 Likes
7

You’re correct in that two manager nodes don’t help resiliency of your cluster. You really need at least 3 managers for that. You’ve probably already read this but it provides more details as to why: Administer and maintain a swarm of Docker Engines

One option might be to run your swarm cluster in the cloud itself (I’ve used DockerForAWS to set up such environments and it works well). You’ll of course need to pay for the instances plus an ELB in order to access it, but depending on the amount of traffic and number of containers, it shouldn’t require too beefy instances to run it).

Otherwise, you might be stuck having to provision a third bare-metal server for this purpose to run your own onPrem cluster.

8

When one of two manager nodes drop, only consensus is lost. The containers on the surviving node are still operating. You can probably design the desired-state of the services so that some availability can be maintained through a single node loss.

When one of two manager nodes drop, consensus is lost. Only consensus. Without consensus, there is no leader. The leader detects failures and sends commands to start containers on surviving nodes to recover ‘desired-state’. Without a leader, no commands to start containers are sent. So, if your application can be duplicated on each node, then one can drop, and the other, without any commands from a leader, can continue the application.

Note: On a two node cluster, you would have higher availability if only one were a manager. In this case, if the worker fails, the manager will still be operating, and will be able to direct commands to itself to meet ‘desired-state’.

1 Like