ELM Version Upgrade 701->702 - New Server Machine or Same Server Machine
When upgrading from ELM701 (running on Server01) to ELM702 the instructions workflow from IBM involves setting up a staging server and doing a test migration on the staging server (Server02) prior to production migration
If test upgrade is successful then production upgrade can be planned
Or the production upgrade could be done on Server02 and Server02 could become the new production server. This would require either a ServerRename on the ELM repositories or else a network alias could be reconfigured so the network now recognises Server02 as having the same FQDN address as the old Server01
The advantage of staying on the same sever Server01 for production EML702 is that no server rename or network alias reconfiguration is required.
The advantage of going to a new server Server02 for production EML702 is that if anything goes wrong during the production upgrade process then original 701 production server is still available for quick rollback without any disruption to users
Which of these approaches is the more typical for ELM upgrades?
Accepted answer
My perception is that it's most common to upgrade the original server, since there is an on-going performance penalty when running a renamed server in production. That said, some organizations may use DNS tricks to avoid doing a server rename and thus make the test server the new prod server.
Comments
>>since there is an on-going performance penalty when running a renamed server in production
Thanks Daniel
Is there any documentation on this performance penalty as I could not find reference to it in the upgrade guides?
I thought the server rename just did a global search and replace on the URI in all the database artifacts so then performance I thought would be similar to before
This doc estimates about 5%. The doc goes back quite a while, but in this aspect it remains relevant I believe.
3 other answers
I have done upgrades on both same server and different server and both work fine.
The key here is that your server machines have a hostname, but they can also have an alias in the DNS, so my server names are always something internal, but the alias is the external name. This can also of course be done with a proxy or firewall rules as well.
Then it doesn't matter at all what your server is called, or even if you move from one server to multiple machines with apps spread across them - the external name remains the same and no Server Rename procedure is required.
During the initial install and set up, you can use your hosts file to hard wire the external name to an IP address for a specific machine and then, once finished and tested, remove the hosts entry and change the alias
Using a reverse proxy to serve the (unchanging) external URI means you could if you want use your server02 method without a server rename - you reconfigure the reverse proxy to direct requests to server02 (or server01) on its hostname, without a server rename.
> if anything goes wrong during the production upgrade process then original 701 production server is still available
You would never install 702 directly over 701, so the 701 install will always be present on server01 even if you install 702 there, and a rollback mainly involves restoring the databases back to 701 content (because the upgrade upgrades the databases to 702), which is needed regardless
As Daniel says, I think upgrading the original server is more common. The staging server approach we document means you can do a (very important) trial upgrade while production server is still running so when it comes to production upgrade you are confident it will succeed; but I don't believe it's the intention to indicate that the staging server should be the upgrade route although, as you say, it could.
Thanks for all the feedback Daniel, Davyd, Ian.
I have done several upgrades before but they have always involved moving to a new server (for unrelated network reorganisation reasons) so the 'staging server' always became the production server.
But, good to know that the upgrade can typically be done on the same server, when moving servers is not required for other reasons.