Was ist die beste Strategie, um Daten an Ort und Stelle zu archivieren?

Basierend auf Object Storage lassen sich Daten auch mit „Archive” kennzeichnen. So wird laut Jon Toigo die bisherige Tiering-Strategie aufgebrochen.

Wer sich noch nicht näher mit dem Thema befasst hat, sollte sich zunächst klar machen, dass Archivierung an Ort und Stelle nichts anderes bedeutet, als die Daten dort zu lassen, wo sie physikalisch gespeichert sind, und sie auf eine irgendeine Weise so zu kennzeichnen, dass ihr Archivstatus klar erkennbar ist. Ein solches Vorgehen stellt einen großen Unterschied zu der bestehenden Praxis dar.

De facto werden in einer gut organisierten IT-Umgebung bereits spezielle Schutzmaßnahmen für bestimmte Daten angewandt. Daten aus einer geschäftskritischen „Always-on“-Applikation werden zum Beispiel regelmäßig synchron zu einem zweiten Rechenzentrum oder Standort repliziert, von wo aus sie sofort für Zugriffe zur Verfügung stehen, falls der primäre Standort ausgefallen sein sollte. 

Diese Art von Hochverfügbarkeit gehört zu einer Bandbreite von Dienstleistungen für Data Protection, und sie ist zugleich in der Regel der teuerste Service. Von daher wird sie auch nur für die wichtigsten Anwendungen und Daten, die ständig aktiv sein müssen, eingesetzt. Daneben gibt es weniger umfassendere und kostengünstigere Schutzmaßnahmen für alle jene Fälle, bei denen ein temporärer Ausfall hinnehmbar ist – zumindest dann, wenn er nicht das Unternehmen in seinen Kernfunktionen tangiert.

„Archiving in place“ erfordert zuerst, solche Daten auszuwählen, zu klassifizieren und zu kennzeichnen, die einen archivarischen Wert haben.

Beim Thema „Archiving data in place“ geht es auch um die Unterscheidung von Data Protection und Data Preservation: Welche Maßnahmen eignen sich für welchen Zweck und welche nicht? Aber das ist nur ein Gesichtspunkt unter anderen.

Wenn vorausschauende Storage-Manager und -Planer bereits ihre Services für Data Protection in einer umsichtigen Art und Weise anwenden, können sie dies auch auf Data Preservation (Archivierung) ausdehnen und jene Daten heraussuchen, für die solche Tools geeignet sind – zum Beispiel Daten, die aus historischen, gesetzlichen oder regulatorischen Gründen in ein Archiv gehören. 

Genauso wie es bei Data Protection der Fall ist, müssen nicht alle Daten gleichermaßen nach den Kriterien von Data Preservation behandelt werden. Es ist deshalb nicht notwendig und auch nicht wünschenswert, eine Speicher-Plattform nur für Archivierung einzurichten. Denkt man dies konsequent weiter, gewinnt Archivierung an Ort und Stelle noch mehr an Plausibilität.

„Archiving in place“ erfordert zuerst, solche Daten auszuwählen, zu klassifizieren und zu kennzeichnen, die einen archivarischen Wert haben. Es gibt viele Wege, dies in der Praxis umzusetzen, einschließlich dem Hinzufügen von Metadaten schon zum Zeitpunkt der Entstehung einer Datei. 

Auf der Basis von File-Systemen sind Metadata-Ergänzungen möglich, wobei sie allerdings durch die Vorgaben beim Header Space und beim Metadata Processing teilweise beschränkt sind. Microsoft hat auf diese Situation durch die Öffnung der „File Classification Infrastructure“ (FCI) reagiert, um den Administratoren mehr Möglichkeiten zu geben, Metadaten-Klassen zusammen mit den Dateien zu speichern.

Wenn man eine Datei in Windows-Umgebungen mit der rechten Maustaste anklickt, werden in der Regel bereits Attribute wie „HIDDEN“, „ARCHIVE“, „SECURITY“ und andere angezeigt. Mit FCI können Administratoren darüber hinaus neue Kategorien wie „ACCOUNTING“, „HIPAA“ oder „SEC“ hinzufügen. Werden diese Attribute oder Kategorien für ein bestimmtes Desktop-System oder für einen bestimmten User in eine Active-Directory-Gruppe übernommen, lassen sich alle Desktop- oder User-Daten zusammen mit den jeweils definierten Metadaten abspeichern.

Die Daten zu kennzeichnen erleichtert es, festgelegte Regeln oder Policies für einzelne Datenklassen oder -typen einheitlich anzuwenden. Im Falle von Archivierung könnten solche Policies Replizierung oder „Erasure Coding Objects“ und ihre Verteilung über die gesamte Infrastruktur einschließen. 

Auf diese Weise bleiben die Files sogar bei einer Reihe von unvorhergesehenen Ereignissen erhalten: Dazu gehören teilweiser Speicherausfall, sich wiederholende Integrity Checks von ursprünglichen und replizierten Instanzen oder unbeabsichtigte Datenlöschung. Genauso wichtig ist es, Prozesse wie Komprimierung oder Deduplizierung auszuschließen, wenn sie im Gegensatz zu Vorschriften über die Unveränderbarkeit bestimmter Daten stehen.

Es wäre nicht nötig, Daten zu einer speziellen Archiv-Plattform zu verschieben, wenn wir sie direkt an ihrem ursprünglichen physikalischen Speicherplatz archivieren können. Ein solches Vorgehen hat jedoch Konsequenzen für die traditionelle Sichtweise von Archivierung und Information Lifecycle Management (ILM), die bisher von einem Archiv-Schema in vier Teilen ausgingen:

  1. Einem Datenklassifizierungssystem (wird bei „Archive in Place“ beibehalten)
  2. Einem Speicherklassifizierungssystem
  3. Einem Regelwerk von Policies, um zu entscheiden, welche Daten wie erhalten werden sollen (bleibt ebenfalls bestehen)
  4. Einem Data Mover, um die Daten je nach Policy auf eine Archiv-Plattform zu verschieben

Setzt man die „Archive-in-Place“-Strategie ein, werden nur das Datenklassifizierungssystem und das Policy-Regelwerk benötigt. Ein Server-nahes Speichersystem ebnet darüber hinaus die klassische Speicherhierarchie, so dass man nicht mehr zwischen verschiedenen Tiers und ihrer jeweiligen Storage-Hardware unterscheiden muss. Und wenn es keine Unterscheidung zwischen Speicher-Plattformen und Tiers mehr gibt, gibt es auch keinen Bedarf für einen Data Mover, der die zu archivierenden Daten auf vorher definierte Plattformen verteilt.

Was aber auf jeden Fall in diesem Szenario gebraucht wird, um eine echte Archive-in-Place-Strategie zu entwickeln, ist eine objekt-basierte Speicherumgebung. File-Systeme befinden sich bereits in Umgebungen für Web-Storage auf dem Rückzug, in denen komplexe Baumstrukturen für das Speichern binärer Objekte zugunsten von „horizontalen“ und unendlich skalierbaren Speicher-Designs verdrängt werden. 

Ein zukünftiges Verschwinden der File-System-Strukturen scheint das unvermeidliche Resultat vereinfachter Architekturen auf der Server-Seite und bei den Hadoop-basierten Speichersystemen zu sein.

Man kann diese Entwicklung auch bei dem wachsenden Interesse an „self-describing“ Datenobjekten beobachten, die ausführliche Metadaten-Konstruktionen erlauben. Diese Metadaten werden in Data-Management-Software eingesetzt, um die Policy-basierte Zuweisung von Speicherplatz, Aufbewahrung und Datenschutz zu erleichtern.

Fazit

Die Einführung von Object Storage und von Archiving-in-a-Place ist unbedingt erforderlich für Unternehmen, die miteinander verbundene Storage- und Big-Data-Architekturen verwirklichen wollen. Dafür geeignete, sich allmählich herausschälende Technologien werden bereits von zahlreichen Speicher-Unternehmen angeboten – darunter Dell, EMC, HP, IBM, NetApp, Quantum und Spectra Logic. Einen besonderen Blick sollte man allerdings auf hardware-agnostische Ansätze werfen, zum Beispiel auf „Swarm“ von Caringo.

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

Artikel wurde zuletzt im Dezember 2014 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Sichere Datenspeicherung

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