We are looking to upgrade a sizable DC RUM environment due to a known bug in the CAS code. Because the issue is limited to a specific cluster of CAS servers, I'd like to limit the upgrade, for a short time to that cluster and keep the rest of the infrastructure running on 12.3.2. Is this a feasible plan? I would be upgrading the CSS/RUM Console per the upgrade documentation plan, and I would be upgrading 3 CAS servers out of the many more in the farm to 12.3.6. All other CAS servers, ADS and AMDs would stay at the 12.3.2 version. What considerations would I need to keep in mind when running the CSS/Rum Console at 12.3.6 and only part of the CAS farm at 12.3.6 with the rest of the infrastructure at 12.3.2?
as far as I know it is possible to have CAS servers on different Servicepacks in the same cluster without any problem.
The RUM Console/CSS mustn't be on the same servicepack either.
Therefore it shouldn't be a problem to only apply the servicepack 6 to one of your clusters and leave the rest on servicepack 2.
This is only my opinion as a partner consultant.
I Recently had to undergo a similar upgrade plan. I upgraded my customers RUM Console/CSS/CAS's to 12.3.4 and kept all of the AMD's/ADS's on 12.2.2. Everything went smoothly as expected, however I noticed some disparity in the RUM Console & CAS so thought I would share:
The RUM Console reported an alarmingly high amount of packets lost, 80-95% and varied. I investigated it and it turns out that we weren't missing any packets, but instead the version disparity included a change in how the versions reported lost packets, this caused a bug in the RUM Console in its reporting.
Additionally, as you might know, metrics change (Such as the breakdown/definition of the 'Idle Time') and this caused some erroneous looking data and triggered some alerts where it shouldn't have, it was simply the change in versions. But it is good to bear this in mind.
For known issues/Migration issues, there always this too: https://community.dynatrace.com/community/pages/vi...
Lastly I hope it goes smoothly for you!
I also recently had an instance where the customer's environemnt was left out of version sync, and it resulting in processing delays because the slave nodes did not know how to respond to the primary node's config sync pushes, and on each attempt to synchronize the cluster, the processing fell an additional 5-10 minutes behind. Getting all nodes to the same version resolved that issue.