We are evaluating the idea of virtualizing the CSS-CAS-Console, and moving the databases to a SQL cluster.
According to the requirements page, version 12.4.11 apparently supports SQL server 2016.
We had a long discussion about the Reporting Servers and Databases Clusters HA/FO solution in the following post and I hope you can get some valuable information.
This user can be replaced with a local database server user or a valid domain user. To specify a domain name, use the
Many thanks for your answer.
I read indeed in the DB cluster HA/FO discussion that "the instance will migrate automatically to the other server, and you will still have both CAS/ADS working".
I would like to be sure that the CAS handles this natively and that there is no manual restart of service or such thing needed.
For the DB user, I didn't find this in the CSS installation part, which should be the first component to install. Therefore I didn't check further in the docs.
There is no manual intervention on the reporting server level.
The following documents links are very good written to get the whole concept about LB and FO.
I would suggest if you can have a glance.
It's not 100% clear in the links Babar provided, because there's talk of various methods.
DCRUM components do NOT support SQL HA/FO.
To have HA/FO for DCRUM you have to duplicate your environment, 2x CAS + 2xCASDB, 2xADS + 2xADSDB etc. And use the DCRUM clustering to manage it.
CSS and RUMC are left vulnerable because there can be only one RUMC in an environment, and for CSS while you can have multiple CSS (for load sharing), they all use the same single DB. I believe this in particular is being addressed in the next major release.
Lastly on the virtualisation topic, fully supported, but note that CAS/ADS are very hard on resources, and can cause performance problems for other guests if the host hardware is not sufficiently powerful (high IOPS mainly), and/or over subscribed (memory/CPU sharing). The various components don't play well with 'dynamic memory' (HyperV), always allocate static memory - this is more a concern with Java applications rather than DCRUM specificifally.