|
Might do it that way. However how would that 'minimize rep save
conflicts'? If anything I could see where not using the clustering method
would increase it. For example, if I make a change on NOTES01, and get
antsy because it's not on SAMETIME01 in a very timely fashion, then I
might be tempted to make the change on SAMETIME01 also - thus a
replication or save conflict.
Rob Berendt
--
"All creatures will make merry... under pain of death."
-Ming the Merciless (Flash Gordon)
seanmurphy@xxxxxxxxxxx
Sent by: domino400-bounces@xxxxxxxxxxxx
12/23/2003 01:22 PM
Please respond to
Lotus Domino on the iSeries / AS400 <domino400@xxxxxxxxxxxx>
To
domino400@xxxxxxxxxxxx
cc
Fax to
Subject
Re: Consolidating Clusters
No need to redesign the clusters just to keep the NAB in synch.
We push/pull NAB changes from one cluster to another using a connection
doc to only one server in each cluster. Set the replication interval to 1
minute if necessary to keep everyone happy.
This will minimize rep save conflicts which will occur if you are
replicating/clustering the NAB.
Happy Holidays,
Sean
domino400-request@xxxxxxxxxxxx
Sent by: domino400-bounces@xxxxxxxxxxxx
12/23/2003 01:00 PM
Please respond to
domino400@xxxxxxxxxxxx
To
domino400@xxxxxxxxxxxx
cc
Subject
Domino400 Digest, Vol 1, Issue 469
Send Domino400 mailing list submissions to
domino400@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/domino400
or, via email, send a message with subject or body 'help' to
domino400-request@xxxxxxxxxxxx
You can reach the person managing the list at
domino400-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Domino400 digest..."
Today's Topics:
1. Consolidating clusters (rob@xxxxxxxxx)
----------------------------------------------------------------------
message: 1
date: Mon, 22 Dec 2003 15:48:28 -0500
from: rob@xxxxxxxxx
subject: Consolidating clusters
Currently we only put like servers in a cluster. For example we have
three clusters:
Cluster Member
NOTES01CLUSTER NOTES01
NOTES02
LDAPCLUSTER LDAP01
LDAP02
SAMETIMECLUSTER SAMETIME01
SAMETIME02
We do clustering for failover reasons.
The problem I am having is that users are strongly encouraged to change
their internet passwords in the NAB on NOTES01 only. However, when they
then access applications that use this internet password such as Sametime,
or other web based applications using the LDAP server their password isn't
synced yet.
Does anyone not think that putting this all into one cluster is a good
idea?
Cluster Member
NOTES01CLUSTER NOTES01
NOTES02
LDAP01
LDAP02
SAMETIME01
SAMETIME02
We would still control what databases get created on what server, and on
which servers replica copies are made.
I thought about doing connection documents between them all, specifying
the replication of only names.nsf, and a short interval of just a few
minutes. However, to a user, a few minutes is a lifetime.
Rob Berendt
--
"All creatures will make merry... under pain of death."
-Ming the Merciless (Flash Gordon)
------------------------------
_______________________________________________
This is the Lotus Domino on the iSeries / AS400 (Domino400) digest list
To post a message email: Domino400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/domino400
or email: Domino400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/domino400.
End of Domino400 Digest, Vol 1, Issue 469
*****************************************
_______________________________________________
This is the Lotus Domino on the iSeries / AS400 (Domino400) mailing list
To post a message email: Domino400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/domino400
or email: Domino400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/domino400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.