Internetworkers: http://www.ibiblio.org/internetworkers/

[Scott <catfather AT donpoo.net>]

On May 11, 2004, at 4:26 PM, Colleen McCarthy wrote:

> Hi Folks,
>
> One of my coworkers in the UNC/UNCH world is doing a hardware upgrade 
> and
> trying to be as logical and organized about planning it as he can be.  
> He is
> very interested in hearing from others who have done a hardware upgrade
> about the steps that are involved and the problems that he could 
> potentially
> run into.

<snip>

> Existing machine (6 yrs old) Specs:
> CPU               Mem           Disk
> 4x333 Mhz 604E      2GB       9gb + External
>
> Proposed replacement IBM p630 6C4 - 420C:
> 4x1.2Ghz Power4+    8 GB        72GB + ext.
>
> We run an Oracle database using a PowerBuilder application.

We do this kind of stuff at work (IBM Linux Technology Center) on IBM 
xSeries systems running Linux. While I've never done a system with 
Oracle and PowerBuilder the basic steps should be the same for any 
system migration like this. The "gotcha's" never show up until you get 
the new box in production, of course, but you can do lots of up front 
planning and testing to minimize the severity of any problems as well 
as come up with a sane back-out plan.

The general Game Plan should be to setup the new hardware with base OS 
load in a controlled environment while the existing hardware continues 
to serve production use.  The idea here is to get the new hardware 
configured with the OS and various services to the point where can push 
it into production by simply swapping IPs between the old and new 
systems.  This has the nice side affect of giving you a fairly sane 
back out plan as well. (Swap the systems again if things go wrong)

So, in general, start by figuring out what the base OS load will be on 
the new system. How is that different than the base OS load on the old 
system? You might want to take advantage of new base OS features at 
this time, such as larger disk partitions, LVM, updated JFS, or 
increased swap space. The base OS load should be done on an isolated 
network. (ie. not connected to the internet!)

Once you have a base OS load on the new box secure it. Apply any vendor 
updates as required and setup any user accounts that exist on the old 
system that will still be needed on the new system.

Make a list of services the old system offers. You listed PowerBuilder 
and Oracle as two of the services the old system provides. Take that 
list of services and start installing the needed services software to 
the new box. Use the old box as a reference point for services config 
files. Test each service as you configure it on the new box.

Make a plan to transfer the data from the old box to the new box. For 
example, dumping the Oracle DBs and importing them into the Oracle 
instance on the new box. Try a test run of it which will expose any 
problems and give you an idea how long the process will take. Plan your 
system downtime accordingly.

The general switch over and fall back plan is straight forward. At any 
time if something goes drastically wrong you should be able to hook the 
Old Box back up to the network and continue with normal service.

1) Turn off all services on Old Box
2) Dump the current data (ie, Oracle DB for example)
3) Import the data from Old Box to New Box
4) Assign Old Box network config to New Box
5) Do any final smoke tests needed to ensure continued positive sleep 
experience
6) Enable services on New Box and monitor for problems.

Anyway, this is one way of migrating services to a new system. In 
theory you could also take a backup of your Old Box and do a bare metal 
recovery to the New Box. However given the large difference in hardware 
chances are that's not the optimal route for you to go.

--
Scott (aim: bluecame1)
blog: http://sackheads.org/~scottrus/blog/
Do not trifle with me, I have eaten 104 brains.