# Best practice for cluster nodes

**URL:** <https://forum.ansible.com/t/best-practice-for-cluster-nodes/25416>\
**Category:** Ansible Project\
**Created:** [September 6, 2017, 12:00pm UTC](https://forum.ansible.com/t/best-practice-for-cluster-nodes/25416 "2017-09-06T12:00:35Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Cev\_Ing](https://avatars.discourse-cdn.com/v4/letter/c/f05b48/32.png) [@Cev\_Ing](https://forum.ansible.com/u/Cev_Ing)\
**Post date:** [September 6, 2017, 12:00pm UTC](https://forum.ansible.com/t/best-practice-for-cluster-nodes/25416/1 "2017-09-06T12:00:35Z")

</div>

I have several clusters containing several nodes. I want to run configuration jobs on all cluster nodes. The configuration jobs involve a small down time of the cluster node. I have to take care, that at least a minimum number of nodes in each cluster is still running. What is the best practice to achieve this?

I found an option in Ansible to limit the total number of simultaneous connections. But this does not help, because I need simultaneous connections per cluster.

Another way is to put all nodes of each cluster in groups: First the group of all first cluster members, second the group of all second cluster members and so on. This would make it possible to apply the configuration role to each group. But this is still not exactly what I am looking for, because this serializes the cluster nodes more than necessary. If I have 10 nodes per cluster and I want to keep at least 50% of all nodes running, it would be possible for Ansible to process 5 nodes in parallel.

What is the best practice for Ansible to handle cluster nodes?

---

<div class="post-metadata">

**Author:** ![Dick\_Davies](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Dick\_Davies](https://forum.ansible.com/u/Dick_Davies)\
**Post date:** [September 8, 2017, 5:39pm UTC](https://forum.ansible.com/t/best-practice-for-cluster-nodes/25416/2 "2017-09-08T17:39:21Z")

</div>

Have you seen the serial: argument to plays?

&nbsp;&nbsp;&nbsp;&nbsp;[http://docs.ansible.com/ansible/latest/playbooks\_delegation.html#rolling-update-batch-size](http://docs.ansible.com/ansible/latest/playbooks_delegation.html#rolling-update-batch-size)

That's intended for working on a 'chunk' of N servers in a given group at once.

---

<div class="post-metadata">

**Author:** ![Cev\_Ing](https://avatars.discourse-cdn.com/v4/letter/c/f05b48/32.png) [@Cev\_Ing](https://forum.ansible.com/u/Cev_Ing)\
**Post date:** [September 12, 2017, 2:01pm UTC](https://forum.ansible.com/t/best-practice-for-cluster-nodes/25416/3 "2017-09-12T14:01:18Z")

</div>

No. Thanks for the link!

---

<div class="post-metadata">

**Author:** ![rhysmeister](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/rhysmeister/32/10599_2.png) [@rhysmeister](https://forum.ansible.com/u/rhysmeister)\
**Post date:** [September 16, 2017, 5:42pm UTC](https://forum.ansible.com/t/best-practice-for-cluster-nodes/25416/4 "2017-09-16T17:42:45Z")

</div>

I had a similar issue with a cassandra cluster recently. Serial wasn’t really a workable option for me but I found an alternative solution using delegate\_to. I did a write up of it here; [http://www.youdidwhatwithtsql.com/staged-service-restart-ansible/2337/](http://www.youdidwhatwithtsql.com/staged-service-restart-ansible/2337/)

Rhys