Data Migration

[Grayh]

I have to do a data migration for an Application residing in server with OS HP-UX 11.11 from Server A to server B.

What are the steps I need to follow..wat could be the questions I need to ask the App team.

Please help me out with the other Inputs I need.... This is the first time I will be doing a data migration..

[James R. Ferguson]

Hi:

Even before you engage the Application group, you need to answer questions like:

Are the physical disks that hold the application and/or its data moving from A-to-B or do you need to copy data from A-to-B?

Are both servers attached to a common SAN?

Is the operating system environment identical on A-and-B or will you need to recompile and/or relink executables on the new server?

Regards!

...JRF...

[Bill Hassell]

> I have to do a data migration

Just not enough information. Does the data have to be reformatted or translated during the migration? Or is this nothing more than changing servers? You'll need most of your information to be provided by the project manager in order to coordinate the actual tasks.

[Grayh]

Thanks for the responce...

This is a data migration from Location A to Location B,the OS remains same & the new server will again be similar to the existing one...

The OS will be Imaged is all the Info. I have till now..

There are several Applications running in this server. So for one perticular application what are the things I should take care of ...

I am planning to prepare a checklist which will help me to do this from the server perspective as well as from the application perspective..

plz help

[Grayh]

I would like to reframe my question...

My job is to migrate the server and the applications running on it from Location A to Location B..

Before the actual Migration, I have to prepare a checklist like a step by step procedures to migrate a Server/Application.

Wat r the questions I need to ask or wat r the steps...

plz help

[Roopesh Francis_1]

Grayh,

1.You need to check both servers are in same san so that you can indentify the method of data migration. It could be storage cut over or something like using open migrator or time finder.(possibility of backup and restore also you check)
2.you need to check the file systems details. what are file systems you need to move.
3.you need to check is there any dns entries related to application.
4,you need to ensure file systems in source server is not exist on target. if those are already in target you have to find the solution for merging them(or can you use different mount point).
5.need to check for software dependencies.
6.You need to check for application related user names and groups

Thanks

[Grayh]

frans,

Thanks for thee immediate reply..

I still have some doubts.. I do not know where to start from or how to start as I have never done a migration before..

Could you help me with some document or pdf so that I can understand the Issue much better.. so that I can ask my questions properly..

And with the help of u guys may be complete the migration....

[Jaime Bolanos Rojas.]

Hi Grayh,

You got me confused now by the time that you re-frase your question. Are you going to get a new server on lacation B or are you going to move the whole server to location B?

Moving the whole server is the easiest way to approach the problem:
-On location B you need to make sure that you got all the neccessary infraestructure to run the server, connectors, structured cable connections, routers, switches, UPSs, same voltage, network jacks, etc.

-Make sure that you remember how cables were connected in your server so that they are connected the same way on the remote location.

-If you are using a different subnet on the other location, make sure that you document IP changes, subnet masks, gateways, etc.

-Make sure that you have a backup plan just in case something goes wrong.

-Make sure that you have all your contacts handy and migration documented, service contact number for HW repairs, contacts at the response center for possible SW support.

If the migration is at the SW level, then there are way more changes involved, and until we go exactly the configuration you have problably will be difficult to think what is it that you need exactly.

Regards,

Jaime.

[Mel Burslan]

The Question before any other:

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 ? 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. ?

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

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

ioscan -fnC disk

from both servers. You can put both outputs in a text file, clearly separated and attach that file to your answer.

[Grayh]

Jaime,

Thanks for the Immediate responce...

We are actually Relocating the data centers from location A to Location B...

In this process of relocating we are also asked to do a Server consolidation.

Now I am asked to prepare a Pre-server Migration chicklist in the application perspective.. like sibel application is running on two different quest servers and now I have to implement it on intrigity blade servers...

So the checklist should include how to.. wat are the requirements.. or wat questions I need to ask the application team ....

[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.

[Grayh]

Bill,

Backup? Absolutely. On a tape? How much data do you have?

>>> There are around 400 servers all together of which 160 are HP servers & rest from Sun & IBM..

>>>When we say Backup in this Server Consolidation process.. wat all do we backup.. I know tar..cpio..dump / rdump / ufsdump... but in an environment as huge as this wat r the other options


>>>When we say Imaging... wat do we do exactly.. are there any tools for Imaging..

Do any of the applications or databases use raw disks (disks without any files)?

>>>how do I find the raw disks

Now the details are very dependent on the amount of data on your disks.

>>>I do not have this info yet as I do not have access to the servers.. Could you please advise me on the info that I need to gather or more frankly need to ask which is needed for this please...

While doing some "google" and searching "itrc web" I found the following helpful(I want to keep a record of this entire Data Center Consolidation Process here if the Moderators don't mind..)

http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1248055726718+28353475&threadId=133823


http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=953007

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=133823

from the above I have some doubts.. like what all information should I ask for and I "Should & Must have"...like from thee

>>> Application point of view..
>>> Server point of view..

>>> I have around 200 Applications spread over these servers

>>> Is this process of Migration same over Solaris & Aix.. If so what are the areas I should be careful on...

>>>Please advise on the areas I need to include in my pre-migration checklist which will help me during the actuall migration itself..

[Roopesh Francis_1]

If it is one application or 200+ applications, there will not many changes in each migrations.
Since you are taking regular backup, I do not think you need to take full backup of entire machines which you planned to migrate.
Since you are planning to do ignite backup most of the configuration part will be taking care (I am wondering even though you got a opportunity to migrate/consolidate old systems but you still stick with HP UX 11.11). You just need to tune your new environment according to the applications.
Since you planned to move SAN to new DC, I think you got the method of migration which is here definitely storage cut over.
As mentioned in my previous posts, please make a check list.

Thanks,

[OldSchool]

"If it is one application or 200+ applications, there will not many changes in each migrations."

uh...did you notice the part where he said the underlying network, including IPs and gateways was going to change as well?


"Since you are taking regular backup, I do not think you need to take full backup of entire machines which you planned to migrate."

I'd still get at least a solid full backup immediately prior to the migration.


"Since you are planning to do ignite backup most of the configuration part will be taking care "

right, with the "old" networking info. each server will required at least some configuration if the ip's are changing.


"(I am wondering even though you got a opportunity to migrate/consolidate old systems but you still stick with HP UX 11.11). You just need to tune your new environment according to the applications."

make sure the "new" hardware is supported in 11.11. If you plan to move up OSes as well, make sure any commercial software you have will run on the newer OS.

[Roopesh Francis_1]

>>Oldschool. uh...did you notice the part where he said the underlying network, including IPs and gateways was going to change as well?
Right, I noticed that also. I meant say network configuration part is applicable for each and every migration. He need to take care of that in every migration. if it is 200+ migrations or one migration, he HAS to ....!!!!!!!.He need to concentrate on each and every migration.
Thanks

[Grayh]

I have an Application "SAP" running on two differeent Production Servers servers which will also be migrated(Physically)...

What are the things I need to take care while moving these servers other than the networking stuff...

How much downtime do I need to take to bring these servers down...

What will be the impact...