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.
Limitations
Write Once Read Many (WORM) is not supported on global folders.
Byte-range locks taken on a global folder, are not reflected at the satellites.
NLM and NSM on connections to satellites are not supported.
SMB application instance IDs are not supported.
Event notifications are not supported on global folders.
Indestructible Object Mode is not supported on global folders.
It is not allowed to have a Global Access protected path under a bucket.
S3 bucket logging is supported only if both the source bucket and the destination bucket are in the same global folder.
Configuring a global folder with source and destination paths shared with asynchronous replication is supported with limitations. For details, see Configuring Async Replication and Global Access on Shared Paths.
Supported Protocols and Security Flavors
The following combinations of protocols and security flavors are supported for clients accessing a Global Access protected path (global folder) on the source cluster:
NFS flavor | SMB flavor | Mixed Last Wins flavor | S3 Native flavor | |
|---|---|---|---|---|
NFSv3 | + | + | + | + |
NFSv4 | + | + | + | |
SMB | + | + | + | + |
S3 | + | + | + | + |
The following combinations of protocols and security flavors are supported for clients accessing a satellite path on the destination cluster:
NFS flavor | SMB flavor | Mixed Last Wins flavor | S3 Native flavor | |
|---|---|---|---|---|
NFSv3 | + | + Requires VAST Cluster 5.5.0 or later | ||
NFSv4 | ||||
SMB | + | + | + | + |
S3 | + | + | + | + |
The following combinations of protocols and security flavors are supported for clients accessing a path which is part of both Global Access and asynchronous replication setup:
NFS flavor | SMB flavor | Mixed Last Wins flavor | S3 Native flavor | |
|---|---|---|---|---|
NFSv3 | + | |||
NFSv4 | ||||
SMB | + | + | + | + |
S3 | + | + | + | + |
NFSv3 and SMB Client Access to Global Folders
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.
S3 Client Access to Global Folders
S3 Bucket Replication on the Satellite
In order for S3 clients to access the satellite folder, an S3 bucket is needed on the satellite path.
This is accomplished either by automatic bucket replication, a feature that automatically replicates buckets on the satellite, or you can manually create a bucket on the satellite path to the global folder.
Bucket replication is enabled automatically on newly created global access paths.
Prior to VAST Cluster 5.5, bucket replication is a global cluster setting that can be enabled or disabled on all protected paths. Global access paths that were created prior to upgrade to VAST Cluster 5.5 may not have bucket replication enabled, depending on the legacy global setting on the cluster.
When the bucket replication feature is enabled on a given global access protected path, the feature creates a bucket on the destination path if the following conditions apply:
The bucket on the source path must be configured with the S3 default view policy
The destination tenant on the satellite cluster must have an S3 default view policy.
If these requirements do not apply, a bucket must be created manually on the satellite path to enable access. The bucket configuration must mirror the configuration of the source 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 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:
Whether Versioning is enabled or not
Whether Object Lock is enabled or not
Object ownership configuration
Whether Allow anonymous access is enabled or not
Whether the bucket is a database (has Database in the list of enabled protocols on the view)
The bucket policy
Whether Bucket logging is enabled or not
Bucket owner
Replication of S3 Access Keys and Identity Policies
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:
Access key pairs and identity policies associated with any users on external authorization providers that are configured on each peer are replicated from each peer to the other. Access keys and identity policies are not replicated for users on the cluster's VAST providers.
Each cluster stores access key pairs and identity policies as either local or remote. Access keys and identity policies that are received by replication from remote peers are stored as remote. They cannot be modified or deleted on the remote peer to which they are replicated, although they can be enabled and disabled there. On their source, they can be modified or deleted and those changes are replicated. Remote identity policies are disabled by default.