- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- RE: SAN migration question
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
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
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
тАО05-24-2011 07:34 AM
тАО05-24-2011 07:34 AM
We are migrating to a new SAN the vendor will be carrying out a disk copy at the array level for us. I have been reading a number of old threads which seem to suggest you have to vgexport the old VG's and therefore remove device files. In honesty I don't understand why that is the case. The disk headers will be identical so surely when it scans the disk on reboot the new volumes will simply be imported. I will do a -p to take a copy of the files without actually exporting for a backup but do I really need to remove them.
The intention is to shut down the hosts do a cold copy at the array level and then zone in the servers to the new array and reboot. Sounds far too easy and sure your going to tell me that it is not!!!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-24-2011 07:41 AM
тАО05-24-2011 07:41 AM
Re: RE: SAN migration question
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-24-2011 07:44 AM
тАО05-24-2011 07:44 AM
SolutionNOTE LVM VG and PV are all at logical volume manager (LVM) level references below
You have LVMs living on VGs
You have VGs living on PVs
You have PVs living on physical spindles
Your spindles are on a SAN array
You move exchange your SAN frame
Your spindles changed.
Your LVM PVs know your old spindles and how to talk to those. Unfortunately at this point, the game has changed. Your server LVM needs to be reacquainted with the spindles, even if the LVM headers are the same, it still needs to learn how to talk to the hardware for the lack of better terminology.
This is where vgexporting (with map files) from old volumes and vgimporting once you are on the new volumes come into action. My terms may not be accurate but short of a miracle, I don't think you can just bitcopy the data from a SAN fram to a different manufacturer SAN and be able to read it without any additional efforts.
UNIX because I majored in cryptology...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-24-2011 09:33 AM
тАО05-24-2011 09:33 AM
Re: RE: SAN migration question
> Sounds far too easy and sure your going to tell me that it is not!!!
Well adam, if you want to migrate one set of disks to another set of disks with LVM v2.x it's way more easier than this . There is a very nice command called as vgmove which allows you to do this making migration much more simpler which could be one of the reasons to go LVM v2. Well whatever you have mentioned in the post looks like standard procedure at the O.S level as far as LVM is concerned.
You need to present what is called as a diskmap file which is textbook documentation naming which would allow you to specify the set of disks that you want to migrate in terms of device files.
And what is way cooler is that you tend to keep the high availability aspect as this requires absolutely no_downtime.
Regards
Ismail Azad
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-24-2011 11:14 AM
тАО05-24-2011 11:14 AM
Re: RE: SAN migration question
The -s flag will scan the header of the disks and put the VGID in beginning of the map file.
The vgimport will then use the vgid to import the proper disks into the vg.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-24-2011 02:31 PM
тАО05-24-2011 02:31 PM
Re: RE: SAN migration question
I vote vgexport/vgimport ( with detailed mapping ).
However, you are still going to have to figure a way to verify all those LVM objects and their contents after the migration to the new SAN is complete.
My concern would be that some time after your migration, your applications stumble upon some bit of corruption on disk ( logical corruption resulting from the SAN to SAN level copy ) and fail. At this point, even your backups could be corrupted, depending on the amount of time that has passed, which could leave you in a really bad spot.
Spend some time planning out your post migration activities and decide just how thorough you want to be.
Hth,
-klb
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-25-2011 12:18 AM
тАО05-25-2011 12:18 AM
Re: RE: SAN migration question
We have done san migration in cluster environment plz find the procedure attached which we have followed