move HPUX 11.00 to 11.00

[David Willams]

I have a L2000 server running hpux 11.00 and is a very critical applications.This is connected to an external storage like emc

I have to move this server from one location to another with zero downtime...

so I bought another L2000 with the same firmware levels and everything same.here i have the same OS 11.00 and everything same.

How do I go about transferring data.storage is like 900 Gb.

[OldSchool · Accepted solution]

you might start with what kind of external storage is it really, what kind of data (just files, database, or ??). Then is it static data, dynamic, or both? If both, can you segregate the types? links between locations? all impact what can be done or what will work

[David Willams]

you might start with what kind of external storage is it really,

EMC

what kind of data (just files, database, or ??).

Database & files

Then is it static data, dynamic, or both?

Dynamic

If both, can you segregate the types?
links between locations?

How to find this...

There is no ignite for 11.0 .. how would i take the images

[OldSchool]

"you might start with what kind of external storage is it really,

EMC"


* what I was looking for was NAS, SAN, nfs, local?????


"what kind of data (just files, database, or ??).

Database & files

Then is it static data, dynamic, or both?

Dynamic"


* short of some kind of on-line or ip-based replication, then you are probably going to have downtime. I don't see any obvious way around it. of course, that requires network connectivity (and possibly substantial bandwith) which leads to .....


"links between locations?

How to find this..."

/sigh - Uh...you don't know what kind of network is available????? which impies there may not be any????



"There is no ignite for 11.0 .. how would i take the images"

Simple...there *was* one when the O/S was supported. Now it's not, so there isn't one available at hp. You might find someone that has an old depot available and can give you a link. If not, basically, you're out of luck / won't be able to.

If you've got a support contract, you *might* convince hp to give you a hand. Doubtful because, as I noted previously, the OS is no longer supported.

[David Willams]

Ok... what if I had a similar setup on 11.11... I am trying to learn here

move a 11.11 to a 11.11

storage is san
legecy systems

what would I do if i am asked to move a server running on 11.11 pn pa-risc from location A to location B with zero downtime

[Matti_Kurkela]

The total amount of data is less important than the amount of updates to the data in an unit of time. If less than 1% of the 900 GB is added/updated daily, keeping two distant sites in sync is easy enough with commonly-available network speeds. If more than, say, 50%, not so easy: you should be thinking about dedicated fiberoptic links between the sites.

What does "zero downtime" mean in this case? Is a break of less than one minute OK (e.g. unplugging a network cable at location 1 while someone else plugs in another cable at location 2)?

If you really need the change to be effective in less than one second, it is going to require a lot of careful planning, configuration, testing and practice. It may also be rather expensive, if your current network + storage + hardware + application combination does not support high-availability cluster operation.

What kind of distance are you moving? From one server room to another within the same building, from site 1 to site 2 within the same city, to another city in the same country, or maybe even to a different continent?

Is the storage moving too? If so, can you already access the same storage from both locations? This would allow "leapfrogging": for example, first duplicate the server in the new location, switchover to the new server, remove the old one, then use the server in the new location to mirror the data from the old (remote) storage to the new (local) one.

Can your application(s) run for a while with an old copy of data and then re-integrate some data updates later, or must the data be 100% real-time accurate at all times?

Can your application(s) run as a two-node active/active-type cluster at all? If not, achieving zero downtime may be impossible or at least much, much harder.

Can your network reroute the traffic from one site to the other fast enough? If the same IP network segment is accessible at both locations, this may be simple to achieve. If the server must move to a different network segment, not so simple. Some things like DNS changes will need advance preparations: do not assume that all network changes can be applied without any delay.

The level of detail required in planning a move like this is huge. If you think someone on the Internet can supply you with a set of easy-to-follow "cookbook" instructions based on your vague description, don't hold your breath.

You're obviously way out of your depth here. Get some datacenter operations training, or get someone who already has successfully executed such a move to assist you. S/He is definitely going to need a NDA, because after the planning & testing phase is complete, s/he is going to know at least as much about your current setup as you do now... and you'll have learned a lot more.

MK

[OldSchool]

I think Matti is correct when he questions the definition of "zero downtime". Some locations define it as literally no downtime, others as "no unscheduled downtime", or have available maintenance windows. Hopefully, one of the latter applies to your case.

===========================

To get around the lack of availablity Of Ignite for 11.0, you could use Mirror-UX to do the heavy lifting.
IF the server's are identical (especially in the various peripheral cards) and the number / size of the internal drives, you should be able to:

A) take one disk out of the original production box and replace it with one of the drives from the "new" server. In all of the L2000's I've seen, the internal drives were alwauys hot-swappable, so this should be possible while the production box is up.

B) Mirror the remaining original disk in the old box to the new one you just inserted, creating a clone for the "new" box.

c) Remove the clone and install it back in the "new" server.

D) Reinstall the original mirror in the production box and re-establish the mirror / syncing. See when "Good Disks Go Bad" for checklists / procedures

E) On the "new" box, set up mirroring as desired.

At the conclusion, you should have 2 servers with identical OSes and mirroring on both. You may need to run "setparms" on the "new" machine at this point.

If the OS is the only thing on the internal drives (or OS and applications -- but not the data), you're still left with moving the data...and the database. Depending on your needs, you might be able to move the bulk of that by taking a full backup on the "old" server, restoring this on the "new" server. This would need to be done prior to the cutover. Then, at the time of the changeover, you should be able to apply an incremental backup of the old to the new. The incremental process should run faster as there would be less data (hopefully) to contend with. The ability to due this in a timely manner would depend on the "change rate" for the non-database data...the more "static" it is, the quicker this goes..

================================================

As for the database(s), you're probably going to need guidance from your DBA. A lot of databases can accumulate change journals or log that can be used to help in this process. Basically, its the same idea as the full / incremental noted above, except in this case you would restore the full database backup on the new machine and at cutover, rollforward the journals/logs to bring the new servers' db current. Note that the terminology for the above varies from DB to DB.

Another possibility might be database replication from the old to new servers. Most of the commercial DBs have some form of replication available, which allows the DB to propagate changes in one DB to the "new" copy. Don't know if this is available for the popular Open Source DB's or not. Note that even if it is available for whatever you've got installed, it may be a rather costly option.

================================================

Also, be aware that if there are commercially purchased applications running on the original server, be aware there may be licensing issues that need to be resolved. That all depends on the original licensing agreements, how licensing is enforced and a wealth of things.

The basic idea behind all of the above is to reduce the amount of data that needs to be applied at changeover time to minimize the amount of time necessary. Hopefully, the timetable for doing this allows you sufficient time to practice whatever process you actually decide on a couple of time. That would allow you do iron out any defects in the final process as well as determine how long an outage may be necessary...

[David Willams]

.