Migrate Mnaged Cluster RHL 7 a RHL 9

[HectorNP]

Hello I want to perform a migration of a dynatrace managed cluster this is installed in a virtual machine with RHL version 7 and we need to upgrade the operating system to version 9 the problem is that we can not do the upgrade gradually by incompatibility issues, so you need to make the migration to a new virtual machine and with RHL version 9 leaving the same ip and network rules.

Has anyone already made a migration with this scenario or similar? is it possible?

I have already checked the documentation in https://docs.dynatrace.com/docs/managed-cluster/operation/migrate-a-clusterbut I don't see any mention of something related to this kind of migration. 

Thank you very much.

[Mizső]

Hi @HectorNP ,

We did a similar migration from Ubuntu x to RHEL 9 at a client. I recommend to have at least 35 days grace period with two managed nodes. Before that we had a failed migration because the original node was switched off too early We had ElasticSearch issues, Support had to repair it remotely. 

I hope it helps.

Best regards,

Mizső

[HectorNP]

Hi thank you Mizső for your reply,

Thanks for the clarification of the recommended days we intended to make the direct change, we will take your recommendations for the customer to facilitate us this option. 

Thank you.

[Babar_Qayyum]

Hello @HectorNP 

I would also recommend going with the 'Replication method'.

Regards,

Babar

[Julius_Loman]

The easiest method it to do a backup/restore method. But until the backup is restored you will be left without monitoring and you will lose the volatile data such as traces from the node as those are not part of the backup.  Probably even the trace data can be backup/restored manually - but I never tried it.

Just curious - what is your blocker for not upgrading the OS in place? We had customers event going from CentOS 7 to RHEL9. 

[HectorNP]

Hi Julius,

So you say that it could also be done with the backup/restore method? The thing is that the client by its "policies" did not allow to make this update that way, even wants that once the migration is done the host has the same IP as the current host so the method of back up would be perfect if only I could take the backup file and restore it to the new host but the documentation says that only applies to the staggered update on the same server.

[Julius_Loman]

Sure, if the client accepts the unavailability of Dynatrace Node for a few hours and accepts some of the data such as traces will be missing after restoration. Backup can be restored on a newly created host without any issues on different IP addresses.

If Dynatrace is not mission critical, I'd prefer this approach in small single-node cluster environments.

[HectorNP]

Hi Julius,

Thanks for the answer, if the client is most interested is to perform the update of your operating system does not matter if some metrics are not saved, now we have a question if the new host needs to have connectivity to mission control because when you want to create a new node is canceled because there is no connectivity to mission control I guess there is no way to create a new node without that connection.

Julius do you know if in a cluster there is the concept of master and worker?

[Julius_Loman]

If you can't upgrade OS in place for any reason, then you can use the backup/restore method.
So basically:

1. Ensure you have the backup (by backup I mean the automated backup configured in CMC
2. Shutdown the cluster node OS. (monitoring stops from this time)
3. Install the desired OS (from scratch) or provision a new VM with the same IP addresses (to ensure your OneAgents and ActiveGates can connect without reconfiguring)
4. Restore the backup following the restore procedure.

Caveats - some data will be lost (traces for example) and depending on the backup configuration also additional data such as user session may be lost. Be sure to check this first.

I suggest reaching out to DTONE or your local Dynatrace contact if you are in doubt or you don't fully understand the procedure.

FYI - Dynatrace does not have the master and worker concept. There is a quorum concept in place used by the embedded Cassandra database.

[jiri_stefanek]

Hi Julius,

Would you recommend this solution for an environment with two managed cluster nodes?

Or will the procedure be fundamentally different?

Thanks

[stevenp]

Hi Julius,

Interested to your recommendation. 

I have a question, can the cluster be restored to different Dynatrace cluster version? 
Here is the condition. I need to migrate the current cluster (Centos OS, Dynatrace cluster version 1.25x) to new cluster (RHEL 9 and install latest cluster version 1.28x), let assume that in place OS upgrade is not possible by our ends. So, the cluster will be migrated from 1.25x to 1.28x, is it possible?

Thanks,
Steven

[Julius_Loman · Accepted solution]

@stevenp No, not possible. You restore to the same version, the installer is part of the backup with configuration and other data. You can restore it to a different (supported) operating system, but the restore procedure installed the version you have in your backup.

[stevenp]

Hi @Julius_Loman ,

Well, thanks for the explanation. Let me make a summary:
1. Restore to same Dynatrace cluster version, even it different (supported) OS platform & version : Possible
2. Restore to different Dynatrace cluster version, whether it same or different (supported) OS platform & version : Not Possible.

Is it correct?

[Radoslaw_Szulgo]

correct. The backup always restores the the version that was at that point as installation binaries are also part of the backup archive.