|
.0> It looks like MRMEMO can have multiple servers connected to the same MEMO
.0> on the same or different machine (right ?).
Right. It's supported to configure up to 9 MRMEMO servers in a system.
It doesn't matter whether the different servers are connected to the
same or to different MEMO systems. But not to the *same* MEMO/GWY port!
.0> So, let suppose there is a dual-host where I would like to start a
.0> server on one machine and a second server on the other one, using of course
.0> two different logical units.
.0>
.0> I would like to know if:
.0>
.0> - this configuration does make sense
That depends on what you are trying to achieve. One restriction is that
the MRMEMO servers must use different MR mailboxes. So you can NOT do
this:
----- MRMEMO ---
MEMO/Gateway port < > MR mailbox
----- MRMEMO ---
.0> - if I can expect a sort of load balancing of the traffic sent from MEMO
.0> (I actually have some doubt here ...)
No, not in any transpararent way. In the same way as only one MRMEMO
server at a time kan use an MR mailbox, only one server at a time can
be connected to a MEMO/Gateway distribution port. There is no "fan-out"
mechanism in MEMO that allows messages to a distribution port to be
fetched by several gateways.
You can, however, set up different distribution ports in MEMO but this
requires that the MEMO users use the different addresses. I heard about
an installation that wanted to use DDS for address lookups (MEMO to MR
recipient validation) but still allow X.400 messages to be sent to MRX
for arbitrary recipients (not present in DDS). They solved it by running
two MRMEMO servers. When a MEMO user wants to send an ordinary message
it is addressed to VAX.xxxxx.yyyyy and when a message is to be sent to
X.400, another distribution port is used - X400.G=xxxxx..S=yyyyyy...etc.
MEMO/Gateway port VAX. <----- MRMEMO ---> MR mailbox
MEMO/Gateway port X400.<----- MRMEMO ---> MR mailbox
.0> - if some performance improvement can be expected
There will be a performance improvement unless there is a bottle neck
somewhere. If, for example, the SNA link from the SNA/Gateway is already
saturated, there isn't much to gain.
Internally in the MRMEMO server there is very little parallel activities
going on. E.g. while an SNA message is being sent, no Message Router
activity is taking place. So if you have spare resources, you can
increase the throughput by running parallel servers (limited by the
restrictions above).
.0> - if one of the two machine fails, the one remaining takes over the whole
.0> job in a transparent way
Since the parallel transparent setup is not possible, this is not
applicable but...
MRMEMO *does* support a crude way of failover through the use of standby
servers. By running more than one server having the *SAME* server
parameters specifying a specific SNA session address, only one server
will be able to get hold of the SNA session. If the server having the
session goes away, the standby server will get the session and take over.
This is described in the Operator's Manual (V2.1), section 2.5.1.
This causes the standby server to log a failed connection attempt every
clock_tick (default 30 seconds) so you would have make room for a large
log file or increase the clock_tick interval time (DEFINE/CLOCK_TICK).
Anders
|