Portworx Enterprise + Disaster Recovery

The primary and exclusive purpose of this software is dedicated to storage, specifically for provisioning pure volumes within containerized environments.

A custom IBM script is designed to tackle the storage management challenges within containerized environments, providing crucial data services and features required for enterprise applications.

It would be highly advantageous to include an integrated backup solution within the same license, rather than purchasing backup separately. It would ensure a comprehensive and streamlined approach to data management and protection.

I have been working with it for a year now.

It is a highly stable and reliable tool.

It provides good scalability features.

Dealing with customer support can be challenging when there's an intermediary involved. However, this is a situation that we've encountered before and successfully resolved. We faced a similar issue with Dell, where, for instance, when purchasing storage solely as an OEM product, you are required to go through this intermediary rather than approaching the source directly.

Neutral

The decision to transition from Red Hat to another platform was driven by the customer's choice and was supported by IBM.

The initial setup proved to be a relatively straightforward process. It is important to note that the installation scripts provided by IBM are quite challenging. When working with these scripts, careful attention and caution are required since they are sourced directly from IBM.

The installation process is typically initiated by the customers themselves, and the customer specifically originates from IBM Cloudbox. This represents an OEM version, and since an enterprise requires a license, the customer must secure the necessary license directly from IBM.

I would recommend ensuring that you perform regular backups, specifically the TX backup, which is essential for Portworx. It's crucial to note that no other backup software is suitable for this purpose. Therefore, when obtaining the enterprise license, including a comprehensive backup solution is important as part of the package. Overall, I would rate it eight out of ten.

The main purpose was to replace the NSS as the back-end storage because they were using open source products. We shifted to Portworx to mainly implement shared volumes. We do not use the solution in a heavy environment.

Because we also needed block storage performance, not only NSS, it helped because we could implement PersistentVolumes without needing to know if it was HDS or EMC, using cloud-compatible storage like the feature they are deploying with AWS.

Portworx virtualizes the aspects of the underlying block storage. That is good because they can also use block storage for their future deployment instead of just NFS.

We were using MongoDB, and Portworx has many instructions for applications like MongoDB and Couchbase. They have a lot of documentation, so you can implement PersistentVolumes and PersistentVolumeClaims and construct the YAML based on the application.

I didn't implement it, but I saw many caveats with Portworx Backup. And today, we have other products that are far ahead of Portworx in terms of their backup implementation.

They have not integrated Portworx with Ondat since they are too focused now on Pure Storage APIs and not on users like us.

I have been using Portworx Enterprise for three months. We did a proof-of-concept for a customer.

I rate the scalability at least a nine out of ten.

I could rate the scalability at least a nine out of ten.

The main problem, since they are a small company, was when we opened a support request, there were too few people to handle it. The problem was also that OpenShift was very complex because we migrated from OpenShift 3 to 4, so many of the problems were more related to OpenShift.

Portworks knew the environment at that time and could guide us, and they had lots of documentation with comprehensive texts and best practices.

Positive

My old company evaluated Velero as a backup solution because it was free before VMware acquired it.

The deployment can be complex with Red Hat OpenShift, which closes off possibilities and even creates some barriers, such as while testing dynamic volume expansion. The deployment is complex with Red Hat and even worse now because IBM is adding its object storage. Portworx is not the problem.

The price is competitive, but it is too expensive when paired with Red Hat IBM.

As a company managed in a Kubernetes environment, being trusted by a Kubernetes vendor, Red Hat creates barriers against using other certified solutions that work. Because IBM is a competitor of Pure Storage, things seem to be getting worse.

I don't have plans to use Portworx Enterprise in the future because, at the moment, I am working with Ondat, and I have to follow NetApp's direction on that.

When evaluating Portworx, one should make sure their company has already chosen Pure Storage. Still, if they are evaluating the solution on Ondat or Dell or other platforms, they should get a roadmap statement from Pure Storage, that they will continue to develop storage hardware diagnostics.

I rate Portworx a nine out of ten.

We use it for storage. In terms of data locality, Portworx is pretty good compared to other technologies in the long run. We also have other SBS layers, but those are not enterprise, and there are not many offerings from those technologies, so I understand.

The best thing about Portworx is the Stork, they have called the VPS (Volume Replacement Strategy) and they also have topology awareness, and these are the three features I like. Additionally, the engine is thoroughly tested, and the load-balancing engine can handle the load very well.

One area where Portworx can be improved is with data locality. This is not always achieved, especially when we don't use VPS or when we don't have a sufficient number of worker nodes. Portworx generally guarantees data locality, but we have found that with a replica factor of two, we need six worker nodes to ensure data locality. Data locality is important because it allows data pods to find the data locally instead of going over the network. If the data is not locally present, it has to go over the network to get it. So data locality is an area that could be improved. Additionally, the documentation could be better. We have found quite a few bugs, and they need to improve the documentation to address this.

It is a stable solution.

It is a scalable solution. It can easily scale up and down. Around 20 people in my organization might be using Portworx Enterprise at the time.

We've had a constant engagement with Portworx support and have raised quite a few bugs with their toolbox.

For the initial setup, the company provides Portworx's Spectrum, which generates URLs after passing a few details, making it seem straightforward. But it's not that easy. Sometimes issues arise during deployment because understanding the Portworx architecture is crucial. It has several components, such as KBDB, a Stork scheduler, and Portworx cluster, so understanding the architecture helps troubleshoot any issues.

The initial setup usually takes five minutes. It's pretty fast.

It has two offerings. One is free, which is limited to only five nodes. The other is enterprise, which is a bit pricier.

Let me give you an example of a customer. They provided storage but not for use with Kubernetes. The storage was network-attached and not integrated with Kubernetes. In order to integrate the storage with Kubernetes closely, you need to install drivers. Requests for PPE or PBC creation and volume creation should go through these drivers. The drivers are deployed as ports or deployments in Kubernetes. For example, Dell provides its own Kubernetes plugins when we use Dell storage, which makes it easy to provision the requested storage. Currently, it can interact with the storage.

In one of our customer's cases, the storage was connected to all of the nodes, but the integration was not done because that storage did not support Kubernetes integration.

We had a database application that needed dynamic volume provisioning, which was not the case. We tried initially with Longhorn, but we ran into many issues. So we had to drop the idea of Longhorn and go with Portworx. When compared with Longhorn, Portworx was better in terms of performance and handling of the load. So we deployed the solution and tested it thoroughly. We went through the Portworx documentation and features. Basically, Portworx uses Stork, which is one of their native technologies that you can leverage as Kubernetes. Whenever a port request comes in, it goes to the Kubernetes scheduler and that information is passed to Stork. Stork then assigns scores to the worker nodes based on the volume where it is present. This ensures data locality, and Portworx does it better than other technologies in the long run. So based on that, Portworx will be deployed on a node where the volume is already present.

I would recommend the solution depending on the use case. If a use case demands support, and the high-performance, then you should go for Portworx. Also, consider the type of application you want to use it for and take certain factors into consideration before going into the storage, VPS layer, or CSI.

Overall, I would rate the solution an eight out of ten because of the data locality, documentation, and possibly a cheaper price, which could increase the score. It works quite well under intensive load, and support is available. It does what it has to do at the end of the day.