Concepts and Terminology
This section introduces the terminology used throughout this guide, and the concepts to understand before planning a Hammerspace S3 deployment: multi-protocol file access, tested S3 limitations, multi-tenancy options, and transport security.
Hammerspace and S3 Terminology
| Term | Definition |
|---|---|
Access key |
A key used to access and authenticate with the Hammerspace S3 server. |
Anvil |
A component in the Hammerspace architecture that provides a global namespace and metadata management. |
Bucket |
A container for storing data on the S3 server. |
Bucket Container |
An S3 endpoint that clients can authenticate to for the purpose of creating S3 buckets. |
DSX (Data Service Exchange) |
A Hammerspace node that provides data access and management services. S3 service runs on DSX nodes. |
Endpoints |
One or more DNS endpoints with prefixes. The endpoint identifies the S3 server and provides a way for clients to connect to different S3 servers. The endpoint must be unique to this S3 server. If no endpoint is configured, the default server option must be checked. Prefix allows virtual hosted style bucket access. The prefix must be the same for all endpoints. |
FQDN (Fully Qualified Domain Name) |
A unique identifier for the S3 server used by clients to connect. |
Global Data Platform |
The core platform provided by Hammerspace unifies data across different storage systems and locations. |
List Objects Limit |
Sets the default number of keys returned by the ListObjects or ListObjectsV2 API call. Note that the ListObjectsV2 API is allowed to override this value. |
Local user |
A user created on the Hammerspace system to map to Linux identities. |
Name |
Management name for the S3 server. |
Objective |
A policy that defines how data should be placed and managed within the Hammerspace system. |
RFC2307 / RFC2307bis |
A method for mapping Unix users to their associated Microsoft Active Directory accounts. Hammerspace leverages these standards to maintain permissions in multi-protocol environments. |
S3 (Simple Storage Service) |
An object storage service supported by Hammerspace. |
S3 Access Permissions |
Access permissions for objects created in buckets. |
s3cmd Command-line Client |
A command-line client that is a widely used tool for interacting with S3-compatible storage. |
S3 Interface |
Tool within the Hammerspace GUI to configure S3 storage in a Hammerspace infrastructure. |
S3 Server |
A server that provides S3 storage services. |
Strict Bucket Lists |
When enabled, only return the buckets owned by the user. |
Strict Bucket Names |
Enables strict bucket naming to conform with Amazon S3 bucket naming rules. |
Virtual-hosted Bucket Names |
Check to enable virtual hosted style bucket access; if checked, a prefix is required in the endpoint address (Ex: |
Multi-protocol File Access Support
To support multi-protocol access that maintains permission consistency between NFS, SMB, and S3 clients, Hammerspace leverages RFC2307 to map S3 access keys to AD users and Unix UIDs/GIDs. These user mappings control the identity of the objects within the file system.
RFC2307 should be implemented in Active Directory and enabled on the Hammerspace cluster if you intend to provide multi-protocol access to files.
S3 Limitations
The following tested limitations currently apply to Hammerspace support for the S3 service:
-
Maximum number of S3 servers: 2048
-
Maximum number of buckets: 20,000 per S3 server
-
Maximum number of objects (total): No limit; the total number of objects is limited by metadata capacity.
-
Maximum number of objects in a bucket: No limit; the total number of objects is limited by metadata capacity.
-
Maximum number of Access Keys per S3 Server: 10,000
-
Minimum object size: 0 bytes
-
Maximum object size (multi-part upload): Chunk Size * maximum number of chunks (10,000); the chunk size is controlled by the S3 client.
-
File locking support: S3 does not have the concept of file locking, though locking is supported across SMB and NFS v4.2 protocols.
S3 and Multi-tenancy
Hammerspace allows you to achieve multi-tenancy with S3 in a few ways. By combining these methods, you can create a secure and isolated environment for each tenant within your Hammerspace infrastructure.
-
Support for Multiple S3 Servers: Each S3 server is configured with a unique name (FQDN)/endpoint.
-
Buckets: Each S3 server can be assigned a bucket or set of buckets, ensuring that data is logically separated and tenants cannot access each other’s data.
-
Access Control: Each S3 server can be configured with unique access keys, ensuring that S3 clients and their data can be isolated.
-
Objectives: Use objectives to control data placement and access for each tenant, allowing you to set different policies for tenants, such as where their data is stored and who can access it.
Transport Security
An S3 server can be configured to allow HTTP and/or HTTPS connections, though it is recommended to use HTTPS to ensure transport-level security between the S3 client and the S3 server.
-
HTTPS connectivity is enabled by default and is supported on port 443.
-
HTTPS connectivity is only supported with TLS (Transport Layer Security) versions 1.2 and 1.3. Support for 1.0 and 1.1 has been removed as those versions are no longer considered safe. If there is a choice, using TLS 1.3 on your client is recommended.
The encryption ciphers have also been reduced to comply with the latest security errata.
X.509 Server Certificate
By default, the product comes with a self-generated security certificate. However, this will often generate "untrusted certificate warnings" that some S3 clients may not be able to bypass.
To avoid these warnings, you can install a certificate in the product using the cluster-config CLI command.
For more information about managing server certificates, consult the Hammerspace Administration Guide.