Just 10 years ago, a data center move involved a van and a long weekend for technical support staff. Now, with cheaper hardware and smarter storage, the process of moving a data center is fast and clean.
Developing a strategy
Ultimately, your data center relocation strategy should depend on scope and the target data center site. A “ready” data center can encompass anything from a grassy field to a running operation. Having scope is important -- moving a couple of CICS regions and some batch jobs is much easier than porting everything from the operating system up.
The tried-and-true truck access method -- put your data in a truck and drive it to the remote site -- is now too slow. A shop may pursue storage-based solutions such as EMC Corp.’s Symmetrix Remote Data Facility (SRDF) and IBM’s Peer-to-Peer Remote Copy (PPRC), which both support asynchronous disk replication over long distances. With these tools, direct access storage device (DASD) replication may begin when the alternate data center site is up.
Storage tape is a special medium that has several solutions. Shops that use tape on disk solutions, such as EMC’s Disk Library for mainframe (DLm), can replicate faux tape volumes and the DASD to the target site. Real tapes must be physically carried to the new data center. For this medium, timing is important. Archive tapes can go to the new center immediately. The tapes needed for tomorrow’s batch should be shipped on the conversion weekend. Some companies may forgo physically moving tapes altogether by installing drives at the remote site and using channel extenders to write from the primary data center.
Even in the 21st century, physical media, including print, punch cards and fiche, must be considered. A careful inventory decides what needs to go and when. A lucky enterprise may even run into some reports or cards that aren’t needed.
Planning the data center move
At the beginning of a data center move, the enterprise should build a move team that includes several technicians and business people. Technicians can operate the computer equipment, and business folks understand the enterprise’s rules and requirements. A project manager and a planner should lead the move team to ensure that actions are carried out in proper sequence.
Building a data center from scratch involves acquiring and installing lots of hardware. In addition, because some replication strategies require active mainframe systems at the target site, IBM, for example, can help create a starter mainframe system to act as a bootstrap for a full Sysplex during the move.
Decisions must be made about the current data center. The replication strategy and the amount of data determine the network bandwidth needed. If the company can’t afford to replicate all of the DASD, someone must decide which volumes can be copied and restored at appropriate intervals. Physical tape policy becomes important to ensure the volumes are where they’re supposed to be before and after the transition. Without careful planning, the first job in the new data center may require a tape that is stored away at the old site.
The trickiest piece of planning the data center move is timing. Switching to the new site must be done at a quiet time so that customers barely notice effects, ideally at the beginning or end of batch, or when jobs can pause for a few hours. After picking a switch time, the entire move team must convene to build a detailed timeline of individual events and how long they’ll take.
Of course, any good implementation plan also includes a back-out strategy, which can be tricky considering that falling back to the old data center becomes almost impossible once the first update transaction runs. Therefore, the best back-out plan has an excellent implementation script and all hands on deck to fix problems after the transition.
Executing the data center move
Another great advantage of modern hardware is the ability to do dress rehearsals. The move schedule should include several tests to execute and vet the plan for accuracy. The test scripts will differ a little from the execution plan because the current data center must remain operative while the target site is carefully isolated from production data, the network and the users.
Every test should begin at the designated quiet point, where a systems programmer breaks the replication between the current and target data centers. At the target site, someone else should vary the replicated volumes online and bring up the system. In a perfect world, the target system would stay up long enough to also allow for extensive batch testing.
Someone else should be present when testing to note the success or failure of any given step and how long each step takes. After each test, the move team should use lessons learned to rewrite and refine the script. Ideally, after two or three tests, things should be in good shape.
On the golden day, things may go smoothly, but expect the unexpected. Unfortunately, the true success of the data center move won’t be apparent until CICS or IMS have been up for a few days and after batch runs. Therefore, the move team must remain vigilant for at least a few weeks. After that, it’s time for a long vacation.
ABOUT THE AUTHOR: For over 25 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.