Windream Objektspeicher

Transkript

1 Windream Objektspeicher Directory Pools und Filestream Pools verfügen über neue Optionen zur Integration von NetApp. Das Leistungsmerkmal wird über die Lizenz des windream Objektspeichers freigeschaltet. Directory Pool

2 Schalter Nur Schreiben Der Schalter Nur Schreiben des Directory Pools ermöglicht es, einen Directory Pool der z.b. für Replikationszwecke eingerichtet ist oder als Cachepool seine Daten direkt in den mm-arc Cache schreibt von lesenden Zugriffen auszuschliessen. Schalter Keine Requestdatei erzeugen Der Schalter Keine Requestdatei erzeugen des Directory Pools ermöglicht es, einen Directory Pool der in ein NetApp Dateisystem schreibt, einen Blob ohne Requestdatei zu erzeugen. Desweiteren kann der Schalter in Kombination mit Nur Schreiben dazu verwendet werden, im Cacheverzeichnis des mm-arc nur Blobs ohne Requestdatei zu erzeugen. NetApp Snapplock Integration Schalter Integration anwenden Der Schalter Integration anwenden bewirkt, dass ein Archivobjekt nur lesenden Zugriff erhält. NetApp Snapplock Integration Schalter Archivenddatum verwenden Der Schalter Archivenddatum verwenden bewirkt, dass die Angaben zu Archivierungsenddatum und zeit zu einem Archivobjekt eines windream Dokuments bei der Ablage in Netapp gesetzt wird. Dabei muss das in Netapp konfigurierte Archivierungsenddatum im Feld Datumsangabe für unbegrenzte Archivierungsdauer gesetzt werden. Netapp Ontap 6.x, 7.0: Die Vorbelegung dazu ist der :14:07 UTC (GMT). Ohne diesen Schalter wird ein Blob auf nur Lesen (readonly) gesetzt. Netapp Ontap 7.1 Das Datum muss auf den gesetzt werden. Ändern Sie dazu nur die Jahresangabe. Ohne diesen Schalter wird bei einem Blob lediglich nur Lesen (readonly) gesetzt. Liegt das übergebene Datum jenseits dieser Datumsangabe, dann wird das maximal zulässige Archivenddatum verwendet.

3 Filestream Pool Windream Objektspeicher NetApp SnapLock Integration

4 NetApp Snapplock Integration Schalter Integration anwenden Der Schalter Integration anwenden bewirkt, dass das bei ein Container nach Abschluss nur lesenden Zugriff erhält. NetApp Snapplock Integration Schalter Archivierungszeitraum in Jahren nach Abschluss des Containers Der Schalter Archivierungszeitraum in Jahren nach Abschluss des Containers bewirkt, dass das bei einem Container nach Abschluss das Archivierungsendatum auf den Zeitpunkt des Abschlusses plus die Angabe in Jahren gesetzt wird. Die Angabe bewirkt, dass auch das auch die Option Archivenddatum verwenden gesetzt sein muss. NetApp Snapplock Integration Schalter Archivenddatum verwenden Der Schalter Archivenddatum verwenden bewirkt, dass beim Abschluss eines Containers und Setzen von nur Lesen der Zeitpunkt der Archivierung plus Jahren mit dem maximalen Archivenddatum in Netapp verglichen wird. Liegt das berechtnete Datum jenseits dieser Datumsangabe, dann wird das maximal zulässige Archivenddatum verwendet. Das in Netapp konfigurierte Archivierungsenddatum muss im Feld Datumsangabe für unbegrenzte Archivierungsdauer gesetzt werden. Netapp Ontap 6.x, 7.0: Die Vorbelegung dazu ist der :14:07 UTC (GMT). Ohne diesen Schalter wird ein Blob auf nur Lesen (readonly) gesetzt. Netapp Ontap 7.1 Das Datum muss auf den gesetzt werden. Ändern Sie dazu nur die Jahresangabe. Ohne diesen Schalter wird ein Blob auf nur Lesen (readonly) gesetzt.

5 Konfigurationen Bei der Netappintegration ist die jeweils in Netapp konfigurierte Einstellung in den Pooloptionen abzubilden. - Snaplock 7.x ist installiert und konfiguriert das Archivendedatum zu setzten, - Snaplock / 6.5 ist installiert (setzt das Archivendedatum auf unendlich) Directory Pool: Filestream Pool: Außer Integration anwenden sind keine weiteren Optionen zu setzen. - Das Archivenddatum wird an SnapLock übergeben: Directory Pool: File-stream Pool: Alle Angabe müssen vorhanden sein. Für Ontap 7.1 setzen Sie das Datum auf das Jahr 2071.

6 Unter dem Eintrag Verzeichnisse, Daten muss auf das NetApp Verzeichnis verwiesen werden.

7 Im Folgenden ist ein Auszug aus der Netapp Snaplock Record Retention Implementation Strategy beigefügt SnapLock Record Retention Date Implementation Strategy Introduction A record retention date, as defined by this document, is the date after which Data ONTAP will permit the deletion of a write once, read many (WORM) file on a SnapLock volume. Regulatory environments require that records be retained for lengthy periods that can vary based on the regulatory body, record type, and relevance of the record to ongoing litigation or investigation. Traditionally, with optical WORM and WORM tape, this record retention has been done at the granularity of the storage medium and relied on meticulous indexing and organization of the physical storage media along with a manual process of physical media destruction or erasure. SnapLock allows for association of record retention periods at the granularity of individual records. Each and every record committed to WORM on a SnapLock volume can have an individual associated retention date. Data ONTAP enforces retention of these records until the retention dates of the records have been reached, after which time the disposition of the records will automatically change to allow deletion, but not modification, of the records. Data ONTAP will not autonomously delete any records. All record deletions must be done by the application. SnapLock also allows the extension of record retention dates further into the future to allow records to be retained beyond their originally determined retention period. SnapLock does not allow record retention periods to be shortened. The open protocol implementation of SnapLock and high performance of the NetApp hardware platforms allow SnapLock to support record retention periods at the record transaction level with minimal impact to the performance of the storage system. This makes it completely unnecessary to coalesce multiple records into blobs or collections (with a single associated retention period) in order to achieve acceptable performance characteristics. SnapLock provides a true transactional, rather than batch, interface for storage and retention of regulated records. SnapLock, as introduced in Data ONTAP 6.4.1, already includes the capability for applications to associate a retention date with a record before committing that record to WORM state. This document will cover the recommended approach for setting and managing retention dates on WORM records. Secure Time Mechanism For the purposes of regulatory compliance, Data ONTAP versions 7.0 and later utilize a ComplianceClock secure time mechanism that operates independently from the regular real-time clock of the storage system. ComplianceClock permits the storage system to be synchronized with the time base of the facility for correct operation of CIFS and NFS, yet still provides a secure mechanism by which regulatory compliance can be assured for retained records. Setting Record Retention Dates with SnapLock

8 In keeping with the SnapLock open protocol design, the support for record retention periods can be implemented in applications without any need for the use of proprietary APIs or protocols. Record retention dates can be set and queried programmatically through standard system call interfaces supplied by many operating systems or interactively via standard command-line tools. All these operations occur over standard network file system interfaces such as NFS and CIFS. This flexibility allows applications to use SnapLock from compiled code or scripts without the requirement for any libraries or software installed on the client systems.