Moderne Unified-Messaging-Lösungen bauen den Notes Mail-Client zur Kommunikationszentrale aus, über die Faxe und SMS direkt vom Arbeitsplatz verschickt und empfangen werden können. Fernabfragbare Voice-Mailbox-Module ermöglichen zusätzlich das Speichern und Abhören von Sprachnachrichten. Durch die Bündelung der Dienste wird das System zur Kommunikationsdrehscheibe. Dadurch gewinnt das Thema Hochverfügbarkeit auch im Bereich Unified Messaging immer mehr an Bedeutung. Die Ferrari electronic AG wurde von der Zentrale einer europäischen Nationalbank beauftragt, ein hochverfügbares System zu realisieren, das integriert in Lotus Notes die Zusatzdienste Voice-Mail und Fax für ca. 1.200 Mitarbeiter bereitstellt. Bei der Realisierung der komplexen Architektur des Gesamtsystems einschließlich der TK-Anlage wurde ein innovativer Lösungsansatz gewählt, der im Folgenden aus der technischen Sicht dargestellt werden soll.

Komplexe Gesamtlösung

Herzstück des Systems bilden zwei Domino-Server DS1 und DS2, die als Cluster konfiguriert sind. Über eine dedizierte Netzwerkverbindung synchronisieren beide Server ihre Datenbanken und stellen dadurch sicher, dass bei Ausfall eines Servers der andere Server für alle angeschlossenen Clients mit aktuellen Datenbeständen die Funktion aufrecht erhalten kann. Dieses so genannte Cluster-Failover ist eine Standardfunktion, die die Domino-Server bieten.

Die Dienste Fax und Voice-Mail werden über Gateway-Rechner bereitgestellt, die zur Erzeugung der notwendigen Redundanz doppelt ausgelegt sind. Als Betriebssystem kommt Windows 2000 zum Einsatz. Um die Arbeitsweise der Gateways zu verstehen, wird der Ablauf beim Senden bzw. Empfangen von Faxen und die Behandlung von Voice-Mails zunächst losgelöst von der Forderung nach weitgehendem Ausfallschutz beschrieben.

Auf dem Gateway-Rechner sind folgende Komponenten installiert: ein Notes Client, für den auf dem Domino-Server das Postfach ffax.box als Foreign Domain eingerichtet ist, das eigentliche Fax-Gateway, das die Fax-Aufträge steuert und der Fax-Server, der über eine S2m-CAPI-Karte Faxe über die TK-Anlage (Siemens Hicom) sendet und empfängt. Zusätzlich ist auf dem Gateway-Rechner der Voice-Server installiert, der die gleiche S2m-CAPI-Karte nutzt. Bei der CAPI-Karte handelt es sich um eine EICON-Server PRI mit 30 Kanälen, von denen 7 mit DSPs ausgerüstet sind, also für den Fax-Verkehr genutzt werden können. Die anderen 23 Kanäle sind für das Voice-Mail reserviert.

Fax-Versand auf dem Domino Server

Für den Fax-Versand wird auf dem Domino-Server eine Datenbank mit dem Namen Mail.box eingerichtet. Als Fax zu versendende Dokumente werden in diese Datenbank geschrieben. Sie erhalten dabei bestimmte Eigenschaften, u.a., wenn sie versendet werden sollen, eine Zieladresse in der Form Nummer@fax – also z.B. 03328455960@fax. Auf dem Domino-Server läuft als Server-AddIn-Task ein Router, der zyklisch die Dokumente vorgegebener Datenbanken darauf untersucht, ob für sie Transportaufträge spezifiziert wurden. Dieser Router kopiert das Dokument aus der Datenbank mail.box in die Datenbank ffax.box.

Das Gateway pollt zyklisch die Datenbank ffax.box nach neuen Aufträgen. Eine wichtige Funktion des Gateways besteht darin, die Dokumente – also die eigentliche Notes-Mail und eventuell vorhandene Attachments – in das Fax-Format SFF zu konvertieren, das für die CAPI-Karten vorgeschrieben ist. Diese Umwandlung erfolgt durch Drucken auf einen Fax-Drucker. Dabei wird die Notes-Mail unter Ausnutzung der Druckfunktion des auf dem Gateway-Rechner befindlichen Notes Clients konvertiert. Für die Konvertierung der Attachments werden die jeweiligen Anwendungsprogramme per OLE-Druckansteuerung benutzt. Die konvertierten Dokumente werden zusammen mit der im ursprünglichen Dokument enthaltenen Fax-Nummer als Versende-Auftrag an den Fax-Server übergeben. Technisch ist es möglich, und gelegentlich wird davon auch Gebrauch gemacht, Gateway und Fax-Server auf getrennten Rechnern zu installieren.

Die Schnittstelle zum Fax-Server wird vom Gateway zyklisch überwacht. Darüber werden sowohl abgeschlossene Sendeaufträge als auch vom Fax-Server empfangene Faxe gemeldet. Für fertige Aufträge wird ein Dokument erzeugt, das alle Statusinformationen und als Zieladresse die Mail-Adresse des ursprünglichen Absenders enthält. Optional kann in das Dokument als Attachment auch das eigentliche Fax integriert werden. Dieses Dokument wird vom Gateway in die Datenbank mail.box gestellt und der Router auf dem Domino-Server sorgt dann automatisch dafür, dass es in das Postfach des Absenders gelangt. Bei empfangenen Faxen wird zunächst eine Abfrage an die Adressdatenbank (in der Regel names.nsf) gesendet, um zu ermitteln, welcher Empfänger zu der Durchwahlnummer gehört, an die das Fax gesendet wurde. Seine Mail-Adresse wird in das Dokument eingetragen, das das empfangene Fax als Attachment enthält. Über die Datenbank mail.box gelangt dieses Dokument dann in das Postfach des Empfängers.

Beim Voice-Mail wird anhand der Durchwahl ebenfalls über die names.nsf der Empfänger der Sprachnachricht ermittelt und die Sprachnachricht als Attachment in einem Dokument via mail.box in sein Postfach geroutet. Bei der Fernabfrage von Sprachnachrichten wird über die Nummer der Sprachbox (Durchwahl) aus der names.nsf der Dominoserver und der Name der Postfachdatenbank für den Benutzer ermittelt. Aus dieser Datenbank werden dann die Sprachnachrichten selektiert und über den Voice-Server dem Fernabfrager geordnet nach ungelesenen und bereits abgehörten Nachrichten vorgespielt.

Kein Informationsverlust

Aus den beschriebenen Abläufen wird sehr schnell klar, dass an der Gesamtfunktion viele Komponenten beteiligt sind und dass die Wirkung, die der Ausfall einer Komponente auf das System hat, von der jeweiligen Komponente abhängt. Ein einfaches Beispiel kann dies veranschaulichen. Fällt z.B. die TK-Anlage aus, so können bis zu ihrer Wiederherstellung keine Faxe empfangen und keine Sprachnachrichten entgegengenommen werden. Die Benutzer des Systems bemerken diesen Ausfall aber gegebenenfalls überhaupt nicht. Sie können weiterhin Faxe zum Versenden beauftragen. Diese Aufträge landen in einer Warteschlange, gehen also nicht verloren, sondern werden mit Wiederverfügbarkeit der TK-Anlage ordnungsgemäß abgearbeitet.

In der Theorie sind die Notes Clients, die mit Domino-Servern zusammenarbeiten, die als Cluster geschaltet sind, auf automatischen Cluster-Failover vorbereitet. D.h.: Der Notes Client holt sich die benötigten Daten aus dem jeweils lebenden Domino-Server, falls einer der Domino-Server ausgefallen sein sollte. In der Praxis stellt sich aber heraus, dass dies nicht unter allen Betriebsbedingungen zuverlässig funktioniert. So empfiehlt Lotus z.B. selbst, dass Datenbanken, auf die der Router zugreift, wie die mail.box auf dem Domino-Server als nicht replizierbar eingerichtet werden sollten. Sie sind dann zwar auf beiden Domino-Servern vorhanden, haben aber eine unterschiedliche Replica-ID – werden also nicht synchronisiert. Für das beschriebene System bedeutet dies, dass Aufträge, die bei einem Ausfall eines Domino-Servers noch unbearbeitet in der mail.box stehen (dies können sowohl Versende-Aufträge für Fax als auch noch unverteilte Statusnachrichten oder empfangene Faxe bzw. Sprachnachrichten sein), solange nicht bearbeitet werden, bis dieser Domino-Server wieder läuft. Wichtig ist, dass sie nicht verloren gehen.

Symmetrische Lastverteilung

Das Postfach ffax.box ist dagegen eine replizierte Datenbank. D.h.: Versende-Aufträge, die von den Routern auf den beiden Domino-Servern in diese Datenbank kopiert wurden, stehen in beiden Servern zur Verfügung. Da das automatische Cluster-Failover sich aus Sicht des Clients als nicht zuverlässig erwiesen hat, wurde mit Hilfe der C-API ein eigenes Failover implementiert. Beim Start des Gesamtsystems pollen beide Gateways ausschließlich die ffax.box eines der beiden Domino-Server, in der durch die Replikation die Aufträge beider Server gelandet sind. Antwortet dieser Domino-Server innerhalb eines bestimmten Timeouts nicht, wird davon ausgegangen, dass er ausgefallen ist. Die Gateways pollen dann den anderen Domino-Server. Jedes Gateway trägt in der ffax.box für einen Auftrag, den es übernommen hat, seine Identität ein. Beim nächsten Polldurchlauf wird von den Gateways immer der Domino-Server als Erster angesprochen, der beim letzten Pollen geantwortet hat. Dies hat den Vorteil, dass immer der Server benutzt wird, bei dem die höchste Wahrscheinlichkeit besteht, dass er verfügbar ist, d.h. die Timeout-Zeiten werden vermieden. Durch den Pollvorgang werden die Fax-Aufträge sehr gleichmäßig auf die beiden Gateway-Rechner verteilt; es kommt also im Normalfall zu einer symmetrischen Lastverteilung.

Bei der Bearbeitung der Aufträge innerhalb eines Gateway-Rechners müssen verschiedene Ausfallszenarien betrachtet werden. Fällt der Gateway-Prozess aus, so würde der zugehörige Fax-Server durchaus weiter arbeiten können. Er könnte z.B. Faxe empfangen und diese solange zwischenspeichern, bis der Gateway-Prozess wieder gestartet ist. Es wurde aber angestrebt, dass ein Gateway-Rechner seinen Betrieb möglichst geordnet einstellt, wenn eine seiner Komponenten nicht mehr einwandfrei funktioniert. Daher wurde auf den Rechnern ein so genannter Watchdog implementiert, der alle aktiven Dienste überwacht. Fällt der Gateway-Dienst aus, so beendet der Watchdog aktiv den Fax-Server und zwar so, dass gerade laufende Sende- und Empfangsvorgänge noch ordnungsgemäß beendet werden. Außerdem sendet der Watchdog eine Mail an einen Administrator, damit dieser sich um den Gateway-Rechner kümmern kann.

Neues Administratoren-Tool

Für den Administrator wurde ein zusätzliches Programm entwickelt, dass es ihm erlaubt, auf die ffax.box zuzugreifen. Dort sind u.a. alle Aufträge sichtbar, die von dem defekten Gateway bearbeitet, aber nicht beendet werden konnten. In diesen Aufträge kann der Administrator die Kennung des defekten Gateways durch die Kennung des noch aktiven Gateways ersetzen. Durch diesen einfachen Eingriff wird erreicht, dass diese Aufträge sofort bearbeitet werden.

Ein besonderes Problem der automatischen Umschaltung von einem Gateway auf das andere stellt der Anschluss an die TK-Anlage dar. Fällt beispielsweise ein Gateway-Rechner aus, so kann die CAPI-Karte auf ankommende Rufe nicht mehr antworten. Da die ISDN-Karte aber weiterhin elektrisch versorgt wird, wird sie von der TK-Anlage weiterhin als existent erkannt und es wird versucht, eine Verbindung zu ihr aufzubauen. Da dies nicht gelingt, interpretiert die TK-Anlage diesen Zustand als besetzt. Sie könnte nun versuchen, diesen Ruf auf einen anderen Anschluss, nämlich den, der zu der ISDN-Karte des anderen Gateway-Rechners führt, umzuleiten. Dies geht bei der Hicom-Anlage aber nicht, da alle ankommenden Rufe für den Sprachspeicher bereits umgeleitete Rufe des Teilnehmers sind, der ursprünglich erreicht werden sollte. Umgeleitete Rufe lassen sich aber nicht nochmals umleiten.

Eine Abhilfe für dieses Dilemma schafft die neueste Software in den ISDN-Karten von EICON. Durch den Watchdog werden, wie beschrieben, der Fax-Server und der Voice-Server bei einem Fehler im Gateway-Rechner gezielt beendet. Damit existiert für den CAPI-Treiber der Karte keine Anwendung mehr, die auf ankommende Rufe reagieren kann. Dies veranlasst die Karte, die Verbindung zur TK-Anlage in einen elektrischen Zustand (hochohmig) zu bringen, der von der TK-Anlage so interpretiert wird, als sei keine Karte mehr vorhanden, also dass der Anschluss nicht verfügbar sei. Aus diesem Zustand kann die TK-Anlage einen automatischen Failover auf den anderen Anschluss machen. Damit schließt sich auch diese letzte Lücke in dem umfassenden Konzept eines ausfallsicheren Systems.

Ferrari electronic AG

D–14513 Teltow

Telefon: (+49) 03328/455-90

www.ferrari-electronic.de