New Features in 5.1.0

Prev Next

Global Access, Simplified Configuration Flows for Replication

VAST Cluster introduces Global Access, a feature that enables you to make a subset of a cluster's namespace read and write accessible to clients of other clusters. Global access is configured on a protected path. Protected paths can be configured and managed from the Data Protection page of the VAST Web UI as previously, with a now simplified flow including the global access option, with the equivalent VAST CLI commands, and also from the DataSpace page of the VAST Web UI.

For more information about global access and how to configure it, see Global Access.

For DataSpace documentation, see Multi-Cluster Management (DataSpace was previously called Multi-Cluster Management.)

The following limitations apply:

  • Having Global Access and replication on the same path is not supported.

  • Lease expiration time can only be set when creating a global access protected path. You cannot change lease expiration time when you modify a global access path.

  • ORION-164710: When making capacity estimations for a directory, remote files and subdirectories are not taken into account. This means that in some cases, e.g. if local and remote capacity figures differ significantly and the remote capacity amounts to a significant portion of the overall capacity, the reported capacity and data reduction estimations can be skewed and would not reflect the real data reduction.

    For example, if a parent directory contains one subdirectory with file1 and file2, each of 2GB in logical capacity and 1GB in physical capacity, and another subdirectory with remote files file3 and file4, each of 100GB logical capacity and 100GB physical capacity, VAST Cluster would show the parent directory's data reduction ratio of 2:1, while the real ratio would be closer to 1:1.

Known issues are as follows:

  • ORION-154973: Prior to making massive deletions (from the on-premises cluster) on a path that is configured to be replicated to a remote cluster, you need to delete the protection policy associated with this path on the on-premises cluster to avoid deletion performance degradation.

  • ORION-145307: Bulk permission updates are not supported for files and directories on remote clusters.

Write Once Read Many Views

You can configure a view in a VAST Cluster to be Write Once Read Many (WORM) enabled. You can create WORM-enabled views on a VAST Clusters for SMB, NFSv3, and S3 protocols.

Once configured, files and objects that are saved to the view can be locked. When they are locked, they can be read, but not modified or deleted. You can also use the view to save files and objects without locking them, for normal read/write activity. You can set a retention period for objects and files saved in the view. This is the time during which the files or objects are locked for read only, and after which they can be removed. The retention period can be minutes, days, months, or years.

You can also set the retention mode for WORM-enabled views. You can set the view such that the retention period can be lengthened or shortened by authorized users (Governance mode), or only lengthened but not shortened (Compliance mode).

You can also set a Legal Hold on files or objects in a WORM-enabled view. In this case the file or object is retained until manually removed.

Attribute-Based Access Control (ABAC)

VAST Cluster 5.1 supports Attribute-Based Access Control (ABAC) on  views that are accessed via NFSv4.1 with Kerberos authentication or via SMB with Kerberos or NTLM authentication.

With ABAC, access to a view is allowed if the user's account in Active Directory has an ABAC attribute that matches the ABAC tag assigned to the view. The type of access - read-only or read/write - is determined based on the value set for the user's ABAC attribute in Active Directory.

For more information about this feature, see Attribute-Based Access Control (ABAC).

The following user controls have been added for this feature:

  • In VAST Web UI: the Attribute-Based Access Control (ABAC) tab in the Create View dialog (Element Store -> Views -> choose to create a view)

    • The Attribute-Based Access Control (ABAC) tab in the Create View dialog (Element Store -> Views -> choose to create a view)

    • The ABAC read only and ABAC read-write fields in the Active Directory settings (User Management -> Active Directory -> choose to create or edit an Active Directory configuration -> go to the Attribute mapping tab).

  • In VAST CLI:

    • The --abac-tags option on the view create command

    • The --abac-read-only-value-name and --abac-read-write-value-name options on the activedirectory create and activedirectory modify commands.

The following limitations apply:

  • ABAC is supported on views controlled with SMB and Mixed Last Wins security flavors.

  • ABAC is not supported with NFSv3 and S3.

  • (RESOLVED IN 5.2.0) ORION-167553: ABAC tags are case-sensitive. For example, tags AB and ab are considered different values, which may cause permission deny errors for the users.

  • (RESOLVED IN 5.2.0) ORION-166268: If a user is assigned ABAC attributes that allow read/write access to an ABAC-tagged view but the associated view policy sets All Squash for the host, the host would encounter a Permission Denied error when trying to list files and directories on the view.

  • ORION-163697: When an SMB user accesses a file for which the user has ABAC set to read-only, a lock is placed on the file although the user does not have read/write permissions for the file.

Note

See also rules and limitations in Attribute-Based Access Control (ABAC).

Known issues include:

  • (RESOLVED IN 5.2.0) ORION-176151: When creating a view with many 50-character ABAC tags in VAST Web UI, an ABAC tags were not set, they were inherited from another view instead error message can be displayed although no ABAC tag inheritance occurs. To avoid this message, try reducing the length of ABAC tags by one character.

  • (RESOLVED IN 5.2.0) ORION-171054: If an NFSv4.1-enabled view has ABAC tags assigned, an attempt to mount a nested view through NFSv4.1 fails with a Permissions Denied error.

Managing NFS and SMB File Locks

VMS provides an ability to easily find and release all types of file locks for NFS and SMB access. To manage locks in VAST Web UI, go to the Views page (Element Store -> Views), right-click the view for which you want to manage locks and choose a relevant option in the Find Locks and Release submenu.

Support of NFSv4.2 Security Labels in Limited Server Mode

VAST Cluster 5.1 supports NFSv4.2 labeling in Limited Server Mode. In this mode, VAST Cluster can store and return security labels of files and directories on NFS views of NFSv4.2-enabled tenants, but it does not enforce label-based access decision-making. Label assignment and validation are done by NFSv4.2 clients.

For more information about this feature, see NFSv4.2 Security Labels.

The following limitation applies:

  • ORION-158953: VAST Catalog does not include information about NFSv4.2 security labels.

Support of SID History for Groups

In addition to supporting SID History for users, VAST Cluster now supports SID History for groups. Up to 12 historical SIDs are supported for Active Directory users and groups. (Previously, only 2 historical SIDs were supported.)

For more information about this feature, see SID History.SID History

S3 Bucket Ownership Controls

VAST Cluster 5.1 introduces support for the following S3 actions that let you manage S3 Object Ownership rules:

  • The PutBucketOwnershipControls action can be used to set the ObjectWriter ownership rule for the bucket.

  • The GetBucketOwnershipControls retrieves the bucket ownership configuration.

Note

DeleteBucketOwnershipControls  is not supported.

VAST Web UI provides two new options that let you determine whether ACLs are used when authorizing access to an S3-enabled view governed with the S3 Native security flavor: ACLs enabled and ACLs disabled. The new options can be found in view settings after you select a view policy with the S3 Native security flavor.

For more information about the VAST implementation of S3 Object Ownership, see S3 Object Ownership.

Storing Protocol Audit Logs in VAST Database Tables

You can now configure VMS to store protocol audit logs in a VAST Database table (in addition to the existing option to store them as a file).

When configured, log entries are stored in the table as a JSON record.

Audit logs can be viewed directly from the VAST Web UI in the VAST Audit Log page in the Database section.

For more information about this feature, see Protocol Auditing.

The following known issue can be encountered:

  • (RESOLVED IN 5.1.0-SP40) ORION-206735: Running protocol audits where the audit results are written to a VAST Database table may impact performance of subsequent VAST Database and VAST Catalog queries.

Exposing VAST Database Table Row IDs

You can now expose the row IDs of VAST Database tables, and control the allocation of row IDs for inserted data. For queries on tables, this means you can query specific rows or ranges of rows, to limit the query and improve performance.

For inserts, this means you can insert data at specific row IDs or ranges of row IDs.

For more information about this feature, see User-Defined Row ID.

Managed Applications on CNodes

With VAST Cluster 5.1, you can run a managed Spark cluster on designated CNodes in the VAST cluster. This allows you to run this query engine close to the VAST Database, to improve performance. It uses a ready-to-run image that contains the Spark cluster, including Master and Worker nodes.

You can access the managed Spark cluster using traditional Spark client applications such as pyspark, spark-submit, and spark-sql, as well as the Spark Web UI.

For more information about this feature, see Managed Applications on Clusters.Managed Applications on Clusters

The following known issue can be encountered:

  • ORION-209079: Assigning a VLAN to application CNodes (e.g. Data Engine -> Applications -> choose to create or edit an application -> Network tab -> VLAN field) does not work as expected, resulting in incorrect network configuration.

SSO Authentication to VMS

VMS supports Single Sign-On (SSO) authentication using SAML-based Identity Providers (IdP). This allows VMS managers to sign in to a VAST Cluster using their credentials an IdP such as Okta.

When configured for SSO with an IdP, VMS acts as the SAML Service Provider (SP).

When SSO is configured, users will see an option to log in to VMS using SSO, in addition to the option to login directly using a username and password.

You configure roles in VMS, each with specific permissions to access VMS functionality, and assign these roles to users authenticating with SSO. This is done by creating roles on the IdP and mapping these roles to roles in VMS.

For example, consider a user who has the role VMS Administrators in the IdP, which is mapped to the role VMS Administrators in VMS, with Admin permissions. When the user signs on to VMS from the IdP, they will have Admin permissions in VMS.

For more information about this feature, see Configure SSO Authentication in VMS.Configure SSO Authentication in VMS

Inspect Cluster Resources

You can now inspect pages and tabs for cluster resources to see more detail. An Inspect panel has been added to these pages and tabs. This panel is open by default when the page or tab is opened (but can be closed). The detail for the resource appears as labels, for the attributes of the resource. Some of the labels are links to other tabs, where you can see more detail for the specific attribute.

For example, in the image below, click on the Protocols link to see detail for the protocol (in this case NFSv3).

Inspect-panel.png

The Inspect panel for resources in the Infrastructure page also show a Tree view of the cluster and its subcomponents, with the selected resource highlighted. For example, in the image below, the Tree view highlights the selected CBox (cnode-3-173, in this case).

Inspect-Tree.png

Alarm Aggregation

In VAST Cluster 5.1, the list of alarms in the Alarms page of VAST Web UI is filtered to remove alarms from lower-level components (such as an SSD) when there are also alarms for the higher-level components (such as a CNode). For example, if an alarm for an SSD failure occurs together with a related alarm for the CNode containing the SSD, the list of alarms shows the SSD alarm, but not the CNode alarm.

For more information about this feature, see Viewing Events.

CNode Virtual IP Rebalancing

For clusters that have a combination of CNode generations, we introduced a virtual IP rebalancing feature that you can use to maintain a static virtual IP ratio between the different CNode types within a virtual IP pool. This allows you to leverage the increased CPU capacity of newer CNode generations that can handle higher workloads. The following ratios are maintained:

  • Ice Lake CNodes are allocated 50% more virtual IPs than Cascade Lake CNodes.

  • Cascade Lake CNodes are allocated 50% more virtual IPs than Broadwell CNodes.

This feature automatically moves virtual IPs to optimally balance the load across the CNodes according to these ratios.

You can enable the feature on new or existing virtual IP pools using the Enable proportional CNode VIP rebalancing setting.

InfiniBand Switch Monitoring

VAST Cluster 5.1 provides extended monitoring capabilities for InfiniBand clusters through integration with OpenSM, an InfiniBand-compliant subnet manager. If the cluster uses IB networking on its internal interfaces, each CNode in the cluster participates in OpenSM High Availability scenarios.

With VAST Cluster 5.1, OpenSM is to be deployed and run on all CNodes in the cluster. Contact VAST Support to enable the service and manage its configuration files.  

DBox Migration

You can now migrate data from old DBoxes to new ones in a controlled and automatic process. Once data is moved to the new units, the older units can be removed from the cluster without interrupting operations. This allows newer hardware to be added to the cluster, and older hardware removed.

The migration process is managed by VMS as a background process. During the migration data in the cluster is fully accessible (including data in the DBoxes that are marked for migration and removal). If several DBoxes are marked for migration, data is moved from each in turn, and then the unit is removed from the cluster and powered off.

The migration process can take several days, depending on the number and size of the units to be migrated, and the loading on the cluster.

For more information about this feature, see Migrating DBoxes.Migrating DBoxes

SSH by Node Name

With VAST Cluster 5.1, after you have established an SSH connection to one of the cluster's CNodes, you can further connect through SSH to a CNode or a DNode of the cluster using the node name rather than the node IP, for example:

> ssh cnode-1-5

Where the node name is as listed in the Name column of the CNodes or DNodes page in VAST Web UI or shown in the Name field in the VAST CLI cnode list  or dnode list command output.

Note

This node name is different from the node's hostname listed in /etc/hosts.

The following limitation applies:

  • (RESOLVED IN 5.1.0-SP56) ORION-223443 Root permissions are required to establish an SSH connection by node name.

Fornetix VaultCore EKM

Data encryption on VAST Cluster 5.1 supports Fornetix VaultCore as an external key manager (EKM). As with other EKMs, encryption with Fornetix can be enabled only on new clusters during installation. For details, see Encryption of Data at Rest.Encryption of Data at Rest