Skip to main content

Configure a global namespace for grid federation

Contributors netapp-lhalbert netapp-pcarriga
PDFs

Configure a global namespace to allow tenant access to buckets across multiple StorageGRID systems.

For more information about global namespace, refer to Learn about global namespace for grid federation.

Before you begin

Requirements for configuring global namespace

  • All grids in the global namespace must have grid federation connections with global namespace enabled between every pair of grids.

  • The maximum number of grids that can participate in a single global namespace is 11 (the local grid and 10 remote grids).

    Caution The 10-grid limit is constrained by the maximum total number of grid federation connections supported by a StorageGRID deployment. The total connection limit applies to all grid federation connections in the deployment, including those without global namespace enabled, so you must ensure that the fully connected global namespace and any additional grid federation connections together do not exceed this overall limit.

  • S3 clients must use signature version 4 (SigV4) authentication. Anonymous and signature version 2 requests aren't supported for global namespace routing operations.

Number of required connections

In a global namespace, every pair of grids must be connected. The number of connections required depends on the number of grids:

Number of grids Number of connections required

2

1

3

3

4

6

5

10

n

n × (n − 1) / 2

Step 1: Set a unique default region for each grid

Each grid in the global namespace must have a unique default region. The default region identifies the grid that owns a bucket.

CreateBucket and ListBuckets requests are routed based on this region, and all other requests must match the default region that they are sent to.

For more information, refer to Configure S3 regions.

Steps

  1. On each grid, set the default region to a unique value. For example, set Grid A to us-east-1 and Grid B to us-west-1.

    Note You can still use non-default regions, set using the LocationConstraint element in CreateBucket requests, for ILM policy purposes. Non-default regions aren't validated for uniqueness across grids in the global namespace.

  2. Repeat for every grid in the global namespace. Each grid must have a different default region.

  3. Set up additional regions as needed.

Step 2: Configure S3 global namespace settings

On each grid in the global namespace, you add two S3 endpoint domain names:

  • A global namespace endpoint that's the same on all grids

  • A unique CNAME for the grid

You'll configure your external DNS so that the global namespace endpoint resolves to one or more of the grids, and the unique CNAME endpoints resolve to the specific grid.

Caution You must configure the default region before you configure the S3 global namespace settings. When you enable global namespace settings, S3 request will fail if they don't specify the correct region. All S3 requests need to be signed with the grid's default region.
Steps

  1. On each grid, select Configuration > Network > S3 endpoint domain names > Domain names.

  2. Add a global namespace endpoint domain name that's the same on all grids. For example: s3.example.com.

  3. Add a unique CNAME for the grid. For example, s3.company.com.

  4. Select Save.

  5. Select Global namespace settings.

    1. Select the global namespace endpoint.

    2. Select the grid's unique CNAME domain name.

  6. Select Save.

  7. Ensure that the server certificates used by clients include the new S3 endpoint domain names.

  8. Repeat these steps on every grid in the global namespace.

For details, refer to Configure S3 endpoint domain names.

Step 3: Create grid federation connections with global namespace enabled

After the S3 endpoint domain names and default regions are configured on all grids, you can create grid federation connections with global namespace enabled.

About this task

When you create a grid federation connection and enable global namespace, the global namespace endpoint, CNAME, and default region fields are automatically populated using the values you configured in the previous steps. The Grid Manager prevents enabling global namespace if these fields are not correctly set.

Caution After a grid federation connection with global namespace is created, the global namespace endpoint, CNAME, and default region for the grids in that connection can't be changed.
Steps

  1. On the first grid, follow the steps described in Create grid federation connections.

  2. When entering connection details, select Enable global namespace.

    The fields for the global namespace endpoint, CNAME, and default region are automatically populated with the values you've configured in the previous steps. If any of the values are missing or invalid, you won't be able to enable global namespace until you resolve the issues.

  3. Complete the connection by downloading the verification file and uploading it on the other grid.

  4. Repeat the previous steps for every pair of grids in the global namespace.

    For example, with 3 grids, you need 3 connections (Grid A–Grid B, Grid A–Grid C, Grid B–Grid C). With 4 grids, you need 6 connections. You can have a maximum of 10 grids in a global namespace. Refer to Number of required connections.

Step 4: Configure load balancer endpoints

Configure a load balancer endpoint for each grid in the global namespace. Use the same port for each of these endpoints.

Note Make sure you configure the load balancer endpoints before you configure DNS resolution.

Step 5: Configure DNS resolution

StorageGRID doesn't provide a built-in DNS resolver for global namespace. You must configure your external DNS infrastructure to route S3 requests to the correct grid.

Your DNS resolver should:

  1. Resolve the global namespace endpoint (for example, s3.example.com) to the load balancer endpoints of one or more grids, typically using round-robin DNS.

  2. Resolve each grid's unique CNAME (for example, s3.grid-a.example.com) to the load balancer endpoints for that specific grid.

  3. For virtual-hosted-style bucket requests (for example, bucket.s3.example.com), use your organization's routing policy to map bucket names to the appropriate grid's CNAME.

    StorageGRID doesn't provide a DNS-based mechanism to discover which grid owns a bucket. If you need automatic routing based on bucket ownership, use the Tenant Management API to issue ListBucket requests to return the bucket UUIDs. Maintain an internal mapping from bucket UUIDs to grids. Your external DNS should use that mapping rather than querying StorageGRID directly.