Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

OpenShift and Node Affinity

DZone's Guide to

OpenShift and Node Affinity

In this post we take a look at OpenShift's ''Affinity'' feature, which can compliment Infinispan's node affinity. Interested? Read on to find out more.

· Cloud Zone
Free Resource

MongoDB Atlas is a database as a service that makes it easy to deploy, manage, and scale MongoDB. So you can focus on innovation, not operations. Brought to you in partnership with MongoDB.

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 that you read those articles before continuing this tutorial.

How Does the Affinity Feature Work... in Short?

In order to decide on which node a 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 the 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 DeploymentConfigurations with Node Selectors (this tells OpenShift on which nodes 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), as site matches the predicate. In this case, the rack and machine parameters are not used (because we have only one node).

Note that the default OpenShift 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 you to choose better nodes for backing up your data (in distribution mode). 

As a matter of fact, Infinispan uses siterack, 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 sitesracks, and machines. The good news is that all those three are optional, so you have two options — reuse the 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:

apiVersion: v1
kind: DeploymentConfig
metadata:
  name: infinispan-server
  namespace: slaskawi
  labels:
    app: infinispan-server
spec:
  replicas: 2
  selector:
    app: infinispan-server
    deploymentconfig: infinispan-server
  template:
    metadata:
      labels:
        app: infinispan-server
        deploymentconfig: infinispan-server
    spec:
      containers:
        -
          name: infinispan-server
          image: jboss/infinispan-server
          args:
            - cloud
            - '-Djboss.default.jgroups.stack=kubernetes'
            - '-Djboss.jgroups.topology.rack=default'
            - '-Djboss.jgroups.topology.site=primary'
          ports:
            -
              containerPort: 7600
              protocol: TCP
            -
              containerPort: 8080
              protocol: TCP
            -
              containerPort: 8181
              protocol: TCP
            -
              containerPort: 8888
              protocol: TCP
            -
              containerPort: 9990
              protocol: TCP
            -
              containerPort: 11211
              protocol: TCP
            -
              containerPort: 11222
              protocol: TCP
            -
              containerPort: 57600
              protocol: TCP
          env:
            -
              name: OPENSHIFT_KUBE_PING_NAMESPACE
              valueFrom: {fieldRef: {apiVersion: v1, fieldPath: metadata.namespace}}
      nodeSelector:
        region: primary
        zone: default


  • 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 you 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!

MongoDB Atlas is the best way to run MongoDB on AWS — highly secure by default, highly available, and fully elastic. Get started free. Brought to you in partnership with MongoDB.

Topics:
openshift ,infinispan ,scaling ,cloud

Published at DZone with permission of Sebastian Laskawiec. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}