|
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-2024 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.