Datacenter:
Praxis: Virtualisierungsrisiko real berechnen

von Bernd Reder (bernd.reder@networkcomputing.de), Joachim Brembeck

Share
28.05.2010

Server-Virtualisierung und -Konsolidierung ist in den meisten Rechenzentren längst Realität. Die Konzentration vieler Prozesse auf ein und derselben Hardware erfordert allerdings eine Neubewertung des finanziellen Ausfallrisikos. Wer die Kosten einer Downtime vorausberechnet, sieht sofort, wie viel ihm die Hochverfügbarkeit seiner Server wert sein sollte.

Die Zeiten, in denen sich leistungsstarke Server mit wenigen Aufgaben langweilten, sind vorbei. Server-Virtualisierung vermeidet durch eine Trennschicht zwischen Hardware und Betriebssystemen die gegenseitige Beeinflussung der installierten Workloads.

In friedlicher Eintracht teilen sich nun mehrere virtuelle Maschinen einen Rechner. Programme, die früher allein schon aus Inkompatibilitätsgründen auf mehrere physische Server verteilt wurden, laufen nun auf einem Rechner.

Ein weiterer Vorteil von Virtualisierung: Server können zeitweise oder komplett ausgeschaltet werden. Die Umwelt freut es – und auch das Controlling macht gerne mit, denn die Kosten sinken dadurch.

Risikobewertung muss neu vorgenommen werden

Weniger kooperativ zeigen sich die Zahlenjongleure allerdings, wenn es um das Thema Datenabsicherung und Hochverfügbarkeit geht. Da soll in Hard- und Software investiert werden, die nicht unmittelbar produktiv ist. So wird in der Regel eine Risikoabschätzung in Euro und Cent gefordert, um eine sinnvolle Investitionsentscheidung vorzubereiten. Schließlich will man ja nicht mit der teuersten Redundanz-Kanone auf einen Risiko-Spatzen schießen.

Schadensprognosen für den Downtime-Fall gibt es in vielen Unternehmen, sie wurden aber nicht selten vor der Virtualisierung erstellt und sollten der neuen Risikosituation angepasst werden. Denn das Risiko verteilt sich nach der Virtualisierung anders als zuvor.

Insgesamt sind weniger Server am Netz – und wo weniger Hardware ist, kann logischerweise auch weniger kaputt gehen. Das ist die gute Nachricht.

Die schlechte: Das Risiko kumuliert sich auf den konsolidierten Servern. Fällt einer von ihnen aus, ist sofort eine ganze Reihe von Services nicht mehr verfügbar. Dann wird aus dem Risiko-Spatz schnell ein kapitaler Pleitegeier.

Kosten von Serverausfällen berechnen

Grob lassen sich Unternehmen in zwei Gruppen einteilen: Solche, die bereits von einem größeren Ausfall von IT-Systemen betroffen waren und solche, die ihn noch vor sich haben. Was aber kostet die Downtime nun konkret?

Grundkonfiguration: Änderungen auf dem Produktiv-Server werden sofort auf einen Ziel-Server repliziert. Fällt der Produktiv-Server aus, werden die Anwender einfach auf den zweiten Server umgeleitet und können schon nach kurzer Zeit weiterarbeiten. Ist der Schaden am Produktiv-Server behoben, erfolgt der Restore.

Eine Studie von CIO.com [1] zeigt, wie sich das Risiko in etwa verteilt: Eine Stunde »Offline« macht bei 42 Prozent der untersuchten Unternehmen moderate 1000 Dollar aus, bei mehr als einem Viertel stehen allerdings schon 10.000 Dollar pro Stunde. In der Spitzengruppe werden für ausgefallene Server gar 50.000 Dollar fällig – wohlgemerkt pro Stunde.

Was der Ausfall eines Servers genau kostet, lässt sich nach einer recht einfachen Formel ausrechnen:

Ausfallkosten= (To + Td) x (Rp+Lr)

To steht für die tatsächliche Dauer des Ausfalls in Zeiteinheiten.

Td bezeichnet die so genannte Delta Time. Darunter versteht man die seit dem letzten Backup verstrichenen Zeiteinheiten.

Rp (Rate of Personnel) bildet Kosten ab, die durch die untätig herumsitzende Belegschaft entstehen. Dieser Wert errechnet sich aus den monatlichen Personalkosten des betroffenen Bereichs, geteilt durch die geleisteten Zeiteinheiten.

Lr (Lost Revenue) schließlich gibt den entgangenen Profit an. Hier nimmt man am besten einen Durchschnittswert aus mehreren Monaten und dividiert ihn wieder durch die betrachteten Zeiteinheiten.

Auf diese Weise lässt sich das Risiko exakt berechnen, heruntergebrochen auf Tage, Stunden oder Minuten. Dass auf einem physischen Server mehrere virtuelle Maschinen angesiedelt sind, macht die Sache allerdings nicht gerade einfacher. Denn die einzelnen Workloads umfassen ja nicht selten verschiedene Teile des Unternehmens. Will man also das Risikopotenzial eines bestimmten Server errechnen, legt man zuerst nach der eben beschriebenen Formel die Ausfallkosten für jeden Workload fest und addiert diese dann.

Berechnung nach Workloads

Die nach Workloads getrennte Risikoabschätzung ist zwar mühsam, aber in mehrfacher Hinsicht hilfreich. Sollen Prozesse von einer physischen Maschine auf eine andere übertragen werden, lässt sich das neue Risikoprofil schnell aus den vorhandenen Modulen errechnen. Außerdem kann man so Konstellationen vermeiden, die eine unnötig hohe Risikoakkumulation auf einem physischen Server bedeuten würden.

Addiert man wiederum die Ausfallkosten der einzelnen Sever, kommt man schließlich das Gesamtrisiko für einen kompletten Standort.

Dass die Ausfallhäufigkeit in konsolidierten Rechenzentren aufgrund der geringeren Anzahl der in Betrieb befindlichen Komponenten abnimmt, spricht für die Virtualisierung. Für eine Kosten-Nutzen-Abschätzung bei der Anschaffung einer Hochverfügbarkeitslösung ist dieser Faktor aber leider nicht von Belang. Schließlich kann ja auch ein statistisch sehr unwahrscheinlicher Ausfall bereits am nächsten Morgen eintreten.

Rolle von Backups

Betrachtet man die Formel (To + Td) x (Rp+Lr) genauer, zeigt sich deutlich, dass die Art des Backups einen ganz entscheidenden Einfluss auf die Ausfallkosten hat. So werden etwa Band-Backups in der Regel einmal pro Nacht gezogen.

Fällt der Server dann am nächsten Tag um 17:00 Uhr aus, beträgt der Td-Wert bereits mindestens acht Stunden – ein erheblicher Multiplikator, auch wenn ein schneller Support die tatsächliche Ausfallzeit (To) gering hält.

Personalkosten

Der Personalkosten-Ausfallwert Rp wird stark durch moderne und vernetzte Arbeitsweise getrieben. So kann ein ausgefallener Mail- oder Internet-Server schnell die gesamte Belegschaft lahmlegen. Der entgangene Umsatz Lr hängt natürlich stark von der jeweiligen Applikation ab. Besonders teuer wird eine Downtime bei unmittelbar am Verkauf beteiligten Prozessen wie etwa E-Shops oder Warenwirtschaftssystemen.

Auch wenn eine Risikoabschätzung nach dieser relativ einfachen Formel keine statistischen Parameter wie Varianz oder Standardabweichung mit einbezieht, sind die Ergebnisse doch in der Regel ein schlagendes Argument gegenüber der Controlling-Abteilung – zeigen sie doch, dass auch ein relativ kurzer Ausfall oft viel, viel teurer kommt als eine richtig dimensioniertes Hochverfügbarkeits-System.

Die entscheidende Frage bleibt dabei immer: Was ist ein richtig dimensioniertes Hochverfügbarkeits-System?

Permanente Replikation statt Snapshots

Die Formel zur Kostenabschätzung zeigt, dass sich die Downtime und die seit dem letzten Backup verstrichene Zeit addieren. Deshalb ist es wichtig, alle Änderungen am Datenbestand möglichst kontinuierlich zu sichern. Dabei gibt es verschiedene Methoden.

Asynchrone Replikation: Geänderte Daten werden zwischen Betriebssystem- und Dateisystem-Ebene abgefangen und sofort an das Zielsystem weitergeleitet, ohne dass das Programm auf eine Bestätigung wartet. Dadurch wird das Datenaufkommen so gering, dass die Replikation auch über gängige Internet-Verbindungen erfolgen kann.

Bei der synchronen Replikation fängt die Software Schreibzugriffe ab und sendet sie gleichzeitig an das primäre und sekundäre Array. Erst wenn beide den Empfang bestätigt haben, akzeptiert das Programm den nächsten Write-Request. Beide Speicher haben also immer exakt denselben Stand, Datenverluste sind praktisch ausgeschlossen.

Synchrone Replikation lässt allerdings den Traffic im Netz stark ansteigen und erfordert daher oft schnelle und teure Fibre-Channel-Verbindungen. Das geht ordentlich ins Geld, ist aber zum Glück nur in den seltensten Fällen erforderlich.

Asynchrone Replikation reicht häufig aus

Akzeptiert man einen Td-Wert (oder in der Backup-Fachsprache: ein Recovery Point Objective) im Bereich weniger Minuten, kann man auf die wesentlich preiswertere asynchrone Replikation zurückgreifen. Dabei werden Write-Requests des Betriebssystems zunächst an das lokale Array weitergereicht und erst nach dem Schreibvorgang auf das sekundäre, entfernte Array kopiert.

Dabei wartet die Anwendung nicht auf Bestätigungen, sondern fährt unmittelbar mit den nächsten Daten fort. Asynchrone Replikation beansprucht kaum Bandbreite und kann daher auch über WAN-Verbindungen betrieben werden.

Das Verfahren ist prinzipiell nicht ganz verlustfrei so wie die synchrone Variante. Rechnet man aber mit der Ausfallformel nach, ergibt sich hier oft das beste Preis-Leistungs-Verhältnis.

Recovery – automatisch oder manuell

Der To-Wert (oder in der Backup-Fachsprache: Recovery Time Objective) muss, wie der Td-Parameter, umso niedriger sein, je geschäftskritischer ein Service ist, also je höher die Werte Rp oder Lr sind.

Ein nicht verfügbares Warenwirtschaftssystem zum Beispiel lässt nicht nur große Teile der Belegschaft untätig herumsitzen, sondern verursacht auch noch hohe Umsatzeinbußen, weil keine Verkäufe und Bestellungen mehr abgewickelt werden können. Diese Applikation muss nach einer Viertelstunde wieder online sein.

Hier muss ein mit dem Produktionssystem weitgehend identischer Backup-Server im Stand-by vorgehalten werden. Das Recovery muss zudem automatisch erfolgen und alle Applikationen auf dem neuesten Stand wieder herstellen.

Hier braucht man ein asynchrones Replikationsprogramm mit Full-Server-Failover. Der Backup-Server übernimmt vollautomatisch den Posten seines ausgefallenen Kollegen.

Full-Server-Failover bei kritischen Anwendungen

Das kann er ohne Probleme: Denn es wurden nicht nur die Daten repliziert, sondern auch alle Änderungen an den Anwendungen, zum Beispiel Service Packs oder Updates. Diese Rund-um-Sorglos-Lösung ist natürlich nicht billig – ob sie wirtschaftlich sinnvoll ist, zeigt wieder der Check mit der Ausfall-Formel.

Sind die Rp- und Lr-Faktoren niedriger, kann man auf eine Many-to-one-Datenreplikation mit automatischem Failover zurückgreifen. Mehrere Server werden auf ein und dasselbe Backup-System repliziert.

Auch in diesem Fall ist nach einer Viertelstunde alles wieder online. Dieses Konzept greift natürlich nicht bei Mehrfach-Ausfällen, bietet aber in vielen Fällen ein mehr als ausreichendes Sicherheitsniveau.

Einsatz von Sekundär-Servern

So genannte Sekundär-Server, etwa im Archivbereich, haben geringe RP- oder LR-Werte. Das heißt, auch ein mehrstündiger Ausfall verursacht keine allzu hohen Kosten. Hier wird wieder Many-to-one-Replikation eingesetzt.

Auf ein automatisches Recovery kann man verzichten, das macht die Sache wieder deutlich preiswerter. Die Wiederherstellung erledigt der Administrator per Image-Mounting.

Wer also genau nachrechnet, kann seinen Disaster-Recovery-Plan individuell anpassen und viel Geld sparen. Anbieter wie Double-Take Software [2] haben für jede Risikosituation das richtige Produkt im Portfolio.

Räumliche Trennung schafft Sicherheit

Nicht nur Replikations- und Wiederherstellungs-Software spielen eine Rolle bei beim Disaster-Recovery-Plan, sondern auch die räumliche Risikoverteilung. Die besten Backup-Systeme nützen nichts, wenn sie im selben Gebäude oder gar im selben Raum stehen.

Management-Konsole: Zentralisierte Replikation schafft mehr Überblick und minimiert die Folgen eines Systemausfalls. Eine Risikoanalyse hilft bei der Auswahl des Sicherheits-Levels mit der besten Kosten-Nutzen-Relation.

Treibt ein Großbrand die Temperatur der Festplatten über den Curie-Punkt, sind alle Daten verloren – und nicht selten auch das Unternehmen selbst. Die Statistik spricht hier eine deutliche Sprache: Nach einer Brandkatastrophe müssen 70 Prozent der betroffenen Firmen Konkurs anmelden – trotz Entschädigung.

Die Versicherung zahlt nämlich nur für unmittelbare Schäden, etwa die zerstörte Hardware, nicht aber für entgangenen Umsatz.

Den Verlust des kompletten Rechenzentrums einfach dem Restrisiko zuzuordnen, ist also nicht eben ratsam. Server mit hohem Rp- und Lr-Wert sollten daher an einen entfernten Standort repliziert werden, etwa in einer Filiale.

Nur modifizierte Daten sichern

Auch bei dieser Remote-Sicherung erweist sich die asynchrone Replikation als sehr praktikabel. Moderne Hochverfügbarkeits-Software schickt – nach der einmaligen Vollsicherung zu Beginn – nur noch geänderte Daten über die WAN-Verbindung, und zwar auf unterster Ebene. Übertragen werden tatsächlich nur diejenigen Bytes, die auf dem Primärsystem modifiziert wurden.

Je nach Umgebung ist damit eine Replikation sogar über Standard-Internet-Verbindungen wie SDSL oder gar ADSL möglich, wobei die Daten via VPN-Tunnel vor unbefugten Zugriffen geschützt werden.

Da eine generische Replikation über Software wie Double-Take lediglich I/O-Requests abfängt und übermittelt, ist sie auch völlig unabhängig von Applikationen und Hardware. Das Zielsystem muss in keiner Weise mit dem produktiven System identisch sein.

Zudem werden durch Replikation auch offene Dateien wirkungsvoll gesichert, wichtig zum Beispiel bei Exchange-Servern oder SQL-Datenbanken.

Daten in der Cloud sichern

Die Bandbreiten-sparende und Plattform-übergreifende Replikationsmethode hat aber noch weitere Vorteile. Wer keinen Sekundär-Standort fürs Backup zur Verfügung hat, kann Daten und Applikationen einfach in die Cloud replizieren.

Auch Double-Take bietet einen solchen Service an; die gesicherten Server-Farmen steuert der Projektpartner Amazon bei. Im Falle eines Ausfalles werden die kritischen Applikationen einfach im Internet gestartet, und der Geschäftsbetrieb kann weitergehen – von jedem Ort der Welt aus.

Der Autor: Joachim Brebeck ist Marketing-Manager DACH (Deutschland, Österreich, Schweiz) bei Double Take [2].

[1] http://www.cio.com/
[2] http://www.doubletake.de/
[3] http://www.doubletake.de/

Verwandte Artikel