Im Gepräch mit Kunden taucht immer wieder die Frage nach dem Grad der Verfügbarkeit der print2forms-Dienste auf. Hier fallen dann Begriffe wie Hochverfügbarkeit und Einsatz von print2forms im Cluster, genauso wie Forderungen nach einer Garantie für die fehlerfreie Ausgabe der Dokumente.

Mit diesem Dokument sollen die einzelnen Punkte etwas näher beleuchtet werden, um dem Leser ein Gefühl dafür zu vermitteln, was im Zusammenhang mit dem Drucken realisierbar ist und was eben nicht.

print2forms kann aus rein technischer Sicht prinzipiell sehr wohl auf einem Server-Cluster installiert werden. Allerdings müsste, wie bei aller anderen Cluster-fähigen Software, die Lizenzierung anders erfolgen, was, wie üblich, erhebliche Mehrkosten nach sich zöge.

Unabhängig davon basiert print2forms auf einer Client/Server-Architektur. Der print2forms-Server ist der zentrale Punkt einer Installation und existiert auch nur einmal pro Installation. Er stellt damit einen klassischen Single Point of Failure dar. Es scheint daher durchaus attraktiv, den print2forms-Server auf einem Cluster zu installieren - ja, wäre da nicht die Sache mit den Daten im Verzeichnis p2fRoot. Diese dürfen natürlich nicht einfach so im Cluster dupliziert werden, weil sonst die Druckergebnisse davon abhingen, auf welchem Cluster-Mitglied aktuell gedruckt wird.

Um das abzustellen, könnte das Verzeichnis p2fRoot beispielsweise auf ein SAN ausgelagert werden (wäre somit aber wieder ein Single Point of Failure). Das hiesse aber dann, dass mehrere print2forms-Server auf das gleiche Verzeichnis zugriffen, was einen ganz erheblichen Synchronisationsaufwand nach sich zöge.

Oder es werden Synchronisationsmechanismen implementiert, die die verschiedenen Versionen von p2fRoot auf einem identischen Stand halten - inklusive entsprechender Locking-Verfahren, die während dieser Synchronisation verhindern, dass für irgendwen innerhalb des Clusters Zwischenzustände sichtbar wären.

Für keine dieser Varianten ist der aktuelle print2forms-Server vorbereitet - somit ist der Server aus Architektur-bedingten Gründen definitiv nicht Cluster-fähig.

Bliebe die Frage, ob es möglich wäre, die Client/Gateway-Services im Cluster zu betreiben. Um es gleich vorweg zu nehmen, auch das macht keinen Sinn.

Wenn der Client/Gateway-Service auf jedem Cluster-Mitglied läuft, konkurieren alle diese Clients um die physikalisch tatsächlich nur einmal vorhandene Ressource Drucker. Das bedeutet konkret, daß, wenn ein Client eine Netzwerkverbindung zum Drucker hält, alle anderen Clients für diesen Drucker im Cluster ausgebremst werden. Damit entstehen zum einen Durchsatzprobleme - weil die anderen Clients nicht direkt mitbekommen, daß ein anderer Client seine Druckerverbindung abgebaut hat, und deshalb Druckpausen entstehen - und zum anderen werden die Druckreihenfolgen vollkommen unvorhersagbar. Somit könnten im Ausgabefach die Ausdrucke von mehreren Nutzern munter vermischt liegen.

Auch aus Gründen der Ausfallsicherheit bringt ein Cluster für das Drucken gar nichts. Wenn ein Cluster-Mitglied ausfällt, wird damit auch die Netzwerkverbindung zum Drucker unterbrochen. Der Drucker wird die Druckdaten, die er bis dahin empfangen hat, ausgeben und dann stehen bleiben. Inzwischen hat der druckende Rechner mitbekommen, dass die Verbindung zum Drucker (sprich print2forms-Client) ausgefallen ist und versucht ein Recovery. Im Cluster findet sich jetzt ein anderer Rechner, der den Druckauftrag entgegennimmt. Dieser Rechner weiss aber nichts über den vorherigen Verbindungsabbruch und hat insbesondere auch keine Ahnung, bis zu welcher Seite des Druckauftrags sein Vorgänger gekommen ist. Wenn der druckende Rechner diese Informationen auch nicht hat (ausser bei Grossrechnern mit Druckprotokollen wie IPDS also praktisch immer), beginnt der unterbrochene Druckauftrag wieder von vorne.

Abgesehen davon, dass wahrscheinlich nur teilweise gedruckte Seiten im Ausgabefach des Druckers liegen, entstehen dadurch Duplikate, was je nach gedrucktem Dokumenttyp zu erheblichen kommerziellen Folgen führen kann. Es ist also in den allermeisten Fällen für das Unternehmen besser, daß eine automatische Wiederaufnahme des Druckvorgangs unterbleibt.

Die für die Datenübermittlung von den Druckern angebotenen Protokolle sind per se nicht recovery-fähig. Weder kann sicher ermittelt werden, welche Seiten tatsächlich auf dem Papier sind (z.B. bei Druckern mit grossen Empfangspuffern oder Festplatten), noch lassen sich partiell übertragene Seiten nachträglich irgendwie löschen. Es liegt also auch zum grossen Teil an den Druckern selbst, dass die Erwartungshaltung der Anwender an print2forms gar nicht erfüllt werden kann.

Werden print2forms-Gateways im Cluster betrieben, sind die potentiellen Konsequenzen abhängig von den Aufgaben des Gateways oft gar nicht zu überschauen. Man denke nur an Gateways, die mehrere Dokumente nach bestimmten Kriterien aufsammeln und dann erst aufgrund eines Trigger-Ereignisses bearbeiten. Das ist nur extrem aufwändig zu synchronisieren. Eventuell doppelt via E-Mail verschickte Rechungen oder Duplikate im Archiv sind weitere unangenehme Folgen.

Aus dem hier Gesagten folgert, dass es keinen Vorteil bringt - ganz im Gegenteil, sogar erhebliche Nachteile - den print2forms-Client/Gateway-Service im Cluster zu betreiben. Auch der Client/Gateway-Service gilt somit als nicht Cluster-fähig.

Das Thema Cluster ist für print2forms nicht relevant.

print2forms selbst kann ohne weiteres auf einer virtuellen Maschine betrieben werden. Insofern sind die Vorteile solcher Systeme im Falle eines Ausfalls der Hardware auch für print2forms nutzbar. Allerdings gilt auch hier, dass die virtuelle Maschine nicht automatisch auf einen anderen Rechner umgezogen werden sollte, weil wie im Cluster keine Recovery-Fähigkeit der Druckerverbindungen gegeben ist. Auch in einem solchen Fall kommt es zu unvollständigen Ausdrucken und Duplikaten mit unabsehbaren Folgen für das laufende Geschäft.

Beim Einsatz virtueller Maschinen ist die Frage der Lizenzierung von Bedeutung. Die USB-Management-Konsole ist nur auf virtuellen Maschinen einsetzbar, die das Mapping einer physikalischen Schnittstelle - hier USB - erlauben. Das ist oft aber auch gar nicht gewollt, weil so die virtuelle Maschine nicht so leicht umgezogen werden kann.

Eine mögliche Lösung dieser Problematik ist der Einsatz eines sogenannten USB-Extenders. Über einen speziellen Treiber wird ein USB-Port simuliert, der in Wirklichkeit Anfragen via TCP/IP an eine im Netzwerk installierte Extender-Box schickt und von dort Antworten empfängt. Die Erfahrungen mit diesen Produkten sind gemischt, und vom Hersteller des Extenders und den lokalen Netzwerkgegebenheiten abhängig. Wir empfehlen diese Art der Installation nur im Ausnahmefall.

Für solche Installationsbedingungen gibt es die NET-Management-Konsole, die sich via Internet gegenüber einem von drei Servern der SPE Systemhaus GmbH autorisiert. Sollte die Verbindung zu einem dieser Server ausfallen, schaltet die NET-Management-Konsole automatisch auf einen der beiden anderen Server um. Die NET-Konsole kann jederzeit auf einer virtuellen Maschine eingesetzt und im Havarie-Fall schnell umgezogen werden.

Ein Nachteil dieser Lösung ist zugegebenermaßen, daß bei einem Ausfall der Internet-Anbindung selbst für mehr als zwölf Stunden print2forms zum Stehen kommen kann. Allerdings haben die meisten Unternehmen in so einem Fall viel tiefgreifendere Probleme. Der Notbetrieb der Konsole über eine Ersatzanbindung, z.B. via UMTS-Stick ist wegen der extrem geringen Datenmenge, die auch nur alle vier Stunden übertragen wird, ohne weiteres auch über längere Zeit denkbar.

Zur Reduktion von Last auf den firmeninternen VPN-Strecken und im WAN kann ein print2forms-Proxy-Server eingesetzt werden. Dieser spiegelt in einer Zweigniederlassung die Daten des print2forms-Servers und beantwortet so die Anfragen von lokal in der Niederlassung installierten Clients und Gateways.

Nach einiger Betriebszeit kennt der Proxy-Server alle print2forms-Daten, die in der Niederlassung gebraucht werden, und außer gelegentlichen Statusabfragen findet keine Kommunikation mit dem print2forms-Server in der Zentrale mehr statt. Eigentlich könnte dann der Betrieb in der Niederlassung auch weitergehen, wenn die Verbindung zur Zentrale und/oder zum print2forms-Server ausgefallen ist.

Ohne weitere Maßnahmen ist auch dies nur für einige Stunden der Fall, weil meist die Lizenzierung der Clients und Gateways in der Niederlassung über eine Management-Konsole in der Zentrale erfolgt. Hier macht es Sinn, eine weitere Management-Konsole lokal in der Niederlassung zu installieren, die den Proxy-Server und die anderen in der Niederlassung installierten Komponenten von print2forms lizenziert. Damit ist die Niederlassung dann, was lokal erzeugte Druckaufträge betrifft, für beliebig lange Zeit autark.

Dies gilt allerdings nur für Druckaufträge, die in der Vergangenheit schon einmal in der Niederlassung gedruckt wurden, und deren print2forms-Daten dem Proxy bekannt sind. Taucht ein vollkommen neuer Dokumenttyp auf, kann dieser erst gedruckt werden, wenn wieder Verbindung zum print2forms-Server besteht.

Es existieren systembedingt keine praktikablen und bezahlbaren Möglichkeiten, einen Hot-Fallover zu realisieren.

Daher kann die Ausfallzeit von print2forms im Falle von Netzwerk- oder Hardwareproblemen nur durch Cold-Standby reduziert werden. Dies kann entweder über den Umzug virtueller Maschinen oder über die Bereitstellung von Ersatzrechnern realisiert werden. In jedem Havariefall ist aber zu berücksichtigen, daß die Drucker keinerlei Recovery anbieten, und durch physischen Eingriff das Auftauchen von teilweisen Ausdrucken und Duplikaten kontrolliert werden muß.

Sowohl der print2forms-Server als auch der Client/Gateway-Service bieten die Möglichkeiten, manuell oder automatisch Backups ihrer Konfiguration und der print2forms-Daten anzulegen, die dann auf Cold-Standby-Rechner repliziert werden können.

Weiterhin verfügen beide über aktive und passive gegenseitige Überwachungsmöglichkeiten, die einen unbemerkten Ausfall verhindern und einen Administrator zeitnah benachrichtigen können. Diese Mechanismen müssen aber je nach Einsatzbedingungen von print2forms im Vorfeld eingerichtet werden.

Typischerweise liegt die Zeit, die für ein Wiederanlaufen von print2forms benötigt wird, im Bereich von unter 15 Minuten. Viel kürzere Zeiten sind nur schwer realisierbar, weil sich im Falle eines Hardware-Wechsels auch erst die ARP-Caches aller beteiligten Rechner, Switches und Router geleert haben müssen, damit das Routing im Netzwerk wieder einwandfrei funktionieren kann. Werden in print2forms Namen statt IP-Adressen verwendet, müßen auch die DNS-Caches auf einen neuen Stand gebracht werden, was im Einzelfall zu erheblichen Verzögerungen im Minutenbereich führen kann.


Sollten bei besonderen Installationen höhere Anforderungen über das hier Besprochene hinaus bestehen, sprechen Sie uns direkt an.