Rancher2.0 server HA on docker swarm

The reason for me to use rancher is because it can setup a k8s cluster easily, so it makes no sense to setup another k8s beyond rancher to run rancher server on.

As docker swarm is easy to setup, fast and reliable, I decided to try rancher server on it.

The setup is : use 2 machines to form a docker swarm, both mount a nfs export to bind mount to /var/lib/rancher, and start the ranceher-server as a service, it so far runs very well.

The two swarm servers have also a ucarp ip setup on it, so the rancher web UI is accessed via the ucarp ip.

I hope this will be supported in the future.

I am curious to know if rancher-server I/O pattern could suit glusterfs or not, if so, I can remove nfs server from this and make these 2 docker swarm server bind rancher dir to a glusterfs share, that would be even higher HA.

I hope this will be supported in the future.

I don’t think we will every officially support this, but if it is working for you that is great. The market and industry are focused on kubernetes, so it doesn’t make sense us for us to commit the effort to supporting what you described.

I am curious to know if rancher-server I/O pattern could suit glusterfs or not

We do lots of writes and even more reads to/from etcd. Even when not deployed into an existing k8s cluster, it is using k8s under-the-hood as the data store and driver. But we don’t have detail numbers around read/writes and that will largely depend on the amount of activity in your cluster.

That is ok. I think as long as I kept the /var/lib/rancher data and its server ip address, I can move the rancher server to run out of swarm if get into problem

For I/O I mean the part done by rancher-server to /var/lib/rancher dir, the only part that I think need persistent for rancher server to keep its settings. The other part of the k8s cluster I will run out of the swarm on normal docker nodes, and need not read write from the same network fs service.

Right, I’m saying when you run rancher/rancher the way you are running it, it is talking to an internal etcd that is also running inside the rancher/rancher container and that etcd is writing to /var/lib/rancher/<something>.

Good to know that.

Just made a test on glusterfs, seems quite snappy so far, at least it works.