Portworx Enterprise 2.8.1 is now GA

We are very pleased to announce that Portworx Enterprise 2.8.1 is now GA. This release includes important enhancements for DR configuration, Cloudsnap Optimizations and some key bug fixes.

Improvements

Portworx has upgraded or enhanced functionality in the following areas:

Improvement Number Improvement Description
PWX-21172 In a Metro DR configuration, there can be multiple cluster domains within the same cluster. When a sharedv4 volume is created, its replicas are placed across these cluster domains. If an app requests a sharedv4 volume, then there is no guarantee which replica node will act as the sharedv4 NFS server. This improvement ensures that whenever a sharedv4 application is started in any of the domains, the volume is attached to a node in the same domain where the application is running, guaranteeing minimum latency.

Fixes

The following issues have been fixed:

Issue Number Issue Description
PWX-21227 While trying to run IOs on multiple volumes with an overlapped overwrite pattern, an sm abort error sometimes occurred on one of the nodes. User impact: This error caused Portworx to restart. Resolution: This rare deadlock during resync no longer occurs.
PWX-21002 A deadlock in the NFSWatchdog path caused lock contention and an inspect command to hang. User impact: Users experienced a mounting issue for the affected volume and saw the pod stuck in the ContainerCreating state. Resolution: This deadlock has been eliminated.
PWX-21224 Setting cloudsnap threads to 4 or less resulted in cloudsnap backups in hung state. User Impact: With cloudsnap threads (Cloudsnap maximum threads field in cluster options) set to 4 or below and doing more than 10 cloudsnaps at the same time, cloudsnaps would be in hung/stuck state without making any progress. Resolution: Incorect check for thread count resulted in deadlock causing the above scenario, which has been addressed in this release.
PWX-20949 Issue” Cloudsnap restore may fail with error message “Restore failed due to stall”. This happens if restore incorrectly thinks that the node is in maintenance mode. User Impact: These restores may never complete and user may with need to restart the node where the restore is stalled or reissue the restore command Resolution: This change fixes the issue where cloudsnap does not interpret node status. An upper layer module handles it preventing the issue.
PWX-19533 Fixed an issue where a node may accumulate over-writes for a volume causing the px-storage process to restart. User impact: None
PWX-21163 Prometheus was unable to access the Portworx internal etcd on a multi network interface setup, hence etcd alerts are not seen. User impact: Prometheus alerts and monitoring did not work properly for the alerts related to internal etcd on a multi-network interface setup. Resolution: Portworx is now allowed internal etcd access from all network devices, giving Prometheus access to scrape alerts.

Full release notes here