Alex_Mac - Fotolia

Katastrophenschutz im Rechenzentrum: Tipps und Tricks

Wirksamer Katastrophenschutz im Rechenzentrum erfordert eine Planung des Kapazitätsbedarfs und der Datensicherung.

Bei zahlreichen Aspekten der Speicherverwaltung benötigen Unternehmen Informationen dazu, wie schnell sich ihre Daten ändern. Dies ist beispielsweise bei der Definition einer Datensicherungsstrategie oder der Planung des zukünftigen Kapazitätsbedarfs der Fall. Die Datensicherung ist ein wichtiger Bestandteil eines Disaster-Recovery-Plans und basiert auf anwendungskonsistenten Snapshots, die auf Arrays erstellt werden. Sie können wahlweise lokal wiederhergestellt oder über einen Partner an einem anderen Standort repliziert werden. Mit diesen Snapshots lässt sich ein früherer Systemzustand wiederherstellen, so dass IT-Administratoren auf historische Daten zugreifen können.

Trotz umfassender technischer Optimierungen zur Verringerung des Speicherplatzbedarfs von Daten wird für das Speichern und Replizieren dieser Snapshots nach wie vor Speicherkapazität und Bandbreite benötigt, was mit entsprechenden Kosten verbunden ist. Um besseren Einblick in die Aspekte zu erhalten, die für das Anwachsen von Snapshots sowie die damit verbundenen Auswirkungen auf die Speicherkapazität und Replikation verantwortlich sind, haben wir mit unserem Monitoring-Tool InfoSight die Daten aus über 8.100 Kundeninstallationen analysiert und zudem untersucht, wie verschiedene Systemparameter die Datenänderungsraten beeinflussen.

Abhängig von der Schreiblast und der Häufigkeit, mit der Snapshots erstellt werden, kann die Datenänderungsrate und damit auch die Größe der Snapshots erheblich variieren. Die Änderungsrate im Hinblick auf diese Parameter richtet sich jedoch sehr stark nach der jeweiligen Anwendung. Ich werde diese Beobachtungen im Folgenden näher ausführen, um Hilfestellung bei der Planung des zukünftigen Kapazitätsbedarfs und der Anforderungen einer Infrastruktur für die Datensicherung zu bieten.

Auswirkungen der Schreiblast auf die Snapshot-Größe

Logischerweise werden mit zunehmender Datenmenge auch die Snapshots größer. Infolge von Komprimierungen, Löschvorgängen und Überschreibungen handelt es sich dabei jedoch keinesfalls um ein 1:1-Verhältnis. Wird eine bestimmte Datenquelle innerhalb eines Snapshot-Intervalls mehrfach bearbeitet, so wird für den Snapshot nur eine Änderung berücksichtigt.

Die relative Größe eines Snapshots im Vergleich zur Datenmenge nimmt außerdem ab, je mehr Daten geschrieben werden. Wenn beispielsweise 10 Gigabyte Daten schreiben, ist der entsprechende Snapshot in der Regel rund 1,4 Gigabyte groß. Die Größe entspricht somit 14 Prozent der Datenmenge. Wenn Sie 1.000 Gigabyte Daten schreiben, beträgt die Snapshot-Größe durchschnittlich 96 Gigabyte bezeihungsweise 9,6 Prozent der Datenmenge. Dieses variierende Verhältnis zwischen Snapshot-Größe und Datenmenge ist außerdem in hohem Maße anwendungsspezifisch. Unter Oracle Virtual Desktops und Microsoft Sharepoint entstehen die größten Snapshots, während unter SQL Server und Exchange die Snapshot-Größe im Verhältnis zur Datenmenge am geringsten ausfällt. Ausschlaggebend hierfür ist, wie schnell sich das Verhältnis zwischen Datenmenge und Snapshot-Größe ändert. Unter Oracle Virtual Desktops und Sharepoint nimmt dieses Verhältnis linear zu, während es in Exchange- und SQL-Server-Anwendungen bei zunehmender Datenmenge schnell kleiner wird.

Demnach bekommen Storage-Architekten deutlich mehr für ihr Geld, wenn sie Exchange- und SQL Server-Snapshots nach vielen Schreibvorgängen erstellen – für einen Snapshot, der nach dem Schreiben von 100 Gigabyte Daten erstellt wird, benötigen Sie deutlich weniger Speicherplatz als für zehn Snapshots, die nach dem Schreiben von 10 Gigabyte Daten erstellt werden. Bei Oracle-, SQL- und Sharepoint-Volumes hingegen ändert sich das Verhältnis zwischen Snapshot-Größe und Datenmenge nur geringfügig. Entsprechend ergeben sich bei der Erstellung mehrerer Snapshots für kleinere Datenmengen nur geringe Einsparungen beim Speicherplatzbedarf gegenüber der Erstellung eines einzigen Snapshots für eine große Datenmenge. Die durchgehenden Linien zeigen den bestmöglichen Schätzwert für anwendungsspezifische Regressionen, die schattierten Bereiche zeigen 68 Prozent Konfidenzintervalle für die Regressionen.

Auswirkungen des Snapshot-Intervalls auf die Snapshot-Größe

Informationen zur Datenänderungsrate bei unterschiedlichen Datenmengen sind zwar nicht uninteressant, doch folgt die Kapazitäts- und Snapshot-Planung einem bestimmten zeitlichen Rhythmus. Einen besseren Anhaltspunkt liefert daher die Entwicklung der Datenänderungsrate im zeitlichen Verlauf. Da die Zahl der Schreibvorgänge und somit auch die Datenmenge mit der Zeit zunehmen, wird natürlich auch der Snapshot mit der Zeit größer. Wie sehr die Snapshot-Größe im Verhältnis zur Datenmenge zunimmt, hängt von der jeweiligen Anwendung ab.

In den Installationen unserer Kunden kommen bei Virtual Desktop-, Virtual Server- und Exchange-Volumes im Laufe einer Stunde etwa 0,1-0,2 Gigabyte neue Daten hinzu, während es bei allen anderen Volume-Anwendungen meist weniger als 0,05 Gigabyte pro Stunde sind. Auf eine ganze Woche hochgerechnet sind Snapshots von Virtual Desktop-Volumes rund vier Mal größer als die anderer Anwendungen. Ursache hierfür ist die nahezu lineare Änderungsrate sowohl im Hinblick auf die Zeit als auch im Hinblick auf die Datenmenge. Wie bereits oben ausgeführt, gilt diese nahezu lineare Wachstumsrate ebenso für Oracle-Volumes. Während die Snapshots also im Vergleich mit anderen Anwendungen für einen Zeitraum von einer Stunde relativ klein ausfallen, sind auf eine Woche hochgerechnet nur die Snapshots für virtuelle Desktops noch größer.

Wie bei Schreibvorgängen ergeben sich somit kaum Einsparmöglichkeiten beim Speicherplatzbedarf, wenn Snapshots für Virtual Server- und Oracle-Volumes in kurzen Intervallen erstellt werden. Aus diesem Grund ermöglichen häufige Snapshots von Virtual Server- und Oracle-Volumes zusätzliche Wiederherstellungspunkte, ohne dass hierfür übermäßig viele Speicherressourcen benötigt werden. In SQL-Server, Sharepoint und File Server wiederum fallen weniger häufig neue Daten an, und die Snapshot-Größe nimmt sublinear zu. Durch längere Snapshot-Intervalle wird also sowohl weniger Speicherplatz als auch weniger Bandbreite für die Replikation benötigt. Die Festlegung von Snapshot-Intervallen für Virtual Server und Exchange ist hingegen etwas komplexer: In der Regel werden die Daten auf den Volumes auf denen diese Anwendungen ausgeführt werden, innerhalb eines kurzen Zeitraums, häufig geändert. Mit Snapshots, die einen längeren Zeitraum abdecken, lassen sich jedoch der benötigte Speicherplatz und die erforderliche Bandbreite deutlich verringern.

Aufheben der Wechselwirkung zwischen Datenmenge und Snapshot-Größe

Die Snapshot-Größe nimmt sowohl im zeitlichen Verlauf als auch parallel zur Schreibaktivität zu. Doch wie lassen sich die Auswirkungen aufgrund der Tatsache vermeiden, dass die Zahl der Schreibvorgänge im Lauf der Zeit zunimmt? Und von welcher Snapshot-Größe sollte man ausgehen, wenn die Datenmenge von der Norm abweicht? Um diese Aspekte besser zu verstehen, wollen wir uns das Verhältnis zwischen der Snapshot-Größe und der Datenmenge für unterschiedliche Zeitintervalle näher anschauen.

  „Als Datenwissenschaftlerin bin ich der Ansicht, dass anhand von Schlussfolgerungen, die auf Zahlen und Fakten basieren, bestehende Prozesse bestmöglich verbessert werden sollten.“

Dr. Shannon Loomis, Nimble Storage

Allgemein nimmt die Snapshot-Größe in der Regel ab, wenn das Snapshot-Intervall größer wird. Im Verlauf einer Stunde beträgt das Verhältnis zwischen Snapshot-Größe und Datenmenge bei Exchange- und SQL-Server normalerweise rund 0,25, bei allen anderen Anwendungen etwa 0,20. Besonders interessant ist hierbei, dass File Server die einzigen Anwendungen sind, bei der die Snapshot-Größe für eine bestimmte Datenmenge fast unverändert bleibt. Das Verhältnis zwischen Snapshot-Größe und Datenmenge bleibt mit 0,22 nahezu konstant, und zwar unabhängig vom Snapshot-Intervall. Das bedeutet, dass Anwender File Server-Volumes auf völlig andere Weise nutzen als Volumes, auf denen andere Anwendungen ausgeführt werden. Während die Daten anderer Volume-Typen bei einem größeren Snapshot-Intervall in der Regel durch Löschvorgänge und Überschreibungen häufiger geändert werden, bleiben sie auf einem File Server-Volume meist in ihrem ursprünglichen Zustand erhalten.

Fazit: Optimierung der Datensicherung

Der Overhead für die Replikation lässt sich verringern, indem Sie das Snapshot-Intervall für virtuelle Server verlängern. Doch könnten Storage-Architekten und Entscheider es sich tatsächlich leisten, bei einem katastrophalen Ausfall ihrer Server die Daten einer ganzen Woche zu verlieren? Als Datenwissenschaftlerin bin ich der Ansicht, dass anhand von Schlussfolgerungen, die auf Zahlen und Fakten basieren, bestehende Prozesse bestmöglich verbessert werden sollten. Dabei sollte man jedoch Vorsicht walten lassen – denn Vorsicht ist die Grundvoraussetzung für die Sicherheit Ihrer Daten.

Über den Autor:
Dr. Shannon Loomis ist Datenwissenschaftlerin bei Nimble Storage.

Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Essential Guide: Alles zu Business Continuity und Disaster Recovery.

Cloud-Disaster-Recovery: Warum die Dokumentation so wichtig ist.

DR-Test-Pläne mit verfügbaren Technologien optimieren.

So sparen Sie bei den Hardwareredundanzen für Disaster Recovery.

Artikel wurde zuletzt im Oktober 2016 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Disaster Recovery

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close