Skip to main content
Outside service Partner
Hitachi Vantara Knowledge

Tenant and namespace properties


Tenants and namespaces have certain properties that affect how they operate. Some of these properties are set when the tenant or namespace is created. Others are set after creation. Some can be modified after they are initially set; others cannot.

This chapter addresses these properties of tenants and namespaces:

Namespace quota

Storage quotas

Data protection level

Cryptographic hash algorithm

Retention mode

Namespace owner

Namespace tags

Default retention, shred, and index settings

Whether POSIX ownership and permission changes are allowed for objects under retention

Which custom metadata operations are allowed for objects under retention

XML checking for custom metadata

Versioning

Compatibility

Disposition

Data access permission masks

Minimum data access permissions

Access control lists

Replication

Service plans

System-level administrative access

For information on the search and indexing properties of tenants and namespaces, see Managing search and indexing.

NoteWebHelp.png

Note: In this chapter, in the context of namespace access, the term users means both people and applications.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Namespace quota


The namespace quota for a tenant is the number of namespaces HCP reserves for the tenant out of the total number of namespaces the system can have. At any given time, the tenant can own only as many namespaces as specified by this quota.

The namespace quota is set when the tenant is created. HCP system-level administrators can change this quota at any time. However, the quota cannot be set lower than the number of namespaces the tenant currently owns.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Storage quotas


Both tenants and namespaces have hard and soft storage quotas:

A hard quota is an absolute number of bytes. For a tenant, it is the total amount of storage available to that tenant for allocation to its namespaces. For a namespace, it is the total amount of space available for storing objects in that namespace, including object data, metadata (except ACLs), and the redundant data required to satisfy the namespace DPL. For information on DPL, see Data protection level.

NoteWebHelp.png

Note: HCP checks the amount of data stored in a namespace against the namespace hard quota hourly. If large amounts of data are added rapidly to a namespace, the namespace can store substantially more data than its hard quota allows.

Each namespace managed by a tenant can exceed its hard quota in this way. As a result, the total amount of storage used by all the tenant's namespaces can exceed the hard quota for the tenant.

A soft quota is the percentage point at which HCP notifies the tenant that allocated storage space is being used up. For a tenant, the soft quota measures the space used in all the namespaces the tenant owns relative to the hard quota for that tenant. For a namespace, the soft quota measures the space used in just that namespace relative to the hard quota for that namespace.

The storage quotas for a tenant are set when the tenant is created. HCP system-level administrators can change these quotas at any time. However, the hard quota for a tenant cannot be set lower than the amount of space the tenant has currently allocated to its namespaces.

The storage quotas for a namespace are set when the namespace is created. You can change these quotas at any time. However, the hard quota for a namespace cannot be set lower than the amount of space currently used in the namespace. And, the total of the hard quotas for all the namespaces owned by a tenant cannot exceed the hard quota for that tenant.

For information on changing the hard or soft quota for a namespace, see Changing the namespace storage quotas.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Data protection level


Each namespace has a data protection level (DPL) that specifies how many copies of each object HCP must maintain. HCP stores each copy of an object in a different location. All but one of these copies can become unavailable (for example, due to a hardware outage) without affecting access to the object.

The DPL for a namespace can be one (if allowed by the HCP system configuration), two, three, four, or dynamic. The highest allowed DPL is also determined by the HCP system configuration.

When the DPL is set to dynamic, the namespace uses the current HCP system-level DPL setting. Typically, this is the optimal DPL for the system configuration. If the system-level DPL setting changes, HCP adjusts the number of copies of objects in the namespace to match the new setting.

The DPL affects the amount of storage used when data is added to the namespace. With a DPL of one, HCP stores only one copy of the object. With a DPL of two, HCP stores two copies, thereby using twice as much storage.

The DPL for a namespace is set when the namespace service plan is created. You can change this setting at any time.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Cryptographic hash algorithm


At object creation, HCP uses a cryptographic hash algorithm to calculate a hash value for the object from the object data. HCP then uses this hash value to ensure the integrity of the object over time.

HCP supports these cryptographic hash algorithms:

MD5
SHA-1
SHA-256
SHA-384
SHA-512
RIPEMD-160

The cryptographic hash algorithm HCP uses for a namespace is set when the namespace is created. Once set, it cannot be changed.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Retention mode


Each object has a retention setting that specifies how long the object must remain in the namespace before it can be deleted; this duration is called the retention period. While an object cannot be deleted due to its retention setting, it is said to be under retention.

Retention mode is a property of a namespace that affects which operations are allowed on objects under retention. A namespace can be in either of two retention modes:

In compliance mode, objects that are under retention cannot be deleted through any mechanism. Additionally, the duration of a retention class cannot be shortened, and retention classes cannot be deleted. Similarly, the Minimum Retention after Initial Unspecified value cannot be shortened and cannot be deleted.

In enterprise mode, you can use the Tenant Management Console to delete objects under retention if you have the compliance role. This is called privileged delete.

Also in enterprise mode, you can shorten the duration of a retention class, and you can delete retention classes.

NoteWebHelp.png

Note: Users can perform privileged deletes in a namespace that’s in enterprise mode. To do this, however, they need the privileged data access permission.

The retention mode for a namespace is set when the namespace is created. You can change the retention mode of a namespace from enterprise to compliance mode but cannot do the reverse.

You can create namespaces in compliance mode only if allowed to do so by the tenant configuration. HCP system-level administrators can change this configuration from not allowing the creation of namespaces in compliance mode to allowing it. However, they cannot do the reverse.

For information on:

Changing the retention mode of a namespace, see Changing the retention mode

Retention settings, see Changing the default retention setting

Retention classes, see Working with retention classes

Privileged delete, see Using privileged delete

Roles, see Administrative roles and permissions

Data access permissions, see Data access permissions

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Namespace owner


A namespace can optionally have an owner that corresponds to an HCP or Active Directory® (AD) user. Assuming that the user has the allow namespace management property, the owner of a namespace can use the S3 compatible and HCP management APIs to:

View and change the versioning status of the namespace

Delete the namespace

See the namespace in a namespace listing

You can also use the Tenant Management Console and HCP management API to perform these activities if you have the administrator role, even if you’re not the namespace owner.

You can specify the owner of a namespace when you create the namespace or at any time thereafter. You can also change namespace owners at any time.

When the S3 compatible API is used to create a namespace, the namespace creator automatically becomes the namespace owner.

When a user with an HCP user account becomes the owner of a namespace, that user account automatically gets the browse, read, write, read ACL, and write ACL data access permissions for that namespace. If the S3 compatible API was used to create the namespace, the owner user account also automatically gets the delete permission for the namespace.

You can limit the number of namespaces that can be owned by a single user. You can change this limit at any time.

For information on:

The allow namespace management property, see About user and group accounts

Using the S3 compatible API, see Using the Hitachi API for Amazon S3

Using the HCP management API, see HCP Management API Reference

The Tenant Management Console, see Tenant Management Console

Changing namespace owners, see Changing the namespace owner

Changing the limit on namespace ownership, see Setting the maximum number of namespaces per user

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Namespace tags


A tag is an arbitrary text string associated with a namespace. You can associate up to ten tags with any given namespace, and you can use the same tags for multiple namespaces.

You can use tags to group namespaces and filter namespace lists. For example, if you’ve created multiple namespaces for a company named ABC Corporation, you could associate the tag ABC with each of those namespaces. Then you could filter a list of namespaces to display only the namespaces with that tag.

You can associate tags with a namespace when you create the namespace or at any time thereafter. You can also remove tags from a namespace at any time.

For information on associating tags with namespaces, see Changing the namespace tags.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Default retention setting


Each namespace has a default retention setting. This is the setting applied to an object when it is stored in the namespace unless the retention setting is explicitly specified in the request to store the object. After an object is stored, users can change its retention setting (subject to the rules for changing retention settings).

When you create a namespace, its default retention setting is Deletion Allowed. Objects with this retention setting can be deleted at any time except when they’re on hold.

You can change the default retention setting for a namespace at any time. Changing this setting does not affect existing objects in the namespace.

For information on changing the default retention setting, see Changing the default retention setting. For more information on retention settings in general, see Using a Namespace.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Default shred setting


Shredding, also called secure deletion, is the process of overwriting the places where all the copies of an object were stored in such a way that none of the object data or metadata, including custom metadata, can be reconstructed. Each object has a shred setting that determines whether it is shredded when it’s deleted from the namespace.

Each namespace has a default shred setting. This is the setting applied to an object when it is stored in the namespace unless the shred setting is explicitly specified in the request to store the object. After an object is stored, users can change its shred setting from don’t shred to shred but not from shred to don’t shred.

When you create a namespace, its default shred setting is not to shred. You can change this setting at any time. Changing this setting does not affect existing objects in the namespace.

NoteWebHelp.png

Note: If HCP is allowed to use erasure coding to implement replication of a namespace, setting the default shred setting to shred for that namespace can significantly increase the load on all systems in the replication topology.

For information on changing the default shred setting, see Changing the default shred setting.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Default index setting


Each object in the repository has an index setting that is either true or false. This setting is present even if the namespace containing the object is not search-enabled or indexed.

The metadata query engine uses the index setting for an object to determine whether to index custom metadata for that object. The HCP search facility uses the index setting to determine whether to index the object at all. Metadata query API requests can use the index setting as a search criterion. Additionally, third-party applications can use this setting for their own purposes.

NoteWebHelp.png

Note: If custom metadata indexing is disabled, the metadata query engine does not index custom metadata regardless of the index settings for individual objects. For more information on custom metadata indexing, see Metadata query engine indexing of custom metadata.

Each namespace has a default index setting. This is the setting applied to an object when it is stored in that namespace unless the index setting is explicitly specified in the request to store the object. After an object is stored, users can change its index setting.

When you create a namespace, its default index setting is to index. You can change this setting at any time. Changing this setting does not affect existing objects in the namespace.

For information on changing the default index setting, see Changing the default index setting.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Default POSIX UID, GID, and permissions


To support the NFS protocol, HCP supports certain POSIX metadata for objects. This metadata includes the POSIX user ID (UID) of the object owner, the POSIX group ID (GID) of the owning group, and the POSIX permissions.

NoteWebHelp.png

Notes: 

POSIX object ownership is different from object ownership in HCP. The owner UID is not related to either HCP user accounts or Active Directory user accounts.

POSIX permissions are different from HCP data access permissions and access control lists. They affect the operations that clients can perform only through the CIFS and NFS protocols.

POSIX UIDs and GIDs are visible through the HTTP, WebDAV, CIFS, and NFS protocols. POSIX permissions are visible through the WebDAV and NFS protocols. They map to CIFS permissions, which are visible through the CIFS protocol.

For objects stored through NFS, the POSIX UID and GID are determined by the current NFS user. Objects stored through other protocols do not have an explicit UID or GID. Instead, when you use NFS to view these properties for such an object, you see the default UID and GID currently specified in the NFS protocol configuration for the namespace that contains the object.

When you create a namespace, the default UID and GID in the NFS protocol configuration are both set to 0 (zero). You can change these settings at any time.

POSIX permissions for objects, directories, and symbolic links stored through NFS are determined by the client. POSIX permissions for objects stored through other protocols are always 555. POSIX permissions for directories and symbolic links stored through other protocols are always 777.

For information on changing the default UID and GID in the NFS protocol configuration, see NFS protocol configuration.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Retention-related properties


Namespaces have two properties that affect objects under retention:

Whether changes to POSIX UIDs and GIDs and to object owners are allowed

Which custom metadata operations are allowed

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Ownership and permission changes for objects under retention


Namespaces have two properties that affect objects under retention:

Whether changes to POSIX UIDs and GIDs and to object owners are allowed

Which custom metadata operations are allowed

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Custom metadata operations for objects under retention


Custom metadata is user-supplied information that describes an object in a namespace. For objects that are not under retention, users can add, replace, and delete custom metadata annotations as needed. For objects that are under retention, the operations allowed for custom metadata annotations are determined by a namespace-level setting.

You can configure a namespace to:

Allow annotations to be added, replaced, and deleted for objects under retention

Allow annotations to be added for objects under retention but not replaced or deleted

Disallow all annotations operations for objects under retention

When you create a namespace, only the addition of annotations is allowed for objects under retention. You can change this setting at any time.

For information on changing custom metadata handling for a namespace, see Changing retention-related settings. For more information on custom metadata in general, see Using a Namespace.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Protocol optimization


HCP namespace access protocols are categorized as either cloud protocols or noncloud protocols. The cloud protocols are the REST, S3 compatible, and HSwift APIs. The noncloud protocols are WebDAV, CIFS, NFS, and SMTP.

Protocol optimization improves namespace ingest performance. You can optimize namespaces for all protocols, which provides balanced performance across both cloud protocols and noncloud protocols. Alternatively, you can optimize namespaces for cloud protocols only. Cloud-only optimization improves the ingest rate of namespaces using cloud protocols. Cloud protocols, themselves, are further optimized for improved ingest performance.

A namespace that is optimized only for cloud protocols is said to be cloud optimized. Clients can use only cloud protocols to access cloud-optimized namespaces. For clients to use noncloud protocols to access a namespace, the namespace must be optimized for all protocols.

Only cloud-optimized namespaces support multipart uploads. Additionally, only cloud-optimized namespaces can be configured to allow erasure coding.

You can change the protocol optimization setting for a namespace from optimized only for cloud protocols to optimized for all protocols only if the namespace does not contain any objects. You can change the setting from optimized for all protocols to optimized only for cloud protocols only if no noncloud protocols are enabled for the namespace.

The default protocol optimization setting for new namespaces is set by the HCP system administrator.

For information on changing the protocol optimization setting for a namespace, see Changing the protocol optimization for a namespace.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

XML checking for custom metadata


By default, when a custom metadata annotation is added to or replaced in a namespace, HCP checks whether it contains well-formed XML. If the XML is not well-formed, HCP rejects the annotation.

For any given namespace, you can choose to allow users to provide annotations in non-XML formats (for example, as thumbnail images to accompany large objects with image content). In this case, you need to disable custom metadata XML checking for the namespace so that HCP accepts non-XML annotations.

XML checking applies only when annotations are added to or replaced in a namespace. It does not apply to annotations that already exist in the namespace.

You can enable or disable custom metadata XML checking for a namespace at any time. For instructions on doing this, see Enabling or disabling XML checking for custom metadata. For more information on custom metadata in general, see Using a Namespace.

NoteWebHelp.png

Note: If the XML in an annotation for an object includes a very large number of different elements and attributes, HCP may determine that the XML is not well-formed, even if it is, and reject the annotation. If this happens, the user can try restructuring the XML so that it includes fewer different elements and attributes. Alternatively, you can temporarily disable custom metadata XML checking to allow that XML to be stored in the namespace.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Versioning


Versioning is the creation of multiple versions of objects. Versioning is supported only with the REST and S3 compatible APIs. Users cannot create new versions of objects or access old versions through any other protocol.

Any given namespace can be configured to support versioning or not to support it. However, you cannot enable versioning for a namespace while the WebDAV, CIFS, NFS, or SMTP protocol is enabled for that namespace. Conversely, you cannot enable the WebDAV, CIFS, NFS, or SMTP protocol for a namespace while versioning is enabled for that namespace. You can disable versioning at any time.

When versioning is enabled for a namespace, you can set a time for version pruning. Version pruning is the automatic deletion of previous versions of objects that are older than a specified amount of time.

If you disable versioning after it was enabled, old versions of objects remain in the namespace and continue to be pruned according to the pruning settings. If you change the pruning settings, the new settings apply to old versions regardless of whether versioning is enabled.

You can create namespaces with versioning enabled only if allowed to do so by the tenant configuration. HCP system-level administrators can change this configuration from not allowing the creation of namespaces with versioning enabled to allowing it. However, they cannot do the reverse.

For information on changing versioning settings for a namespace, see Configuring object versioning.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Compatibility property


To support compatibility with other storage products, POSIX atime values can be synchronized with HCP retention settings. For information on the effects of this option, see Using a Namespace.

When you create a namespace, both of this features is disabled. You can enable or disable it at any time.

For information on enabling and disabling this feature, see Changing the compatibility setting.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Disposition


Disposition is the automatic deletion of objects. Disposition can be enabled for:

Objects with expired retention periods. To be eligible for disposition, an object must have a retention setting that’s either:

oA date in the past

oA retention class with automatic deletion enabled that results in a calculated expiration date in the past

Objects flagged as replication collisions.

Disposition has the benefit of automatically freeing HCP storage space for the creation of more objects. Without disposition, users need to explicitly delete qualified objects to free the occupied space.

Disposition deletes only the current version of a versioned object. It does not delete old versions.

Disposition is enabled on a per-namespace basis. When you create a namespace, this feature is disabled. You can change this setting at any time.

For information on enabling and disabling disposition, see Changing disposition settings. For information on retention classes, see Working with retention classes. For information on objects flagged as replication collisions, see Object content collisions.

NoteWebHelp.png

Note: HCP system-level administrators can enable or disable disposition for the repository as a whole. While disposition is disabled for the repository, enabling it for a namespace has no effect.

 

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Automatic abort of multipart uploads


After initiating a multipart upload, the user who initiated it can upload parts at any time until the multipart upload is completed or aborted. Completing a multipart upload creates a multipart object from the uploaded parts. Aborting a multipart upload causes the uploaded parts to be deleted. After a multipart upload is aborted, no more parts can be uploaded for it, and it cannot be completed.

NoteWebHelp.png

Note: When a multipart upload is aborted, its parts may not be deleted immediately. However, an aborted multipart upload cannot be completed even if its parts have not yet been deleted.

If a multipart upload is never completed or aborted, the disjointed parts can remain in HCP indefinitely. Even though the multipart upload is incomplete, these parts count toward the storage used by the namespace to which they were uploaded.

To prevent parts of multipart uploads from remaining in HCP indefinitely, you can set the amount of time for which a multipart upload can remain incomplete before the multipart upload is automatically aborted. This time is counted from the time the multipart upload was initiated.

Each namespace has its own automatic abort time for multipart uploads. By default, the automatic abort time for new namespaces is 30 days. A time of zero days tells HCP never to abort multipart uploads in the namespace automatically.

You can change the automatic abort time for a namespace at any time. When you change the time, the new time applies to all subsequent multipart uploads as well as to multipart uploads that are already in progress.

For example, if a user initiates a multipart upload on September 9th while the automatic abort time is set to 30 days, that multipart upload will be automatically aborted on October 9th. If, before October 9th, you change the automatic abort time to 35 days, the date on which the multipart upload will be automatically aborted changes to October 14th. If you change the automatic abort time to an amount of time that has already elapsed since the multipart upload was initiated, the multipart upload is immediately aborted.

NoteWebHelp.png

Note: The value of the x-amz-abort-date header returned in response to an S3 compatible request to list the parts of a multipart upload is the date on which the multipart upload will be automatically aborted, as determined by the current automatic abort time setting.

For information on changing the automatic abort time for a namespace, see Changing the automatic abort time for multipart uploads.

For more information on multipart uploads, see Working with multipart uploads.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Data access permission masks


A data access permission mask determines which of these operations are allowed in a namespace:

1.Read — Lets users:

oView and retrieve objects, including object metadata (system metadata, custom metadata, and ACLs)

oView and retrieve previous versions of objects

oList annotations for objects

oList directory contents

2.Write — Lets users:

oAdd objects to the namespace.

oModify system metadata. For users to modify the hold status of objects, privileged operations must also be allowed.

oAdd and replace custom metadata.

oAdd, replace, and delete ACLs.

oChange object owners.

Delete — Lets users delete objects and custom metadata from the namespace.

Purge — Lets users delete all versions of an object with a single operation. For users to perform purge operations, delete operations must also be allowed.

3.Privileged — Lets users:

oDelete or purge objects that are under retention. For users to perform privileged delete operations, delete operations must also be allowed. For users to perform privileged purge operations, delete and purge operations must also be allowed.

oHold and release objects. For users to perform hold and release operations, write operations must also be allowed.

Search — Lets users use the HCP metadata query API and the HCP Search Console to query or search the namespace. For users to query or search a namespace, read operations must also be allowed.

Data access permission masks are set at the system, tenant, and namespace levels:

The system-level mask applies across all namespaces (that is, systemwide).

The tenant-level mask is set individually for each tenant. This mask applies only to the namespaces owned by that tenant.

The namespace-level mask is set individually for each namespace and applies only to that namespace.

The effective permissions for a tenant are the operations allowed by both the system-level and tenant-level permission masks. That is, to be in effect for a tenant, a permission must be included in the system-level permission mask and in the tenant-level permission mask.

The effective permissions for a namespace are the operations that are allowed by the masks at all three levels. That is, to be in effect for a namespace, a permission must be included in the system-level permission mask, the tenant-level permission mask, and the namespace-level permission mask.

The table below shows an example of the effective permissions for a namespace given a set of data access permission masks.

Permission mask

Permissions

Read

Write

Delete

Purge

Priv. delete

Search

Systemwide permission mask

 

Tenant permission mask

 

Namespace permission mask

 

Effective permission mask

 

 

 

A tenant initially has all permissions in its data access permission mask. When you create a namespace, it also has all permissions in its data access permission mask.

HCP system-level administrators can change the systemwide permission mask at any time. You can change the tenant and namespace permission masks at any time.

You can make a namespace effectively read-only be removing all operations except read from its data access permission mask.

For information on setting the tenant and namespace permission masks, see Changing the tenant permission mask and Changing the namespace permission mask.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Minimum data access permissions


The configuration of a namespace can include minimum data access permissions for all users (that is, authenticated users and users that access the namespace anonymously) and for authenticated users only. When accessing the namespace:

Authenticated users have all the data access permissions associated with the applicable user account or group accounts and all the minimum data access permissions for authenticated users. Additionally:

oWhen using a protocol that requires authentication, authenticated users may or may not also have the minimum data access permissions for all users. This is determined by a namespace option that’s intended to support the following scenario:

Data can be written to the namespace only from within a secured environment and only from a limited number of client computers through a protocol such as NFS that does not support authentication. This requires write permission for all users.

Objects can be accessed from outside the secured environment but only through a protocol that requires authentication. This requires read permission but not write permission for authenticated users.

oWhen using a protocol that does not require authentication, authenticated users also have the all minimum data access permissions for all users.

Authenticated users also have any object-specific permissions granted to them by object ACLs (see Access control lists).

Unauthenticated users (that is, users who access the namespace anonymously) have the minimum data access permissions for all users and any object-specific permissions granted to all users by object ACLs (see Access control lists).

If you don’t set any minimum data access permissions for all users, the only operations unauthenticated users can perform in the namespace are those for which they are granted permission by ACLs.

TipWebHelp.png

Tip: If you enable only namespace access protocols that don’t support authentication, consider setting at least one minimum data access permission for all users.

For both all users and authenticated users, the set of minimum data access permissions can include only these permissions:

Browse — Lets users list directory contents.

Read — Lets users:

oView and retrieve objects, including system metadata and custom metadata for objects

oView and retrieve previous versions of objects

oCheck the existence of objects

oList annotations for objects

For this permission to be granted, users must also have browse permission.

Read ACL — Lets users view and retrieve object ACLs.

Write — Lets users:

oAdd objects to the namespace

oModify system metadata (except retention hold)

oAdd or replace custom metadata

Write ACL — Lets users add, replace, and delete object ACLs.

Delete — Lets users delete objects, and custom metadata, and ACLs from the namespace.

Purge — Lets users delete all versions of an object with a single operation. For this permission to be granted, users must also have delete permission.

Users with any data access permissions for a namespace can view information about that namespace.

NoteWebHelp.png

Note: To store an object with CIFS on a Windows client, a user must have both read and write permissions.

When you create a namespace, the set of minimum data access permissions is empty for both all users and authenticated users. You can modify these sets at any time.

For information on:

Changing minimum data access permissions, see Changing minimum data access permissions

User and group accounts, their associated data access permissions, and user authentication, see About user and group accounts

Authenticated and anonymous access to namespaces, see Using a Namespace

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Access control lists


A namespace can be configured to allow users to associate ACLs with objects. An ACL consists of access control entries. Each access control entry grants a user or group of users (the grantee) one or more data access permissions for the applicable object.

ACL permissions

The permissions that can be included in an access control entry are:

Read — Lets the grantee read and retrieve the object, including the system metadata and any custom metadata for the object, and list annotations for the object.

To read or retrieve the object through CIFS or NFS, the grantee must also have browse permission.

Read ACL— Lets the grantee read and retrieve the object ACL.

Write — Lets the grantee modify system metadata and add and replace custom metadata for the object.

Write ACL — Lets the grantee add, replace, or delete the object ACL.

Delete — Lets the grantee delete or purge the object and delete the object ACL.

For information on working with ACLs, see Using a Namespace.

Use of ACLs

When you create a namespace, the use of ACLs is disabled. You can enable this feature for the namespace at any time. However, once this feature is enabled, you cannot disable it.

Users can add and replace ACLs only with the HTTP protocol. Therefore, if you enable the use of ACLs for a namespace, you should also enable that protocol.

For information on enabling the user of ACLS, see Enabling the use of ACLs.

Enforcing ACLs

While the use of ACLs is enabled for a namespace, you can specify whether HCP should enforce ACLs in that namespace. While HCP is enforcing ACLs, the operations that a given user can perform on a given object are those permitted by any of:

The data access permissions associated with the applicable user account or group accounts

The applicable minimum data access permissions specified in the namespace configuration

The object ACL

When not enforcing ACLs, HCP allows only the operations permitted by the first two items above.

You can change the specification of whether HCP should enforce ACLs at any time while the use of ACLs is enabled.

More information

For more information on:

Specifying whether HCP enforces ACLs, see Changing the option to enforce ACLs

User and group accounts and their associated data access permissions, see About user and group accounts

Minimum data access permissions, see Minimum data access permissions

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Replication


Replication is a process that supports configurations in which selected tenants and namespaces are maintained on two or more HCP systems and the objects in those namespaces are managed across those systems. This cross-system management helps ensure that data is well-protected against the unavailability or catastrophic failure of a system.

In addition to replicating objects, HCP replicates tenant and namespace configuration, user and group accounts, retention classes, content classes, all compliance log messages, and most other tenant log messages.

A replication topology is a configuration of HCP systems that are related to each other through replication. Typically, the systems in a replication topology are in separate geographic locations and are connected by a high-speed wide area network. This arrangement provides geographically distributed data protection (called geo-protection).

Clients can read from namespaces on all systems where those namespaces are replicated. The replication topology, which is configured at the system level, determines the systems on which clients can write to namespaces.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Replication benefits


Replication has several purposes:

If a system in a replication topology becomes unavailable (for example, due to network issues), another system in the topology can provide continued data availability.

If a system in a replication topology suffers irreparable damage, another system in the topology can serve as a source for disaster recovery.

If multiple HCP systems are widely separated geographically, each system may be able to provide faster data access for some applications than the other systems can, depending on where the applications are running.

If an enterprise has several satellite offices, an HCP system at a central facility can consolidate data from the HCP systems at those outlying locations.

If an object cannot be read from one system in a replication topology (for example, because a node is unavailable), HCP can try to read it from another system in the topology. HCP tries to do this only if:

oThe namespace that contains the object is being replicated.

oThe namespace has the read-from-remote-system feature enabled.

oThe object has already been replicated. Users can check object metadata to determine whether an object has been replicated.

For information on this feature, see Changing replication options.

If a system in a replication topology is unavailable, requests to that system that come through the REST, S3 compatible, or HSwift API can be automatically serviced by another system in the topology without the client needing to modify the target URL. The other system can service a request only if:

oThe namespace named in the URL is replicated on the other system

oThe namespace named in the URL is configured to accept requests redirected from other HCP systems

oThe HCP systems involved use DNS for system addressing

For information on enabling this feature, see Changing replication options.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Replication implementation


Replication is implemented at the tenant and namespace level. When creating a tenant, the HCP system administrator specifies whether the tenant is eligible to be replicated. HCP system administrators can change this setting from not allowing replication to allowing it. However, they cannot do the reverse.

If the tenant is eligible for replication, you can choose whether to include each namespace in the replication of the tenant. You can change this setting for a namespace at any time.

If allowed by the tenant configuration, for each cloud-optimized namespace replicated with the tenant, you can specify whether HCP is allowed to use erasure coding to implement replication of the objects in that namespace. Erasure coding improves storage efficiency. However, read performance may be better for replicated namespaces that do not allow erasure coding.

System administrators can change a tenant from not being able to choose whether namespaces allow erasure coding to being able to do this. After this change occurs:

Preexisting cloud-optimized namespaces with replication enabled are automatically reconfigured to allow erasure coding.

When you enable cloud optimization for a preexisting namespace that had replication enabled but was not cloud optimized, the namespace is automatically configured to allow erasure coding.

The HCP system administrator selects tenants to be replicated from among those that are eligible. If a tenant has granted system-level administrative users access to itself, the system administrator can change the namespace selections for that tenant. HCP replicates the configuration of each selected tenant and the configuration and contents of all the namespaces selected for replication with the tenant.

Depending on the replication topology, you may not be able to make any configuration changes to the tenant or any of its namespaces on one or more systems in the topology. Clients cannot make any changes to namespace content on systems on which you cannot make configuration changes.

Replication is asynchronous with other HCP activity. If allowed by the system administrator, you can monitor replication progress in the Tenant Management Console. For information on this and on selecting namespaces for inclusion in replication of a tenant, see Monitoring and managing replication.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Replication collision handling


If clients can write to multiple systems in a replication topology, collisions can occur when different changes are made to the same objects on different systems. Similarly, if you can make configuration changes to the tenant and its namespaces on multiple systems in a replication topology, configuration collisions can occur.

The way HCP handles collisions that occur due to replication depends on the type of collision. However, the general rule is that more recent changes have priority over conflicting less recent changes.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Object content collisions


An object content collision occurs when, for a namespace without versioning enabled, these events occur in the order shown:

1.An object is created with the same name in that namespace on two systems in a replication topology, but the object has different content on the two systems.

2.The object on one of the systems is replicated to the other system.

If versioning is enabled for the namespace, no collision occurs. Instead, the less recently created of the two objects becomes an old version of the more recently created object.

When an object content collision occurs, the more recently created object keeps its name and location. The other object is either moved to the .lost+found directory in the same namespace or renamed, depending on the namespace configuration.

When HCP moves an object to the .lost+found directory, the full object path becomes .lost+found/replication/system-generated-directory/
old-object-path.

When renaming an object due to a content collision, HCP changes the object name to object-name.collision or object-name.version-id.collision, where version-id is the version ID of the object. HCP uses the second format only if versioning has ever been enabled for the namespace that contains the object but is not currently enabled.

If the new name is already in use, HCP changes the object name to object-name.1.collision or object-name.version-id.1.collision, as applicable. If that name is already in use, HCP successively increments the middle integer by one until a unique name is formed.

Objects that have been relocated or renamed due to content collisions are flagged as replication collisions in their system metadata. Clients can use the metadata query API to search for objects that are flagged as replication collisions.

If an object that’s flagged as a replication collision changes (for example, if its retention period is extended), its collision flag is removed. If a client creates a copy of a flagged object with a new name, the collision flag is not set on the copy.

You can configure namespaces to have the disposition service automatically delete objects that are flagged as replication collisions. When selecting this option for a namespace, you specify the number of days the disposition service should wait before deleting such an object. The days are counted from the time the collision flag is set. If the collision flag is removed from an object, the object is no longer eligible for deletion by the disposition service.

For information on configuring the method HCP should use to handle object name collisions in a namespace, see Changing replication options. For information the metadata query API, see HCP Metadata Query API Reference.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

System metadata collisions


A system metadata collision occurs when these events occur in the order shown:

1.Different changes are made to the system metadata for a given object on each of two systems in a replication topology.

2.The changed system metadata on one of the systems is replicated to the other system.

For example, suppose a user on one system changes the shred setting for an object while a user on the other system changes the index setting for the same object. When the object on either system is replicated to the other system, a system metadata collision occurs.

If a collision occurs when changed system metadata for a given object is replicated from one system (system A) in a replication topology to another system (system B) in the topology:

For changed system metadata other than the retention setting and hold status:

oIf the last change made on system A is more recent than the last change made on system B, HCP changes the system metadata on system B to match the system metadata on system A.

oIf the last change on system B is more recent than the last change on system A, HCP does not change the system metadata on system B.

For a changed retention setting:

oIf the retention setting on system A specifies a longer retention period than does the retention setting on system B, HCP changes the retention setting on system B to match the retention setting on system A.

oIf the retention setting on system B specifies a longer retention period than does the retention setting on system A, HCP does not change the retention setting on system B.

For a changed hold status:

oIf the object is on hold on system A but not on system B, HCP places the object on hold on system B.

oIf the object is on hold on system B but not on system A, HCP leaves the object on hold on system B.

Here are some examples of how HCP handles collisions when changed system metadata for a given object is replicated from one system (system A) in a replication topology to another system (system B) in the topology.

Example 1

The object starts out on both system A and system B with these system metadata settings:

Shred: false
Index: false

The table below shows a sequence of events in which the system metadata for the object is changed and the changes are then replicated.

Sequence

Event

1

On system A, a client changes the shred setting to true.

2

On system B, a client changes the index setting to true.

3

The changes on system A are replicated to system B. The resulting settings for the object on system B are:

Shred: false
Index: true

Example 2

The object starts out on both system A and system B with these system metadata settings:

Retention: Initial Unspecified
Shred: false
Index: false

The table below shows a sequence of events in which the system metadata for the object is changed and the changes are then replicated.

Sequence

Event

1

On system A, a client changes the retention setting to Deletion Prohibited.

2

On system B, a client changes the retention setting to Deletion Allowed.

3

On system B, a client changes the index setting to true.

4

On system A, a client changes the shred setting to true.

5

The changes on system A are replicated to system B. The resulting settings for the object on system B are:

Retention: Deletion Prohibited
Shred: true
Index: false

Example 3

The object starts out on both system A and system B with these system metadata settings:

Retention: Initial Unspecified
Hold: true
Shred: false
Index: false

The table below shows a sequence of events in which the system metadata for the object is changed and the changes are then replicated.

Sequence

Event

1

On system A, a client changes the retention setting to Deletion Allowed.

2

On system B, a client changes the retention setting to Deletion Prohibited.

3

On system B, a client changes the index setting to true.

4

On system A, a client changes the shred setting to true.

5

On system A, a client releases the object from hold.

6

The changes on system A are replicated to system B. The resulting settings for the object on system B are:

Retention: Deletion Prohibited
Hold: true
Shred: true
Index: false

7

The changes on system B are replicated to system A. The resulting settings for the object on system A are:

Retention: Deletion Prohibited
Hold: true
Shred: true
Index: false

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Custom metadata collisions


A custom metadata collision occurs when these events occur in the order shown:

1.One of these changes occurs:

oAn annotation is added with the same name to a given object on each of two systems in a replication topology, but the annotation has different content on the two systems.

The addition of an annotation to a given object on only one of the systems does not result in a custom metadata collision if the object does not have an annotation with the same name on the other system. In this case, the new annotation is replicated without conflict.

oDifferent changes are made to the content of a given annotation for a given object on each of the two systems in a replication topology.

oA change is made to the content of a given annotation for a given object on one system in a replication topology, and the same annotation is deleted on another system in the topology.

2.The change made on one of the systems is replicated to the other system.

If a collision occurs when a custom metadata change for a given object is replicated from one system (system A) in a replication topology to another system (system B) in the topology:

If the last change on system A is more recent than the last change on system B, HCP applies the change from system A to the custom metadata on system B

If the last change on system B is more recent than the last change on system A, HCP does not change the custom metadata on system B

Here are two examples of how HCP handles collisions when custom metadata changes for a given object are replicated from one system (system A) in a replication topology to another system (system B) in the topology.

Example 1

The object starts out with annotations named a1 and a2 on both system A and system B.

The table below shows a sequence of events in which the annotations for the object are changed and the changes are then replicated.

Sequence

Event

1

On system B, a client changes the content of a1.

2

On system A, a client makes a different change to the content of a1.

3

On system A, a client adds annotation a3 to the object.

4

On system B, a client adds annotation a3 with different content from the a3 added on system A.

5

The changes on system A are replicated to system B. The resulting annotations for the object on system B are:

a1 with the changed content from system A
a2 (unchanged)
a3 with the content added on system B

6

The changes on system B are replicated to system A. The resulting annotations for the object on system A are:

a1 with the changed content from system A
a2 (unchanged)
a3 with the content added on system B

Example 2

The object starts out with the annotations named a1, a2, and a3 on both system A and system B.

The table below shows a sequence of events in which the annotations for the object are changed and the changes are then replicated.

Sequence

Event

1

On system B, a client changes the content of a1.

2

On system A, a client deletes a1.

3

On system A, a client changes the content of a2.

4

On system B, a client changes the content of a2.

5

On system A, a client deletes a3.

6

On system B, a client changes the content of a3.

7

The changes on system A are replicated to system B. The resulting annotations for the object on system B are:

a2 with the changed content from system B
a3 with the changed content from system B

8

The changes on system B are replicated to system A, the resulting annotations for the object on system A are:

a2 with the changed content from system B
a3 with the changed content from system B

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Access control list collisions


An ACL collision occurs when these events occur in the order shown:

1.Different changes are made to the ACL for a given object on each of two systems in a replication topology.

2.The changed ACL on one of the systems is replicated to the other system.

An ACL is treated as a single unit. If a collision occurs when a changed ACL for a given object is replicated from one system (system A) in a replication topology to another system (system B) in the topology:

If the last change to the ACL on system A is more recent than the last change to the ACL on system B, HCP changes the ACL on system B to match the changed ACL on system A

If the last change to the ACL on system B is more recent than the last change to the ACL on system A, HCP does not change the ACL on system B

For example, suppose the ACL for a given object starts out with these grants on both system A and system B:

All users: read
User lgreen: write
User mwhite: write, delete

The table below shows a sequence of events in which the ACL for the object is changed and the change is then replicated.

Sequence

Event

1

On system B, a client changes the grants in the ACL to:

All users: read
User lgreen: write, delete
User mwhite: write, delete, read ACL

2

On system A, a client changes the grants in the ACL to:

All users: read
User mwhite: write
User pdgrey: write

3

The changed ACL on system A is replicated to system B. The resulting ACL for the object on system B contains these grants:

All users: read
User mwhite: write
User pdgrey: write

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Configuration collisions


A configuration collision occurs when these events occur in the order shown:

1.Different changes are made to the same configuration property on each of two systems in a replication topology.

2.The changed property on one of the systems is replicated to the other system.

Examples of configuration properties are:

The data access permission mask for a namespace
The default shred setting for a namespace
The HTTP protocol enabled setting for a namespace
The default versioning setting for new namespaces
The roles for a user account
The data access permissions a group account has for a namespace
The protocol optimization setting on a namespace

Certain groups of properties are treated as a single unit. Generally, these groups consist of properties that are updated by a single submission in the Tenant Management Console. Two notable exceptions to this rule are data access permissions for user accounts and content properties for content classes. In these cases, each set of data access permissions for a namespace and each content property is treated as an individual property.

If a collision occurs when a configuration change is replicated from one system (system A) in a replication topology to another system (system B) in the topology:

If the last change to the configuration on system A is more recent than the last change to the configuration on system B, HCP changes the configuration on system B to match the configuration on system A

If the last change to the configuration on system B is more recent than the last change to the configuration on system A, HCP does not change the configuration on system B

The rules above apply to all configuration collisions except collisions that occur when retention class properties are changed. For information on how HCP handles this type of collision, see Retention class collisions.

Here are two examples of how HCP handles collisions when configuration changes are replicated from one system (system A) in a replication topology to another system (system B) in the topology.

Example 1

A given namespace starts out on both system A and system B with these properties:

Read from remote system: enabled
Collision handling: move object

The table below shows a sequence of events in which the namespace configuration is changed and the change is then replicated.

Sequence

Event

1

On system B, an administrator disables read from replica for the namespace.

2

On system A, an administrator changes the collision handling option for the namespace to rename object.

3

The change on system A is replicated to system B. Because read from remote system and collision handling are properties in the same submission group, the resulting properties for the namespace on system B are:

Read from remote system: enabled
Collision handling: rename object

Example 2

A given user account starts out on both system A and system B with these roles and data access permissions:

Roles: monitor, compliance
Namespace-1 permissions: browse, read, write, delete

The table below shows a sequence of events in which the user account is changed and the changes are then replicated.

Sequence

Event

1

On system B, a security administrator adds the administrator role to the user account.

2

On system A, a security administrator removes the monitor role from the account.

3

On system B, an administrator removes the write permission from Namespace-1 and adds the purge permission.

4

On system A, an administrator adds the privileged permission to Namespace-1.

5

On system B, an administrator gives the user account browse and read permissions for Namespace-2.

6

On system A, an administrator gives the user account browse, read, and write permissions for Namespace-3.

7

The changes on system A are replicated to system B. Because roles and data access permissions are in separate submission groups, the resulting roles and data access permissions for the user account on system B are:

Roles: compliance
Namespace-1 permissions: browse, read, write, delete, privileged
Namespace-2 permissions: browse, read
Namespace-3 permissions: browse, read, write

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Retention class collisions


A retention class collision occurs when these events occur in the order shown:

1.Different changes are made to the same retention class on each of two systems in a replication topology.

2.The changed retention class on one of the systems is replicated to the other system.

If a collision occurs when a change to a retention class is replicated from one system (system A) in a replication topology to another system (system B) involved in the topology:

If the last change to the retention class on system A is more recent than the last change to the class on system B and:

oThe value of the class on system A is greater than the value of the class on system B, HCP changes the value of the class on system B to the value of the class on system A

oThe value of the class on system A is less than the value of the class on system B and:

System B is in enterprise mode, HCP changes the value of the class on system B to the value of the class on system A

NoteWebHelp.png

Note: An exception to this rule is when the value of the class on system A is -2 (Initial Unspecified) and the value of the class on system B is not 0 (Deletion Allowed). In this case, the value of the class on system B does not change.

System B is in compliance mode, HCP does not change the value of the class on system B

If the last change to the retention class on system B is more recent than the last change to the class on system A, HCP does not change the value of the class on system B

NoteWebHelp.png

Note: A retention class value of -1 (Deletion Prohibited) is greater than a value that’s a specific duration. A retention class value of 0 (Deletion Allowed) or -2 (Initial Unspecified) is less than a value that’s a specific duration.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Service plans


A service plan is a named option that can be associated with a namespace. This option determines how HCP manages the objects in that namespace. Service plan names are system specific.

When creating a tenant, the HCP system administrator specifies whether the tenant is allowed to associate service plans with namespaces. HCP system administrators can change this setting from not allowing these associations to allowing them. However, they cannot do the reverse.

The service plan you select for a namespace should match the expected usage pattern and properties for that namespace. For example, if the purpose of the namespace is to store objects that most likely will not be accessed again, you would choose a service plan with a description indicating that the plan is intended for archiving.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

System-level administrative access


A tenant can optionally grant HCP system-level users administrative access to itself. This enables those users to access the Tenant Management Console for that tenant and perform the same management and monitoring activities as the tenant-level users. Additionally, it enables system-level users to search the namespaces owned by that tenant and perform all allowed operations on the objects they find.

For more information on system-level administrative access to tenants, see Enabling or disabling system-level administrative access. For information on the Tenant Management Console, see Tenant Management Console.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.