From: Bill Thompson (wht@NEO.RR.COM)
Date: Fri Oct 18 2002 - 13:10:33 EDT
Regarding the concern about not having a serial connection. I've come to
think if you're network is configured correctly it's not as important as it
used to be. In our high availability environments we have both public (WAN)
and private (LAN) connections using different network connections (different
switches, routers, etc.). The only way heartbeats could not get through
would be for multiple network failures or for the TCP/IP subsystem to fail.
The first is highly improbable (we've eliminated a single point of failure).
The second is perhaps equally improbable - when's the last time the TCP/IP
subsystem failed on an AIX machined? But, even if it did fail on one
machine, wouldn't you want the failover machine to take over?
For anybody that's familiar with HP's ServiceGuard you'll find that as a
rule they do not use a secondary method to receive heartbeats. A serial
connection is not even supported on more than a two node cluster. I thought
this was terrible when I first go into ServiceGuard but with the proper LAN
connections, this has never been an issue.
I realize IBM *highly* recommends a secondary connection, but I wouldn't let
that be my deciding factor.
Just my 2 cents.
Bill Thompson
Sr UNIX Systems Administrator
The Goodyear Tire & Rubber Co.
Contains Confidential and/or Proprietary Information
May Not Be Copied or Disseminated Without Express Consent of The Goodyear
Tire & Rubber Company.
AIX-L Archives: http://marc.theaimsgroup.com/?l=aix-l&r=1&w=2
----- Original Message -----
From: "Ferenc Gyurcsan" <fgyurcsa@AVAILANT.COM>
Newsgroups: bit.listserv.aix-l
To: <aix-l@Princeton.EDU>
Sent: Friday, October 18, 2002 11:04 AM
Subject: Re: HACMP Question
> Hageo has its advantages to it.
> Some type of non-IP connection is highly recommended, in case your ip
> stack/wire gets corrupted or conjusted. You can get some extenders to
rs232
> though, but I heard they are a little expensive.
> If you just want to use HACMP for what it's designed, I don't see any
> problem with this configuration, other than the difficulty of the serial
> connection. However, if you would want to use it for DR (eg. one building
is
> on fire), then you'd need data mirroring, and if you have data mirroring,
> then you would definitely want DBFS as well, so that you don't take over
the
> disk resources until you're sure that the other site is completely gone
(and
> dbfs will make sure of that), otherwise you may have to test your backup
> strategy. Especially, if all of the cables you use for communication go in
> one channel (ip, nonip, san), then if somebody cuts through that channel,
> all of your communication channels are gone (except the phoneline DBFS
would
> use).
>
> Of course this pure-HACMP solution won't prevent you from problems on loss
> of power in one building because your storage is in one location (unless
you
> have mirroring).
>
> So depending on what your goals are, this setup may work for you.
>
> --Ferenc
>
>
> -----Original Message-----
> From: Dearman, Richard [mailto:rdearm1@UIC.EDU]
> Sent: Friday, October 18, 2002 10:38 AM
> To: aix-l@Princeton.EDU
> Subject: HACMP Question
>
>
> I have 3 two node clusters and I was thinking of splitting them up.
> Basically I wanted to take one node from each cluster and move it offsite
to
> another building. All of our buildings are on the same networks and we
also
> share a common SAN fabric. So the storage will still be available if the
> first node fails.
>
> Does anyone see a problem with this type of setup from and hacmp point of
> view. I noticed none of the redbooks for hacmp mention anything about
> failover between locations. I know an rs232 connection cann't be used but
> they can still have tcpip communications. I know IBM has a product called
> hago but why purchase that product if hacmp works.
>
> Thanks in advance
> Brian
> ***************************EMAIL DISCLAIMER***************************
This
> email and any files transmitted with it may be confidential and are
intended
> solely for the use of th individual or entity to whom they are addressed.
> If you are not the intended recipient or the individual responsible for
> delivering the e-mail to the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on it,
> is strictly prohibited. If you have received this e-mail in error, please
> delete it and notify the sender or contact Health Information Management
> 312.996.3941.
>
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 22:16:16 EDT