au-aixlpar_migrations-pdf.pdf

8/13/2019 au-aixlpar_migrations-pdf.pdf

1/7

Copyright IBM Corporation 2009 Trademarks

Avoiding the gotchas of AIX LPAR migrations Page 1 of 7

Avoiding the gotchas of AIX LPAR migrations

Christian Pruett

Senior Systems Administrator

16 June 2009

Learn how to identify and get past the common roadblocks that can interfere with migrating

IBM AIX servers to the latest in logical partition (LPAR) technology.

Many times in the computing world, systems that worked well a year ago outgrow their hardware

and suddenly require more resources. Fortunately, with the latest AIX LPAR technology, it

has become much easier to migrate a server from one piece of hardware to another with little

downtime. The virtualization, portability, and manageability that IBM pSeries and System p

hardware offer provide flexibility in systems administration and support. But there can be a few

speed bumps along the way in the process of migrating to an AIX LPAR. This article focuses on

avoiding the common "gotchas" that can spring up and slow down AIX LPAR migrations.

Frequently used acronyms DBA:Database administrator

I/O:Input/output

Gotcha 1: Resource shortfallsThe first and most important thing in moving to a new LPAR is to ensure that sufficient resources

are available. The most common reason for moving is that the resources on the original hardware

are no longer able to support the purpose of the server. Nothing is worse than putting in long hours

only to find that the new hardware lacks power and functionality.

Although the purpose of this article is not to serve as a sizing document for architecting LPARs,

it is critical that the new LPAR have all the necessary features. How many and what kind of

processors will you need? Will the processors be dedicated, or will they come from a shared

pool? Will there be enough memory? What about the I/O adapters? Is it worth setting up a virtual

I/O (VIO) server to manage the resources? Are there any floor, rack space, power, or cooling

restraints?

To answer these and other questions, IBM provides the Systems Workload Estimator (see

Resources). This tool can provide approximate sizing information for the new equipment you'll

need, as well as a general idea of the type of equipment you'll need. You can then combine the

information from the tool with information from third-party vendors to properly determine the

resources needed to meet LPAR requirements.
http://www.ibm.com/developerworks/ibm/trademarks/http://www.ibm.com/legal/copytrade.shtml


2/7

developerWorks ibm.com/developerWorks/


Gotcha 2: Establishing the root volume group

Moving on to the technical side of LPAR migrations, the first thing you must manage is the root

volume group (rootvg). Just as a house needs a firm foundation, the rootvg must be solid for the

migration to be successful. There are three main ways to establish the rootvg, each with its own

pros and cons.

Strategy 1: Fresh operating system installation

Here, the operating system is installed from CD, DVD, or Network Installation Manager (NIM) on

the disks to create the rootvg.

Pros: This installation is the cleanest and most pristine way of loading the operating system.

Over the years, I have seen servers that have migrated through every version and release

of AIX from 4.3.2 to 5.3, and even though the AIX operating system migration process is one

of the most robust upgrade paths around, fragments of software and third-party applications

can sometimes sludge their way through the operating system iterations. These elements canmake the server look unsightly at best or complicated and difficult to upgrade and manage at

worst. But by using base media, the operating system is guaranteed to be just it was when it

rolled off the factory floor.

Cons: Unfortunately, with a completely clean installation, making the new LPAR look like the

old server can be time-consuming. You'll have to re-create user IDs, groups, file systems,

environment variables, and all the features that define the server. If the server is simple, this

may be the way to go. But if the server has a complicated environment with hundreds of

users, it may be more worthwhile to choose another route.

Strategy 2: Physical disk moveHere, you remove the physical disks from the original server, insert them into the new hardware,

and assign them to the LPAR.

Pros: By taking the root disks out of the old server and putting them in the new, you

guarantee that the new server has the same identity as the old server. Just about everything

in the rootvg will be preserved, and you can count on everything being available upon first

boot.

Cons: There are four reasons why this strategy is not the wisest option. First, there is a

chance that you could drop or damage the disks while physically transporting them. Second,

the original server may not have all the device drivers to make the new hardware functional,which will then require hunting down and installing additional software. Third, you will most

likely have to delete or reconfigure devices to make the new LPAR functional (I cover

this in more detail later). Finally, there is a chance that the form factor of the disks will be

incompatible with the new hardware, completely ruling out this option altogether.

Strategy 3: System backup and restore

Here, you back up the original server to an mksysb image, then lay it down onto the new

hardware.


3/7


4/7



numbers, volume group names, health check intervals, and any other tunables. This way, disks

can be identified, configured, and imported with no guesswork.

Third, consider other disk maintenance that you can perform during the migration. Take advantage

of the server being unavailable to change the disk architecture. You can change external volume

groups to big or scalable volume groups. You can replace numerous small disks with a single largelogical unit number (LUN). You can reclaim unwanted file systems or disk space to save resources.

Gotcha 4: Setting up and configuring devices

The last challenges to completing the LPAR migration are to get all the other devices set up

properly. Depending on the strategies you used earlier, management of the devices can be a time-

consuming task or an easy endeavor.

Before moving over to the new server, take the time to get all the configuration parameters from

the existing devices. The lsdev Ccommand will show all the devices that are on the old server;

you can then run the lsattrand lscfgcommands against that output to get all the customized

settings and attributes. Some of these parameters will not necessarily apply equally to the new

LPAR because of the different hardware, but some settings should be carried over, like IP aliases,

memory tunables, and Fibre Channel speeds.

If the root disks are imaged from original media or a NIM installation, you will need to set up and

configure all the devices when the server boots up (except for the network adapter that NIM uses).

This is the most time-intensive course of action for configuring devices and will require the most

attention. And if you used NIM, you may need to change the IP address and/or hostname when

the cutover time occurs.

If the root disks will be physically moved to the new LPAR or if you select the option in NIM to

recreate devices, you will need to sort out a number of old and new devices. For example, if the

original server had one Ethernet adapter (ent0) and the new server has one Ethernet adapter

(ent1), the new server will have one defined adapter (ent0), one available adapter (ent1), and no

active interface with a working IP address. So, you will have to delete both interfaces using the

rmdev dl -Rcommand, re-detect the correct device using cfgmgr, and then set an

IP address. The same process applies to any other adapters and disks that were formerly defined.

I have also found that the one thing that tends to come back and haunt me is device definitions

that do not correlate directly to a physical piece of hardwarein particular, asynchronous I/O

devices (AIO) on database servers. For these devices, first run a mkdevoperation to make thedevice available, then run chdevto set the device to be available upon reboot. Otherwise, there will

be some very agitated DBAs once the new LPAR is active.

Conclusion

In my years of experience, I have performed dozens of successful LPAR migrations. And the one

piece of advice I cannot reiterate enough is this: Plan, plan, and plan some more! Although it may

seem like gathering so much information about the original server is trivial and going over each


5/7

ibm.com/developerWorks/ developerWorks


and every part of the hardware a waste of time, I cannot count the number of times where knowing

something abstract like a PVID, Maximum Transmission Unit (MTU) size, or timeout value came in

handy to save a customer account. There is no worse feeling than flipping the switch and watching

a new LPAR grind to a halt, but by avoiding these common gotchas, you will have the greatest

chance for success in your LPAR migration.


6/7



Resources

Learn

UNIX on Power systems: Learn more about AIX Power systems software.

HMC attached system setup: Learn how to set up your system using the HardwareManagement Console.

AIX wiki: Get the technical information you need from this collaborative site.

AIX and UNIX: Visit the developerWorks AIX and UNIX zone provides a wealth of information

relating to all aspects of AIX systems administration and expanding your UNIX skills.

New to AIX and UNIX? Visit the New to AIX and UNIX page to learn more.

Technology bookstore: Browse for books on this and other technical topics.

Get products and technologies

Systems Workload Estimator: Download the Systems Workload Estimator for use on your

server hardware.

Discuss

developerWorks blogs: Check out developerWorks blogs and get involved in the

developerWorks community.

Participate in the AIX and UNIXforums:

AIX Forum

AIX Forum for developers

Cluster Systems Management

IBM Support Assistant Forum Performance Tools Forum

Virtualization Forum

More AIX and UNIX Forums
http://www.ibm.com/developerworks/forums/dw_auforums.jsphttp://www.ibm.com/developerworks/forums/dw_auforums.jsphttp://www.ibm.com/developerworks/forums/forum.jspa?forumID=748http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=749&cat=72http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=935&cat=72http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=907&cat=72http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=905&cat=72http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=747&cat=72http://www.ibm.com/developerworks/communityhttp://www.ibm.com/developerworks/communityhttp://www.ibm.com/developerworks/forums/dw_auforums.jsphttp://www.ibm.com/developerworks/forums/forum.jspa?forumID=748http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=749&cat=72http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=935&cat=72http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=907&cat=72http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=905&cat=72http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=747&cat=72http://www.ibm.com/developerworks/communityhttp://www.ibm.com/developerworks/blogs/http://www-912.ibm.com/estimator/index.htmlhttp://www.ibm.com/developerworks/apps/SendTo?bookstore=safarihttp://www.ibm.com/developerworks/aix/newto/http://www.ibm.com/developerworks/aix/http://www.ibm.com/developerworks/wikis/display/WikiPtype/Homehttp://www.ibm.com/developerworks/wikis/display/WikiPtype/HMC+attached+System+Setuphttp://www-03.ibm.com/systems/power/software/aix/index.html


7/7

ibm.com/developerWorks/ developerWorks


About the author

Christian Pruett

Christian Pruett is a senior UNIX systems administrator with more than 14 years of

experience with AIX, Sun Solaris, Linux, and HP/UX in a wide variety of industries,

including computing, agriculture, and telecommunications. He is the co-author of two

IBM Redbooks on AIX, has served as a UNIX book review for OReilly Publishing,

and has worked on several of the IBM AIX certification exams. He resides in Colorado

with his wife and two children. You can reach Christian at [email protected].

Copyright IBM Corporation 2009

(www.ibm.com/legal/copytrade.shtml)

Trademarks

(www.ibm.com/developerworks/ibm/trademarks/)
http://www.ibm.com/developerworks/ibm/trademarks/http://www.ibm.com/legal/copytrade.shtmlmailto:[email protected]

au-aixlpar_migrations-pdf.pdf

Documents

Transcript of au-aixlpar_migrations-pdf.pdf