Search the docs

Deployment Examples

To illustrate how to create multitenant S3 configurations in Hammerspace, this section contains two fictional but realistic deployment examples. The first example has two tenants configured to use shared resources, and the second example has two tenants with isolated resources. Not every option is shown, so this document should be used in combination with other applicable documentation as needed.

After listing the prerequisites and pre-installation preparatory procedures all multitenant S3 Hammerspace installations have in common, step-by-step instructions are provided for configuring each example configuration. For simplicity, these examples use the GUI, but all of the configuration shown can be completed using the CLI or with automation leveraging the Hammerspace REST API.

Prepare for S3 Configuration

Several decisions need to be made before configuring Hammerspace S3 services. The major ones are listed below. For complete information on all of the S3 configuration options, refer to the Hammerspace Administration Guide.

  • S3 Server Endpoint Names: Each S3 server in a multitenant configuration is addressed using an endpoint name, which is an FQDN. The endpoint name specified by the client is used by the receiving DSX to route the request to the appropriate S3 server process.

  • Data Access Method: S3 buckets in Hammerspace may be addressed two ways: path-based (e.g., s3.meche.ivy.edu/mybucket) or virtual-host style (e.g., mybucket.s3.meche.ivy.edu). Virtual-host style requires DNS entries for each bucket.

  • Identity Provider: Hammerspace can connect to Active Directory or use a local user database. Connecting Hammerspace to AD requires the appropriate AD administrative credentials. Local users are configured in the Hammerspace admin GUI.

  • Strict Bucket Names: If maintaining 100% compatibility with Amazon AWS is required, Strict Bucket Names should be selected. This option restricts bucket names to those that conform with AWS S3 bucket naming rules.

  • Strict Bucket Lists: Should S3 clients be able to see all buckets on an S3 server using a 'list buckets' command, or should their view be restricted to only the buckets they own?

  • Bucket Management: Should S3 clients be able to create buckets using the appropriate S3 commands, or will they be restricted to using pre-created buckets? If the former, a 'Bucket Container' will need to be created. If the latter, the administrator must create the buckets in advance. If creating buckets will be allowed, will deleting buckets also be allowed?

  • S3 Access Permissions: What default permissions should be assigned to objects? Options are Private, Group, and Public. Note that this default can be overridden by the bucket-level access permissions settings, which can be unique for each bucket and bucket container.

Prerequisites

  • Configure Storage: Ensure the storage that will be used with Hammerspace is installed and configured. Refer to the Hammerspace Configuration Guide for instructions.

  • Install Hammerspace Software: Install the appropriate number of Anvil nodes and DSX nodes. For details, refer to the Hammerspace Installation and Licensing Guide.

  • Install Quorum Server: If required, install the lightweight quorum service on a Linux server (physical or VM). Complete requirements and installation instructions for the quorum server are contained in the Hammerspace Installation and Licensing Guide.

  • Configure DNS: When using floating DSX IP addresses, create one DNS 'A' record for each DSX FIP for each S3 server.

  • Configure Load Balancer: Load balancing services are customer-provided and should be configured to spread traffic for S3 endpoints across DSX nodes as appropriate for the configuration.

  • Identify S3 Clients: Identify the individuals and applications that will be using each S3 server. All clients using a particular S3 server must have a corresponding user account in the same identity provider - either AD or Hammerspace local.