Migrate AIX to new Hardware

Hello Friends/AIXgurus,

When you have time, could you please look into below. We're planning to migrate AIX LPARs on to new Hardware.

Requirement: Migrate AIX LPARs from POWER 6 to POWER 8 Hardware (*everything should run as is after the transition)

Below is our thought process. Ours is a small environment, we do not have VIO/LPM (NIM as of now).

for testing/understanding purpose; We've 2 test LPARs (AIX001, AIX002)
AIX001 ==> Database LPAR
AIX002 ==> Application LPAR

AIX001 (aix001.domain.net ; 10.1.2.3)
rootvg
data1vg
data2vg
data3vg
data4vg
data5vg

AIX002 (aix002.domain.net ; 10.1.2.4)
rootvg
app1vg

Pre-checks
1) AIX (7.1) version must be supported on new Hardware (if not, upgrade/migrate to hardware supported OS level on existing hardware/LPAR)
2) Make sure application/middleware/database software must be compatible with AIX version and new hardware

Backups
1) Stop all the running applications and databases on test/lab AIX servers.
2) Backup OS(rootvg) on 2 test AIX LPARs (1 database, 1 app) using "mksysb" command
3) Backup all non-rootvg (datavg's and appvg)using "savevg" command
4) Backup profile data using HMC
5) Backup important config file/information from both LPARs (/etc/filesystems, lspv, crontab, lscfg etc...)
6) DBA will capture Database level backups using Database utilities (* just in case)
7) move mksysb, savevg, database backup files on to a remote server.

*bring down 2 LPARs

We will follow proper procedure to backup rootvg/OS (using mksysb) and non-rootvg vg's (using savevg).
Example: rootvg filesystems must be mounted and non-rootvg vg's must be varied on and fs mounted during backup operation.

Restore/setup of new AIX LPARs on new Hardware
1) Once everything is setup from network side, using HMC will either create brand new LPAR profiles or will use the old LPAR profiles (if possible)
2) Planning to use same hostname/IP address
3) will boot in to SMS mode, will look for attached disk (of same size/bigger) ; then
4) using optical DVD/CD, will install the bootable mksysb in new LPARs (*have done in the past)
5) reboot the servers after setting up IP/hostname/network etc

6) allocate/assign same number of disks (same/big in size) to respective LPARs
7) then transfer the save vg files on to respective lpars
8) Restore each non-rootvg volume group using savevg backup file on LPARs one by one (*will follow the sequence as mentioned in the /etc/filesystems)
9) will do all basic checks

Please correct me If our thought process is not correct at any stage. Please see the questions we've.

Question 1) I am pretty sure that, my OS will work as is on new Hardware (*because of mksysb).

How about "savevg" restores ? Will it restore as is on new hardware/LPAR without any changes?
I believe that, Everything will work as is (including port numbers etc).

Please correct me if am wrong.

Question 2) Or Instead of savevg/restore approach, Is it recommended to

a) re-install OS using old servers mksysb
b) Re-install Application/middleware software (* made appropriate config changes/SSL etc)
c) Re-install Database software (* restore databases using old server DB backups)

Please provide your suggestions. I know its time consuming. But If the "savevg/restore works as is, am sure will avoid this option".

Question 3) What if my existing LPARs (on POWER 6 H/W) must be up and running when we have to bring up 2 new LPARs on new POWER 8 H/W ?

a) Do we need to have new IP address and Hostnames ? (temporary)
b) will the application/databases work with this approach ?

Could you please let me know, if assigning new IP/hostname recommended ?

Please feel free to provide your comments/suggestions, if you've any recommendations for doing this actvity using mksysb and savevg tools.

thank you.

Q3:
a) Yes
b) we know nothing about your Database, and even less about your network, but lets say you have Oracle: there is something called "listener" which cares about instances and should know were they run... so same instances running with 2 different IP hummmm...

What surprises me is we know nothing about your storage... and Q: is your rootvg mirrored?

@vbe

Thanks for the reply. Sorry I should have provided the information.

OS: AIX 7.1 TL 04 SP 06
Middleware: WAS 8.x

Database: DB2 11.x

we use only 1 IP per LPAR. We do not have Mirrored vg as of now.
But, We usually add a (on demand) new disk (alt_disk_copy/clone) during OS upgrades.

Thank you.

Yes, that will work but i still suggest that you install the OS from scratch. First, you should have a "how to build server X"-part in your documentation (if not: high time to create it). It is a good test for this procedure to actually carry it out and find out if it works to expectations - that is, ends with a satisfactorily running system.

Second, over time servers tend to accumulate settings/other customisation which is not documented and/or not necessary. If it is only not necessary this is a good way to get rid of it, because a server should always only contain the absolute minimum of necessary software. If it is undocumented but necessary (even more dangerous) then this is the time to find out.

Third, i have noticed that you have several datavg s in your DB server. What are they necessary for? It might be a good opportunity to make that on VG becauase it is one application anyway. If you don't have it by now you should also create scalable VGs instead of classical or big ones. See the man page for mkvg for this. This also answers Q2.

A new IP should pose no problem because everything should be done using DNS-names. If this is not the case you have some problems in your network organisation, but that only as an aside.

If you want to run the old and new servers in parallel you can do several things:

1) a new (temporary) IP address and name. This means you have a procedure in place to adjust your application quickly and reliably to the new hostname for the switch. The best solution is to create a script that replaces one hostname with the other and does all things necessary for this adjustment. At the given time you just let this script run so there cannot be an oversight of some necessary detail.

2) you can create a non-routed network and run the new systems with their original IPs/names there. You will need a NAT-gateway in front to access this network, which is a bit troublesome but for temporary testing purposes should be feasible. Ask you network admins if they can do that.

I hope this helps.

bakunin

1 Like

@bakunin
Thanks much for your help.

We're planning to install OS on new LPARs using (existing servers bootable mksysb image). I will suggest my team/manager to consider installing from Scratch as well. Since we have multiple servers (nonprod and prod), I believe they ask us to go with mksysb approach.

Yes, as mentioned above we do have several VG's for database related filesystems. Unfortunately 1 VG (Big) per disk was created long back by some admin.

After installing OS, will restore these datavg's and appvg on respective servers (original existing LPARs will be offline during this time).

After save vg restore on new Database LPAR, Do you recommend us to merge datavg's into one scalable vg (using lvm commands) ?

I mean moving lv's into 1 VG (multiple pv's).

Thanks for your time.

You cannot "move LVs across VGs", at least not with LVM commands. My suggestion is: do a file-based backup, not a savevg . Then create the new scalable VG on the new system, create LVs (and of course FSes) as needed and restore to these LVs/FSes. This is a simple and straightforward approach.

I hope this helps.

bakunin

1 Like