I look up at the clock on Monday morning, and it's that time! Nine o'clock—time again for our weekly IT staff meeting. I enter the conference room with a little excitement this morning. On the agenda is a bullet point to discuss the new IBM System i servers that will be installed shortly. The highest-level IT people have been brought in just for this topic.
Being a bit more on the technical side, I expect them to bounce ideas and comments around, possibly ask me a question or two, and then determine a direction for the project. And that is exactly what happens. The direction they determine is for me and my team to replace the existing system with the new one...and, by the way, perform the replacement with no impact on the data and minimal or zero impact on the users.
Immediately, I feel a rush of anxiety. How can I do this?
The new system operates differently than the last did. How will the applications run on this system? We are up to multiple terabytes of DASD. How can we possibly get all of this data to the new system without impacting the users? I turn and smile to my boss and my peers and comment, "No problem!" And so begins another fun IT project.
So often anymore we are being asked to do more with less. We have been given the task of upgrading all of the i5 systems. We have been asked to consolidate the systems onto one big machine. Or we have been asked to coordinate the physical move of the i5 systems from one location to another. Regardless of the specific project at hand, the details involved in making it happen are similar and can be quite complex.
Using High Availability for Migration
Like most IT professionals, we are trained to accept change and to look for new technologies to assist us with the tasks at hand. In the case of migrating an old AS/400 to a new i5 system, the technology of choice is the use of a high availability software solution. Too often, people think of high availability (HA) as a means to quickly recover a system in the event of a disaster or as a tool that enables us to move some of our workload to a secondary system (such as a tape backup) so the primary system can remain available longer. While these two scenarios are popular examples of high availability, using an HA software solution for a migration is also an extremely effective use of this technology, for more reasons than may be obvious at first glance.
Let's start with Replication 101. All HA software essentially operates in the same manner. The functions of system auditing and database journaling are turned on for all objects to be replicated. This effectively begins a process of recording all activity to those objects. The transactions captured by the journaling function are then transmitted to a secondary system where they are applied to the appropriate objects on that system. The objects are now synchronized between the two systems, thus giving you a replicated environment. In keeping with this foundation, there are three main approaches for using HA software for a migration: the switch approach, the cascade approach and the parallel processing approach.
The Switch Approach
The switch approach is a migration technique that starts with the use of two systems (a primary and a secondary). Using the HA software tool, the data (not the OS) is replicated from the primary system to the secondary system. If both systems are to be upgraded, the process is as follows:
- Start by severing replication between the primary and the secondary systems. Allow the users to remain on the primary system and the journals to collect all of the transactions. For the users, it is business as usual.
- Upgrade the secondary system (hardware, OS, or both) by saving and restoring the data from the secondary system to the new secondary system. This can be done anytime as it does not affect the users.
- Replace the secondary system with the new secondary system and reestablish communications to the primary system.
- Replicate all of the transactions that have transpired on the primary system since the connection to the secondary system was severed.
- Once everything has caught up, perform a controlled switch of the users to the new secondary system. Switching environment capabilities is standard procedure for most HA software packages. Some things to consider are network considerations (bandwidth), printing functions, routing functions, etc. This is primarily due to the location of your physical devices.
- Now that the users are on the secondary system, repeat the upgrade process for the primary system.
- Reconnect the two systems, replay all transactions, and perform a controlled switch back to the original configuration.
You are now running from a new primary system to a new secondary system, with no impact to the data and only a small controlled outage during each switch to the users.
When to use: This approach is popular for relocating a system, upgrading an OS, or upgrading hardware. By switching the users to a secondary system, you free up the primary system to perform any necessary functions.
Things to consider: In order for this approach to work, the systems must be "like" hardware for performance. Having a much smaller secondary system would not allow normal business to properly perform during the switch. The HA software must be configured to replicate "all" data. Any data not replicated from the primary system to the secondary system would be missing from the secondary system during the switch.
Also, each system must have enough DASD to house the journal receivers during the time that the systems are not replicating. This is the major factor in performing a system relocation as the amount of time the systems are disconnected can be substantial.
When trying to meet the specific needs of a migration project, there are many other considerations that can be worked out during planning. For example, most HA software solutions support clustering technology that could further reduce the already minimal outage to users during each of the switches, if that is a project requirement.
The Cascade Approach
The cascade approach is a migration technique that also starts with two systems, a primary (A) and a secondary (B).
- The way these systems are migrated is by configuring a third system (C) down-line from the secondary system (B) and a fourth system (D) down-line from C.
- Using an HA software solution, replication would be configured to send data from A to B, then B to C, and then C to D.
- Once all of the necessary checks are made, the users can be moved from A to C using a reconfiguration of the network. At this point, A and B have been migrated out and C and D remain.
When to use: This approach is popular for upgrading hardware when switching is complex. It is also popular when the size of system B is large enough to hold the data and pass it on but not large enough to operate as a primary system with all of the users attached. This approach is also used for "staging" the application data onto the new system to enable you to test how the applications will perform on the new systems.
Things to consider: The HA software must be configured to replicate all of the data from system A downward. Any data not replicated from the top down will never make it to systems C or D. This approach also requires a heightened awareness of synchronization of the data between each pair of systems. If the data is improperly replicated from A to B, the mistake will be repeated from B to C and C to D.
The Parallel Processing Approach
The parallel processing approach is a migration technique that uses four systems: a primary and a secondary system and a replacement primary and secondary system.
- This approach is accomplished by using an HA software solution to establish replication between the primary system (A) and the secondary system (B).
- Next, the replacement primary system (C) could be staged next to the primary system (A), and replication could be established between it and the replacement secondary system (D) that is staged next to the secondary system (B).
- From there, an additional replication environment could be built between A and C. The replication configuration from A to B and C to D could be identical. The replication configuration from A to C would need to include 100% of the data. Again, anything not replicated from A to C would not make the migration.
- The appropriate checks would be performed on all replication instances, and then the users would be moved to the C system by way of a network modification.
- At this point, A and B could be retired, C and D would remain as primary and secondary systems and the remaining replication configuration would be exactly as it was from the original A to B systems.
When to use: This approach is favorable for giving a user the ability to get the data from the original source. It does not require a switch. And it enables the user to pre-test the applications on the new systems.
Things to consider: This approach involves the most configuring, albeit simple. The time it takes to configure and stabilize this environment (the time in parallel mode) is longer than it is with the other approaches. However, there is a greater reduction in the downtime to users. In addition, the integrity of the data is improved because comes from the original source. As with the other approaches, bandwidth, network, and hardware requirements must be considered.
Customize Your Own Approach
Endless modifications can be made to these migration approaches. For example, you may have a need to replace only one system. That new system will become the new primary system. But the old primary system was bigger than the old secondary system. So you want to retire the old secondary, make the old primary the new secondary, and install the new primary. Combinations of these approaches can be modified to accomplish this.
Actually, these examples imply the requirement of having a replicated environment. If you simply have one system and want to migrate it to a new system with minimal downtime, you could implement an HA software solution to replicate all of your data to the new system, audit the data for likeness, and perform a simple controlled switch to that system.
When determining how to begin such a project, start by getting the facts. Being informed and consulting with those who have experience will ensure a quick ROI. Make sure that the initial planning for this project is conducted thoroughly.
Often, when analyzing the results of such a project, the team will concede that some things could have been done differently that would have made the project go smoother. Because the end company performs such migrations so infrequently, get the experience of a team that does these migrations all the time.
Then, choose the approach that will best suit your needs and make it happen. You will likely never migrate a system again without the assistance of a high availability software solution.
Craig S. Hartwig is a Solution Services Practice Manager at Lakeview Technology, Inc. Craig has 18 years experience with the System i platform. A significant portion of that time was spent working for IBM System i high availability Business Partners. Most recently, Craig has developed HA solution services at Lakeview for the SMB space, focusing on managed and migration services.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online