Please, Dojo - when evaluating DaaS/STaaS,
are there any known thresholds to be respected in terms of latency?
E.g. ... for on-premise, SSDs are recommended to achieve fast writing to the DB;
Similarly, there are ranges of ms for comms between a DMA and another in the same DMS cluster to achieve a good SYNC.
Any connectivity requirement to achieve comparable performance with Cloud-based solutions,
such as DaaS or STaaS?
Any link to pages with technical reference for Cassandra & OpenSearch clusters would be helpful.
Many thanks
Hi Alberto,
Let me try to give you a bit more information on this topic.
We don't immediately have thresholds or requirements in terms of latency. And you do mention many different areas where latency plays a role...
First of all, STaaS does not use Cassandra/OpenSearch. It uses cloud native storage of Microsoft Azure. This way you basically have access to state-of-the-art storage which is super reliable, always available and always secure. Difficult, if not impossible, to achieve the same with self-managed storage.
If you use DaaS, then you can run your DaaS nodes in the same datacenter as the location you chose for your STaaS. Then latency will be minimal. But we run self-managed DMAs with up to 100 ms latency to STaaS without any noticable impact. Lower latency is of course better.
DaaS DMAs can be clustered across different continents, that is not really a problem for the syncing because each DMA operates on its own, only things like e.g. a protocol file need to be synced. Everything in the DB storage is nicely handled by STaaS.
Then you also have the latency from the DaaS DMA to the data sources or equipment. That is typically also not really a concern.
So, in general, latency is not that much of a concern for DataMiner, because we don't have storage nodes which need to be in sync like Cassandra and OpenSearch have.
Anyhow, this is definitely an interesting topic. Feel free to ping me to discuss this in more detail.
Bert
Some more feedback:
– It is possible to cluster a DaaS DMA with on-prem DMAs, but then the whole DMS cluster must use STaaS.
– STaaS can be used for on-prem DMAs as well. Any DMA you manage yourself can be connected to STaaS, and these DMA can be hosted wherever you want, on-prem or in any cloud provider you want to use. It's actually even the recommended storage nowadays.
– Interesting website to check latency from your curreny location to the Azure datacenters can be found here: https://azurespeedtest.azurewebsites.net/
– STaaS will decide to store the data in the most optimal Azure storage depending on the data type. E.g. alarms are stored in Cosmos DB, trending is stored in Table Storage.
Thanks the clarification, Bert – appreciated
This will be key:
STaaS = Azure Storage –> no Cassandra // no OpenSearch
DaaS = (same as above)
Please correct me if I'm wrong – I guess this also means that it won't be possible to have a DaaS DMA in the same cluster with ON-PREMISE DMAs.
Is that the case also for STaaS?
At present, since the cloud based options are already available, my main goal is to understand what are the measured times in ms, on average,
between a monitored target in a given region (e.g. APAC) and the related storage node, thus having some time indication for the parts in angular brackets below.
DMA wise, I'd expect the time in ms would sit somewhere in the middle:
Target Device (on premise) <–Polling–e.g.GET/SET—> DMA (can be Daas) <–Write/Read–> DB (can be STaaS).
I'll possibly repost, but these are the main "latency" points I wanted to consider here.
P.S.: when Azure storage is in use, is the application DB MySQL or NoSQL?
Assuming that DaaS/STaaS can deliver the same sort of fast text search in history logs – I seem to recall that OpenSearch (and ElasticSearch before) had been added as separating alarms would make text searches faster than over the NoSQL DB.