unified_mode - unified identity between object and file
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 only uses SMB based file interface and none other 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 created from the object interface is owned by the user doing the object PUT operation.
If the object already 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 Spectrum 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 Spectrum 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. This means that 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 is done to prevent changing of the file ACL from the object interface to maintain file ACL semantics. In such 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 performs 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 performs 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 inherence ACL that is set. To summarize, the object ingest does not change any file ACL and vice versa.
| 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 an object that is not present | The ownership of the file is set to Bob | NA | Default GPFS™ ACLs are set | NA |
| Bob does a PUT operation for a container that is not present | 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. | 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 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) of existing container owned by Alice | NA | The ownership of the directory continues to be with Alice. Bob is not given any directory ACL | NA | NA |
| Bob does a POST operation (update ACL) of existing container 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 | |||
Advantages of using unified_mode
IBM Spectrum Scale offers various features that leverage 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 using NFS or SMB exports using their AD or LDAP credentials.
- Quota: Quota for users that work on UID or GID can be set
such that they work for the file as well as object interface.
Example: User A can have X quota on a unified access fileset assigned using GPFS quota commands which can hold true for all data 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 leveraging UID or GID.
Example 1: The UID and GID file attributes can be used to create an ILM placement policy to place the files 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 for as long as defined as defined by the ILM policies.
- Backup: Backup of user specific data leveraging UID or
GID.
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.
Quota related considerations for unified_mode
- Quota for a user set using file system commands for that fileset which is set using User ID or Group ID. This quota represents the size in bytes up to which the user can create data on a given fileset. This is tracked at the file system level.
- Container quota: This is the size in bytes of objects that can be stored in a container with no mapping with the user. For more information, see OpenStack documentation of container quotas.
- Account quotas: See OpenStack documentation of account quotas.
The fileset quotas and container level quotas as well as fileset quotas and account quotas are independent of each other.
In some cases, the fileset quota should be cumulative of all the containers' quotas hosted over it, though it is not mandatory. When both the quotas at the fileset level as well as 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 hosted by that fileset, despite of the container quota not being reached. Hence, when you plan to use both the quotas, it is important to understand these details.
The objectization process does not take into account 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 has objectized files as objects.
For example, consider that:
- You want to have a total of 1 TB of data allocated for file and object access.
- You want each user to have an overall quota from the file as well as the object interface to be 10 GB.
- You have a pre-defined set of 100 containers which are enabled for object and file access (using the storage policy for object storage) and users access to different containers is dependent on the container ACLs.
In this case, quotas are set as follows:
- Set the fileset quota associated with the file access policy to 1 TB.
- Set the user quota on that fileset to 10 GB.
- Set the container quota to the required level. However, setting it more than fileset quota cannot be honored until fileset quota is increased or unset.
In this example scenario, note that the object access will be restricted if either the user quota or the fileset quota is reached, even though the container quota is not reached.