unified_mode - shared identity between object and file

Consider the following points when you use unified_mode identity management.

  • Users from object and file are expected to be common and coming from the same directory service (only AD+RFC 2307 or LDAP).

    Note: If your deployment uses only SMB-based file interface for file access and file authentication is configured with Active Directory (AD) with Automatic ID-mapping, unified file and object access can be used, assuming that object is configured with the same AD domain.

  • Ownership: Object that is created from the object interface is owned by the user who completes the object PUT operation.

  • If the object exists, existing ownership of the corresponding file is retained if retain_owner is set to yes in object-server-sof.conf. For more information, see Configuration files for IBM Storage Scale for object storage.

  • Authorization: Object access follows the object ACL semantics and file access follows the file ACL semantics.

  • Retaining ACL, extended attributes (xattrs), and Windows attributes (winattrs): If the object is created or updated over existing file, then existing file ACL, xattrs, and winattrs are retained if retain_acl, retain_xattr, and retain_winattr are set to yes in object-server-sof.conf. For more information, see Configuration files for IBM Storage Scale for object storage.

  • When a user does a PUT operation for an object over an existing object or does a PUT operation for a fresh object over a nested directory, no explicit file ACL is set for that user. If no explicit ACL is set for the user, it is possible that in some cases, the user might not have access to that file from the file interface even though the user has access from the object interface. This function prevents changing of the file ACL from the object interface to maintain file ACL semantics. In these cases, if the user is required to have permission to access the file also, explicit file ACL permission need to be set from the file interface.

    For example, if user Bob completes a PUT operation for an object over an existing object (object maps to a file) owned by user Alice, Alice continues to own the file and there is no explicit file level ACL that is set for Bob for that file. Similarly, when Bob completes a PUT operation for a new object inside a subdirectory (already created by Alice), no explicit file ACL is set on the directory hierarchy for Bob. Bob does not have access to the object from the file interface unless there is an appropriate directory inheritance ACL that is set. To summarize, the object ingest does not change any file ACL and vice versa.

Table 1. Object input behavior in unified_mode.
Note: In the scenarios listed in the following table, the operations are being done by user Bob from the object interface. The instances that are owned by user Alice imply that the file or directory ownership maps to user Alice from the file side. Also, it is assumed that the retain_owner, retain_acl, retain_xattr, and retain_winattr parameters are set to yes in object-server-sof.conf.
Operation from SWIFT interface on object or container Ownership result on corresponding file or directory ACL, xattr, and winattr retention behavior on corresponding file or directory
  File Directory File Directory
Bob does a PUT operation for a new object. The ownership of the file is set to Bob. NA Default GPFS ACLs are set NA
Bob does a PUT operation for a new container. NA The ownership of the directory is set to Bob. NA Default GPFS ACLs are set
Bob does a PUT operation for an object that is already present and is owned by Alice. The ownership of the file continues to be with Alice. Bob is not given any file ACL explicitly. There are no changes in the ownership of the parent directory. Existing ACL, file xattrs, and file winattrs are retained.** NA
Bob does a POST operation (update metadata) of existing object that is owned by Alice. The ownership of the file continues to be with Alice. Bob is not given any file ACL explicitly. NA Existing ACL, file xattrs, and file winattrs are retained.** NA
Bob does a POST operation (update metadata or ACL) of existing container that is owned by Alice. NA The ownership of the directory continues to be with Alice. Bob is not given any directory ACL. NA NA
GET/DELETE/HEAD No impact
Note: **Unified file and object access retains the extended attributes (xattr), Windows attributes (winattrs) and ACL of the file if there is a PUT request from an object over an existing file. However, security or system namespace of extended attributes and other IBM Storage Scale extended attributes such as immutability or pcache are not retained. Swift metadata (user.swift.metadata) is also not retained and it is replaced according to object semantics that is the expected behavior.

Advantages of using unified_mode

IBM Storage Scale offers various features that use user identity (UIDs or GIDs). With unified_mode, you can use these features seamlessly across file and object interfaces.
Unified access to object data
User can access object data by using SMB or NFS exports by using their AD or LDAP credentials.
Quota
GPFS quota for users that work on UID or GID can be set so they work for the file and object interface.

Example: User A can have X quota on a unified access fileset that is assigned by using GPFS quota commands that can hold true for all data that is created by the user from the file or the object interface.

For more information, see the Quota-related considerations for unified_mode section.

ILM
Tiering of user-specific data by using UID or GID.
Example 1
The UID and GID file attributes can be used to create an ILM placement policy to place the files that are owned by the Gold customers in faster storage pools and retain the files in the pools even when the pool storage starts reaching the threshold. The UID and GID file attributes can also be used to create a migration ILM policy so that, when the pool reaches its storage threshold, all files older than 30 days are moved to a slower storage pool except the ones owned by the Gold customers.
Example 2
After a user has left the organization, the UID of the user can be used to migrate the data and retain it on the archive tape when defined by the ILM policies.
Backup
Example: UID and GID file attributes in the policy rules that are defined for the mmbackup command can be used to regularly back up the data of selective users.
Figure 1. unified_mode - unified identity between object and file
unified_mode - unified identity between object and file

Quota-related considerations for unified_mode

There are three types of quotas that need to be considered:
  • Consider the quota for a user set by using file system commands for that fileset that is set by using user ID or group ID. This quota represents the size in bytes up to which the user can create data on a specified fileset. This data is tracked at the file system level.
  • Consider container quotas. The container quota is the size in bytes or number of objects that can be stored in a container regardless of the user that makes the upload (PUT) request. For more information, see OpenStack documentation of container quotas.
  • Consider account quotas. The account quota is the size in bytes or number of objects that can be stored in an account regardless of the user that makes the upload (PUT) request. For more information, see OpenStack documentation of account quotas.

The fileset quotas, container level quotas, fileset quotas, and account quotas are independent of each other.

In some cases, the fileset quota must be cumulative of all the containers quotas that are hosted over it - though it is not mandatory. When both the quotas at the fileset level and at the container quota level are set (and if the fileset quota is reached), no more object data can be input on any of the containers that are hosted by that fileset - whether the container quota is reached. Hence, when you plan to use both file and object quotas, it is important to understand these details.

The objectization process does not consider the container quota and the account quota. This means that there might be a scenario where a container can host more data than the container quota associated with it especially when the ibmobjectizer service contains objectized files as objects.

For example, consider that:

  • You want to have a total of 1 TB of data that is allocated for file and object access.
  • You want each user to have an overall quota from the file and the object interface to be 10 GB.
  • You have a pre-defined set of 100 containers that are enabled for object and file access (by using the storage policy for object storage) and users access to different containers depends on the container ACLs.

In this case, set the quotas:

  1. Set the fileset quota that is associated with the file access policy to 1 TB.
  2. Set the user quota on that fileset to 10 GB.
  3. Set the container quota to the required level.
    Remember: Setting it more than fileset quota cannot be accepted until fileset quota is increased or unset.

In this example scenario, the object access is restricted if either the user quota or the fileset quota is reached even though the container quota is not reached.