Same Server New SAN

[chmc]

We are moving our data center.
I am keeping my server but loosing the SAN that it is currrently attached to and will have to reattach to a new one. I have a rp3440 with HP-UX 11.11 loaded. The OS is on vg00 and my Oracle database is stored on the SAN EVA5000. Once I get connected to the new SAN I will want everything to be setup the same as it was (vg's ect.)
I have not done this before so I am looking for some help in getting started. I have used Ignite in the past for a server build but since I am keeping the server I will have vg00 still intact.
I know how to create luns,vg's but I do not have any experience with a move and am struggling with the overall approach. Any help is appreciated.

[Mel Burslan]

If your new data center has the same exact type of SAN storage and you will have control over how and where the new LUNs are going to be created, you have very little to worry about. Just make sure you have the LUNs setup to the same size as they were before and make sure the zoning on FC interfaces are done correctly. You should see the LUNs once you bring up the system connected to the SAN. In some bizzare cases, I have seen the change in the device file on the last digit, due to the LUN presentation but since I am not a SAN expert, I am not sure what is causing this but a quick call to the SAN admins fixed my problem. Since you will be the SAN admin as far as I can tell, this should not be an issue.

Make sure you have a good backup or two, or three of your database contents. Also, make sure the data center is retaining your data on SAN, until you give them the go ahead and delete permission, once you are perfectly operational in your new place.

I can not think of any other gotchas for the time being.

Good luck...

[Ivan Krastev]

Hello,

You can do the following, described in this previous thread :

1. create and present same LUNs from second SAN to server
2. extend VG over new disks
3. make a mirror of every logical volume over new disks (from SAN2) with lvextend
4. reduce mirror from old SAN disks.
5. remove old disks from VG.

And of cource first create backups - Ignite and so on ...

All this can be done without any downtime with MirrorDisk/UX and OnlineJFS.

regards,
ivan

[Ivan Krastev]

And thread link - http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1242251

regards,
ivan

[chmc]

A couple of notes/clarification-

I will be moving my server to a new data center and will have no connection to the old SAN.
I do not have online JFS. We do have scheduled downtime for this since we are moving the server and attaching it to a new SAN.

[Tim Nelson]

As you are loosing your old storage it would seem much simpler to just document what you have for vg config and re-create it when you are attached to the new san.

You are obviously not trying to save any data so why work so hard on hours of config exporting / importing when it would only take minutes just recreating the config from scratch ?

Exporting the vg config is a waste as there is no data or structure on the new san and you will spend more time deleting old configs and creating new ones.

This is just like DR, great to have the vgnames but all lvols will need to be recreated and newfs on all.

Document your config and manually recreate it.

[Michael Steele_2]

Hi chmc:

What is the make and model of the disk array? And most importantly, what is the disk emmulation. If OPEN-V, like in an XP 12000, you have a choice of lun sizes. They're user definable. But others, like OPEN-E, you have no choice. The size is fixed. In this 'ioscan' example you'll see OPEN-E emulation.

dev1:/home/hp>>ioscan -fnC disk
Class I H/W Path Driver S/W State H/W Type Description
==================================================================
========

/dev/dsk/c3t2d0 /dev/rdsk/c3t2d0
disk 3 0/4/0/0.8.0.2.0.0.0 sdisk CLAIMED DEVICE HP OPEN-E
/dev/dsk/c4t0d0 /dev/rdsk/c4t0d0
disk 4 0/4/0/0.8.0.2.0.0.1 sdisk CLAIMED DEVICE HP OPEN-E
/dev/dsk/c4t0d1 /dev/rdsk/c4t0d1

The point I'm trying to make here is that newer disk arrays have SCSI emulations of larger sizes. And therefore you'll need a new volume group. This is because the old volume group is limited to the size of the old disks. Refer to PE_SIZE and MAX_PE in the vgcreate command. And if you're using bigger disks then you can't vgextend them into the old vg. You have to make a new one.

I've done several disk migrations. I've never vgextended the new disks into the old vg. I've always created a new vg.

[OFC_EDM]

chmc,

How much data is there?

Would you have enough local disk to temporarily move your SAN stored data (via mirroring) onto local disk?

If not, maybe your vendor will lend you some drives for the duration of the move? If you ask nicely sometimes they'll accomodate... especially if you've just bought a bunch of stuff from them.

Then when connected to new SAN and new storage you can mirror it over to the new disk from the local disk. Then break the mirror and remove the local disk from the VG.

And I suggest you keep the LUNs on your old storage around until your move is complete by just unpresenting the LUNs from the host and not deleting them until the move is completed and your data is seen on the new setup. Then you have a possible fall back position.

Cheers

[chmc]

Thank you for the replies.

It looks to me like the approach is to just rebuild the vg's etc. and then restore the data. Question- should I remove the old ones before I power down the server and move it? Any issues with old vg's being in there when I atttach to the new SAN?
I see one recommendation is to unpresent the luns on the old SAN. I can do that.
A couple of answers to questions:
The old SAN is a EVA5000 I am not sure the exact model of the new one but it is a higher class of SAN- XP.
I was planning on restoring the data from tape but I do have a slot for a internal drive not being used. Data size it about 150GB

[Tim Nelson]

I would cleanup the old vgs with vgexport before attaching to the new storage.

The info needed is not really hard to aquire and if you have 50 or 100s of vgs/lvols then I would script the re-creation from a simple input file that contains the config needed.

Then save this script and use it for DR because it would be the exact same thing needed.

Best of luck.

[Michael Steele_2]

Hi chmc:

When you migrate to a new disk array you do so by first making the new disk array luns exported to the server.

You do this by freeing up one HBA. All the luns associated to this HBA are first reduced out of the volume groups BUT NOT from ioscan and /dev. Keep them around until its time to clean up.

Now you have a free HBA. Attach it to the new disk array and present the new luns to ioscan.

Build a new vg with this new luns.

Create temporary mount points and mount the new vg to the temp mount point.

Copy all of the data from the file systems in the old vg into the temp mount point.

Verify your data. Umount the file systems. And remount them with the new vg / lvols into the STANDARD mount point.

Update /etc/fstab.

Agree to a point of no return date with mgmt. because you can still rollback off of the new disk array at this point.

When you get a green light free up the primary HBA, attach it to the new, present the new ALTERNATES to ioscan and vgextend them into the new vg.

Clean up.

[chmc]

I actually have to move the server to a data center that is 100+ miles away. I will be leaving the old SAN and taking only the server to the new data center to attach.

[chmc]

I actually have to move the server to a exsisting data center that is 100+ miles away. I will be leaving the old SAN and taking only the server to attach to the SAN at the other data center.

[Michael Steele_2]

OK, so, you'll be migrating data from the old disk array to the new disk array by, how? Tape?

[chmc]

Yes, tape is the current plan. I also have one internal drive slot that is empty. I am going to see about getting that as well.

[Michael Steele_2]

Then its just a straight first time hook up. Attach both HBAs to the new disk array, viewable by ioscan. Verify sizes of luns. This seems to be where you are stuck. If you refer to my above response about make and model of disk array, scsi disk emulation type, you'll see that this is something that you may not be able to modify.

What is the disk array?

What is the SCSI disk emulation?

I don't see how you're going to do this from tape unless you have mounted file systems. And you can't have mount file systems until you're luns are viewable in ioscan and you have new vg's created.

In this situation it makes no difference what the old disk luns size are. Because they won't exist. YOU SHOULD REMOVE ALL OF THESE OLD LUNS WHILE STILL ATTACHED TO THE OLD DISK ARRAY. REMOVE ALL OF THE OLD VG'S. You'll be starting fresh BASED UPON THE MOUNT POINTS IN /ETC/FSTAB.

'lvdisplay' every lvol listed in /etc/fstab. Get all the information you can, especially size and special arguements like bad block relocation, etc. Refer to the man page for 'lvdisplay' and 'pvdisplay' and review every arguement and determine if you're using any.

The vgcreate stuff should be straight enough. Focus on the lvol data.

[chmc]

Yes- this will be fresh hook up. The SAN is a HP XP I don't know the exact model. My counterpart at the new location will hook up the server-dual HBA's. We will then build the luns with veritas. I can select the exact size that I want- I am going to just match what I currently have because they are sized appropriately.
I will then build out the vg's and lvols so that I can restore from tape. Where I was really stuck is concerning the clean up I should do before I power down the server. I have only a a handful of vg's and lvols...I just wasn't sure if I needed to remove them before I power down- sounds like I do from your post. And I will be naming them the same as they were before so getting rid of them seems like the appropriate thing to do but wanted to get some feedback if I was going down the right path.

Thanks for the help.

[Michael Steele_2 · Accepted solution]

You can 'vgexport' every vg and use 'rmsf -k -H 0/0/#/#.#' for every old lun. I'd build a script based upon what UNCLAIMED states of old luns in 'ioscan', pipe first into and echo and then, when satisfied, replace the echo command with the 'rmsf' command.

And I'd do this before I moved the server. Otherwise the box will complain once it arrives.

[chmc]

OK thanks- I am going to do this early next week. I'm sure I will be posting again if I run into issues.

[chmc]

Going to remove and rebuild