2006 bis 2010 – die Epoche der Server-basierenden Speichersysteme und der Speichervirtualisierung, Teil 4

Anbieter zum Thema

Volume-Kopien

Selbstverständlich können auch Volume-Kopien erzeugt werden. Volume-Kopien können – wie Snapshots – sofort nach deren Initiierung verwendet werden. Das physikalische Kopieren läuft im Hintergrund, bis alle Datenblöcke kopiert sind.

Beschreibbare Snapshots

Ein Snapshot kann jedem beliebigen Host zugewiesen werden. Das ist oft hilfreich für eine Weiterverarbeitung der Daten, beispielsweise beim Erzeugen von Backups oder als Datenquelle für ein Data-Warehouse. Standardmäßig kann auf Snapshots dabei nur lesend zugegriffen werden. Bei Bedarf können Snapshots aber auch mit einem Handgriff als beschreibbar (engl. writeable) markiert werden. Das ist oft hilfreich für Tests oder andere Szenarien, bei denen auf die Daten schreibend zugegriffen werden muss.

Snapshots von Snapshots

Manchmal ist es wünschenswert, von einem Snapshot eine weitere logische Kopie zu haben. XIV-Systeme können mit demselben Mechanismus mehrere Kopien eines Snapshots erzeugen. So könnte ein Snapshot z. B. als beschreibbar markiert werden, während die zweite Kopie für ein Backup dient.

Consistency Groups

Für manche Anwendung ist es wichtig, konsistente Snapshots zu erzeugen, wenn die Anwendung mehrere Volumes benutzt. Das trifft beispielsweise auf Datenbanken zu, wenn diese ihre Log-Dateien auf separaten Volumes speichert. Für diese Fälle können mehrere Volumes zu Konsistenzgruppen (engl. Consistency Groups) zusammengefasst werden.

Beim Erzeugen eines Snapshots ist dann sichergestellt, dass selbige konsistente Daten enthalten, also dass der Zeitstempel der verschiedenen Volumes identisch ist. Volumes einer Konsistenzgruppe müssen alle demselben Storage-Pool angehören.

Automatischer Snapshot bei entfernter Spiegelung

XIV-Systeme erzeugen vor einem Synchronisationsprozess entfernter Spiegel automatisch einen sogenannten Last-Consistency-Snapshot auf dem Zielsystem. Der Grund hierfür ist die Sicherstellung eines konsistenten Zustands für den Fall, dass während des Synchronisationsprozesses das Quellsystem ausfällt oder die Verbindung unterbrochen wird.

In diesem Fall ist es möglich, dass das Zielsystem einen inkonsistenten Zustand hat. Der automatische Snapshot kann dann verwendet werden, um zu einem definierten, konsistenten Zustand zurückzukehren. Diese automatischen Snapshots haben eine Deletion-Priority von null, d.h., sie werden im Falle einer Überprovisionierung eines Pools nicht automatisch gelöscht.

Remote Mirroring/Disaster Recovery

Für katastrophenresistente Installationen ist es möglich, entfernte Spiegel (engl. Mirror) auf einem anderen XIV-System zu erzeugen. Dies kann entweder über dedizierte iSCSI- oder Fibre-Channel-Ports implementiert werden.

Weiter mit: Die synchrone Spiegelung im Detail

(ID:2043883)

Auszug aus dem IBM Storage System Kompendium