Cluster
Today a Leshan server cannot be easily deployed in a cluster for high-availability and scalability. This page list the modification to be done to Leshan and Californium and propose an example on how to deploy Leshan as a cluster. We will focus on the southbound interface: the device to server communication (CoAP).
If we deploy Leshan as mutiple machine we need a front load balancer for sending the incoming messages to one of the cluster Leshan instance.
Today Leshan accept CoAP+DTLS device communications. It's all based on UDP (maybe later TCP). One of the few load-balancer supporting UDP is LVS - Linux Virtual Server. We will focus on providing a solution compatible with it. (Please if you know another Level 3 load-balancer usable in this situation please mention it!). We don't explore DNS round robin load balancing, because the amount of state to share would be larger (whole DTLS states). We prefer level 3 source IP/port based routing.
- A DTLS connection contains a lot of states (fragment, epoch, handshake states, master key etc..)
- CoAP states: MID, tokens
- LWM2M: registrations, security parameters, observations
If we try to share all of those states we are going to greatly reduce the performance. We should try to keep some on the leshan instance. For example we can say the MID and most of the DTLS states (outside of the ones needed for DTLS resume) can be kept in the Leshan instance because the level3 state-full load-balancer will push all the UDP packets coming from the same source IP/port to the same Leshan instance.
The remaining long term states to share would be: CoAP observations (Tokens), LWM2M registration, and parameters for starting a DTLS handshake.
For a first step DTLS resume can be excluded because we can force the client into a full re-handshake (which is not so costly with PSK schemes).
A first implementation based on Redis will be proposed.
Leshan: the registration store is already good, the only problem is the Observation registry.
Californium: observation are based on the "exchange" abstraction and is quite difficult to persist, this should be refactored or we also could create a more low level API for receiving .
Scandium: on a second step we can extract the information for re-handshaking and share it.
