"Zero Downtime" bei SAP-Upgrade

13.02.2006 von Stefan  Ueberhorst
Realtech verspricht SAP-Kunden, die einen Release-Wechsel oder eine Migration ihres R/3-Systems planen, dass die damit einhergehenden Ausfallzeiten mit einem neuen Verfahren nahezu gegen Null gehen.

Aktuelle Studien von RAAD-Consult haben ergeben, dass knapp 70 Prozent der SAP-Kunden im Jahr 2006 ein Upgrade ihres Systems von "R/3 4.6c" auf "R/3 Enterprise 4.7" oder "Mysap ERP" planen. Ob Release-Wechsel, Plattform-Migrationen oder auch die Umstellung auf Unicode: Unterbrechungen des Systembetriebs sind in diesen Fällen vorprogrammiert. Wie lange dieser Systemstillstand andauert, ist in erster Linie vom eingesetzten Upgrade- beziehungsweise Migrationsverfahren abhängig.

Stillstand bis zu 24 Stunden

Das Zero-Downtime-Verfahren verwendet für den Release-Wechsel beziehungsweise die Migration des SAP-Systems eine Datenbankkopie, auf der die Benutzer während der Umstellung arbeiten. Der Stillstand des Systems beschränkt sich damit auf das zweimalige Umschalten der Anwender.

Laut der in Walldorf ansässigen Realtech AG liegen die Ausfallzeit der bisherigen Upgrade- und Migrationsverfahren in der Regel zwischen sechs und 24 Stunden. Standard-Upgrades auf das Ziel-Relase 4.6c verursachen Ausfallzeiten, die je nach System und Größe mehr als 24 Stunden betragen können. Während dieser Zeit stehen alle auf dem jeweiligen System abgebildeten Geschäftsprozesse still. Um die daraus resultierenden Auswirkungen möglichst in Grenzen zu halten, ist es notwendig, den Termin für solche Aktionen entsprechend zu planen, sie also eventuell am Wochenende vorzunehmen. Kommen also für die Systemumstellung ohnehin nur wenige Termine im Jahr in Frage, laufen Anwender zudem Gefahr, dass sie bei unplanmäßigem Verlauf oder bei unerwarteten Störungen eine noch längere Ausfallzeit in Kauf nehmen müssen. Im schlimmsten Fall ist ein Rollback erforderlich: Das Projekt wäre somit gescheitert und müsste dann neu geplant werden.

Um die Downtime während des Upgrades zu verringern, entwickelte SAP ein zeitoptimiertes Upgrade-Verfahren, das "System Switch Upgrade". Es reduziert die Ausfallzeiten deutlich, da einzelne Schritte des Upgrades bereits erfolgen, während das System noch produktiv ist. Allerdings erweist sich dieser Schritt in vielen Situationen als noch nicht ausreichend, zumal wenn bestimmte Anwendungen eines Unternehmens eine 24x7-Verfügbarkeit voraussetzen. Ein weiterer Nachteil des Verfahrens ist, dass zusätzliche Systemressourcen benötigt werden.

Intensive Vorbereitung

Realtech hat nun mit "Zero Downtime" ein Verfahren vorgestellt, mit dessen Hilfe wichtige Kern-Geschäftsprozesse während des Upgrades beziehungsweise der Migration nahezu ohne Unterbrechung zur Verfügung stehen: Systemausfallzeiten seien hiermit zu vernachlässigen, so der Anbieter. Das Verfahren hat einen hohen Serviceanteil. Unternehmenskritische Geschäftsprozesse, die auch während der Systemumstellung verfügbar sein müssen, werden gemeinsam mit dem Kunden analysiert und definiert. Anschließend werden aus den festgelegten Prozessen die benötigten Transaktionen abgeleitet und dafür dann eine individuelle Lösung entwickelt.

Zu Beginn des Upgrades oder der Migration erstellt man ein Duplikat der Datenbank. Die Benutzer werden im nächsten Schritt vom Produktivsystem getrennt und auf die Kopie umgeleitet. In dieser stehen alle im Vorfeld definierten kritischen Transaktionen während der gesamten Dauer der Umstellung des Produktivsystems unterbrechungsfrei zur Verfügung. Auf der Client-Ebene sind keine Änderungen in der Konfiguration erforderlich, sofern bereits mit Alias-Host-Namen gearbeitet wird.

Für die Zwischenspeicherung der Daten auf der Systemkopie und für die Weiterleitung an das Produktivsystem, die in einem späteren Schritt erfolgt, wird SAPs "Exchange Infrastructure" (SAP XI) oder die Realtech-eigene Software "Interface Manager IM/3" verwendet. Beide Lösungen sorgen für ein konformes Mapping auf die Strukturen des Produktivsystems nach dem Upgrade. Im Fall einer Migration entfällt das Mapping, da hier die Datenstrukturen des Quell- und Ziel-Release identisch sind. Monitoring-Funktionen sollen die korrekte Aufzeichnung, Reihenfolge und spätere Verbuchung der Daten sichern.

Projektphasen auf einen Blick

  • Kritische Prozesse analysieren;

  • daraus die benötigten Transaktionen ableiten;

  • Duplikat der Datenbank erstellen, auf der die Transaktionen während der Umstellung zur Verfügung stehen;

  • Benutzer vom Produktivsystem trennen und auf die Datenbank- kopie umleiten;

  • Mapping der zwischengespeicherten Daten auf das neue Produktivsystem (nur bei Upgrade nötig, nicht bei Migration);

  • Tests und Nacharbeiten auf dem Upgrade;

  • Netzumstellung auf das neue System und gleichzeitiges Einspielen der zuletzt aufgezeichneten Daten;

  • Anmelden der Benutzer am Upgrade beziehungsweise migrierten System.

Auch Nacharbeiten zeitunkritisch

Das Zero-Downtime-Verfahren ermöglicht auch eine zeitunkritische Planung der obligatorischen Nacharbeiten nach einem Upgrade beziehungsweise einer Migration. Begleitend gibt es Tests am neuen System, bevor man die Benutzer wieder auf das Produktivsystem zurückschaltet. Mit der Netzwerkumstellung zurück auf das Originalsystem werden gleichzeitig die letzten aufgezeichneten Daten eingespielt. Sobald diese verbucht sind, können die Benutzer nach einer Neuanmeldung sofort mit den aktuellen Daten auf dem neuen System weiterarbeiten. Die Ausfallzeiten des Systems beschränken sich damit auf die zweimalige Umschaltung der Benutzer.