[prev in list] [next in list] [prev in thread] [next in thread] 

List:       veritas-ha
Subject:    RE: [Veritas-ha] VCS design question
From:       "Jim Senicka" <jsenicka () veritas ! com>
Date:       2005-05-10 1:27:45
Message-ID: 7FB50D43FA9B7B4090F811363535A42604191BAF () hroxchcln1 ! enterprise ! veritas ! com
[Download RAW message or body]

well said.
 

-----Original Message-----
From: veritas-ha-admin@mailman.eng.auburn.edu
[mailto:veritas-ha-admin@mailman.eng.auburn.edu] On Behalf Of Cronin,
John S
Sent: Monday, May 09, 2005 4:33 PM
To: Brown, Rodrick; veritas-ha@mailman.eng.auburn.edu
Subject: RE: [Veritas-ha] VCS design question

I am not 100% sure, but I think what you are asking is should you use
one 4-node cluster or two 2-node clusters?

I often run into resistance about using a cluster with more than
2-nodes, but I like using larger clusters where they make sense, and
they often do.

The first thing I would note is that if you need a minimum of 1 node
from App-A and one node from App-B available, a likely configuration is
the N+1 cluster, which in this case indicates a 3 node cluster (2 apps
plus a spare) as it is unlikely that both App A and App B will fault on
different nodes simultaneously, and if they do, in my experience the
outage will be such that neither will be able to run on the spare node
(eg it will be a failure the cluster can't help you with, such as all of
the network or all of the storage disappearing at once).  Thus you save
the cost of 1 server.

If you do use the same number of servers, eg use a 4-node cluster, you
should be able to have an even higher level of availability than using a
two 2-node clusters, providing you can resist the urge to configure the
service groups such that the four node cluster looks like two 2-node
clusters lashed together, which so many of my customers insist on doing
- they have this mindset of primary and secondary nodes and can't get
past that.

Finally, if you have any dependency between app A and app B (eg app A is
a WebSphere MQ message broker, and app B is the database required by app
A), then the most sane way to do this is have them all in the same
cluster and use service group dependencies.

--
John Cronin
ipager: johncronin
Desk Phone: 404-986-3992
Cell Phone: 678-480-6266

-----Original Message-----
From: veritas-ha-admin@mailman.eng.auburn.edu
[mailto:veritas-ha-admin@mailman.eng.auburn.edu] On Behalf Of Brown,
Rodrick
Sent: Monday, May 09, 2005 4:10 PM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] VCS design question


I have a pair of applications I will be clustering and would like to
know the pros/cons of using the provide configurations 

Note for the overall application to work I will need the minimum 1 node
from APP-A and another from APP-B running which is the better approach
and why ? 

So far I've been leaning to approach 1) because it seems fairly simple,
one centralized place to manage all my nodes but I was asked why not use
approach B but I'm not sure how I should answer this. 

Can anyone provide any insight thanks? 


Approach A) 
		  [VIP-A][VIP-B]
----------------Cluster A------------------
(Service group 1) 	  (Service group 2) 
     [ APP-Aa] 		      [APP-Ba] 
     [ APP-Ab]                [APP-Bb] 
-------------------------------------------


Approach B) 

    	 [VIP]		      [VIP] 
------Cluster A----- |------Cluster B------
(Service group 1) 	  (Service group 1) 
     [ APP-Aa] 		      [APP-Ba] 
     [ APP-Ab]                [APP-Bb] 
-------------------- |---------------------

--
Rodrick R. Brown
Unix Shared Services 

_______________________________________________
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

*****
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. 162


_______________________________________________
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


_______________________________________________
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
[prev in list] [next in list] [prev in thread] [next in thread]