OpenShift (and Kubernetes) has a great feature called
Affinity. In some scenarios, it might be beneficial to configure it along with
Infinispan node affinity.
Before we start... this tutorial is heavily based on our
previous blog post about deploying Infinispan on Openshift and OpenShift
Scheduler functionality. It is highly recommended to read those articles before continuing this tutorial.
How does the Affinity feature work... in short?
In order to decide on which node given Pod should be running, OpenShift looks at so called
Predicates and
Priority Functions. A predicate must match the one configured in
DeploymentConfiguration and Priority Function is responsible for choosing the best node for running Pods.
Let's assume that we have a sample policy (similar to
one provided in OpenShift manual), that uses
site as a Predicate along with
rack and machine as Priority Functions. Now let's assume we have two nodes:
- Node 1 - site=EU, rack=R1, machine=VM1
- Node 2 - site=US, rack=R2, machine=VM2
And two DeploymentConfiguration with Node Selectors (this tells OpenShift on which nodes given DeploymentConfiguration wishes to run) defined as follows:
- DeploymentConfiguration 1 - site=EU, rack=R5, machine=VM5
- DeploymentConfiguration 2 - site=JAP, rack=R5, machine=VM5
With the above example only DeploymentConfiguration 1 will be scheduled (on Node 1), since site matches the predicate. In this case rack and machine parameters are not used (because we have only one node).
Note that the default OpenShift's configuration uses
region (as a Predicate) and
zone (as a Priority Function). However it can be reconfigured
very easily.
And I need it because....
Some OpenShift deployments might span multiple racks in a data center or even multiple sites. It is important to tell Infinispan where physical machines are located, which will allow to choose better nodes for backing up your data (in distribution mode).
As the matter of fact, Infinispan uses site, rack and machine. The main goal is to avoid backing up data on the same host.
The implementation
The implementation is pretty straightforward but there are several gotchas.
The first one is that OpenShift uses regions and zones by default and Infinispan uses sites, racks and machines. The good news is that all those three are optional, so you have two options - reuse existing region and zone (map them to rack and site for example), or adjust OpenShift scheduler settings. In my example I used the former approach.
The second one is the need of hardcoding those parameters into
DeploymentConfiguration. Unfortunately Node Selectors are not exposed through
Downward API, so there's no other way.
So let's have a look at our DeploymentConfiguration:
- Line 26 - Zone default used as a rack
- Line 27 - Region primary used as a site
- Lines 57 - 59 - Node Selector for scheduling Pods
Conclusion
Combining OpenShift Affinity Service and Infinispan Server Hinting allows to optimize data distribution across the cluster. Keep in mind that your configuration might be totally different (OpenShift Scheduler is a highly configurable thing). But once you understand how it works, you can adjust the hinting strategy for your needs.
Happy Scaling!
