Scaling and middleware roles

Any of the middleware pods can have any combination of these roles:

  • hazelcast-data-holding or hazelcast-lite-member
  • http-api
  • sync
  • admin

You can specify how many pods for any combination of these roles you want in your cluster. Let's look at a few examples:

core-mw:
  scaling:
    nodes:
      groupware:
        replicas: 3
        roles:
          - http-api
          - sync
          - hazelcast-data-holding
      admin:
        replicas: 1
        roles:
          - admin
          - hazelcast-data-holding

This gives us four pods, all hazelcast data holding nodes with 1 reserved for provisioning (admin) and 3 for the rest of the functions. What does it mean to be reserved for a task? The helm chart sets up services for the roles and puts every pod that is supposed to serve that role into one of those services:

RoleService
adminappsuite-core-mw-admin
http-apiappsuite-core-mw-http-api
syncappsuite-core-mw-sync

So you can set up incoming traffic routing accordingly.

  • DAV and EAS/ActiveSync goes to the appsuite-core-mw-sync.appsuite.svc.cluster.local
  • HTTP-API traffic to appsuite-core-mw-http-api.appsuite.svc.cluster.local
  • internal SOAP calls via different Gateway on a different Port go to appsuite-core-mw-admin.appsuite.svc.cluster.local.

We can also slice the cake differently, with, say specialised pods for all tasks:

core-mw:
  scaling:
    nodes:
      hazelcast:
        replicas: 3
        roles:
          - hazelcast-data-holding
      http-api:
        replicas: 4
        roles:
          - http-api
          - hazelcast-lite-member
      sync:
        replicas: 2
        roles:
          - sync
          - hazelcast-lite-member
      admin:
        replicas: 1
        roles:
          - admin
          - hazelcast-lite-member

This gives us a cluster of

  • 3 Hazelcast data holding pods that serve no traffic,
  • 4 HTTP-API pods,
  • 2 Sync pods and,
  • 1 provisioning pod.

Routing is still the same as above, since the pods will be added to the services matching the roles they have. If we don't want a separate sync cluster, we can consolidate them back into the http-api nodes:

core-mw:
  scaling:
    nodes:
      hazelcast:
        replicas: 3
        roles:
          - hazelcast-data-holding
      http-api-and-sync:
        replicas: 4
        roles:
          - http-api
          - sync
          - hazelcast-lite-member
      admin:
        replicas: 1
        roles:
          - admin
          - hazelcast-lite-member

Etc. The point is, we can scale individual roles independently of each other and also figure out