In place upgrade of NW 8.2.x to 19.1

Hello,

We have been tasked within a rather tight timeline to upgrade our two Networker 8.2.x servers to 19.1 for both support compliance and some use cases such as MySQL server clients that have upgraded to MySQL 8. Here are the dirty details, which might be more than needed but better that than too little:

Current environment:

Two Networker 8.2.12 servers are physical Supermicro storage servers running CentOS Linux 6/7. One is also the NMC server. iSCSI attached LUNs on a NexSAN storage system are also backup targets.
All backups are cloned to two offsite storage nodes (SuperMicro storage servers) also running CentOS Linux.
Backups of production database server clients also have monthly fulls cloned into S3 via Amazon Storage Gateway with VTL, which is iSCSI attached to one of the NetWorker servers.
NMDA 8 is used for some MySQL DB servers and Oracle DB servers.

Test environment:

NW 19.1 VM (NVE) was deployed in our VMWare environment for testing, to familiarize myself with the GUI and new policy and workflow characteristics, and testing backup job use cases with both NW 8 and 19.1 clients on Solaris, Windows, and Linux. Also NMDA 8.2 for MySQL backups, which seem to work fine. Next steps are to test MySQL db restores using both NMDA 8.2 and NMDA 19.1. This is the due diligence requested by the database team who are our primary customers, to ensure continuity of service for both 8.2 and 19.1 clients after upgrade.


With the planned in-place upgrades of the production Networker servers and offsite storage nodes, what are the special considerations or expected headaches we might be facing? I understand per documentation that everything *should* go fine, but if anyone has seen some significant disruptions in service due to a major upgrade from 8.x to one of the newer Networker versions that would be helpful.

Also, I understand that 'undoing' the upgrade in case things go south is not so cut and dry. In the past our servers had dual OS disks set in RAID 1 and I would just break the mirror before a big upgrade and keep the second disk handy to become primary. However we are now using our second SSD disks in these servers as dedicated mounts for /nsr since they get so large so that is not an option. My only thought is to tar up and copy the /nsr directory in its entirety to one of the RAID volumes, and rollback would simply be uninstalling 19.1, re-installing 8.2 and copying /nsr back in place. I also understand we would likely lose manageability / recoverability of any savesets generated while the server was running as 19.1 due to the back end database differences.

Thoughts? Warnings?

Thanks in advance
joe


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module

In regard to: [EMC-DataProtection-L] In place upgrade of NW 8.2.x to 19.1,...:

> We have been tasked within a rather tight timeline to upgrade our two
> Networker 8.2.x servers to 19.1

We're already on 9.2.x, looking at 19.1.

Can you go straight from 8.2.12 to 19.1, or do you have to do an
intermediate update? I don't remember, but that's an important
consideration for you.

> Thoughts? Warnings?

You've already been looking at the changes to the interface and concepts
(workflows, policies, etc.) that come with 9.x and later, so you're in
good shape for what I would consider the major adjustments brought on
by product changes.

For us, even going from 9.2.1.x to 19.1, the trick has been coordinating
all the related software versions. The fact that they've now split the
compatibility guide into different locations for different versions of
the software has made certain things more challenging.

For example, our 9.2.x NMC is still running on RHEL 5.x. NMC 19.1 doesn't
support RHEL 5. We therefore have to move the NMC to a different host
running a later version of RHEL before we tackle any of the 19.1 upgrade.
We have to look in one compatibility guide to see which OS versions our
current 9.2.x NMC supports and another compatibility guide to find which OS
versions NMC 19.1 supports, to see if e.g. RHEL 7 is supported for both
versions (it looks like it is).

It's this kind of intermediate OS juggling, for nearly every related
component, that has added some complexity to the planning for the upgrade.

We recently replaced our Data Domain with a newer model, and picked a
DDOS 6.2.x.y version that is compatible with both our current 9.2.1.x
clients and our future 19.1.x clients, so that's been taken care of.

We also have to do things like match the version of the NvP (the VMWare
backup proxy that replaced VBA) with the version of vCenter we're using.

If you have a handle on all of these version compatibility considerations
then you're likely well prepared for the upgrade.

Tim
--
Tim Mooney Tim.Mooney@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module

Because I do not know how your systems has been setup, I personally would chose a standard NW/Linux distribution instead of NVE.

Why? - because NVE does not allow you to make any changes, for example to the install path. The intention is to make it very easy for a new NW user to deploy it. Consequently, it does not even have such option.

Another issue is that NVE - by default - runs on a DHCP address. This is usually not wanted. I assume that you must do a bunch of corrections within the resources just due to this fact.

NVE insists on an internet access - at least for installation and upgrades. Again, such would be a k.o. criteria for a bunch of customers. You may cut that later ... but will you ever remember it when you run the next upgrade? - And there is no clear error message that indicates the real problem.

Finally, NVE uses SuSE ... without GUI. That means that you need to make all necessary changes from the command line. Not only that you must know linux commands and YAST - I just figured out that with the YAST 'GUI' you might insert/append to an edit field but so far I have found now way to delete a chararcter. So how do you correct typos?


Just to name some major restrictions which would convince me not to use NVE. But of course you talk to an experienced NW user.

Thanks for the input. The Networker 19.1 Updating from a Previous Version doc indicates that updating directly from 8.1.x or 8.2.x is supported. It's looking like if all our components are 8.2.x and on either CentOS 6 or CentOS 7, there should be no compatibility issues.



In regard to: [EMC-DataProtection-L] In place upgrade of NW 8.2.x to 19.1,...:

> We have been tasked within a rather tight timeline to upgrade our two
> Networker 8.2.x servers to 19.1

We're already on 9.2.x, looking at 19.1.

Can you go straight from 8.2.12 to 19.1, or do you have to do an
intermediate update? I don't remember, but that's an important
consideration for you.

> Thoughts? Warnings?

You've already been looking at the changes to the interface and concepts
(workflows, policies, etc.) that come with 9.x and later, so you're in
good shape for what I would consider the major adjustments brought on
by product changes.

For us, even going from 9.2.1.x to 19.1, the trick has been coordinating
all the related software versions. The fact that they've now split the
compatibility guide into different locations for different versions of
the software has made certain things more challenging.

For example, our 9.2.x NMC is still running on RHEL 5.x. NMC 19.1 doesn't
support RHEL 5. We therefore have to move the NMC to a different host
running a later version of RHEL before we tackle any of the 19.1 upgrade.
We have to look in one compatibility guide to see which OS versions our
current 9.2.x NMC supports and another compatibility guide to find which OS
versions NMC 19.1 supports, to see if e.g. RHEL 7 is supported for both
versions (it looks like it is).

It's this kind of intermediate OS juggling, for nearly every related
component, that has added some complexity to the planning for the upgrade..

We recently replaced our Data Domain with a newer model, and picked a
DDOS 6.2.x.y version that is compatible with both our current 9.2.1.x
clients and our future 19.1.x clients, so that's been taken care of.

We also have to do things like match the version of the NvP (the VMWare
backup proxy that replaced VBA) with the version of vCenter we're using.

If you have a handle on all of these version compatibility considerations
then you're likely well prepared for the upgrade.

Tim
--
Tim Mooney Tim.Mooney@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module