The first task was discussing the new server consolidation direction with users to obtain their buy-in and support.

“Those of us on the business side had to be convinced that virtualization was going to benefit us,” says Bill Hindman, Programs Division IS administrator for the OKDHS Children and Family Services Division. “Previously, end business users had their own dedicated boxes for processing information and reports. Suddenly, we were being told these servers were being eliminated and that our applications were being moved to the mainframe. We also heard we would now be ‘sharing’ computer resources with other parts of the agency.”

The announcement of the consolidation strategy was initially met with understandable trepidation from users. “We wanted to be sure our needs would continue to be met with the new mainframe strategy, and that the resources would be there,” says Hindman.

OKDHS IT also had its share of challenges and fears.

IT wanted to replace an older reporting system and database residing on HP-UX with new reporting tools and data that resided in the Linux on System z environment.

“When we made the decision to port the KIDS system to the System z, we developed an architectural approach that took advantage of placing Web-facing report design tools on Windows servers and migrating all of the actual report processing to Linux on System z,” says Little. “We knew this new solution would produce greater turnaround on reporting for the division’s end users, and provide greater and less complicated access to data repositories that already were on the mainframe.”

As an early entrant into server consolidation, however, OKDHS IT had no way of absolutely knowing whether a complete toolset for the planned migration existed at every level of IT infrastructure.

“Not everything was in place for z/VM and Linux when we began our project three or four years ago,” says Little. “We worked closely with IBM since we knew that a number of elements of the environment weren’t yet fully mature. This was one reason why the migration project took as long as it did. … We carefully proceeded, beginning with a migration of smaller databases to the System z that weren’t mission-critical. A total of 10 people were assigned to this project, but none of them was a dedicated resource, as we were all splitting time between working on the migration and working on projects in our actual production environment.”

The migration project team held weekly conference meetings. They opted to use Tivoli Storage Manager as an integral part of their data backup solution, but they also recognized they were “leading edge,” since there were no other clients available to exchange ideas with when they first started the migration with this backup strategy.

“We encountered several obstacles,” says Little, “One of these involved the backup environment. We were using the RMAN interface for backup and recovery of our Oracle database and eventually we used Tivoli Storage Manager. Unfortunately, we found that some infrastructure tools were missing. Our distribution of SUSE Linux had supportive tools in place but we had a version of GCC [GNU Compiler Collection] that had to be built from scratch for Oracle.”

5 Pages