Very Computer

Just a quick check, but I think that this configuration is possible.

Node Y & Z have concurrent access to Resource A (e.g. a db2 raw LV).

Resource B is an application, say db2, that has Node Y at the highest
priority.
Resource C is an application, say db2, that has Node Z at the highest
priority.
Resource B & C are mutual take-over cascading resources utilizing Nodes
Y & Z, respectively.

Finally, Resource D, which is other applications, has Node Y as its
highest priority, and is a standby cascading resource (i.e. Node Z will
take over if Node Y exits cluster).

Sent via Deja.com http://www.deja.com/
Before you buy.

In HACMP Configuration book is written, that you should create only 1
Resource Group per Node (1 Resource Group for 1 Service IP-Label).
When you want standby behaviour for one applicaton you could administrate
this with your applications scripts.

I always made 1 Resource Group per node. an administrated the different
applications via appli-start/-stopscripts from HACMP.
It worked always good.

Mit freundlichen Gr?en / Yours Sincerely

Gerhard Anton BARTOSCH

INFORMATIONS-TECHNOLOGIE AUSTRIA GMBH
Applikationsserver UNIX und VMS

A-1020 Wien, Lassallestra?e 5
Telefon: ++43-1-217 17-58036
Telefax: ++43-1-217 17-89-58036

Quote:> Just a quick check, but I think that this configuration is possible.

> Node Y & Z have concurrent access to Resource A (e.g. a db2 raw LV).

> Resource B is an application, say db2, that has Node Y at the highest
> priority.
> Resource C is an application, say db2, that has Node Z at the highest
> priority.
> Resource B & C are mutual take-over cascading resources utilizing Nodes
> Y & Z, respectively.

> Finally, Resource D, which is other applications, has Node Y as its
> highest priority, and is a standby cascading resource (i.e. Node Z will
> take over if Node Y exits cluster).

> Sent via Deja.com http://www.deja.com/
> Before you buy.

The problem I forsee in my planning is that the Node Relationship of a
Resource Group must be one of cascading, rotating or concurrent.  I want
one resource to be concurrent and one to be cascading.  Hence, limiting
myself to one Resource Group per node seems out of the question.

Also, cascading resource groups do not necessarily have to have an
associated Service IP.

Sent via Deja.com http://www.deja.com/
Before you buy.

I have setup one resource group as concurrent and one as cascading on the
same node/cluster without any worries.

In HACMP 4.2.1 and I believe also in 4.2.2 ( not sure about 4.3 and above ),
the order in which the resources are initialized ( the application server
start/stop scripts ) is based on the alphabetical ordering of the resource
group names.  So, if your non-concurrent resource groups contain things that
rely on any applications ( databases perhaps? ) in your concurrent resource
groups AND the alphabetical ordering of the names of these groups shows the
non-concurrent group(s) first, you will have startup problems.

I went after support on this one and their response was that this is the
intended functionality.  So, I just named things so that those I wanted to
start first were first alphabetically.

For instance if you have:

shared_resource_group  -- contains your concurrent database
a_non_concurrent_group -- contains an application that connects to the
database

Then at node startup, your dependant application will start BEFORE your
database!!

-kevin

problem I forsee in my planning is that the Node Relationship of a

There's an error here - DB2 does not use concurrent access disk, even on
raw LVs. Very few applications (mainly Oracle Parallel Server) use
concurrent access disk.

Quote:> Resource B is an application, say db2, that has Node Y at the highest
> priority.
> Resource C is an application, say db2, that has Node Z at the highest
> priority.
> Resource B & C are mutual take-over cascading resources utilizing Nodes
> Y & Z, respectively.

If you're configuring an application which uses concurrent access, and
you want the application instances to be taken over as well, then you
want one resource group for the disk (concurrent Y/Z), and one each for
the application instances and/or IP addresses (cascading Y/Z and
cascading Z/Y).

Quote:> Finally, Resource D, which is other applications, has Node Y as its
> highest priority, and is a standby cascading resource (i.e. Node Z will
> take over if Node Y exits cluster).

So, you add another resource group, cascading Y/Z, making a total of
four.