How to limit the coordinators to be chosen by one class?

Using FoundationDB Kubernetes Operator
1

HI,
I am trying to limit the coordinators choosing to only chosen from one class set namely storage class.
So, in my cluster spec file, I put this in:
coordinatorSelectionSetting:
processClass: storage
priority: 1

I have 5 storage pods when I first created the cluster and I can see 3 of them are coordinators as I use double as redundancy.
I then change my redundancy to triple and also added two more storage pods, the 5 coordinators become all over the place, some goes to a log pods and some goes to a stateless pod.
How do I limit the coordinators to only be selected among the storage pods?
Thanks,

2

Using the coordinatorSelectionSetting is the correct approach. Could you please file an issue with a reproducible example here: GitHub - FoundationDB/fdb-kubernetes-operator: A kubernetes operator for FoundationDB. Could you also ensure if the coordinatorSelectionSetting is still present after you did you changes to upgrade the replication mode.

3

@tangerine @johscheuer
Hi guys, I’m confusing about why “coordinators to only be selected among the storage pods” is a better allocation? I did observe this in my double redundancy mode cluster.
Forgive me if this is documented somewhere. Haven’t found this anywhere.

4

I find this:
This will recruit coordinators based on the process list in the database status to ensure that the coordinators it recruits are properly connecting to the database. This will prefer to recruit coordinators only from storage processes. If it cannot fulfill the fault tolerance requirements using storage requirements, it will expand the candidate list to include log processes, and then to include transaction processes if necessary. It will ensure that the coordinators are distributed across failure domains as evenly as possible. It will also require that ever coordinator has a different zoneid locality. For multi-DC clusters, it will require that we do not have a majority of coordinators using the same value for the dcid locality.
from fdb-kubernetes-operator/technical_design.md at main · FoundationDB/fdb-kubernetes-operator · GitHub
So, it is by design the preference, don’t know the logic behind it though…

1 Like
5

This statement is actually not true anymore and storage and log processes have the same priority for selection or to be precise all stateful processes (log, transaction, storage) will be considered the same if not configured differently. If only storage servers is a better fit depends on you deployment in general I would argue if log and storage processes use the same hardware there is not a huge benefit in restricting it to storage processes.

1 Like