From: Green, Simon (SGreen@KRAFTEUROPE.COM)
Date: Mon Sep 02 2002 - 05:47:39 EDT
> -----Original Message-----
> From: Ken_Sedlacek@KYRUS.COM
> Sent: 30 August 2002 20:39
<SNIP>
> Question 1:
> Would a HACMP environment be advisable instead of our
> home-brew "warmspare"
> environment.
<SNIP>
> Wouldn't HACMP be easier for all concerned??
There's not much that HACMP does that is particularly complicated. What
makes things difficult - and HACMP worthwhile - is stringing it all together
in a co-ordinated and controllable fashion. And HACMP does a _lot_ of
different things!
We've got both techniques in use. We have three applications running with
HACMP/ES, because the customers have decided that they're sufficiently
sensitive to require HA. For these, which need to be up and running again
very quickly after a hardware failure, with minimum intervention from
technical staff, I would be reluctant to use a home-grown solution.
(Remember: don't make administrators a single point of failure! We've got
24x7 standby cover, but in theory, backed up by extensive testing, our HACMP
clusters should do everything without any intervention.)
We also have a homegrown solution, though. This is aimed more at disaster
recovery/business continuity. We have two sites, each of which is intended
to run about half production, half development/testing, with test on one
site being standbys for prod on the other. The hardware configuration and
some of the key details are rather different to your situation, but the
whole thing is built around home-grown scripts. Because there are a large
number of systems involved, it is much more reasonable to invest a lot of
effort in developing the scripts and procedures, and testing them
thoroughly. There are savings to be made on our DR contract and on HACMP
licensing, (we're talking about quite a lot of systems). Also, because of
the situations it's expected to be used in we would anticipate lots of
admin/support staff being available.
> Question 2:
> When using HACMP w/Oracle, when HACMP switches, does the
> "new" Production
> server change its hostname, etc.?
In my clusters, my Application Startup Script just runs the hostname command
to set it to whatever I like before I try to re-start SAP/Oracle. That's
the simplest way, but you could add a script before or after some HACMP
event if you preferred.
> Without going in to too much detail, how does HACMP switch
> the Oracle/AIX
> parameters to maintain Production on the new Production server?
HACMP will automatically re-configure the network, to use the correct IP
addresses. It will also make all of the filesystems etc available, if you
want. (Some people may prefer NOT to let HACMP do this, but to do it
themselves in the Application Startup Script, for more control.)
> It seems to me that we are "reinventing the wheel" with our home-brew
> "warmspare" server and would be much better using HACMP instead?
Maybe. Depends what you want! I would say that if you have a large number
of applications, (i.e. can cover the cost of development and testing) or are
prepared to accept a potentially flaky takeover, requiring some manual
intervention to get everything running properly then home-brew would be OK.
If you have a small number of applications which need to have a smooth and
reliable takeover then you should go with HACMP.
I would also say that there is a third option that might suit you, which is
simply to clone your production system onto the warmspare if you need to.
If you get a couple of decently fast tape drives - DLT or LTO, or maybe
CD-ROM - and get all of your application data onto the external SSA disks,
then you could probably restore a system from scratch inside an hour,
although it does require manual intervention and unless you implement NIM it
will require someone on site as well.
There would be some other issues to consider, such as backing up the
warm-sapre system, and how to swap back to the production server once it was
back up, but those are not all that difficult to deal with.
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 22:16:11 EDT