Data Migration

[Grayh]

Mel,

Thanks for the information provided

Is your data residing on a local or locally connected hard disk or on a SAN, connected most probably by a fiber optic SAN fabric ?

>>SAN

In other words, do both server A and server B have access to the same disk drives or their storage is totally different as in a physically separate location. ?

>>The storage is also being moved from data center A to data Center B... afterwhich data center A will be sold out...

depending on the answer to this question, a proper method can be suggested.

If you are not sure, please provide output of the command

>> I did not get access to the servers yet

[Roopesh Francis_1]

Build the target server as source and migrate the date.
If the storage can be connected to target server, we just need to import all the Vgs and mount the file systems for data migration perspective

[Jaime Bolanos Rojas.]

Hmmm, still we are going to need more information than that.
First things first, checking that the source HW is very similar to the destination.
Some application are licensed on the mac address of the original HW, check to see how is the licensing bound to the servers.

Document how are you going to do to migrate the OS and the applications, are you going to have a full backup of every thing? Are you going to use ignite to restore the OS at the destination, are the application going to need to be reconfigure given the new network design, IP addresses, gateways, etc.
If you are going to full backups make sure that you test them before hand, you don´t want to migrate every thing and then the backup was not good. The like other people said, the storage devices, are there any external storage devices, how are they going to be migrated, connected, and how are you going to make sure that the path to the storage devices are the same to the destination location.

I post the items that you want to check as questions.

Regards,

Jaime.

[Grayh]

Yes I will be using ignite to restore the OS at the destination,

are the application going to need to be reconfigure given the new network design, IP addresses, gateways, etc.

for the storage probably I 'll have he WWN id's match.

[Roopesh Francis_1]

if the application has any hard corded IP's and depends on your network, yes you need to configure them however you can check the possibility to keep same IP address also

[Mel Burslan]

Since the SAN is also moving, I can not emphasize the importance of these three words:

B-A-C-K-U-P !! B-A-C-K-U-P !! B-A-C-K-U-P !!

you may never know if the disk drives in the storage array enclosures will make it to the destination safe and sound. Actually you will at least need 2 copies of the backup on some other media than your SAN disks. Should one backup set is unreadable for this or that reason, you have something to fall back on. This should be the most critical part of your migration planning, i.e., moving the data intact, physically.

Secondly, contact the app vendor and check if they have any product keywords tied to the hardware, IP address and what-not. If they do, build your new server and provide necessary info to the vendor to get these keywords re-generated.

The rest is pretty much playing by the ear. You will need to vgexport your volumes after the final shutdown of the application on data center B, just before halting the server and you will copy the vg map files one way or another to your new server.

You need to plan the networking in advance, especially if your server is in a dmz, facing outside world, because every data center has different sets of IP addresses presented to the outside world and you have to live with them. Learn the IP structure of the new data center today and start planning your networking requirements and firewall rules etc. If you have no idea what these are, let your network folks put sniffers on each of your interfaces and capture data for a few typical days to see who is coming via which port and which protocol. It will help you to sort out networking down the road.

Last but not the least, at least 3 months or longer before you move the data center, freeze the environment for anything other than critical break-fix conditions. No minor design tweaks, no new executables, no new modules to be compiled, no new static routes to be added, etc. etc. You've got my point I am sure. And any critical break fix, document it to oblivion. Ask the requester of these fixes provide you what exactly needs to be done and why in a written form, approved by your management. If you do not CYA, you know what will happen when you move to the new place and app starts acting up. You will be at the target end of the pointing fingers and I am sure you do not want that.

Good luck. I have the same situation in a more grandiose scale, like 500+ servers, by this time next year and I am shaking in my boots already :)

[Grayh]

Thanks Mel for the explanation.. I will get to know more on Monday and then I can absorb more from u guys on this Migration process...

[OldSchool]

"are the application going to need to be reconfigure given the new network design, IP addresses, gateways, etc."

maybe or probably. Configuration may also change because server names change in DNS (if used).

you also need to be aware that some commercial software, such as DataProtector, tie the licensing keys to IP addresses. You need to find all such software and either arrange for temporary keys / emergency keys or keys for the new servers / ip addresses.

My understanding is you are physically picking up everything at Datacenter A, and installing it at Datacenter B. As noted before, BACKUP!.

List every single piece of hardware (including your SAN(s)) and develop a plan to recover whatever pieces don't come back up.

Make the assumption that the equipment ALL teh equipment gets lost / destroyed or is Dead On Arrival.

Whatever you do, don't ship the backup media with the equipment. I'll admit I'm paranoid about such, but imagine the consequences of a moving van filled with your datacenter going up in flames and all of your backups in the same trailer.

Since you imply that this will change all the network configs / routings, this kind of relocation can be high risk, and server consolidation isn't exactly a walk in the park. I can understand management wanting to get a "to-for", but trying to combine these two activities is, at least in my opinion, can be foolhardy, as you are multiplying the risks of the relocation by the risks of the consolidation.

Given the choice, and assuming sufficient lead-time I'd either:

1) get the new harware at the old site, configure it as required for the new location. do the migration and relocate the new equipment.

-or-

2) get the existing equipment on site, get everything functioning (networking, licensing etc). then consolidate.

Mel's point about "freezing" the code base isn't to be taken lightly either.

This is a case where paranoia is your freind. Assume everything will go wrong and develop a plan to mitigate what does. Case in point, I went thru a site relocation years ago where I had no access to the new facility until the actual day the equipment showed up. One area of the building had a network of Apollo engineering workstations that used a ring network topology. Imagine everyone's surprise that the network cabling wasn't installed in that area despite the fact the contractor's claim / bill and the facility manager having checked it off the list as complete. In fact, none of the appropriate co-ax was avaiable locally since it was a weekend. Wound up driving the 150 miles to the old facility and ripping out sufficient cable to get that stuff up and running.

[Grayh]

OldSchool u r back....

Thank you so much for the detailed explanation.. I will gather all the information like type of san used..

but for now I am preparing the Pre-Migration Checklist and I was asked to interact with the Application Team for their inputs.. I am not sure wat to ask them..

I did not get access to the data center yet... As soon as i get access ... the first thing I will do is to take a backup on a tape (Is tape a Good Idea ?? plz advice)

[Bill Hassell]

> the first thing I will do is to take a backup on a tape (Is tape a Good Idea ?)

Backup? Absolutely. On a tape? How much data do you have? And that is a more comp[licated question than you might think. Do any of the applications or databases use raw disks (disks without any files)? I am sure you already have regular backups of all of your data. As mentioned earlier, an Ignite backup (make_tape_recovery) is the first step, then a backup using fbackup or your commercial backup product. Now the details are very dependent on the amount of data on your disks. You may need several tapes and many hours to do this backup. Use bdfmegs (attached) to summarize all your mounted filesystems.