1                     Themenübersicht

Im ERP-System werden wichtige Geschäftprozesse eines Unternehmens abgebildet. Wenn das System nicht verfügbar ist, dann ist der Ablauf dieser Geschäftprozesse behindert oder unmöglich. Aus diesem Grund werden zahlreiche Möglichkeiten geboten, die die Verfügbarkeit des Systems steigern. Im Folgenden werden diese Möglichkeiten im Detail beschrieben.

2                     Zielgruppe

• Technische Berater
• Systemadministratoren

3                     Begriffsbestimmung

Hochverfügbarkeit

Ein System gilt als hochverfügbar, wenn eine Anwendung auch im Fehlerfall weiterhin verfügbar ist und ohne unmittelbaren menschlichen Eingriff weiter genutzt werden kann. In der Konsequenz heißt dies, dass der Anwender keine oder nur eine kurze Unterbrechung wahrnimmt. Hochverfügbarkeit (abgekürzt auch HA, abgeleitet von engl. High Availability) bezeichnet also die Fähigkeit eines Systems, bei Ausfall einer seiner Komponenten einen uneingeschränkten Betrieb zu gewährleisten.

Kontinuierliche Verfügbarkeit

Ein System ist kontinuierlich verfügbar, wenn eine Anwendung auch im Fehlerfall weiterhin verfügbar ist und ohne unmittelbaren menschlichen Eingriff weiter genutzt werden kann. Der Anwender nimmt in einem kontinuierlich verfügbaren System im Fehlerfall keine oder nur eine kurze Unterbrechung wahr. Nicht gespeicherte Daten und in geöffneten Anwendungen gehen nicht verloren.

Failover

Eine Technologie, mit deren Hilfe Daten und Dienste hochverfügbar gehalten werden können. Unter einem Failover ist der ungeplante Wechsel von einem Primärserver zu einem zweiten Standby-Server zu verstehen. Unternehmenskritische Anwendungen können auf diese Weise auch bei einem Ausfall eines Rechners weiter zur Verfügung gestellt werden, da das Zweitsystem im Fehlerfall die Aufgaben des Primärsystems übernimmt. Meist überwachen sich beide Server gegenseitig mittels eines so genannten „Heartbeats“. Dabei handelt es sich um ein Signal, das über eine Netzwerkverbindung zwischen den Servern zyklisch ausgetauscht wird. Antwortet ein Server oder eine Applikation nicht, weil er/sie ausgefallen ist, so initiiert der andere Server automatisch die Übernahme der Dienste. Binnen weniger Sekunden bis Minuten stehen diese dann wieder den Nutzern zur Verfügung.

4                     Beschreibung

Jede für ein Comarch-ERP-Enterprise-System benötigte Ressource (z. B. Rechner, Betriebssystem, JVM,…) kann ausfallen. Um nach dem Ausfall einer Ressource die Verfügbarkeit des Systems zu erhalten oder wieder herzustellen, ist eine Reaktion des Systems oder aber ein manueller Eingriff des Administrators erforderlich. Comarch ERP Enterprise kann beim Ausfall der folgenden Ressourcen automatisch reagieren und die Verfügbarkeit des Systems wieder herstellen.

Die Funktionen, die die Verfügbarkeit eines Comarch-ERP-Enterprise-Systems gewährleisten, werden im Folgenden beschrieben.

4.1               IP-Failover

Die Netzwerkverbindungen zwischen den Application-Server, dem Datenbanksystem und dem Browser sind zum Betrieb eines Systems notwendig (siehe „Clientseitiges Failover“). Wenn eine der Netzwerkverbindungen permanent abbricht und nicht wieder aufgebaut werden kann, dann ist das System nicht verfügbar.

Wenn die Netzwerkverbindung zwischen einem Application-Server und dem Message-Server eines Systems ausfällt, so bleibt der Application-Server noch 30 Sekunden in Betrieb und versucht die Netzwerkverbindung wieder aufzubauen. Wenn die Verbindung zum Message-Server innerhalb von 30 Sekunden wieder aufgebaut werden kann, so läuft der Application-Server ohne Datenverlust weiter. In diesem Fall ist die kontinuierliche Verfügbarkeit gewährleistet. Wenn die Verbindung innerhalb von 30 Sekunden nicht aufgebaut werden kann, startet der Application-Server neu.

Das Failover der Netzwerkverbindungen (IP-Failover) zwischen den Application-Servern eines Systems ist immer aktiv. Eine Konfiguration des IP-Failovers ist nicht erforderlich.

Wenn beim Ausfall der Netzwerkverbindungen auch Datenbankverbindungen verloren gehen, so erkennt das ERP-System häufig diesen Ausfall und leitet ein Datenbank-Failover ein.

Andere Komponenten, wie beispielsweise das Dateisystem, die nicht unter der Kontrolle des ERP-Systems sind, müssen einen Netzwerkausfall ebenfalls behandeln. Prüfen Sie, ob die von Ihnen eingesetzte Hard- und Software nach einem temporären Ausfall des Netzwerks noch verfügbar ist.

Wenn die Netzwerkinfrastruktur zwischen den Application-Servern oder zum Datenbanksystem permanent ausfällt, so ist das System nicht verfügbar.

4.2               Datenbank-Failover

Die meisten Datenbank-Management-Systeme (DBMS) haben Failover-Mechanismen. Das bedeutet, dass mehrere Datenbankinstanzen parallel auf der gleichen bzw. auf einer gespiegelten Datenbasis laufen. Wenn eine Datenbankinstanz aufgrund eines Fehlers nicht mehr zur Verfügung steht, so kann eine andere Datenbankinstanz die Aufgaben der ausgefallenen Instanz übernehmen. Es gibt häufig auch innerhalb eines DBMS mehrere Möglichkeiten wie das Fail­over für ein Datenbanksystem konfiguriert werden kann. Die unterstützten Konfigurationen finden Sie in der Installationsdokumentation.

Comarch ERP Enterprise verwaltet alle Verbindungen zu einer Datenbankinstanz pro Datenbank in einem gemeinsamen Pool. Wenn der Application-Server eine Verbindung benötigt und bereits alle Verbindungen in dem Pool verwendet werden und die maximale Anzahl von Verbindungen in dem Pool noch nicht erreicht ist, so wird eine neue Verbindung geöffnet und im Pool registriert. Wenn die Datenbank einen Fehler meldet, so wird die betroffene Verbindung geschlossen.

Wenn das ERP-System durch die Fehlermeldung erkennt, dass eine Datenbankinstanz ausgefallen ist, so werden alle offenen inaktiven Datenbankverbindungen geschlossen und nach einer Wartezeit erneut geöffnet. Das ERP-System versucht mehrfach mit wachsenden Zeitabständen die Datenbankverbindung wieder aufzubauen, sofern das erneute Öffnen einer Datenbankverbindung fehlt schlägt. Damit wird berücksichtigt, dass das DBMS einige Zeit zum Vollzug des Failovers benötigen kann. Während der Application-Server versucht die Verbindung zum DBMS wieder aufzubauen, werden alle Anwendungen, die auf diese Datenbank zugreifen wollen, angehalten.

Die beispielsweise von einer Anwendung auf einer Datenbankverbindung ausgeführte Operation bricht beim Ausfall der Datenbankinstanz mit einer Fehlermeldung ab. Das ERP-System erkennt diese Fehlermeldung und versucht soweit als möglich die Operation mit einer neuen Datenbankverbindung erneut auszuführen. Die folgenden Operationen können nicht erneut ausgeführt werden:

• Abschluss einer Datenbanktransaktion mit Commit.
• Abfragen des nächsten Datensatzes in einem bereits geöffneten ResultSet.

Wenn bei einer dieser Operationen die Datenbankverbindung abbricht, so wird die betroffene Anwendung im Allgemeinen mit einer Fehlermeldung beendet.

Wenn auch nach wiederholten Versuchen keine neuen Datenbankverbindungen zu der Datenbankinstanz geöffnet werden können, dann muss der Application-Server manuell beendet werden. Das Problem mit dem Zugriff auf die Datenbankinstanz muss beseitigt werden und danach kann der Application-Server wieder gestartet werden.

Die Datenbankmanagementsysteme unterstützen vielfältige Konfigurationsmöglichkeiten des Datenbank-Failovers. Testen Sie daher unbedingt das Datenbank-Failover auf Ihrem Entwicklungs- oder Testsystem.

4.3               Alternative Message-Server

Der Message-Server koordiniert die Zusammenarbeit aller Application-Server in einem System. Wenn kein Message-Server läuft, kann kein anderer Application-Server starten oder in Betrieb sein. Der Message-Server ist somit ein Single Point Of Failure. Sie können daher für jedes System einen alternativen Message-Server konfigurieren. Der alternative Message-Server kann die Aufgaben des Message-Servers nach dessen Ausfall ohne manuellen Eingriff übernehmen. Diese Übernahme wird im Folgenden Cold-Standby genannt.

Der Cold-Standby läuft wie folgt ab:

1. Der Message-Server beendet sich, damit brechen die Netzwerkverbindungen zu allen Application-Servern und zum alternativen Message-Server ab.
2. Alle Application-Servern und der alternative Message-Server starten neu und versuchen sich neu mit dem Message-Server zu verbinden.
3. Wenn der alternative Message-Server die Verbindung zum Message-Server nicht innerhalb der Wartezeit herstellen kann, so ändert der alternative Message-Server die Konfiguration des Systems und trägt sich selbst als Message-Server ein. Der ursprüngliche Message-Server wird damit zum alternativen Message-Server.
4. Alle Application-Server des Systems starten mit dem neuen Message-Server.
5. Das System ist wieder verfügbar.

Beim Ausfall des Message-Servers ist ein System durch den Cold-Standby nach einigen Minuten ohne manuellen Eingriff wieder verfügbar. Die Benutzer des Systems können sich nach dem Start des alternativen Message-Servers wieder am System anmelden.

In dem Dokument „Systemcockpit Typ: „System““ ist beschrieben, wie Sie alternative Message-Server konfigurieren.

4.4               Clientseitiges Failover

Kurzfristige Ausfälle der Netzwerkverbindung zwischen dem Browser und dem Application-Server können von Comarch ERP Enterprise überbrückt werden. Erfolgt innerhalb eines definierten Zeitfensters keine Interaktion vom Client, wird durch Comarch ERP Enterprise die Kommunikationsverbindung zwischen dem ERP-System-Application-Server und dem Client periodisch überprüft. Kann die Verbindung innerhalb des Zeitfensters von der ursprünglichen Webbrowser-Instanz wieder hergestellt werden, dann kann der Benutzer ohne jede Einschränkung an derselben Stelle weiterarbeiten.

Comarch ERP Enterprise bietet für das unerwartete Beenden des Application-Servers und für den längerfristigen Ausfall der Verbindung zwischen Browser und Application-Server Funktionen, die es dem Benutzer erleichtern, bei erneuter Anmeldung an das System weiter zu arbeiten. Bei der erneuten Anmeldung wird (abhängig von den Benutzereinstellungen) die vor dem Fehlerfall zuletzt gestartete Anwendung mit dem zuletzt bearbeiteten Business Entity erneut gestartet. Der Benutzer findet nach der erneuten Anmeldung also die gleiche Arbeitsumgebung wie vor dem Fehlerfall vor.

Im ERP-System wird pro Benutzer der Verlauf aufgezeichnet:

• Die zuletzt benutzten Anwendungen
• Die jeweils primär betrachteten Business Entities.

Dieser Verlauf kann in verschiedenen Ansichten betrachtet werden, beispielsweise pro Anwendungen, pro Business Entity oder pro Zeitspanne. Mit dem Verlauf kann der Benutzer einfach und schnell die zuletzt verwendeten Anwendungen öffnen und Objekte bearbeiten.

Die Auftragsanwendung wie beispielsweise die Anwendung Vertriebsaufträge speichern beispielsweise alle 16 Positionen zwischen. Das bedeutet, dass ein Benutzer, der in einer Auftragsanwendung einen Auftrag eingibt, höchsten 16 Positionen erneut eingeben muss.

Die Menge der ungespeicherten Eingaben ist in der Praxis stets relativ klein, da das regelmäßige Speichern gefördert wird. Die Menge der Anwendungs-Instanzen im Modus “Neu” beziehungsweise “Bearbeiten” pro Dialog-Session ist beschränkt.

4.5               Load-Balancer

Auf jeden Application-Server, der für Dialog-Verarbeitung genutzt wird, kann über eine URL zugegriffen werden. Die URL ist normalerweise eindeutig einem Application-Server innerhalb eines Netzwerks zugeordnet. Wenn ein Application-Server ausfällt und nicht neu startet, dann kann im Allgemeinen über die URL, die diesem Application-Server zugeteilt war, kein Dialog-Zugriff mehr erfolgen. Die Benutzer, die üblicherweise auf diesem Application-Server gearbeitet haben, müssen über eine andere URL einen anderen Application-Server benutzen.

Mit Comarch ERP Enterprise wird der Load-Balancer ausgeliefert. Der Load-Balancer stellt eine URL für den Zugriff auf ein System bereit und verteilt die Zugriffe auf diese URL auf mehrere Application-Server. Die Verteilung der Benutzer auf die laufenden Application-Server er-folgt automatisch unter Berücksichtigung des Zustands der Application-Server.

Wenn ein für Dialog-Verarbeitung genutzter Application-Server ausfällt und ein Load-Balancer eingesetzt wird, dann gehen alle nicht gespeicherten Daten der Benutzer, die auf diesem Application-Server gearbeitet haben verloren. Die Benutzer können sich jedoch, ohne eine andere URL zu verwenden, wieder neu anmelden und weiterarbeiten. Wie im Abschnitt „Unterstützung für clientseitiges Failover“ beschrieben, kann das ERP-System beispielsweise automatisch die zuletzt gestartete Anwendung bei der erneuten Anmeldung wieder starten und das zuletzt bearbeitete Business-Entity laden.

Ein Load-Balancer verteilt sobald ein SAS ausfällt weitere eingehende Verbindungsanforderungen transparent für den Benutzer auf die noch zur Verfügung stehenden SAS und trägt so zu der Hochverfügbarkeit eines Systems bei.  .

4.6               Verteilte Verarbeitungs-Warteschlangen

Die Verarbeitungsaufträge in einer verteilten Verarbeitungs-Warteschlange werden von allen Application-Servern bearbeitet, die Worker (Threads) für diese Verarbeitungs-Warteschlange bereitstellen. Die anstehenden Verarbeitungsaufträge werden automatisch auf die laufenden Application-Server verteilt. Wenn einer der einer verteilen Verarbeitungsschlange zugeordneten Application-Server nicht zur verfügbar ist, so werden die anstehenden Verarbeitungsaufträge von den anderen der verteilten Verarbeitungs-Warteschlange zugeordneten Application-Servern bearbeitet. Wiederanlauffähige Verarbeitungsaufträge, die zum Ausfallzeitpunkt auf dem Application-Server in Bearbeitung waren, werden automatisch auf einem anderen Worker der verteilten Verarbeitungs-Warteschlange gestartet. Nicht widerauflauffähige Verarbeitungsaufträge werden abgebrochen und müssen manuell neu gestartet werden.

In den Dokumenten „Systemcockpit Typ: „Application-Server““ und „Systemcockpit Typ: „Verarbeitungs-Warteschlange““ ist beschrieben, wie Sie verteilte Verarbeitungs-Warteschlangen konfigurieren.

5                     Vorgehensweisen

Die Anforderungen an die Verfügbarkeit des Systems sind individuell. Je höher die Verfügbarkeit sein soll, desto höher sind die Kosten. Im Folgenden werden Konfigurationsvarianten beschrieben, die die Verfügbarkeit des Systems erhöhen. Sie können diese Varianten je nach Anforderung kombinieren oder variieren.

5.1               Verteilte Verarbeitungs-Warteschlangen

Voraussetzungen

Sie benötigen mindestens zwei aber besser mehr unabhängige Rechner, die jeweils ausschließlich für Hintergrundverarbeitung bestimmt sind. Die Rechner müssen so ausgelegt sein, dass beim Ausfall eines Rechners, die übrigen Rechner noch genügend Worker bzw. Rechenleistung übrig haben, um den störungsfreien Betrieb zu gewährleisten.

Beachten Sie, dass Sie bei einer CPU pro Application-Server nicht mehr als 3 Worker für Hintergrundverarbeitung erfassen dürfen.

Anleitung

1. Erfassen Sie eine Verarbeitungs-Warteschlange ohne Application-Server mit dem Namen „SERVICES“ für die Application-Server unabhängigen Dienste.
2. Ordnen Sie der Verarbeitungs-Warteschlange „SERVICES“ so viele Worker auf so vielen unterschiedlichen Rechnern zu, dass beim Ausfall eines einzelnen Rechners, noch hinreichend viele Worker übrig bleiben, um alle Dienste zu starten.

Beispiel:

Wenn sie 2 Dienste betreiben möchten, dann erfassen Sie auf 3 Application-Servern, die auf 3 unterschiedlichen Rechnern laufen, je einen Worker für die Verarbeitungs-Warteschlange „SERVICES“.

3. Erfassen Sie eine Verarbeitungs-Warteschlange ohne Application-Server mit dem Namen „USERJOBS“ für kurz laufende Verarbeitungsaufträge.
4. Ordnen Sie der Verarbeitungs-Warteschlange „USERJOBS“ so viele Worker auf so vielen unterschiedlichen Rechnern zu, dass beim Ausfall eines einzelnen Rechners, noch hinreichend viele Worker übrig bleiben, um alle die kurz laufenden Verarbeitungsaufträge in akzeptabler Zeit zu verarbeiten.

Beispiel:

Wenn Sie mindestens 2 Application-Server mit je 2 Workern benötigen, um kurz laufend Verarbeitungsaufträge zu verarbeiten, dann erfassen Sie auf 3 Application-Servern auf 3 unterschiedlichen Rechnern, je 2 Worker für die Verarbeitungs-Warteschlange „USERJOBS“.

5. Erfassen Sie eine Verarbeitungs-Warteschlange ohne Application-Server mit dem Namen „MASSJOBS“ für lang laufende Verarbeitungsaufträge.
6. Ordnen Sie der Verarbeitungs-Warteschlange „MASSJOBS“ so viele Worker auf so vielen unterschiedlichen Rechnern zu, dass beim Ausfall eines einzelnen Rechners, noch hinreichend viel Worker übrig bleiben, um alle die lang laufenden Verarbeitungsaufträge in akzeptabler Zeit zu verarbeiten.

Beispiel:

Wenn Sie mindestens 1 Application-Server mit je einem Worker benötigen, um lang laufend Verarbeitungsaufträge zu verarbeiten, dann erfassen Sie auf 2 Application-Servern auf 2 unterschiedlichen Rechnern, je einem Worker für die Verarbeitungs-Warteschlange „MASSJOBS“.

5.2               Alternative Message-Server

Voraussetzungen

Sie benötigen mindestens zwei unabhängige Rechner auf die Sie die alternativen Message-Server verteilen können. Diese Rechner sollten angemessen ausfallsicher sein. Wenn Sie alternative Message-Server nutzen, prüfen Sie, ob Sie nicht auch das Datenbank-Failover benötigen. Sowohl die Datenbank als auch die Message-Server sind Single Points of Failure und bei gleich guter Hardware haben beide Komponenten die gleiche Ausfallwahrscheinlichkeit.

Anleitung

1. Erfassen Sie zwei Application-Server auf unterschiedlichen Rechnern.
2. Tragen Sie die beiden Application-Server als alternative Message-Server beim System ein.