Hi Stefan,

If I understand this well your current cluster is not yet making use of an indexing database (elasticsearch / opensearch) and is running the local cassandra database in a setup where each failover pair is connected to its own 2 node cassandra cluster dedicated for that failover pair.

Summary: 4 DataMiner failover pairs where each pair has its own local cassandra database cluster of 2 nodes.

This kind of setup where each DMA (failover or regular) has its own local database is considered legacy and will not allow you in the future to make use of high value features such as swarming and low code apps.

For these features the DataMiner system (DMS) architecture relies on shared central database cluster as well as indexing database where all DMA's in the cluster share the same local and indexing database. This is automatically the case when opting for the STaaS as your storage solution. More detailed info on STaaS can be found here

In such a future proof architecture we can actually distinguish multiple clusters:

• DMS: 1 or more DataMiner Nodes grouped together.
• Local database: 3 or more Cassandra nodes grouped together.
• Indexing database: 3 or more Opensearch nodes grouped together.

In each of these clusters the max. latency requirements differ.

A DMS cluster is not that prone to latency between its nodes. We have several global DMS clusters running where the latency between certain DataMiner nodes of the same cluster is greater than 100ms.

For the Cassandra cluster and Opensearch cluster, the latency requirements for the communication between nodes of the same cluster are more strict where Opensearch has the lowest max. latency of 30ms between nodes of the same cluster.

The communication between your DMA's in the DMS and the local database / indexing database cluster doesn't immediately have a max. latency defined from a functional point of view. We do advise to keep this latency as low as possible as there eventually will be performance impact if the latency between DMA and its database is increased. Sub 30ms latency between the DMA and its local / indexing database should be fine where the general rule of thumb is: the lower the better performance on certain aspects like trend data requests / DMA startup times you will get.

For sake of convenience our general advise would be to choose for STaaS as your future storage solution. This will relief you from the burden of having to maintain and operate the local / indexing database cluster and will also alleviate any concerns you have on latency in your DataMiner cluster.

In any scenario (local database per DMA, local / indexing database cluster shared between DMA's / STaaS) each DataMiner node maintains its own connection to the storage and in the event that the DMA loses this connection, it will start local caching and remain operational. Only specific funtions like requesting historical alarmreports / trenddata will no longer function at that time. Once the connection recovers the cached data will be offloaded to the storage and the system will return in full operation.

Hopefully this clarified some things.
Let me know if you have any additional doubts.