von Thomas Hertel
Die IT hat sich im Handel längst vom Kosten- zum Produktionsfaktor gemausert. Und zwar zu einem der wichtigsten, denn ohne IT funktionieren weder Lagerhaltung noch Logistik, weder Einkauf noch Shop-Optimierung. Einfache Fehler, technische oder menschliche, können dabei erhebliche Auswirkungen haben: Wenn der Kassenserver streikt, geht in der Filiale nichts mehr – Umsatzeinbußen sind die unmittelbare Folge. Steht der Web-Server mit dem Online-Shop, ist der Kunde mit einem Mausklick beim nächsten Wettbewerber – mit den gleichen Folgen. Solche Einbußen müssen sich nicht auf die tatsächliche Ausfallzeit beschränken; manch unzufriedener Kunde wendet sich auch dauerhaft vom Unternehmen ab.
Wenn schon ein lokaler Systemausfall teuer werden kann – wie sieht es dann erst mit den zentralen Servern aus, auf denen alle für das Unternehmen lebensnotwendigen Applikationen betrieben werden und die Informationen aus den Kassensystemen vor Ort zusammenlaufen? Häufig laufen zwar die kritischsten zentralen Anwendungen auf stabilen iSeries oder ähnlichen Systemen und sind mit High Availability-Lösungen wie Mimix von Vision Solutions gut gegen Ausfälle gesichert, doch ebenso kritische Windows-Applikationen wie Exchange, SQL, Oracle oder SharePoint müssen oft auf einen solchen Schutz verzichten. Vielfach wird dabei übersehen, dass selbst eine scheinbar extrem hohe Verfügbarkeit von 99,5 Prozent statistisch immer noch 44 Stunden Ausfallzeit pro Jahr entspricht.
Hinzu kommt die Tatsache, dass die Ausfallzeit des Servers nur eine Komponente bei der Verfügbarkeit der Gesamtlösung ist. Mit der Wiederherstellung der Hardware ist es nicht getan; oft müssen Betriebssystem und Anwendungen neu installiert sowie Daten von Backup-Systemen wiederhergestellt werden. Je nach Backup-Konzept kann das etliche Stunden oder gar Tage dauern. Zudem kann es natürlich auch jederzeit zu Datenverlusten kommen, ohne dass es überhaupt Hardware-Probleme beim Server gibt.
Sicherheit mit Augenmaß
Gerade bei Datenverlusten, ob nun in Verbindung mit einem Hardware-Problem oder nicht, stellen sich zwei grundlegende Fragen:
- Wie lange darf es höchstens dauern, bis die Systeme und Daten wiederhergestellt sind und den Anwendern wieder zur Verfügung stehen? Hier spricht man in Fachkreisen von der Recovery Time Objective (RTO).
- Wie alt dürfen die Daten sein, die wiederhergestellt werden, oder in anderen Worten, wie viel Datenverlust kann das Unternehmen sich erlauben? Dies wird als Recovery Point Objective (RPO) bezeichnet.
Hier gibt es meist keine unternehmensweit gültigen Zahlen, sondern diese Fragen sind für unterschiedlich kritische Systeme auch unterschiedlich zu beantworten. So kommt es bei den Kassensystemen vor allem auf eine kurze Wiederherstellungszeit an (kurze RTO), während in der Warenwirtschaft die Vermeidung von Datenverlusten im Vordergrund steht (kurze RPO).
Geht man davon aus, dass bei kritischen Kernanwendungen Ausfallzeiten von einer Stunde schon Kosten im fünf- oder gar sechsstelligen Bereich verursachen können und der Verlust von Transaktionsdaten ebenfalls erhebliche Kosten mit sich bringt, wird schnell klar, dass traditionelle Backup-Lösungen den Anforderungen im Handel in der Regel nicht mehr gewachsen sind. Zum einen dauert die Widerherstellung von Magnetbändern zu lange, zum anderen stehen dabei nur die Daten vom letzten Backup-Lauf zur Verfügung. Und das sind typischerweise die vom vergangenen Abend. Alle im Laufe des Tages entstandenen oder geänderten Daten sind dann verloren. Wenn es überhaupt noch Daten gibt, denn schon oft stellte sich erst beim Versuch der Wiederherstellung heraus, dass das Backup gar nicht so funktioniert hatte wie geplant.
Im Shop selber kommt noch dazu, dass in der Regel vor Ort keine IT-Spezialisten beschäftigt werden. Für die Datensicherung ist hier der Filialleiter oder jemand vom Verkaufspersonal verantwortlich; das Band wird dann meist mitsamt den Tageseinnahmen vom Werttransport-Unternehmen abgeholt und eingelagert. Dieses Verfahren mag noch angehen, solange alles gut geht, aber wenn tatsächlich einmal Daten wiederhergestellt werden müssen, muss dafür extra ein Spezialist aus der Zentrale anreisen oder ein teurer Dienstleister eingeschaltet werden. Beide Lösungen bringen erhebliche Ausfallzeiten mit sich – und entsprechende Umsatzverluste.
Es müssen also Alternativen zum klassischen Backup her, doch welche? Wie bereits angedeutet, gibt es dafür keine allgemeingültige Antwort. Die zentralen Anwendungen müssen rund um die Uhr verfügbar sein, die Kassensysteme zumindest während der Ladenöffnungszeiten – was in punkto Absicherung keinen Unterschied macht. Ein einstündiger Ausfall des Mailservers ist dagegen für viele Unternehmen nicht allzu kritisch. Fällt ein Server in einer Filiale aus, hat das in der Regel geringere Auswirkungen als beim zentralen Bestellsystem, mit dem die Kassenserver aus allen Filialen ständig kommunizieren müssen. Entsprechend haben die Systeme auch unterschiedliche Anforderungen an ein Hochverfügbarkeits-Konzept. Es ist auch wirtschaftlich in der Regel nicht vertretbar, ein Konzept, das für die unternehmenskritischen Server entwickelt wurde, auf alle Systeme im Unternehmen zu übertragen. Gerade im Handel mit seinen geringen Margen kommt es darauf an, für jedes System die passende Lösung zu finden. Die Devise muss also sein: „Für jedes System die Sicherheit, die es benötigt“. Nicht weniger, aber auch nicht mehr.
Virtualisierung als Lösung?
Bei den zentralen Applikationen mit ihren proprietären Serversystemen wie AS/400 beziehungsweise System i haben sich viele Logistik-Unternehmen für Hochverfügbarkeitskonzepte auf der Basis von Replikationstechnologien entschieden. Solche Lösungen wie Mimix HA von Vision Solutions replizieren die Produktionsumgebung in Echtzeit und ohne Datenverluste auf einen Backup-Server. Mimix unterstützt dabei jede beliebige Anwendungsumgebung und Netzwerktopologie, einschließlich Intra-Server-Replikation, zwei- und dreistufiger ERP-Umgebungen, bidirektionaler Replikation und Kaskaden-Replikation. Fällt nun der Produktionsserver aus, kann der Backup-Server innerhalb kürzester Zeit seine Funktion übernehmen, so dass die Anwender praktisch unterbrechungsfrei weiterarbeiten können und auch keine Datenverluste entstehen. Zudem ermöglichen solche Hochverfügbarkeitskonzepte es den Verantwortlichen, Wartungsarbeiten am Produktivsystem ebenso ohne Unterbrechung des laufenden Betriebs durchzuführen wie den Test neuer Applikationen oder Updates.
Während in vielen Unternehmen die zentralen Applikationen auf diese Weise gut gesichert sind, laufen die meisten der nicht ganz so kritischen Anwendungen auf Windows-Servern oder auch auf Linux-Systemen; letztere sind vor allem im Bereich der Web-Server populär. Unternehmenskritisch sind hier vor allem die Exchange-, Datenbank- und File-Server, in vielen Fällen auch Sharepoint- oder Blackberry-Server. Eine nahe liegende Maßnahme zur Absicherung solcher Server ist oft der Einsatz von Speichervirtualisierung. Mit dieser Technologie lassen sich Snapshots beliebiger Laufwerke sehr schnell erstellen und verteilen. Durch die Replikation der Snapshots an unterschiedlichen Orten lässt sich mit diesem Ansatz eine sehr wirkungsvolle Disaster Recovery-Strategie umsetzen. Eine Alternative dazu ist die Spiegelung des kompletten Storage Area Networks (SAN) – wodurch beispielsweise Recovery Point Objectives von 30 Minuten zuverlässig erreicht werden können.
Ein virtualisiertes Failover-Konzept erhöht die Verfügbarkeit der Systeme deutlich, hat aber auf der anderen Seite durchaus Schwachstellen. Speichervirtualisierung benötigt an allen Standorten redundante Hardware – eine Anforderung, die die Kosten für Disaster Recovery mit dieser Technologie schnell in die Höhe treibt. Die SAN-Spiegelung hat dazu noch eine vergleichsweise geringe Reichweite und setzt Fibrechannel im Netzwerk voraus. Dadurch ist dieser Ansatz für viele, aber sicher nicht alle Szenarien geeignet, gegen die sich ein Unternehmen durch ein Disaster Recovery-Konzept schützen möchte. Auch erfordert nicht jede Anwendung ein so aufwändiges Sicherheitskonzept.
In vielen Fällen genügt die Replikation von Daten in Echtzeit, wobei je nach Anwendungsfall einer oder mehrere Quellserver auf ebenfalls einen oder mehrere Zielserver repliziert werden. Allerdings sollte man sich hier nicht auf die Replikations-Tools einzelner Applikationen verlassen, die oft erhebliche Anforderungen stellen und schwer zu implementieren und zu verwalten sind. Zudem gibt es viele Applikationen, die keine Replikations-Mechanismen zur Verfügung stellen, und diese müssten ohnehin nach wie vor auf andere Weise gesichert werden.
Zentrales Backup der lokalen Kassenserver
Für Filialisten kann eine solche Lösung auch noch aus ganz anderen Gründen interessant sein. Ihnen steht damit nämlich eine Möglichkeit zur Verfügung, die Kassenserver in den einzelnen Shops unter vollständiger Kontrolle der IT-Abteilung und ohne Beteiligung nicht dafür qualifizierter, lokaler Mitarbeiter auf einen Server im zentralen Rechenzentrum zu sichern – und zwar in Echtzeit und rund um die Uhr. Bei einem lokalen Datenverlust stehen sämtliche Daten im Rechenzentrum zur Verfügung und können unter der Kontrolle der IT-Abteilung innerhalb kürzester Zeit wiederhergestellt werden. Fällt gar ein Kassenserver in einer Filiale aus, kann der zentrale Backup-Server über ein Failover innerhalb weniger Minuten dessen Aufgaben übernehmen, so dass Umsatzverluste vermieden werden.
Bei einem zentralen Backup-Konzept mit Replikation und – bei Bedarf – Failover kann die bisher übliche Bandsicherung der lokalen Server vollständig entfallen. Erst im Rechenzentrum werden die Daten von qualifizierten Mitarbeitern auf Platte oder Band archiviert. Gleichzeitig können sie auf dieselbe Art oder per Geocluster in ein Ausweichrechenzentrum repliziert werden, etwa in einem regionalen Auslieferungslager oder einer größeren Filiale. So entsteht auf preisgünstige Weise eine mehrstufige Sicherheitslösung, die den Ausfall einzelner Kassenserver, aber auch den des gesamten Rechenzentrums praktisch ohne Ausfallzeiten und Datenverluste verkraften kann.
Ein Punkt sollte allerdings bei allen Replikationslösungen berücksichtigt werden: Sie helfen nicht gegen vorsätzliche oder versehentliche Datenmanipulation. Versehentliches Löschen wichtiger Daten oder Virenbefall sind nicht selten; Sabotage kommt glücklicherweise weniger häufig vor, ist aber auch nie gänzlich auszuschließen. Das Ergebnis solcher Vorfälle wird bei einer Replikationslösung wie bei jedem anderen Backup-Verfahren ebenfalls gesichert; eine versehentlich gelöschte Datei lässt sich also nicht ohne weiteres vom Zielserver wiederherstellen. Eine Replikationslösung macht daher das traditionelle Backup nicht immer entbehrlich; in der Regel sollten die Zielserver nach wie vor durch ein Disk-to-Disk-, ein Disk-to-Tape- oder ein Disk-to-Disk-to-Tape-System abgesichert werden, so dass Daten notfalls auch von hier wieder hergestellt werden können. Solche Systeme sind für die Langzeit-Archivierung aber ohnehin erforderlich.
Thomas Hertel ist freier Journalist in München.