cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Partial upgrade of DC RUM

emeck
Contributor

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?

8 REPLIES 8

thun
Advisor

Hello Erich,

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.

Joshua_Clay
Dynatrace Guide
Dynatrace Guide

Hi Erich,

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!

Cheers,

Joshua

Adam_Tryba
Dynatrace Advisor
Dynatrace Advisor

Hello

Just to let you know "(...)CAS servers on different Servicepacks in the same cluster without any problem. (...)" is no longer valid.

In 12.3, we require the builds of the CAS to be exactly the same, otherwise you may get warning messages when loading some reports.

Adam Tryba

The intention is to keep the CAS servers within the specific cluster at the same version. Though there will be some different versions across the farm as a whole.

"exact same version" usually means release, service pack, and patches need to match exactly

-- Erik

Hello Adam,

will this be from 12.3 to all future releases?

Adam_Tryba
Dynatrace Advisor
Dynatrace Advisor

yes, since 12.3, that behavior will be as described (so the CAS version should be equal there for the farm to work properly = same release, same service pack, same build of the service pack)

Erik_Soderquist
Dynatrace Pro
Dynatrace Pro

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.

-- Erik