Your plan looks good ,just added few things for your reference and for 3rd option

you can do it through online if storage team can take it .I believe there is a
option of online flash copy ,but we need to make sure no db ,apps running on the
cluster .

Third Option
Take the down time and bring down the server
Let storage team perform the data copy from DS8100 to DS8886 and map the luns
Bring up the servers with the new storage Luns

Few things to check and plan in details .

Check the sddpcm version of running os -Do check the support matrix for device
driver compatability .if required need to uninstall the existing device drivers and
install the update one.
HBA running firmware version microdecode level with new storage version

Prework :

#Check and take latest mksysb and verify its working .

#Make a note of all the disk PVIDs for reference (lspv,lsvg -o, lsvg -l
<vgname>)

#Take a cluster snapshot backup for safe side

smit hacmp > HACMP Extended Configuration > Snapshot Configuration >
Create a Cluster Snapshot of the Cluster Configuration

# Make a note of all the disk PVIDs for reference (lspv,lsvg -o, lsvg -l
<vgname>)

#Make sure all the new disks should have reserve policy as ""no_reserve""

=======================

Outline of migration:

1. Ask SAN team to present equal size(old disk) of new disk to both the
HACMP nodes
2. Make sure all the disks should have reserve policy as ""no_reserve"" ,do check
the disk list in both nodes before proceeding .Verify the pvids in both nodes .To
make uniform do additional step rename the disk with common standard for new
storage disks for easy identify for future reference .
3. Discover the new disk in to HACMP cluster
4.To replace the new disk under CAA -via smitty hacmp -> Problem Determination
Tools -> Select a new Cluster repository disk.
clmgr modify cluster ha71 REPOSITORY=hdiskX
4a .verify the CAA disk migrated to new one .
clmgr query cluster

REPOSITORIES="hdiskX"

REPOSITORY_PVIDS="OOOXXXXXX-NEW DISK PVID"

5. Mirror the sharedVG with the new disks

smitty cspoc -> Storage > Volume Groups > Mirror a Shared Volume
Group(Important: both the disk will show same PVID so select using the
diskname)
6. Once the mirror is completed, unmirror the old disk using cspoc menu
smitty cspoc -> Storage > Volume Groups > UnMirror a Shared Volume Group
(Important: take extra care on selecting the old disk)
7. Remove the old disks from the odm once the unmirror is completed

rmdev -dl <old disk name>

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$

Storage task:
Storage team assigning the lun

AIX Tasks

migration using - migratepv -l

Assigning the LUN from new storage to aix host

Discovering the New target LUNS
Verify new lun and determine the differences between new lUNS & old LUNS
Identifying the sizes of the new lUNS
Assigning the NEW LUNS to the identified VG where we are going to migrate
Verifying that new LUNS are into the VG's
Identifying the LV's -VGs to be migrated
Migrate the PV from old to new PV's
Verifying LUNS are migrated .
Removing the old LUNS from the VGS
Deleting the device definitions from the host ODM
Verifying that the device definitions are removed

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$

migration using mklvcopy & syncvg

Assigning the LUN from new storage to aix host

Discovering the New target LUNS
Verify new lun and determine the differences between new lUNS & old LUNS
Identifying the sizes of the new lUNS
Assigning the NEW LUNS to the identified VG where we are going to migrate
Verifying that new LUNS are into the VG's
Identifying the LV's -VGs to be copied
reserve free space for an even spread of data.
Copying lv data from source (old) lUNS to target (new)LUNs
Verifying that copies are correct .
Sync the copies
Check for stale partions
Verify lv copies
Verifying LUNS are migrated .
Removing the old LUNS (source) from the VGS
Deleting the device definitions from the host ODM
Verifying that the device definitions are removed

Storage Tasks
Removing the source zone definition
Unassign the source LUNS from the host server

cluster commands :

To replace the CAA disk

smitty hacmp -> Problem Determination Tools -> Select a new Cluster repository
disk.

clmgr modify cluster ha71 REPOSITORY=hdisk51

to verify :

clmgr query cluster

Exteding under cluster
smitty cl_extendvg
smitty cl_mirrorvg
smitty cl_syncvg_lv

to remove lvcopies
smitty cl_unmirrorvg
smitty cl_reducevg
lsvg -p vgname

=====

Thanks
RAJARAJAN M

From: Rajarajan M (CIS)

Sent: 07 January 2019 17:52
To: Sanuja Velayudhan (CIS) <sanuja.velayudhan@wipro.com>; Sinu Thorayintavida
(CIS) <sinu.thorayintavida@wipro.com>
Cc: Shajin P C (CIS) <shajin.c88@wipro.com>; Gowri Sankar Balakrishnan (CIS)
<gowrisankar.balakrishnan@wipro.com>; Rajasekar Jayaraj (CIS)
<rajasekar.jayaraj@wipro.com>
Subject: RE: RSA - Storage Migration

Hello Sanuja ,

Greetings !!!

Thanks for your wishes .Wish you happy new year ?

As a first phase have a look on the below .Do it one test server first ,observe for
a week and then go for non prd and prod servers .

Need to check how much duration its taking for data migration for 100GB between two
storage .data migration as well as flash copy (storage level migration ) It will
helpus to calculate and schedule the change window for each migration change .
What is the vio level ? and how many vscsi adapters already created and mapped
across the lpars ?
Do have a look on this perspective do we have enough buffer to allocate and utilise
.

As a pre work do include in the plan though its pre work .

Check the HBA compatibility between vios and Storage end for 8886 storage .

1.Do check & take latest mksysb and do verify its taken completely .
2.Make note all the PVIDs for reference (lspv,lsvg -o, lsvg -l
<vgname>)
3.Take system snap shot �all config details .
Cluster snapshot taken prior to the change .
4.Once the CAA disks replaced ,make sure next step we do have for verify the CAA
disk migrated .

clmgr query cluster

Thanks
RAJARAJAN M

Sensitivity: Internal & Restricted

From: Sanuja Velayudhan (CIS) <sanuja.velayudhan@wipro.com>
Sent: 07 January 2019 16:57
To: Rajarajan M (CIS) <rajarajan.m58@wipro.com>; Sinu Thorayintavida (CIS)
<sinu.thorayintavida@wipro.com>
Cc: Shajin P C (CIS) <shajin.c88@wipro.com>; Gowri Sankar Balakrishnan (CIS)
<gowrisankar.balakrishnan@wipro.com>
Subject: RSA - Storage Migration

Hi Rajarajan,

Wish you all a very happy new year 2019 !!!

We are having few servers using LUNS from DS8100 storage . Storage team is planning
to migrate LUNS from DS8100 to DS8886.

There are few cluster hosts and non-cluster hosts running in the machines. VSCSI
mappings on the lpars.

The below two options are under consideration and we need your suggestions to
migrate the HB and cluster repository disks so that there should me business impact
�

Lpar Version : 6.1 TL 9

Cluster VERSION="7.1.3.3"

Option 1 : for CAA

To be done while cluster services are running and resource groups are online using
the below method�

smitty hacmp -> Problem Determination Tools -> Select a new Cluster repository
disk.
Verify and synchronize the cluster configuration
For HB lun
1. Present new HB LUNs to both nodes.
2. smitty hacmp --> ..... --> Remove Communication Interfaces/Devices
3. Removed the old HB disk from both nodes
4. smitty hacmp --> ..... --> Add Pre-defined Communication Interfaces and Devices
5. Added the new HB disk to both nodes
6. smitty hacmp --> ..... --> Verify and Synchronize HACMP Configuration

Second Option
Take the down time of the application
Perform the above set of operation

Third Option
Take the down time and bring down the server
Let storage team perform the data copy from DS8100 to DS8886 and map the luns
Bring up the servers with the new storage Luns

Regards
Sanuja V

Sensitivity: Internal & Restricted