Guru: Avoiding Land Mines During A Role Swap
March 3, 2025 Steven McIver
Having a disaster recovery plan is crucial for many businesses running on IBM i. The data that resides on these systems is often mission critical to the business. Implementing a strategy for disaster recovery is tough. Planning and actually executing on the strategy is even tougher.
Even with excellent planning, role swap tests to a designated disaster recovery machine can many times fall short due to unforeseen circumstances that force an immediate role swap back to the production site. In this article, I’ve compiled a few of those land mines to look out for to help ensure a successful swap you may have in your near future.
First: Determine the best way to contact vendors for license keys in an emergency.
Role swaps often happen during the quietest times of your business, which is also often the time when no one may be around to answer the phone at a vendor who provides support for one of your important applications. After a role swap, you may either need to enter a license key or you may find out the key you thought was a good, working key is not actually a good, working key. Something so simple, a license key, can put your entire business in a bind if you cannot reach out to anyone to get the key in a time of need.
When planning for a role swap, list all of your third-party vendors that provide license keys for their products. Call each of them and take note of their support hours. If some are not available during your best time to swap, see if they can provide on-call support for a fee just in case they’re needed. This can provide a great comfort to your business knowing that if support needs to be engaged there will be someone to answer on the other end.
Second: Make sure your DR site public IP is whitelisted for transfers to other companies.
A necessity in many shops is to be able to transfer data from the IBM i to another company. If you go to initiate this transfer from your DR location, which is highly likely to have a different public IP at that location, the company receiving that transfer may see that as a foreign address and refuse to make that connection. An important planning step is to reach out to any company that you make transfers to and inform them of the public IP address of your DR location. That way they can whitelist the IP address if necessary to ensure their system will happily receive the data.
Third: Update IP addresses if your DR location uses a different subnet.
Network architects have to make a decision whether to stretch a network across two-sites, or to have a separate network for each time. Both setups have their pros and cons. The con of the separate networks is that you can run into some land mines on the DR system, especially in a full system replication setup, where IPs for services are still being told to use the network from the production site as opposed to the DR site. Here are some common entries that need updated on a DR system when there are separate networks:
- Host table entries – CFGTCP option 10: Any entries resolving to the production site IPs need to be updated to resolve to the DR site IPs. This is done, strangely, by using the Rename option to change the IP address for the entry.
- Web services – HTTP Web Administration for i: Check to see if any web services are bound to a specific IP address. Go to the properties of the service to update them to the DR site IP.
- SMTP IP binds – Navigator for i: SMTP client and server can be bound to a specific IP on your system. If you’re at the DR site, you will need to bind to an IP that exists and is active on that system. The easiest way to make this change is to go into Navigator for i, find the SMTP service, go to properties, and update the IP for the server and client bind. Then restart the SMTP service.
Fourth: Make sure directory entries are being replicated.
In setups that don’t do full system replication, you often need to make sure directory entries are being replicated. On some systems, these are necessary to send emails and others they are necessary to access Document Library Objects (better known as DLOs and the /QDLS file system). There is a function in the System Distribution Directory that allows for the “shadowing” of these entries to replicate them to another system. No extra software needed. The procedure for enabling this function can be found at this page.
Fifth: Are your web services being replicated?
Replicating your critical data is great. But also great is replicating the web services that often need to be running to access that critical data. Do testing on the DR site system to make sure the replicated copies of the web services can start and are accessible. Also important is making sure the certificates that secure these web services are stored at the DR site as well. If the certificates are not available, and the services are only available through a secure connection, then you will be scrambling to figure out how to get the certificates to the DR system.
As you can see, planning and preparation are key for a successful role swap, and knowing about these pitfalls can make your DR test go much more smoothly. I wish you well on your future role swap – hopefully well-planned and not untested and unplanned!
Steven McIver is an IBM i senior system administrator who has spent 16 years specializing in IBM i, IBM Power Systems and Storage. He has been with Service Express for four years, focusing on projects revolving around IBM i. Steven has been recognized as an IBM Fresh Face for his contributions to IBM i and Power Systems.
RELATED STORIES
A Match Made In The Midrange: IBM i And FlashSystem
Understanding The Power Of Power10
Power10 Upgrade Considerations You Need to be Aware Of
Service Express Buys iTech Solutions, iInTheCloud
iTech Solutions Keeps You In The Know With VERIFi
