Through the life of a typical GroupWise system, it will likely move platforms at some point. No fancy migrations needed as all the database changes get done in place.
This could be hardware replacement, changing virtualization types, to hitting the limits of the OS at the time of the original installation. After all, you can only upgrade a box so much before there become issues with the OS. Even when you otherwise love that OS, a new install gains you so many of the advantages of it that are blocked in just upgrading it in place. Any GroupWise system of any real age has likely been moved a few times, such as from NetWare to NetWare to OES to OES
For this document, I will stick to current (late SLES15 era) and most common GroupWise hosting OS, with pure SLES or OES (built on SLES). Assuming GroupWise is the only application on the system so that the old box can be retired, and running an incremental copy of some sort. Imaging the data such as moving/copying a virtual drive can be done as well. This is for any and each server with a Domain and/or PostOffice on it. A GroupWise upgrade can be a part of this process if desired, but is assuming at least a GroupWise 2014 or greater source system.
This process allows you to build the new server in advance, and get the bulk of the files copied over in advance without downtime as those OFFILES are bulky, don't change much, and take a while (possibly many hours) for that initial copy. You are typically just looking at a couple of hours of downtime for the final move, under an hour if all goes smoothly.
Pre-migration is a good time to make sure your GroupWise maintenance is running properly, also check the results and files that are not part of the GroupWise system are removed from the GroupWise folders.
Build the new system with a different IP from the old server and a separate logical drive for GroupWise, either as NSS or XFS. Both are excellent options, both needing specific settings made, ideally at creation. NSS needs Salvage turned off, XFS (or any DB safe Linux type) mount points need the noatime and nodiratime set for optimal performance.
- Install GroupWise, but do NOT configure it!
- Restart the server at least once before the final migration to really finish that install.
- Copy the data with either rsync or dbcopy. rsync is very native with any Linux and is worth knowing for all platforms. I find it is the faster and easier of the two. It does every file that has ended up in the source (junk included) and doesn't get you restorable db files if the GW Agents are running, which is not a problem with such a migration. DBCopy requires a mount point to the new location to work, only does GroupWise files, is slower, and doesn't delete files. A script of the combination of them make for a decent low budget backup. Example in the Community.
- Both tools can and the one you choose should be used incrementally, with a primary full copy of both the Domain and PostOffice folders, making sure the size at the destination is about what you see on the source. Identify any notable differences, as there may be issues to take care of. You can/should do this in the days leading to the actual flip outage of a couple of hours. If different versions, it tends to be best to use the newest dbcopy if you are using it, otherwise the direction of copy doesn't matter much.
- Easy comparison tools:
- # du -h --max-depth=1 /GWdomain|GWpostoffice (the PO will take a while due to OFFILES)
- or install and use ncdu from GWdomain|GWpostoffice folders
- Is your GroupWise system the same IP as the server it is on, this is where we will change that. It makes these moves so much easier, is mandatory if you were to go to cluster services (where I learned this trick), and is how the containerized future of IT generally works.
- On the new server, make sure the /etc/hosts file has the GroupWise agents as FQDN entries as needed for GroupWise since 18.4, and that they match what you have in the agents' settings.
- On the new box, make sure the GroupWise agents ports are all open on the Firewall. Firewalls on servers are becoming less and less an option in the whole Zero Trust path of things.
- Firewall ports references
- on MTA system: 7100, 7180, 9710
- on POA system: 1677, 8301, 7181, 7101, 7191, 9711,
- on GWIA system: usually an MTA set and 25, 9850
- For the final migration, make sure the source server's agents are shutdown, and preferably can't be turned back on
- # rcgrpwise stop
- # systemctl disable grpwise.service
- perform the final sync
- While that final sync is running, copy the following files to the new system.
- /etc/opt/novell/groupwise/gwha.conf
- /opt/novell/groupwise/agents/share/gwdva.dva
- /opt/novell/groupwise/certificates/*
- # scp /etc/opt/novell/groupwise/gwha.conf root@DestinationServer:/etc/opt/novell/groupwise/
- # scp /opt/novell/groupwise/agents/share/gwdva.dva root@DestinationServer:/opt/novell/groupwise/agents/share/
- # scp -r /opt/novell/groupwise/certificates/* root@DestinationServer: /opt/novell/groupwise/certificates/
- Once the sync is complete, remove the secondary IP from the source server if already using such, or down that server.
- Add the secondary IP to the new server
- # systemctl status grpwise.service
- may not be enabled yet. enable it and start it
- Test system, can you send & receive email, and manage the system
- A reboot to make sure it all behaves is a good thing as well.
If this feels overwhelming, and you are in Canada, please reach out to us, as we can help. For other feedback and comments, post a comment below.
No comments:
Post a Comment