I'm wondering if I can get anyone to quickly browse through my dynaTrace 5.0 to 5.6 migration plan, and if you see anything in there that looks like trouble please let me know. Also, for anyone looking at making this same migration this may serve as a good example that's a little more concise than the general process found in the migration guide. Not trying to re-write the migration guide, just trying to create a working example as an adjunct to it. (Since I have to document what I do anyway.)
dynaTrace upgrade 5.0 - 5.6
First, there are some non standard puculiarities to deal with.
Our Compuware consultant who originally advised on this installation did not use the standard directory location of /opt/dynatrace-<major.minorVersion>. Instead we have /opt/dynaserve03/dynatrace-5.0.0. DT_HOME is set to this value in the init.d/dynaTraceServer script.
I'm hoping the statement made in the migration guide that "The installer will default to /opt/dynatrace-<major.minorVersion>.0." implies I can also override that location somehow. I'm assuming this installation will allow me to create /opt/dynaserve03/dynatrace-5.6.0 and will install a new instance of everything, as opposed to modifying things in /opt/dynaserve03/dynatrace-5.0.0.
The collectors were not installed to any sort of version named directory whatsoever. For example, /opt/dynacollect06 and DT_HOME is set to same in the init.d script. Once again, for upgrade, I assume I should create a new directory like /opt/dynacollect06/dtcollect-5.6.0.
We also have a 'common' dynaTrace analysis server with both our QA and prod installation connecting to it. So the plan is to disconnect the dtanalysis server from QA, leave production connected to it. We will not upgrade the analysis server nor connect QA to it until we do the production environment. From the 'Analysis Server Configuration' doc:
"Upon post-processing of a memory snapshot the dynaTrace Analysis Server is automatically used if it is reachable. If it is not reachable and you are not running a production installation, the snapshot is post-processed by the dynaTrace Server."
So what we want to do is make it 'unreachable', meaning remove the configuration from the 'Services' section of the QA. Unfortunately, the server settings wouldn't let me just remove it. It requires something be there, so I changed it to a nonexistent host and port.
There is a lot of talk about "bootstraped" agents being able to automatically update when they connect to version 5.6 collector, but I could not find a clear description of how to tell what is and what is not a "bootstrapped" agent. As all our agents were installed with version 4.2 or later (most with 5.0) I think they should all be a "bootstrapped" type. Even if so, it is not clearly stated wether or not a restart of the application is necessary before the agent is upgraded.
The exact sequence of dealing with the 5.6 license is at first unclear. It gets clarified a little later in the migration guide, so I believe the sequence is I have to deactivate the 5.0 license while the dT server is running. Then import and activate the 5.6 lincense after migration. Presumably it will let me start the server without an active license in place?
From what I read I understand an older collector can report to a newer server. So to minimize changes and simplify the upgrade I would like to upgrade the server, then restart and confirm operations before upgrading the collectors, which I can then do one at a time.
Upgrade steps for QA:
We have routine daily backups of all components so we should be able to recover to time of last backup. For QA this is acceptable so no additional or specific back ups will be done.
(Note: All operations are run as root user via sudo.)
1. Verify system requirements. The 5.6 version is stated to require 20 - 25% more memory. What we find, however, is that in practice dynaTrace will use whatever memory you give to it, so this does not imply the existing system memory, at 96GB in this case, is inadequate given that it is already 90% utilized. We did increase the number of file handles (ulimit -n).
2. We downloaded a new 5.6 license file for our QA installation.
3. We made the dynaTrace Analysis Server unreachable from QA.
Had to do this by giving the QA service configuration a phony host/port combination. Don't like this, but couldn't find another way.
4. Stop the QA collectors.
There is one local and one remote.
5. Disconnect the performance warehouse.
6. Deactivate the QA lincense.
7. Stop the QA dynaTrace server.
8. Install the 5.6 version. As root user run the following. This is where I don't see an option to specify the destination folder of the new version. Hopefully it prompts for it.
java -jar dynatrace-5.6.0.5802-linux-x64.jar
9. Run dtmigration per instruction in migration guide.
java -jar dtmigration.jar -migration -sourceDTHome "/opt/dynaserve03/dynatrace-5.0.0" -targetDTHome ""/opt/dynaserve03/dynatrace-5.6.0"
10. Manually modify the .ini and configuration files with entries from the 'toBeMigrated' files as specified in the migration guide.
11. Start the new server, import and activate the new license and connect the performance warehouse.
12. Start the dynaTrace collectors. Because the dT server hostname and listener port(s) have not changed, and because the 5.0 collector should be compatible with the 5.6 server, everything should work.
13. Repeat this process for the collectors.
Answer by Ram D. ·
Hi Pete,
Please send documentation to ramchander.dasarathi@fmglobal.com. we are upgradding to 5.6 (from 4.2) tomorrow.
Thanks
Ram
Answer by Pete B. ·
Thanks Guenter and Stefan for all your help. We have completed our migration to 5.6 for our QA environment. If anyone out there needs a practical example of a dt 5.0 - 5.6 migration process I'd be happy to send you our notes. The documentation is pretty good, and Guenter's making it better all the time, but sometimes a real life scenario can help to.
Please send your experiences to Steve via shis235@lni.wa.gov, thanks in advance!
Answer by Pete B. ·
Thank you, I didn't see the extra quote mark. The collectors I use are not even in the same -sourceDTHome directory, so I don't think anything unwanted will be done. Trying again. That seems to have worked. On to the manual parts of the migration. Thanks!
Answer by Guenter H. ·
I gave you a copy - paste example above how to deal with single Collector instances.
Answer by Guenter H. ·
I guess you don´t use the Collector that gets installed with the full package. So: Don´t care.
Answer by Pete B. ·
Now that I read the details again I am also confused on exactly what gets migrated and implications of the -migrateInstances switch. This switch was not used, then I notice the 'default' behavior implies it will "Upgrade / migrate all default and additional dynaTrace Server and Collector instances". Is this attempting to migrate my collectors (only one of which is local to the server)? The collectors, per my original plan are not upgraded yet.
Answer by Pete B. ·
I have a problem. The installation went quickly, but the migration comes up with a prompt. This was completely unexpected and I have no idea what to do with it. Not having any luck solving it via the documentation, but still looking.
Installation finished successfully in 32s
[root@dynamite04 dynaserve03]# java -jar dtmigration.jar -migration -sourceDTHome "/opt/dynaserve03/dynatrace-5.0.0" -targetDTHome ""/opt/dynaserve03/dynatrace-5.6.0"
>
Answer by Guenter H. ·
Pete,
one more note: When you migrate the Collectors with the class caches, could you please have an eye on the time it takes the new Collectors to convert the class caches (expected somewhere around one minute / GB) from the 5.0 to the 5.5 / 5.6 format and come up – and immediately contact us if it takes much longer?
Thanks
G.
JANUARY 15, 3:00 PM GMT / 10:00 AM ET