About SnapLock

This topic discusses using NetApp SnapLock as the fixed content system in support of a fixed storage area.

See the Create a Fixed Content Device wizard to create the fixed content device containing the configuration parameters for the SnapLock fixed content device system.

Refer to SnapLock documentation for full information.

Content model

A SnapLock device appears as a standard file system. Under SnapLock, the client creates a file (supplying the complete directory path of the file) to store the content, then writes the data bytes to the file (just as is done with a standard file system). This means that the provider for SnapLock needs to be able to generate a directory path and a filename for each piece of content.

Content elements

Each content element of a (checked-in) document is stored as a separate file on a SnapLock volume. This model simplifies implementation, and includes having unique retention periods set on each content element.

SnapLock fixed store - directory structure

A SnapLock fixed storage area (the FileNet P8 term for the store) can store content elements from multiple file storage areas, object stores, and FileNet P8 domains. The fixed device consists of a set of structured directories, which are partially manually created, and partially created via Enterprise Manager. To create a SnapLock fixed store, there must be a pre-existing shared folder on the SnapLock Compliant Volume (created on the SnapLock side). Under the SnapLock shared folder the root folder of the fixed content store must be manually created, and proper security must be applied to the folder (see Server Security model below). To create the root SnapLock fixed content store directory the command line must be used, Windows Explorer cannot be used (due to how Explorer creates the folder as 'New Folder' then attempts to rename the folder) - for example if the SnapLock share is named \\green\snap_vol1, the following command can be used to create a fixed device named 'p8fx1':

mkdir \\green\snap_vol1\p8fx1

Once the fixed device root folder has been created and proper security has been applied, the directory structure can be created. There are two options for the structure, a small structure and a large structure. See Server security model for more information.

NOTE   The default setting on the Net Appliance system for directory size and maximum number of files in a directory might need to be adjusted when creating a SnapLock volume. The default sizes are fairly small, and will not handle a large amount of content.

Content filename

Each content element is stored as a separate file on the SnapLock fixed device. The filename consists of the following parts:

An example is seen below. In this case the device GUID is {C165C546-B24B-4fd0-BE7D-84522319C80D}, the document ID is {921D7DFF-1E2C-4096-9683-0BDCE9069CB3}, and the content element sequence number is 0.

FN{C165C546-B24B-4fd0-BE7D-84522319C80D}{921D7DFF-1E2C-4096-9683-0BDCE9069CB3}-0

NOTE   Neither the file store or object store identifiers are part of the content element filename. Given that a SnapLock fixed device can store content from various FileNet P8 domains, the file store/object store identifiers are not guaranteed to be unique. Since the document ID does not provide uniqueness (the same document ID can be used in multiple object stores) a 'device GUID' is generated when the content is saved to the SnapLock device. Note that all content elements for a Content Engine document are assigned the same device GUID; only the sequence number is different for multiple content elements of a single document (but each document receives a unique device GUID).

Determining the directory for content

The directory path to store a content element is determined by hashing the device GUID of the element (note that the since all content elements of a document are assigned the same generated device GUID, all content elements of a document are stored in the same directory). The GUID hashing algorithm is identical to the one used by the File Store Service to determine the directory for content stored in a file storage area.

Server security model

The Security model for a SnapLock device is such that the root directory must be locally accessible by the Content Engine (CE) server (either a local disk or a network mounted file system). Permissions must be explicitly set on the root directory outside the CE server’s control so that files and directories under that root directory will inherit the same permissions. The CE server must have both read and write permission to this root directory.

The following steps should be followed to create a new SnapLock fixed device on a Windows platform. For this example, assume that the Windows deployment domain is named 'chile', the FileNet P8 administrative Windows user account is named 'chile\betty', and the 'chile\Content Engine Servers' group is being used as the CE service group.

  1. Using the Network Appliance Filer View utility, create the SnapLock volume and share, and grant full control access to the share to 'chile\betty' and 'chile\Content Engine Servers'. For example, the volume could be named '\\green\snap_vol1'.
  2. From a computer in the Windows domain, create the root folder of the fixed device using the command line - for example: mkdir \\green\snap_vol\p8fx1
  3. Using Windows Explorer, set security on the root directory (p8fx1), removing all inherited security, and granting full control access to 'chile\betty' and 'chile\Content Engine Servers'.
  4. Run Enterprise Manager to create the SnapLock fixed device; the connection string attribute defines the root directory (for example \\green\snap_vol\p8fx1). Note that the directory size (small or large) cannot be changed after the fixed device is created.

Retention periods

SnapLock supports WORM storage and retention periods. There are two SnapLock licensing models, SnapLock Compliance and SnapLock Enterprise. Both models support WORM and retention, the key difference being that an Enterprise SnapLock volume can be deleted at any time by an administrator, whereas a Compliance volume can only be deleted after all content on the volume has passed its retention period and been deleted. Note that a SnapLock retention period can only be extended, it cannot be reduced.

A file on a SnapLock volume is committed to WORM state by setting the read only bit on the file (setting the read-only bit also sets the archive bit). Once the read-only bit has been set, it cannot be un-set until the retention period of the file has expired. Note that the archive bit can never be un-set, even after the retention period expires. Also note that unsetting the read-only bit will allow the file to be deleted, but the file is still prevented from being updated by the archive bit (meaning that the content becomes immutable once the read-only bit is originally set, and cannot be taken out of the immutable state).

The retention period is controlled via the file Last Accessed Time which is set using the native SnapLock ONTAPI API. If the read-only bit is set on a file without the last access time being set, the files retention period will set to the system default of the SnapLock volume. Thus, to allow the retention period to be set based on the FixedStorageArea’s RetentionPeriod property, during content creation, the retention period must be set before the read-only bit is set (unless the default retention is desired).

Note that due to a current defect in the 1.5X version of the SnapLock ONTAPI API, the retention period value cannot be shrunk, after it has been set. Thus, it is recommended that the system default of the SnapLock volume be set to the MINIMUM desired retention period. This will allow the retention period value to be increased from the system default during a create content operation.

After the retention period expires, the file can be deleted.

CE sets the WORM state and retention period on content element files immediately after migration to the SnapLock device.

NOTE   The Snaplock device has its own compliance clock that is used to control all retention period related tasks. This clock needs to be synchronized with the CE Server system clock to within 5 minutes of one another. The reason for this is that CE sets the retention on a SnapLock file as absolute time (for example, "2036-10-19 12:56:01" instead of "NOW + 30 years"). This time is based on the CE Server system clock. If the CE system clock is skewed significantly from the SnapLock clock (more than 5 minutes), then the absolute retention time is also equally skewed. This could cause a retention problem, and could cause the Content Retention Date property of the Document object to be inaccurate. Also note that the minimum retention period applied to a SnapLock device is expressed in days.

The SnapLock provider supports a device query operation which will return the default, minimum, and maximum retention values for a SnapLock volume. The SnapLock device GCD configuration data includes three parameters (default, minimum, maximum). Note that the values for these must be logical, for example, the minimum cannot be larger than the maximum, and the default must be between the minimum and maximum. Enterprise Manager will query the provider when creating a device (or updating the device, to allow for on-the-fly upgrade of the configuration data) to obtain the parameters and adjust the retention options.

The period options applied to a SnapLock device are as follows:

Minimum
The minimum retention period on the device expressed in days. The value of this minimum retention period should not be set to less than 1 day.
Maximum
The maximum retention period on the device expressed in days.
Default
The default retention period on the device expressed in days (value must be between minimum and maximum values).

Deleting content, data scrubbing

Content files can be deleted from a SnapLock volume after the retention period expires. Data scrubbing cannot be performed by the Content Engine since the file cannot be opened for write access. It is up to the SnapLock system to handle data scrubbing.