Migration To 2020.02
In Smile CDR 2020.02.R01, the clustering mechanism for Smile CDR was completely redesigned. This was done in order to simplify clustering and in particular to make it easier to support Docker-based clustering mechanisms such as Kubernetes.
On this page, we will refer to this new clustering design as 2020.02 clustering, and the previous design as 2019.11 clustering.
The primary change to be aware of in the 2020.02 clustering is that the concept of Master Nodes and Clone Nodes has been completely removed. It is still possible to design clusters that perform functionally identically to 2019.11 clustering, but you will no longer need to explicitly designate one of your nodes as a Master and the rest as Clone nodes.
Instead you will create one or more nodes, each having a set of modules. If you wish to scale any of these nodes up, you will simply start more Smile CDR processes with the same Node ID and Cluster Manager module configuration.
The following table shows key concepts from the old and new clustering mechanisms.
| 2019.11 Cluster Concept | 2020.02 Equivalent |
|---|---|
| Master Node | Node + 1st Node Process |
| Clone Node | Node + subsequent Node Processes |
The good news is that migrating existing clusters is very easy. There are two steps to follow:
Any existing Clone Nodes should have the following two properties in the Node Configuration Properties File. In this example, we have a clone node named Clone which is a clone of the Master node Master.
node.id=Clone
node.clone=Master
To migrate this file to the 2020.02 cluster design, these two entries in the Node Configuration Properties File would be replaced with the following single entry.
node.id=Master
In other words, what was previously the node.clone value should now be the node.id value (meaning that all processes for a given node will have the same ID).
Note that in order to help with migration, if Smile CDR detects the deprecated node.clone property in the file, it will automatically use this as the node.id value. This means that technically this step can be skipped, although we do still recommend migrating as this behavior may be removed in a future release.