Wann ist eine Datenbank/Anwendung uneingeschränkt Clusterfähig ?

[BANXX]

Ich bin gerade dabei, möglichst viele Gründe zusammen zu fassen, wann eine Datenbank bzw. eine Anwendung nicht bzw. nur eingeschränkt clusterfähig ist. Ich habe aus diesem Grund bereits im Dominforum eine Anfrage gestartet, möchte das Ganze aber gerne auf noch breitere Basis stellen.

Eine Anwendung ist nicht clusterfähig...
- Wenn eine DB Agenten enthält, in denen ein Ausführungsserver definiert wurde
- Wenn eine DB/Anwendung Lizenzschlüssel benötigt, die den Namen des Servers abprüfen.
- Wenn eine DB/Anwendung Dateien im Programmverzeichnis ablegt (--> eingeschränkt)
- Wenn Verschlüsselung (Datenbank / Dokumente) verwendet wird.

Was fällt Euch noch ein ? Diese Listekönnte dann auch für die BP´s ganz interessant werden....

[Glombi]

Das ist eine gute Frage.

Nicht nachvollziehen kann ich den Punkt
- Wenn Verschlüsselung (Datenbank / Dokumente) verwendet wird

Kannst Du das näher erläutern?

Die Sache mit den Agenten ist ein Bug in meinen Augen. Dort fehlt zumindest die Failover-Funktion.
IBM sagt dazu:
This issue has been reported to Lotus Quality Engineering in the form of an enhancement request; however, there are currently no plans to address it.

Basically, scheduled agents run only on the server on which they are scheduled to run.  If Server A is clustered with Server B and Server A goes down, any scheduled agents on Server A are not going to run on Server B, even though they are clustered.

The only way around this is to code the agents so that they poll the other server for availability.  If the server is available, they do not run; if it is not available, they do run.

It is important to note that this workaround is not supported by Lotus.


Andreas

[Glombi]

Ich denke, wir sollten insb. die Sache mit den Agenten hier vertiefen.

Aus meiner Sicht gibt es zwei Ansätze:
1. Ein Agent läuft auf allen Servern (*). Dann muss geprüft werden, ob ein bestimmtes Dokument bereits auf einem Server angefasst wurde. Falls ja, dürfen die anderen Server dieses Dokument nicht bearbeiten.
Ich sehe da aber dennoch Seiteneffekte.

2. Von aussen wird in regelmäßigen Abständen geprüft, ob ein Server erreichbar ist. Falls nicht, wird der Servername im Agenten durch den Clusterpartner ausgetauscht.

Generell darf in beiden Szenarien nicht (nur) mit der Eigenschaft "Unprocessed" gearbeitet werden. Es muss immer ein Flag ins Dokument oder in eine Log Datenbank geschrieben werden. Letzteres macht Sinn, wenn Dokumente nicht geändert werden sollen/dürfen.

Andreas

[BANXX]

Das ist eine gute Frage.

Nicht nachvollziehen kann ich den Punkt
- Wenn Verschlüsselung (Datenbank / Dokumente) verwendet wird

Kannst Du das näher erläutern?

Da war ich auch stutzig. Ich poste hier mal den Reply von Rockwilder:

Ich habs die Tage bei mir zu Haus gemerkt. Wenn ich die DB nehme und manuell eine Replik anlege, hast du Recht. Wenn ich die Replik per AdminP anlegen lasse, wird die Verschlüsselung mitrepliziert. Bzw. es wird versucht. Tut natürlich nicht, weil der 2. Server an die DB nicht ran kann. Es wird noch der Replikstumpf angelegt und dann ist Schicht. Repliziert wird da gar nix... Du kannst sie zwar manuell anlegen (nur den Replik-Stumpf) und dann replizieren lassen. Aber bei großen Servern nimmst du eher den AmdinP, als 5k DBs per Hand anzulegen, oder?

Zu den Agenten haben wir hier mal ne Programmiertechnische Lösung für den OoO geschaffen, die aber eigentlich auf alle Agenten anwendbar wäre. Ich schaue mal, ob die den grundsätzlichen Ansatz mal rauskriege und hier poste. Ist schon ein wenig her... 

[Semeaphoros]

Gutes und nützliches Thema, das man sicher in die BPs aufnehmen könnte. Zu allen genannten Punkten ist es so, dass da grundlegende Schwierigkeiten der "Clusterbarkeit" auftauchen, welche alle durch eine geschickte Konfiguration mehr oder weniger in den Griff zu bekommen sind.

Das Problem der Verschlüsselung hängt wohl auch daran, mit welchem Schlüssel die DB verschlüsselt wurde und ob es die gesamte DB ist oder einzelne Dokumente. Die Sache genauer anzuschauen ist sicher sehr wertvoll, danke, dass Du diese Diskussion gestartet hast.

[Marinero Atlántico]

Ein hervorragender Themenvorschlag:
Ich hatte mal während der letzten Fußball Weltmeisterschaft ein Problem mit RealTime LEI unter Domino6. Das ging irgendwie im Cluster nicht.
Seitdem hatte ich nicht mehr mit Clustern zu tun.
Vermute aber schon, dass es da für die Anwendungsentwicklung eine Menge gotchas gibt.
Kandidaten sind:
- notes-ini Variablen
- web-sessions
- when new mail arives getriggerte Agenten
- wenn Dokumente eingestellt werden -getriggerte Agenten.
- userspezische Profildokumente

<randnotiz_kein_start_zu_allgemeiner_diskussion>
In J2EE erfordert Clusterbarkeit von Anwendungen einige Punkte, die berücksichtigt werden müssen. Sowohl für Administration als auch für Entwicklung. V.a. damit sich das Cluster selbst nicht als "Performance"-Flaschenhals erweist. Es gibt dafür aber best-practices, don't-do-that Listen, etc.
</randnotiz_kein_start_zu_allgemeiner_diskussion>

[Thomas Schulte]

Fortlaufende Nummer wären auch so ein Thema, da alle Ansätze das zu realisieren auf Single Servern laufen aber auf Clustern zu extrem irritierenden ERgebnissen führen können.

[Glombi]

Ein weiteres Problem:
Calendar Entries/Reservations Do not Automatically Update Free Time in Clustered Server Environment

Problem
While creating various Calendar entries in your Notes/Domino R5 mail file (Mail50.ntf) or Notes/Domino 6 mail file (Mail6.ntf), you notice that you are not being warned of conflicts when you have other meetings or appointments already scheduled for the dates/times you are selecting for the new Calendar entries.  You then notice that you are creating entries on a replica copy of your mail file that is in a clustered server environment, but the mail file that you are creating entries on is not the replica that resides on your home server.  Likewise, you notice that the Resource Reservations database has double bookings when it is also in a cluster environment.  Why isn't the Free Time System (Clubusy.nsf) being updated in a cluster environment?


Solution
When in a clustered server environment, the Free Time system for Calendaring & Scheduling updates the busytime data for users only on their home server.  In the case of the Resource Reservations database it would be the server that the Resource Reservations database was created on.  Changes made on a replica are not immediately applied to the Free Time system.  In a clustered server environment the changes must first be cluster replicated back to the home server or the server that the Resource Reservations database was created on, where they are then picked up from the Sched task and placed in the busytime system (Clubusy.nsf).  Then the updates are cluster replicated back to the clustermates.  The lag time is approximately 30 seconds.

In the case where the home server goes down, and the user's mail file fails over to their cluster server, new Calendar entries will not be added into the Free Time system because the Schedule Manager is designed only to update the Free Time system on the home server.  An enhancement request, to make the Schedule Manager more cluster-aware, has been submitted to Lotus Software Quality Engineering (spr #MGRS5AZE9S).  This request will not be investigated for Notes/Domino R5 or Notes/Domino 6.

As for rooms and resources, Lotus does not recommend or advise clustering a Resource Reservations database.  This issue has been reported to Lotus Software Quality Engineering but has been determined not to be a bug (spr #DCOY4G3R62).   The Sched task is designed to update the busytime only on the home server of a user or the server that hosts the Resource Reservations database (that is, the server that the Resource Reservations database is created on).

Andreas

[Marinero Atlántico]

Ich denke, wir sollten insb. die Sache mit den Agenten hier vertiefen.

Mir fällt gerade ein, dass ich nach der WM 2002 doch nochmal mit Clustern zu tun hatte, nämlich in 02/03 als quasi letzten Einsatz bei meinem großartigen Ex-Arbeitgeber für einen Kunden in Dortmund.
Hab dort für das von Andreas angesprochene Agenten-Problem code aus einer TheView von 2003 oder 2002 implementiert. Das war eine Klasse und schien zu funktionieren (hab zumindest nichts mehr von denen gehört, war aber auch 03/2003 weg, weil die Geschäftsstelle einfach nicht mit der unglaublich brillianten Geschäftsstelle in Stuttgart mithalten konnte und deshalb geschlossen wurde  ).

Jedenfalls gibt es einen view Artikel. Die haben dort eine Klasse, die die von Andreas angesprochenen issues implementiert. Vielleicht nimmt sich jemand die Zeit und durchforstet die TheView Ausgaben mal durch (oder die Webseite, wo ja zumindest der code gepostet ist).
 
Selbstverständlich hab ich den Kunden mitgeteilt, wo ich den code herhabe. Ich weiss zufällig, dass zumindest eienr von denen hier registriert ist. Weiss aber nicht mehr usernamen und ist auch kein häufig Poster. Hab das nur als neu registrierter User kurz gesehen und mich erinnert.

Gruß Axel

[Glombi]

Hier die von Axel genannte Lösung:

Failover Support for Background Agents on Clustered Domino Servers — A Solution for Your Lotus Workflow and Domino Applications
Artikel aus The VIEW

Zum Thema Agenten gibt es von Julie Kadashevich:
Tipps und Tricks von Julie Kadashevich

Andreas

[BANXX]

Hier die von Axel genannte Lösung:

Failover Support for Background Agents on Clustered Domino Servers — A Solution for Your Lotus Workflow and Domino Applications
Artikel aus The VIEW

Habe ich auch gerade gefunden - interessanter Artikel !! Got sei Dank habe ich das View-archiv als Datenbank hier