- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: SAN migration on Service guard
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2012 02:12 AM
10-16-2012 02:12 AM
Guys,
While migrating the SAN on service guard environment....its just a vgexport & vgimport will be enough?
Anything else to be done apart?
I request to provide the step by step procedure and i hope that will give a clear picture.
Thanks & Regards,
Karthik Balu.
Solved! Go to Solution.
- Tags:
- vgexport
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2012 06:12 AM
10-16-2012 06:12 AM
Re: SAN migration on Service guard
Hi,
In most cases, I would say yes, you are right.
I assume that your new disks (raw devices, not filesystem level) already hold a copy of the old ones.
You should use the -s and -m option for vgesport and vgimport and work with the created mapfile. Use the -p (preview) option for this export. If that works fine, realy export the
If you stay on the same server and want to keep the VGname, you have to get rid of the old disks/LUNs bevore importing the new VG.
You should be sure, that your disks or LUNs are presented to the new server and will be unpresented from the old server AFTER all is fine AND AFTER removing any no longer needed devicefiles from the old server.
An alternative way would be to add one set of the new LUNs (assuming you have two sets and want to be mirrored) as 2nd mirror to your VG.
Than remove the original disks that come from the same datacenter as your new disks.
Than add the new disks from the 2nd datacenter (if you want to be mirrored)
and remove the original disks from the 2nd datacenter.
This works without vgimport / vgexport. But you should have PVGs configured.
All this would work on a productive system without downtime and with little effect to the responsetime of the disks. But better us a time with low traffic on the disks and be prepared to wait for about 15 to 60 minutes for each TB.
All depends on what you are realy want to do and what your environment looks like.
Bye
Ralf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2012 09:33 AM
10-16-2012 09:33 AM
Re: SAN migration on Service guard
>>While migrating the SAN on service guard environment
What exactly do you mean by this? Are you moving to a new SAN? More details will allow us to give you better information.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2012 08:59 PM
10-16-2012 08:59 PM
Re: SAN migration on Service guard
Yes Patrick....we are going to remove the old san(EMC Cx3) luns and present the new(VNX5500) luns.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-24-2012 01:54 PM - edited 10-24-2012 02:09 PM
10-24-2012 01:54 PM - edited 10-24-2012 02:09 PM
SolutionThe least interruptive method to migrate to a new array is to
1) add LUNs from the new array into the active package VG.
2) mirror volumes in the VG to the new array LUNs
3) lvreduce the old LUNs (1st copy) out of the volume(s)
4) vgreduce the old array LUNs out of the VG.
5) Update the /etc/lvmtab on the other node(s)
Example steps: (where c6t3d0 is a new array LUN)
Node1: pvcreate /dev/rdsk/c6t3d0 # prep new LUN for use with LVM
Node1: vgextend /dev/vg01 /dev/dsk/c6t3d0
Node1: ioscan -fnCdisk # identify the old array LUN device special files (DSFs), and new array DSFs
Node1: vgdisplay -v /dev/vg01 # identify the disks used by the VG
Node1: lvdisplay -v /dev/vg01/lvol1 # identify the logical volumes on each disk
Node1: lvextend -m 1 /dev/vg01/lvol1 /dev/dsk/c6t3d0 # create a mirror of lvol1 (on c2t0d0) onto c6t3d0
Node1: lvdisplay -v /dev/vg01/lvol1 # confirm all extents are mirrored to c6t3d0
Node1: lvreduce -m 0 /dev/vg01/lvol1 /dev/dsk/c2t0d0 # remove the 1st copy of lvol1 data from the old LUN
Node1: lvdisplay -v /dev/vg01/lvol1 # confirm all extents in the lvol are only on c6t3d0
Node1: vgreduce /dev/vg01 /dev/dsk/c2t0d0
Node1: vgexport -pvs -m /etc/lvmconf/vg01.map /dev/vg01 # create an LVM map file
Node1: scp /etc/lvmconf/vg01.map root@Node2:/etc/lvmconf/ # copy the file to the other node
Node2: ll /dev/*/group # record the minor number of vg01 (eg. 0x010000)
Node2: vgexport vg01 # remove it from /etc/lvmtab
Node2: mkdir /dev/vg01 ; mknod /dev/vg01/group c 64 0x010000 # use previous group minor number # use correct major and minor number
Node2: vgimport -vs -m /etc/lvmconf/vg01.map /dev/vg01
NOTE: Test these instructions on a dummy VG * lvol and modify to suit before implementing on real data volumes.
The cluster ASCII configuration file does not have to be modified unless the cluster uses a cluster lock disk and it is moving to the new array. In this case, update the FIRST_CLUSTER_LOCK_PV reference for each node, and cmapplyconf the file to install a cluster lock structure on the new array LUN/VG.
This method allows the VG to remove active, and it's file systems mounted and usable throughout the procedure.