HPE StoreVirtual Reviews

We were primarily looking for a storage system for a management cluster that was separate from our fiber channel SAN. Fiber channel SAN is all of our mission critical stuff, but we needed somewhere for our management systems that are watching and monitoring everything. So we were looking for something that was ASCII based. We wanted something that wasn't going to take pre-built hardware because we have two different data centers and a third location where we are trying to spread the data across those locations. The VSA solution was great because it runs on ProLiant alongside of our ESX servers and we were able to get that geographic disbursement of our data while watching our mission critical fiber stuff. It's simple to administer too and it was simple to set up.

We leveraged StoreVirtual to provide a software SAN for our management cluster of vSphere - this allowed us to run monitoring and management applications on a separate infrastructure from the rest of our Fibre Channel based vSphere clusters and allowed us to watch and observe, even when the SAN was having a problem.  

The user interface needs to be updated. It's getting kind of long in the tooth, and the user interface makes it look a lot more complex than it actually is to manage, and I think that you can mask a lot of that with a refresh of the user interface. While HPE has created a new HTML5 UI for the HyperConverged 380, it is not available to the rest of the StoreVirtual population.  

We've got about four years worth of experience with it.

Sizing information is scarce to know how to size drives and which types of drives to use.  Different engineers in HPE have different opinions how to deploy the solution.  Using VMDK disks under the StoreVirtual for its primary storage caused a lot of low disk space errors in vSphere on the VMFS drives, so either you leave a lot of space unused to avoid errors or you deploy it onto RDM's with local disks (which takes some extra configuration).  

StoreVirtual has been great. We haven't had a failure in all the years I have run it, and we went through a reconfiguration about three months ago to add some solid state drives to improve the performance, and it works fantastic.  

The great thing about that is if we are hitting a performance issue or something, scale is built into that platform, you add additional nodes, you've got additional capacity, you've got additional IOP capabilities across your virtual array. So scaling within StoreVirtual is really kind of easy, just scale it out to another node. The trick, however, is each node really needs to be configured the same as the last - so mix and match in the future with new technology becomes more of an issue.  

StoreVirtual setup is actually really simple. There are a couple of different ways that you can do it now. You can set it up from intelligent provisioning, which is included on every Proliant server. It will go out to the internet, pull down the bits, and deploy it for you. It's all sort of work-flowed and really simple. If you wanted to, you could pull down the bits yourself and there is a wizard that deploys it. That's also really simple. You have to do a little bit of planning of how you build your rate sets and drive sets and stuff that are going to be underneath it, but it's incredibly easy to deploy, whether you are doing bare metal, or BSA like we are doing.

Pricing is very affordable - it is great for SMB on up to Enterprise looking for branch solutions.  Purpose built-appliances are also available for those looking for more scale.  

StoreVirtual isn't going to be a jack-rabbit - it isn't going to be the best performing SDS you find on the market, but it is most the most affordable and it suits many use cases.  

• The ability to scale out if/when additional capacity is required.
• The ability to migrate data between clusters within the same management group.

It hasn't helped as the HP provided software for the host server systems has become a continuous nightmare when it comes to HP LH OS upgrade process with our 260+ systems in multiple management groups/clusters.

• Inability to customize alerting thresholds.
• Un-usability of the HP CMC for HP LH OS upgrade when a newer version is released but not upgraded although the to-be-upgraded version is an older one.
• Failure to report on lower-level hardware issue via HP CMC and/or SANMON UI unless checking iLO GUI.
• Inability to re-configure/modify iLO settings via HP LH OS.
• Multiple HP SANIQ / LH OS upgrade issues, e.g. upgrade resource partition unavailable, especially if the systems have been running for close to or more than a year.
• Bug(s) in the HP-provided software for the host server systems not detected/identified by HP QA/QE and caused multiple post software-upgrade outages.
• Difficulty on even opening a case due to poor record-keeping of/by HP.

~6 years.

There have been no issue with the deployment.

We have had numerous issues with the stability that have been enumerated above.

We have had no issues scaling it although upgrading a management group with more than 10 nodes can turn into a reboot nightmare...if the reboot even resolves the bug(s)/issue(s).

Just OK...especially if you should be unlucky enough to have a set of P4800 (blade-based)

It's 8/10 once we escalate past Tier One, and sometimes even Tier Two.

We were previously using NetApp for block-based storage requirements. HP StoreVirtual (LeftHand) was selected due to the lower initial purchase (CapEx) and subsequent support (OpEx) costs.

It was reasonably straightforward.

All our HP StoreVirtual (LeftHand) systems are implemented via the vendor teams that handle most of our on-site work followed by in-house Storage Administration team member(s) for additional storage-level configuration.

We have not officially calculated the exact ROI.

There's no advice about pricing/licensing as we handle it via an HP VAR, with a contract established with YP, that provides very good pricing/licensing numbers.

NetApp.

My advice is to only use HP StoreVirtual (LeftHand) for small-scale and/or per-project deployments via iSCSI (IPSAN) preferably on dedicated network between the host server and the storage systems.

That my team can manage it. The server guys can actually manage the storage on their own. It was easy for them to learn to use the console and provision the storage quickly.

It was a long, painful process to get storage from the storage team and having to go through a lot of paperwork and processes, where now we can do it on our own quickly and as needed.

It's easy to set up, easy for my team to manage, the tools are pretty easy to learn, and it's important for us to be able to provision storage quickly in my environment, so as soon as we get a new node in, we can get it up and running very quickly, provision it, immediately use the storage.

The only issue that we have, occasionally, is bonding the NICs sometimes is problematic. It could be our environment. We have the Cisco Nexus infrastructure, and sometimes the nodes just don't want to bind. We have all kinds of problems with it, and we have to call a ticket in, and the product guys to help us figure out what's going on. It happens occasionally, it's not like, every time, it's just every once in a while.

The only thing that comes to mind was we had some issues with once we used up storage and then moved it out and had empty, white space areas, but getting that storage back is a long, painful process. You actually have to run a manual command line on each LUN individually to reclaim the storage.

Making it easier, automated, or being able to do it right from the console would be a great benefit because right now, again, we have to go to a command line and issue that for LUN, there's hundreds of LUNs, so it takes a very long time to go through that process.

Latency is one of the things that our vROPs all the time, complains about the latency for that environment. We don't have good visibility to find out what's really causing it, what's underneath the problem. That's kind of been a sticking point that we're going to look into, but definitely vROPs are always complaining about latency from the StoreVirtual LUNs.

Scalability is one of the reasons why we got it. Now, there is a limitation on how many nodes you can have on each measurement cluster, so we have to kind of figure that out - what the best number is to have on each one.

We've had challenges, especially with opening tickets. Waiting for someone to get back to us can be a huge amount of time. We do have proactive services, so sometimes I have to pull those guys in to help escalate a ticket just to get some attention to it.

I would say it is medium complex. I know I had one guy that understood it, he left the company, and didn't leave good documentation. We got a new node in and it took my guys a little bit to figure out how to get it set up. It's not like it's intuitive, but it's a process. It's not super complex, but once you do it and document it properly, then it's fairly straightforward.

We did go through an evaluation process. It was quite a few years ago. There was definitely competitors to StoreVirtual, actually, it was LeftHand at the time, when we made the decision to go with the product. We've stuck with it since and nothing has come up that has challenged that to make us rethink yet. There was definitely Dell, and as it was a number of years ago, I can't think of any other.

It wasn't EMC, but I think it was a NetApp product, because they do iSCSI as well, but again, then that would fall back onto the storage team and we want it to kind of stay away from that.

I would say, number one spend time to understand the product, to get the proper training or the people involved when you bring it in. Make sure it's the right product for what you're trying to solve. It's not a take care of any type of storage problem, there's no specific use cases that you want that it's good for.

Like I said, for the virtual environment, it does great for VMware, Hyper-V, whatever you want to use that type of storage for. Then it's just quick, easy storage if you need it for a file server, it would be good for that. You wouldn't want to use it for a cluster or a high I/O thing, but for the virtual environment and storage that's not dependent on high I/O, it would be a good fit.

• Heterogeneous hypervisor support
• Broad hypervisor version support (vSphere 4.x, 5.x, and 6.x in future)
• Broad hardware support, no special qualification or HCL beyond that of the hypervisor
• Snapshot for BC and backup
• Multi-Site SAN for DR (synchronous volume replication)
• The Veeam snapshot integration plus the hypervisor integration with vSphere VAAI and VASA as well as the Microsoft VSS integration is second to none.

We can afford shared iSCSI storage and it’s easy to deploy for the lab as well as production usage, not just for critical production apps.

The capacity utilization is the worst in the industry as far as I know. Data compaction in the form or dedupe and compression, while on the roadmap, is long overdue. A serviceable (e.g. practical) “Network RAID 5” would also help the capacity utilization issue.

I've been using it for four years.

We have had no issues with the deployment.

There have been no stability issues.

There have been no issues scaling it for our needs.

It is good if you know how to navigate the HPE support queues (Storage -> LeftHand) to reach a legacy LeftHand support engineer. If you overlook this simple but critical detail you risk falling into a “black hole of support.” If you reach a legacy Left Hand engineer, you will have a successful user experience.

StoreVirtual/LeftHand is very well known in the HPE world. For vSphere, I don’t have the hardware to run VMware VSAN. For Hyper-V, it is rumored to be easier to use than MS Storage Spaces. For KVM it is perceived to be the easiest available solution (due to my ignorance, perhaps?).

The initial setup is very straightforward and not at all difficult. There are good HPE written documents and YouTube videos as well as some good independent content on sites such as https://www.bitcon.be/.

Read the HPE content from 2014 and then watch the StoreVirtual VSA “How To” video series on YouTube. Talk to someone who knows and has implemented LeftHand, if possible.

I don’t maintain hard and fast ROI info, however, I believe it is 50% less expensive than a SAN for deployments under 15 TB of usable capacity. My advice is to make sure that you understand the true usable capacity calculations and that you have no other option for production apps other than “Network RAID 10.”

The design of the solution is critical. If you undersize the hardware the performance will not be adequate. Also, setting the customer’s expectations is very important. StoreVirtual VSA is relatively slow for big block sequential things like migration and large file or directory copies. It is designed for day-to-day random IOPS with at least 50% read IO, typical of most virtual environments.

Talk to someone who knows and has implemented LeftHand and StoreVirtual VSA, if possible. Find an HPE Partner that has deployed this at least 3 or 4 times. If you choose to “roll your own” read the HPE content from 2014 and later then watch the StoreVirtual VSA “How To” video series on YouTube. Also check out Veeam Backup & Recovery’s StoreVirtual snapshot integration as well as HPE’s best kept secret, the StoreOnce VSA for virtualizing your disk-based backup and recovery.

This screenshot depicts a restore operation from an HPE StoreVirtual VSA snapshot of a primary storage, production VMFS volume. This can give you a Recovery Time Objective as low as 30 minutes on StoreVirtual VSA production volumes whereas recovery from a daily backup offers an RTO which can be up to 24 hours. Restores can be executed for SharePoint objects (including sites, libraries, documents, calendar items and lists), Exchange items (.edb files, mailboxes, calendar items, contacts and even individual messages), Active Directory objects (Groups, accounts and GPOs) as well as SQL record and tables. Oracle DB support is now available as well.

Our primary use case is as a database for Oracle Databases and their ERP system, for the VMware server to run Veeam, and for some websites. For a not very high workload, less than 10 TB. For our customers' database, it's around 2 TB in these use cases. 

We are not currently providing services for StoreVirtual, as customers are upgrading to the new model.

As for features that can be improved, it is a costly solution. Maybe upgrading to the new model is better. Additionally, it could be more scalable, the scalability can be more loaded.

Lastly, it could use SD to rehash hybrid storage.

Our customers are using this product for around three years. 

Normally, the customer complains to HPE. In some cases we go on-site to help customers. Or they just buy our support and we will go to the site to help our customers to do some maintenance.

It costs less than $10,000 for one machine. If it costs more than 15% higher than this, then the customer may change to another solution.

StoreVirtual is a single loader converter. Normally, we will sell NetApp and they scale out some dispatch systems software storage. I know some customers are using the Veeam Manager when it is just a small amount of data and they are using the local hard disk and they want to share storage. We also use the Veeam edition. But now, most customers are more interested in the hyper-converged systems. But you know the cost of hyper-converged. The cost is not so low and customers can pay hundreds and thousands.

My advice is not to pay the full price. Compare it to NetApp ECS or the Lenovo or EMC Unity.

Normally, the customer is using it and we may tell them to continue using this solution, otherwise, we may let them change to another product because HPE is not the main solution for my company. My company is selling NetApp, EMC, Cisco - these are our main business.

On a scale of one to ten, I would rate this solution an eight. This is because it's very stable and it's easy to use. That's very good. But if you compare it with new technologies like Scalr, like hybrid solutions with SAP to cache to improvements, it may not be a good choice.

HPE StoreVirtual is very easy to use from the management console. The interface is very good.

This solution is very easy to deploy.

The performance is very good.

I would like to have this solution easily integrate with VMware.

I have been using HPE StoreVirtual for the past four to five years.

This solution is very stable.

This solution scales well and it maintains very good performance as the storage increases.

I have not contacted technical support for this product because it is very easy to use.

The biggest lesson that I have learned from using this solution is that when compared to other products, automatic tiering, availability, and disaster recovery are very good.

This solution also integrates well with the Recovery Management Center. We have a backup solution for VMware and Hyper-V, and it is simple to use with HPE StoreVirtaul.

I would rate this solution a nine out of ten.

Shared storage in the organization allowed for higher availability and simplified server maintenance.

Enables us to build highly available shared storage from a standard rack server, such as HPE Proliant DL. However, it is not limited to that. Thin provisioning lets us get the most value from the hard drives. I found the architecture to have less single point failure than a traditional SAN.

Configuration of application integrated snapshots for VMware is convoluted and it did not work immediately.

In terms of stability, the optional MEM (Multipath Enhancement Module) was unstable in one installation with 1GB iSCSI network. Long running, intensive file copying tasks between VMs produced a storage latency "explosion". The issue disappeared immediately after removing the MEM drivers from the ESXi hosts and restoring the default vSphere Path Selection Policies. We did not have an opportunity to review the environment or test an updated MEM.

There were no scalability issues. The 3 x 4TB license is a very good start for two nodes. We can add a third node for additional storage and compute power. If the performance demands increase, we can simply install or replace the current iSCSI network adapters with 10GbE. The system also supports SSD and auto-tiering with higher licenses.

The HPE technical support for StoreVirtual VSA is very good, but it requires some time to contact them. To get a simple piece of software means registering StoreVirtual VSA. This is a complicated process. The SAR (Service Agreement ID) is associated to the VSA Licenses. It requires you to open a request on the HPE website and this is hard to obtain.

We did not use a different solution before this one.

There's an installation wizard which is quite simple. However, you need to have a clear image of the final scheme, especially for the network. At the time, I missed a reference blueprint, but a recent publication of "StoreVirtual VSA Ready Nodes" filled the gap.

Review the licensing options, because the smaller licenses are time limited. If you buy a five-year license, not only does the technical support expire after five years, but you also lose the ability to change and expand the VSA, and the systems won't go down. I wouldn't keep a traditional SAN in production without support anyway.

Spend some time reading StoreVirtual best practices and consider buying redundant solid switches, like HPE Aruba ProCurve 25xx, or better. Layer-3 is useful, but not mandatory thanks to split network support introduced in VSA 12.5.

It offers, while still affordable, a really high end storage solution that I can present to my customers.

I guess on the top of the list is certainly ease of use. We're a smaller company, and we don't have a lot of engineers who can dedicate their time to a single product. I guess I'd also say reliability. I need something that just kind of works all the time. I don't have the time to be dedicating resources to fixing things.

For this particular product, I was talking to one of their storage people about it. They already added the few things that I needed. So I don't have anything major. But it would nice to have deduplication or compression, things that you have in some of the higher end products.

Stability is excellent.

Scalability is good, as well. We are certainly going to push the upper bounds of what it can do.

We have used technical support and it has been great. It is quick to get access to their support engineers, but also they solve every problem.

This is actually what we selected when we started this search. When selecting a vendor, cost is there, of course, but more than that, some of the other things I've mentioned: Ease of use, reliability, and support. The relationship goes a long way, too. Having access to people directly, whether that's sales engineers, or the sales team themselves. We are a small company, so getting attention from a big company like HPE is great. We probably wouldn't get that from other companies.

The initial setup was very straightforward. It was very simple.

We started using this before HPE purchased it. It was LeftHand Network before. It was them versus HPE's SAN, so technically HPE was the other vendor. Now HPE owns it. We chose this solution because it was cluster storage, so for us and our size, it was a better product line.

I would say with this particular solution, you're getting a lot when it comes in price point. You're getting a lot of features compared to some of the other products out there.