Overview of Block Storage on VAST Cluster

Prev Next

VAST Cluster supports block storage protocol. The block storage service enables you to flexibly and dynamically configure and present paths on the cluster as block storage subsystems and partition cluster capacity as block storage volumes under the subsystem paths.

Backup is easily implemented by taking a snapshot or configuring scheduled local backup on a subsystem path, a volume path, or a path that covers multiple volumes. A backup can be made accessible by mapping the volume from any snapshot that includes the path to hosts.  

VAST Cluster supports connectivity to block storage using Nonvolatile Memory Express over Transport Control Protocol (NVMe/TCP). NVMe/TCP supports high-performance block storage connectivity without requiring specialized networking hardware like Fibre Channel or Infiniband, making it more accessible for many applications, including cloud and data center operations.

Block storage subsystems, implemented as block-enabled views, can be provisioned on the same cluster and tenant as other views enabled for file and object storage.

Supported Client Environments

  • Linux: RHEL 8.8, RHEL 9.4, Ubuntu 24.04 LTS

  • VMWare vSphere ESXi 7.0 U3, ESXi 8.0

Host Connectivity

  • NVMe/TCP (only)

  • Up to 16 paths (one path per virtual IP). During path discovery, up to 16 virtual IPs are chosen from the list of all possible virtual IPs across all virtual IP pools belonging to the relevant tenant.

Provisioning

Block storage resources may be provisioned using:

  • VAST Web UI, described in this guide.

  • VAST CLI, described in this guide.

  • The VMS REST API

  • The VAST Block CSI Driver for Kubernetes

  • The The VAST Data Terraform Provider

  • The VAST Driver for Cinder

Block Storage and Multi-Tenancy

In order for block client hosts to interact with the VAST Block storage service, the hosts must be configured in VMS. When you configure a host, you supply a host NQN. This is a globally unique identifier for the host that must be obtained from the block host.

Prior to VAST Cluster 5.3.2, and, by default, on clusters upgraded to VAST Cluster 5.3.2, the NQN identifier of each host configured on the cluster must be unique on each tenant, but need not be unique on the cluster.

On multi-tenant clusters, the target tenant of a block client host request is resolved on the cluster as follows:

  1. If tenants are associated with different virtual IP pools, the tenant is resolved according to the requested virtual IP.  

  2. If all tenants share a virtual IP pool (a virtual IP pool can be assigned to all tenants), then, if the request comes from a source IP that is configured as a client source IP of a specific tenant, the tenant is resolved according to client source IP. (In the tenant configuration, you can specify a client source IP range. These ranges must be exclusive per tenant when virtual IPs are shared between tenants.)

  3. If all tenants share a virtual IP pool and client source IP ranges are not configured on any tenant sharing the virtual IP pool, then, starting from VAST Cluster 5.3.2, if Host NQN-Based Tenant Resolution is enabled by VAST Customer Success and the host NQN is unique on the cluster, then the tenant is resolved according to host NQN. Prior to VAST Cluster 5.3.2, the tenant cannot be resolved if the tenants share a virtual IP pool and client source IP ranges are not configured on the tenants.

VAST Cluster 5.3.2 has a feature you can enable on request, which resolves tenant according to host NQN. To request this feature, contact VAST Customer Success and ask for Host NQN-Based Tenant Resolution. This feature requires unique host NQNs across the cluster, which is enforced on clusters that are installed with VAST Cluster 5.3.2.

For upgraded clusters, if you wish to enable this feature, begin by eliminating any and all existing duplicate host NQNs, and then ask for the Host NQN-Based Tenant Resolution feature to be enabled. When we enable the feature, we will also enable enforcement of unique host NQNs across all tenants from this point onwards, preventing any future duplication of host NQNs across tenants.  Otherwise, unique host NQN is enforced only per tenant, as in previous versions.

Once the feature is enabled, in addition to having unique host NQNs across the cluster, ensure the following configuration in order that tenants are resolved according to host NQN:

  • All tenants must have no client source IP range configured.

  • All participating tenants must share the same virtual IP pool.

Should you need the ability to share host NQNs among multiple tenants on a cluster installed with VAST Cluster 5.3.2, contact VAST Support to disable this enforcement.