Re: Domino connection to DB2 in an high availability shop

[rob@xxxxxxxxx]

A little more background:
GDIHQ1 is one lpar with both ERP and Domino
GDIHQ2 is the Mimix replica lpar for the ERP and MAILTWO is a different 
lpar for GDDATA2 (and the rest of the "2" cluster replicas).

If we go the coding route and a scheduled agent runs to gather data from 
ERP we traditionally say "run on server" and select the primary (or "1") 
server only.  So it would run on GDDATA and not GDDATA2.  We do this so 
that the agent doesn't run twice; on GDDATA and on GDDATA2.  I realize 
that if GDDATA is down and we're running on GDDATA2 that leaves a hole. 
Just trying to figure out how to work around that hole.

One option that is coming to mind.  Why not spin off the "1" servers off 
of GDIHQ1 and put them on to their own lpar, let's say MAIL1?  This would 
be more consistant with our MAILTWO and our MAIL3 lpars.
The WRKRDBDIRE scheme would look like:

GDIHQ1
Name     Alias    Remote Location    Remote Type
GDIHQ    n/a      *LOCAL             *IP
GDIHQ    GDIHQ2   GDIHQ2             *IP

GDIHQ2
Name     Alias    Remote Location    Remote Type
GDIHQ    n/a      *LOCAL             *IP
GDIHQ    GDIHQ1   GDIHQ1             *IP

MAIL1
Name     Alias    Remote Location    Remote Type
MAIL1    n/a      *LOCAL             *IP
GDIHQ    n/a      GDIHQ              *IP

MAILTWO
Name     Alias    Remote Location    Remote Type
MAILTWO  n/a      *LOCAL             *IP
GDIHQ    n/a      GDIHQ              *IP

MAIL3
Name     Alias    Remote Location    Remote Type
MAIL3    n/a      *LOCAL             *IP
GDIHQ    n/a      GDIHQ              *IP

I think this would significantly ease the connectivity.  If GDDATA domino 
server, running on MAIL1 tries to connect to GDIHQ and our DNS says that 
GDIHQ's IP address is either the IP address for GDIHQ1 or GDIHQ2 it could 
all be handled with that, right?

We still have that concern about not running an agent multiple times by 
using the "run on server" but when it does kick in, it should go to the 
right DB server.

Rob Berendt