ERP-Hochverfügbarkeitslösung für kleine und mittelständische Unternehmen

• Home

Ein Großteil der in der Wertschöpfungskette entstehenden Bewegungsdaten werden innerhalb eines ERP-Systems erfasst, bearbeitet und gespeichert. Daher werden mit Recht an das Sicherheitsniveau und die Verfügbarkeit eines solchen Systems hohe Anforderungen gestellt. In der Vergangenheit ließen sich solche Anforderungen nur mit hohem technischen und finanziellen Aufwand umsetzen. Besonders ungünstig ist, dass diese Aufwendungen häufig sogar bei Updates, Migrationen oder Systemwechseln erneut entstehen. Hier wird demgegenüber anhand eines Beispieles ein Ansatz aufgezeigt, der einen langfristigen betrieblichen Einsatz durch die weitestgehende Plattformunabhängigkeit (Windows, Linux, etc.) möglich macht. Dieser Ansatz wird beispielhaft anhand des ERP-Systems von Mesonic -der Enterprise WINLine , kurz EWL - dargestellt.

Denn selbst das beste ERP-System nützt nichts, wenn die zur Verfügung gestellten Dienste nicht erreichbar sind bzw. ausfallen. Durch die zunehmende Globalisierung sind Unternehmen vermehrt darauf angewiesen, dass die Applikationen 24 Stunden am Tag und 365 Tage im Jahr verfügbar sind. Da der Begriff Hochverfügbarkeit im Weiteren eine zentrale Bedeutung hat, soll er kurz definiert werden: Der Begriff "Hochverfügbarkeit" bezeichnet die Fähigkeit eines Systems, bei Ausfall einer seiner Komponenten einen uneingeschränkten Betrieb zu gewährleisten. Wichtig ist in diesem Zusammenhang, dass eine Anwendung auch im Fehlerfall weiterhin verfügbar ist, ohne dass ein unmittelbarer menschlicher Eingriff notwendig ist [1].

Dabei wird durch die Harvard Research Group (HRG) die Hochverfügbarkeit in ihrer Availability Environment Classification (kurz: AEC 0-5) in sechs Klassen eingeteilt. Bei dem hier dargestellten Lösungsansatz ist die AEC-Klasse 1 (eine prozentuale Verfügbarkeit von 99,9%), also eine Ausfallzeit von maximal 8,76 Stunden im Jahresdurchschnitt möglich. Das bedeutet ausserdem, dass die Funktion unterbrochen werden kann, die Datenintegrität jedoch gewährleistet sein muss. [2]

ERP-Lösung ohne Ausfallzeiten

Besonders im Vordergrund beim Einsatz einer ERP-Lösung stehen aus Sicht des Betriebes die Konsistenz und Aktualität der Daten. Sollte der Dienst kurzzeitig einmal ausfallen, so hat dies häufig keine größeren Folgen. Ein finanzieller Verlust entsteht meist erst dadurch, dass Daten verloren gehen, nicht mehr vollständig sind oder verfälscht werden. Diesem wird in der Regel durch Einsatz von geclusterten DBMS-Systemen (z.B. MS-SQL-Server) entgegengewirkt, was jedoch einen hohen technischen und auch finanziellen Aufwand bedeutet.

Die Vermeidung von Ausfallzeiten kann jedoch letztendlich nur durch den Aufbau von redundanten Strukturen erreicht werden.

Auch in dem hier dargestellten Fall werden mehrere Server verwendet, um die erzeugten Daten redundant zu speichern. Dies muss selbstverständlich vollständig automatisch, also ohne Benutzereingriff, erfolgen. Ein effektiver Lösungsansatz garantiert, dass alle Daten auf demselben Stand sind (Replikation).

Solche Lösungsansätze werden bereits für die meisten auf dem Markt angebotenen ERP-Systeme angeboten und können z.B. durch den Einsatz von Microsoft SQL-Server-Clustern realisiert werden. Doch sind hier die anfallenden Lizenzkosten für Betriebssysteme, Zugriffslizenzen, Clustersoftware, Monitoringsoftware etc. und die abweichende Architektur zu berücksichtigen. Der hier dargestellte Lösungsansatz geht jedoch noch einen Schritt weiter, da zusätzlich eine Lastverteilung bzw. ein Failover-Cluster für den Dienst bzw. das Anwendungssystem (das ERP-System) geschaffen wird [3].

Der Aufbau solcher Lösungen ist sehr komplex und wurde in der Vergangenheit oft für ein individuelles Anwendungsfeld aufgebaut und betrieben. Daher ist es extrem wichtig, dass solche besonders sicheren Lösungen quasi "out of the box" für den betrieblichen Einsatz zur Verfügung gestellt werden können. Sowohl der finanzielle als auch der technische Aufwand für den Aufbau einer individuellen Lösung sind nach dem heutigen Stand der Technik und der Wissenschaft nicht mehr sinnvoll zu begründen.

Zudem steigt mit einem gewissen Maß an Standardisierung auch die Zuverlässigkeit der Lösung durch erhöhte Transparenz. Es empfiehlt sich hier zudem dringend der Einsatz von zuverlässigen und bewährten Architekturen und Technologien.

Dass der Einsatz einer solchen Lösung sich auf jeden Fall rechnet, ergibt sich automatisch bereits durch die Aufrechnung der Arbeitsstunden aller Mitarbeiter über den gesamten Zeitraum des Ausfalls. In der Regel liegt damit der Anschaffungspreis einer solchen Lösung weit unter der entstehenden Schadens-Summe durch einen gravierenden Systemausfall.

Lösungsansatz

Bild 1 verdeutlicht die Funktionsweise des hier realisierten Lösungsansatzes. Es stehen permanent mindestens zwei Server (aktiv, in diesem Fall EWL 1 mit Datenhaltung) zur Verfügung, von denen einer aktiv die Anfragen durch die Arbeitsstationen beantwortet. Mindestens ein weiterer Server (passiv), in diesem Fall EWL 2 mit Datenhaltung) steht bereit, um im Falle eines Ausfalls des ersten (aktiven) Servers umgehend dessen Dienste zu übernehmen (Prinzip eines Failover- Clusters) [3].

Bild 1: Hochverfügbarkeitslösung

Jeder der beiden dargestellten Hauptkomponenten EWL1 und EWL2 sind hierbei üblicherweise identisch aufgebaut. Sie sollten auf den gleichen Hardwarekomponenten basieren, um die Konfiguration möglichst einfach zu halten – dieses muss jedoch nicht zwangsläufig gegeben sein. Die beiden Serversysteme können direkt mit Betriebssystemen betrieben werden, jedoch ist der plattformneutralste und zukunftsträchtigste Weg, die Server zunächst mit Wirtsbetriebssystemen als Virtualisierungsplattform zu versehen. In unserem Fall wird ein Open-Source- Linux (OpenSuse 10.3 64 Bit) und die Virtualisierungssoftware VMware-Server 1.0.5 verwendet. Dadurch lassen sich nahezu alle Hardwareabhängigkeiten vermeiden bzw. abstrahieren. Der durch eine zusätzliche Schicht entstehende Performance-Verlust (von ca. 5 bis 25%) lässt sich durch geeignete Auswahl und Abstimmung der Komponenten und durch die geeignete Konfiguration auf ein Mindestmaß reduzieren [4].

Die nächste Schicht stellt das Betriebssystem für das ERP-System dar. Hier kommen typischerweise Windows- oder Unix/Linux – Betriebssysteme zum Einsatz. Durch die Verwendung der Virtualisierungstechnologie kann hier mit einer einheitlichen "virtuellen Hardware", also mit einheitlichen Treibern gearbeitet werden, welches den Aufwand für die Administration und Wartung der Systeme extrem reduziert. In unserem Fall kommen Linux-Betriebssysteme zum Einsatz. Filesysteme dienen in erste Linie zur Verwaltung und Ablage von Dateien. Moderne Filesysteme wie z.B. EXT3 ermöglichen einen sicheren Betrieb u.a. durch Funktionen wie "Journaling". Trotz hoher Leistung wird die Konsistenz permanent durch das Führen eines Journals sichergestellt. Da jedoch die kleinste Einheit aus Sicht eines Dateisystems eine Datei darstellt, ist dieses Verfahren im Einsatz mit Datenbankmanagementsystemen mit eventuell sehr großen Dateien nur bedingt geeignet.

In der Praxis wird daher oft auf Hardware-Ebene eine Redundanz durch Festplattenspiegelung geschaffen (Mirroring). Jedoch entsteht dabei ein "Single Point Of Failure" (SPOF), da sich alle Komponenten innerhalb eines physikalischen Gerätes befinden. Als optimierter Lösungsansatz auf dieser Ebene kommt dann in dem hier vorgestellten Lösungsansatz noch die Replikation über ein Netzwerk via DRBD hinzu.[5] Das entspricht einer "Spiegelung via TCP/IP-Netzwerk" und arbeitet wie die hardwarebasierte Spiegelung von Festplatten blockbasiert. Auf diese Art und Weise kann sichergestellt werden, dass auf zwei völlig autarken Serversystemen, bis auf die Differenz eines einzelnen Blockes, alle Daten aktuell, identisch gespeichert werden.

Ein Clustering auf der nächsthöheren Schicht der Datenbankmanagementsysteme (DBMS) kann aus diesem Grund entfallen. Dadurch kann technischer und finanzieller Aufwand eingespart werden. Zudem können auch DBMS zum Einsatz kommen, die gar kein Clustering unterstützen. In diesem Szenario kommt aus diversen Gründen Postgres zum Einsatz (z.B. unterstützt die ERP-Software direkt das DBMS PostgreSQL [6]). Als letzte Schicht verbleibt die Applikation, also die ERP-Software, die möglichst alle Anforderungen des Betriebes und der Anwender erfüllen sollte.

Sicherstellung des Betriebs

In dem plötzlichen eintretenden Fall einer Störung des momentan aktiven Servers EWL1, sind die folgenden Aktivitäten zur Weiterführung des Betriebes der ERP-Software notwendig. Als erstes wird der ehemals aktive Server EWL1 deaktiviert (z.B. heruntergefahren), damit durch diesen keine weiteren Schreibzugriffe erfolgen. Zweitens muss der ehemals passive Server EWL2 nun die aktive Rolle übernehmen, das heißt, dass er Lese- /Schreibzugriff auf das "gemeinsame Speichermedium" erhalten muss, dass die ERP-Software und das Datenbankmanagementsystem gestartet und aktiviert werden müssen. Diese Aktivitäten zur Realisierung des Failover-Clusters werden durch Heartbeat [3,7] und DRBD vorgenommen.

Durch dieses Verfahren ist gewährleistet, dass ohne unmittelbaren menschlichen Eingriff (z.B. eines Administrators) im Betrieb umgehend weitergearbeitet werden kann. Auf diese Weise können Störungszeiten und damit entstehende Kosten mit einem vertretbaren Aufwand minimiert werden.

Je nach Umfang und Dauer der Störung ist das Weiterarbeiten an den Arbeitsstationen innerhalb weniger Sekunden möglich. Besonders erwähnenswert ist, dass es hierbei quasi nicht zu einem Datenverlust kommt, da maximal der letzte geschriebene Block fehlen könnte. In Kombination mit dem Transaktionssystem des Datenbankmanagementsystems bleibt die Konsistenz der Datenbasis gewährleistet.

Ausblick

Mit Hilfe des Lösungsansatzes kann ein ausfallsicherer Betrieb eines ERPSystems durchgeführt werden. Die Störungen können automatisch erkannt und behandelt werden. Ein weiterer Vorteil dieses Ansatzes ist, dass durch die Lastverteilung auf mehrere Server die Performance immer den aktuellen Bedürfnissen angepasst werden kann. Durch eine zusätzliche Monitoring-Komponente ließe sich die Erkennung und Beseitigung von Störungen weiter verbessern.

Literatur

[1] Hellberg, Günther: Einführung in die Hochverfügbarkeit, Vorlesungsskript Netzwerke / Betriebssysteme, Fachhochschule der Wirtschaft Hannover, 2007

[2] Wikipedia: de.wikipedia.org/wiki Hochverfügbarkeit, August 2008, diverse Definitionen von Hochverfügbarkeit und die AEC-Klassen der HRG

[3] Hellberg, Günther: Aufbau eines Failover-Clusters, Vorlesungsskript Netzwerke/ Betriebssysteme, Fachhochschule der Wirtschaft Hannover, 2008

[4] Hellberg, Günther: Virtualisierung in der Praxis, Vorlesungsskript Netzwerke/ Betriebssysteme, Fachhochschule der Wirtschaft Hannover, 2008

[5] Internet: www.drbd.org , August 2008, diverse Informationen zu DRBD

[6] Internet: www.postgres.de , August 2008, diverse Informationen zu PostgreSQL

[7] Internet: [[http://www.linux-ha.org/|http://www.linux-ha.org/<a>, August 2008, diverse Informationen zu Heartbeat

Fordern Sie hier Ihr kostenloses und unverbindliches Probeexemplar der Zeitschrift ERP Management an unter: <a href="http://tinyurl.com/dh2jbe" target="_blank">http://erp.gito.de/impress/formulare.nsf/…]]