dynaTrace 5.6 upgrade
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.
Hi Pete,
re /opt/dynaserve03/dynatrace-5.0.0. DT_HOME
As there seems to be more than one dynaTrace Server (installation) on the machine this seems logical.
The installer (sudo java -jar <location>/dynatrace-5.6.0.5802-linux-x64.jar) asks for the location. Only question.
Completely separate installation to a different directory structure /opt/dynaserve03/dynatrace-5.6.0, yes!
Same for Collectors, yes!
We talked about the Analysis Server. As long as it does not run u r OK. I changed the documentation yesterday. Nonexistent host and port to be doubly sure.
Thanks for the non/bootstrapped Agent question. Gives me insight about what people are unsure of.
Just take a look at Agent Connection Status in the configuration panel. Select Agents in the upper pane and look for bootstrapped or not in the lower (detail) pane. (I think there is a bug in 5.0 that the value in the upper pane is wrong!)
Normally your Agents should be bootstrapped. We don´t loose many words how to only use the core Agent.
When 5.6 Server and Collectors are up the old Agents should connect to the new components.
Assuming bootstrap: Restart apps at very last. Agents will get upgraded.
Deactivate the 5.0 license while the old Server is running, yes. Go to eServices and upgrade the license (and UEM volume voucher(s) on the other tab) to 5.6. Import it to the 5.6 Server (via Client UI) on its first start.
Older Collectors talk to new Server, yes. New Server, Collector upgrade one by one, yes.
Your backup(s) (strategy seems to be sufficient and fine.
Sudo is the way to go, yes.
ad 1: Please don´t mess with memory settings. I´m not exactly sure if the Client GUI gives you the right feedback with so much memory on hand. What does "90% utilized" relate to? - 90% of the Server´s quota or system memory?
Don´t tweak memory beyond 14GB with .INI settings unless instructed by support (or your guru tells you from experience he´s better off with 20).
ad 8: Install dir – As said: You will be asked. (Only Agent .shell scripts don´t!)
ad 9: Don´t forget to migrate Collector info! See sample below.
Suggest you migrate the classcaches too, particularly for the Collectors!
//migrate Server //assuming dtmigration was downloaded by the non-sudo user sudo java -jar /home/username/Downloads/dtmigration.jar -migration -sourceDTHome "/opt/dynaserve03/dynatrace-5.0.0" -classcache -targetDTHome "/opt/dynaserve03/dynatrace-5.6.0" //migrate Collectors - example for 06 sudo java -jar /home/username/Downloads/dtmigration.jar -migration -sourceDTHome "/opt/dynacollect06/dtcollect-5.0.0" -classcache -targetDTHome "/opt/dynacollect06/dtcollect-5.6.0" -migrateInstances defaultCollector
ad 11: If the machine with the Client is connected to the Internet, activation is automatic with Import (license)!
So, I sincerely hope I got most stress out of your migration!
Best
G.
Guenter, thanks! I know that was a bit of a lengthy question to review. It certainly helps my confidence level. (All my agents are bootstrapped by the way.) I'll update my document as I go through the migration next week and if it helps anyone to see an example of and upgrade process they would be welcome to it.
Hope I could be of help. I racked my brains that I didn´t forget anything. If got any further questions don´t be afraid to ask immediately. We monitor this forum quite closely and are glad when we can be of help. If it gets past me here, mail.
Cheers
G.
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.
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"
>
seems you have one additional " at the start in the path after the -targetDTHome switch
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.
I guess you don´t use the Collector that gets installed with the full package. So: Don´t care.
I gave you a copy - paste example above how to deal with single Collector instances.
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!
