Scaling and middleware roles
Any of the middleware pods can have any combination of these roles:
documents
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
- documents
admin:
replicas: 1
roles:
- admin
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
:
Role | Service |
---|---|
admin | appsuite-core-mw-admin |
http-api | appsuite-core-mw-http-api |
sync | appsuite-core-mw-sync |
So you can set up incoming traffic routing accordingly.
- DAV and EAS/ActiveSync goes to the
appsuite-core-mw-sync
- HTTP-API traffic to
appsuite-core-mw-http-api
- internal SOAP calls via different
Gateway
on a differentPort
go toappsuite-core-mw-admin
.
We can also slice the cake differently, with, say specialised pods for all tasks:
core-mw:
scaling:
nodes:
documents:
replicas: 3
roles:
- documents
http-api:
replicas: 4
roles:
- http-api
sync:
replicas: 2
roles:
- sync
admin:
replicas: 1
roles:
- admin
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:
documents:
replicas: 3
roles:
- documents
http-api-and-sync:
replicas: 4
roles:
- http-api
- sync
admin:
replicas: 1
roles:
- admin
Etc. The point is, we can scale individual roles independently of each other and also figure out