Ressourcenreservierungs DB im Cluster

[Meff]

@All

interessantes aus der Knowledge Base zu dem Thema 'Replizierung / Clusterfähigkeit der Ressourcen Reservierungs DB' :

Problem:

If you are setting up the Resource Reservations database for Calendaring & Scheduling with Notes 4.5x/4.6x or 5.x Client and Domino 4.5x/4.6x or 5.x Server on several different servers, should the databases be replicas of each other?

Solution:

The Resource Reservations databases should not be replicas of each other; otherwise, you run the risk of free time not being reported accurately for the following reasons:

1.      Creating reservations directly in the replica copy of the Resource Reservations database is limited to the replication schedule between servers (server connection record.)

For example, Server A contains the original Resource Reservations database.  Server B contains a replica copy the Resource Reservations database from Server A.  The busytime database of Server A contains the free time information of the Resource Reservations database.  The busytime database of Server B does not have free time information of the same database.  If users book the resources directly from the replica copy of the Resource Reservations database on Server B, that appointment has to replicate to the original database on Server A for the busytime database to be updated.  Therefore, the free time is subject to a time lag based on the replication schedule.

2.      Creating reservations from the user's mail file, as opposed to creating them directly in the Resource Reservations database, only uses the original Resource Reservations database specified in the Public Address Book (refer to the Mail-in Database view to check the server and reservation database name being used.)  It does not use any existing replicas.

3.      Typical replication issues such as replication and save conflicts can occur.


A Note About Clustering:
In Domino 4.5x/4.6x the Free Time system is not clustered.  In Domino 5.x, the Free Time system is clustered.  However, Lotus strongly recommends that system administrators do not cluster the Resource Reservations database.

The Resource Reservations database should NEVER be clustered, even in a failover scenario.  The reason is because Clubusy.nsf gets updated only on the server that hosts the Resource Reservations database (that is, the server that the Resource Reservations database was created on).  If that server goes down, and users are now making reservations on the failover server, double books are highly likely to occur because the Sched task on the cluster mate is not designed to update the Clubusy.nsf on a clustered server.  This issue has been reported to Lotus Quality Engineering but was determined not to be a bug.  The Sched task updates the clubusy only on the server that hosts the Resource Reservations database.

When using a mixed environment of R4 and R5 Domino Servers, the Calendaring & Scheduling functionality will take on the characteristics of the R4 environment; therefore, you cannot cluster the Free Time system.  Clustering the Free Time system is a Domino R5-only feature.

Meff