Architecture Description
In this architecture:
- A load balancer with sticky sessions is used.
- A total of two machines are prepared for the application cluster. Each machine holds a Nuxeo server node, a Redis node, and a reverse proxy. More machines can be added later for scalability purpose.
- Since we have two Redis nodes, we take advantage from it to configure Redis in master / slave mode.
- An Elasticsearch cluster with at least 3 nodes.
- A database cluster with at least 2 nodes.
- Chronicle Queue as the default implementation for Nuxeo Stream.
This architecture can be improved by externalizing the Redis node inside a specific cluster:
Limitations
As detailed in the messaging system page this is not a recommended solution because:
- The processing done with the Bulk Service relies on Chronicle Queue which is not distributed (poor performance) and not fault tolerant.
- The WorkManager Queuing is limited by the amount of Redis memory and in case of failure Works might be lost.
→ Jump to the Compact architecture with Kafka to:
- Remove Redis and Chronicle Queue limitations
- Benefits from Kafka advantages