Global Namespace Overview

The VAST global namespace enables you to make paths on clusters available to clients of multiple other clusters without the clients having access to the original cluster on which the path resides. These paths are known as global folders. A global folder is configured in VMS by creating a protected path and setting its mode to global access. Destination paths (also known as satellites) can be configured on multiple peers, one per cluster. The data in the global folder is not synced to the satellites but it is immediately accessible for read and write requests to the satellites as soon as the global access path is created.

Data that clients request to read from a satellite is requested from the origin and cached by the satellite. When a satellite peer receives a read request for data that is not cached, the satellite peer reads the data from the origin and prefetches other relevant data and metadata from the origin.

If data is accessed multiple times in a given time-frame, the destination peer requests or renews a lease on the data. For the duration of the lease, the destination peer answers read requests on the leased data without refreshing the data from the source. If the lease expires or if the content has changed at the source, the destination peer invalidates the cache. The next time the same data is requested from the destination peer, the destination peer fetches the data again from the source. The lease expiration time is configured per global access source path.

You can prefetch data in specific folders in a path on the destination peers from the source peer. This data is copied to the cache on the destination cluster. The operation is initiated on the destination peer.

Clients can also write data to the path. The write requests are sent to the origin cluster.

The source path must be a path that exists prior to configuring the global access. Multiple satellites are supported per source path. The destination path (satellite) is a new path created automatically as part of the global access configuration.  

Global folders can be accessed by NFSv3, SMB and S3 protocols, provided a view is created on the path with the relevant protocols enabled.

S3 access to global folders requires the use of the S3 Native security flavor. NFS access to global folders requires the use of the NFS security flavor. Therefore, the combination of S3 and NFS cannot be enabled on a view of the satellite path.

Clients with an NFSv3 or SMB mount to a path on a destination cluster have visibility and access to paths under this mount path that are configured for global access.                                                                                                                                                                                                                                                                                                                                                      

For example, consider a cluster (the source) with a protected path /a/b, which is configured for global access to a destination cluster as path /x/y.

On the destination cluster, if there is a view on /x that is enabled for NFSv3 and/or SMB access, an NFSv3 or SMB client that mounts /x can access /x/y. (If the view on the path /x is also enabled for NFSv4 access, NFSv4 clients will not see the /x/y path.

In order for S3 clients to access the satellite folder, an S3 bucket is needed on the satellite path.

You can accomplish this by enabling automatic bucket replication which replicates buckets on the satellite. Alternatively, and only if automatic bucket replication is not enabled, you can manually create a bucket on the satellite path to the global folder.

Bucket replication is a setting that can be enabled on each cluster (see Enabling Bucket Replication). Provided bucket replication is enabled on both clusters, and a bucket is configured on the source path with the S3 default view policy, and the destination tenant on the satellite cluster has the S3 default view policy, the bucket is replicated automatically to the satellite.  

If there is already a bucket on the satellite path with the same name as the origin bucket before you enable bucket replication, the attributes of the origin bucket will be replicated to that bucket. If there is already a bucket on the satellite path with a different name, bucket replication will fail and raise an alert.

Bucket replication applies the following bucket attributes from the origin bucket to the satellite bucket:

Buckets that are created by the bucket replication feature are created as bucket-enabled views with the S3 default view policy of the remote tenant.

If bucket replication is not enabled on the origin cluster, a bucket must be created manually on the satellite path to enable access. The bucket configuration must mirror the configuration of the source bucket.

As part of the configuration of a global access path, a replication peer is created between the origin and the satellite. When a replication peer is configured between two clusters, S3 access key pairs and identity policies are replicated between the clusters as follows: