Hi Dojo,
With reference to legacy DMS-cluster architectures that were running Cassandra as a local DB on the Windows/DMA server, are there any recommended steps for an upgrade to a newer version of Cassandra?
Based on this info from apache.org, I’m led to think that Cassandra 4.0 will necessarily require a DMS to move from a local DB architecture to a Cassandra cluster that will be Linux-based or to consider STaaS.
Alternatively, could a Docker installation on Windows support Cassandra 4.0 for a stand-alone DMA?
Any steer will be helpful.
Thanks
Hi Alberto,
This is a no-brainer: STaaS is the way forward.
STaaS is so easy to set up, zero maintenance, you’ll have time again to focus on the valuable work and you’ll always have a secure and reliable storage solution available now and tomorrow, ready to scale whenever you need it.
Cassandra 4.0 should indeed be used on Linux (or you could use WSL in Windows). And today we always recommend the cluster schema for the database, but you can still run this on one single node. Of course, if you want redundancy, and backups, and security, and reliability, and scalability and… all of these things… You’ll be better off with STaaS unless you have lots of spare time and spare VMs ;-).
Bert
Hi Alberto,
Sorry for the late response on this, but to answer your questions, we can support these requirements. You need to add these requirements when making the request to our StaaS team. See this procedure: https://docs.dataminer.services/user-guide/Advanced_Functionality/Databases/STaaS/STaaS.html
Thanks for the update, Michiel
We’ll have to run some checks to understand if we are impacted by any of the limitations listed – and if the retention can be adjusted in line with other requirements (e.g. storing data for 6 months and so on).
Worst case scenario: where STaaS may not be viable,
is there any support from SL for Cassandra clusters on-prem rather than in the cloud?
Marking this as solved as I understand STaaS is the recommended strategy, so any different need is better handled under a separate question.
Bert & Michiel, thanks for your insight
Thanks for your feedback, Bert – appreciated.
Indeed STaaS is one of the things I’d evaluate, but I’m afraid in some cases the DM admins or architects may need to consider also the geo-location of the data (once it’s hosted in Azure, there can be specific policies for compliance).
Is STaaS location managed via SL or directly by system admins?
I’ve retrieved this list of regions:
https://learn.microsoft.com/en-us/azure/reliability/cross-region-replication-azure#azure-paired-regions
If DMAs can be in different Countries, how would we choose the related region for STaaS?