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.

• 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.

We went with ConvergedSystem because it's a single bit of infrastructure where we can have compute and network storage in one place. Our support team can be skilled across all devices from top to bottom and manage all the virtualized workloads, which stands at 7800 VMs right now. We don't need to have a separate storage team, or multiple tickets, or requests between systems.

Another valuable feature is its integration with Eucalyptus which provides us analysis for ultra-light loads. It was ready in four weeks and started taking workloads.

It's saved us a huge amount of money on hardware and other data center costs. The next step for us is to integrate it with backbones. We're still doing traditional provisioning of VMs, but ConvergedSystems allow us to do things for our students. The data and analytics we get speeds up on multiple servers.

We're able to give students access to parts of the system and let them onto 30 servers. We didn't have that capability before. One day we'll allow classrooms to do their own self-servers to really speed things up.

I have concerns of whether the VM workload can be sustained in just a couple of racks.

We haven't had any issues with deployment.

We had a few legal issues at the start, but we got the issues ironed out and the systems now run themselves.

Technical support has been good. We have a support contract with HP and access to the right people when we need them. However, HP's presence in Australia is a little light.

It was pretty straightforward. It's built offsite to the configurations you want and shipped to you fully-racked. You just plug it into your data center and start it up.

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.

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.

We use two 4530 shelves in a mirrored SAN configuration, and the ability of the system to virtualize the two shelves as a single storage system is very important to us.

On several occasions, we’ve had a complete power failure at one of our two SAN locations, yet all of our VMs continued to function because the VMs that were running on the downed SAN simply moved to the other SAN without the need for operator intervention. With most other mirrored SAN solutions, the VMs would need to have been manually moved to the other SAN location. With VSA, however, it’s automatic and transparent.

The management system, while OK, could be made a little more user-friendly.

It was installed in April 2015.

We've had no issues with deployment.

It’s been very stable. We've had no issues with instability.

We haven’t outgrown it yet, but if we need additional storage capacity in the future, we can simply add another shelf.

We haven’t needed any technical support yet on this product, but our previous experience with HP SANs was pretty good.

We previously used an HP LeftHand P4500 SAN, the predecessor of the HP VSA. We used it for 5 years but switched to the new one because HP support was ending on the old one and we were out of capacity.

We used an HP partner for the initial setup and configuration. Overall, it was pretty straightforward, although it took a few weeks to get everything “tuned”. Initially, we were getting alarms when moving VMs from one volume to another but bonding the NICs increased the storage bandwidth and resolved the problem.

I definitely recommend purchasing from an HP channel partner as they will handle the licensing. HP licensing can be a very arcane and difficult process and it is best left to the experts. The pricing was comparable with most of the other vendors we looked at.

We looked at a number of products from EMC, Nimble, and Dell, but only the HP VSA could automatically run the VMs from the other SAN in the event of a SAN site failure.

For mission critical systems, I would only recommend this product when used in a mirrored configuration. Unlike other SAN systems where virtually everything in the device is redundant, the HP VSA is basically a server equipped with a bunch of hard disks and special software. Only the power supplies are redundant so there are many more single points of failure compared to other SANs. While other SAN vendors put the redundancy in the same device, the redundancy of the HP VSA is provided by virtue of the two independent devices. What is unique is that the two independent devices appear as a single storage system to the virtualization network and the switching between devices is done by the HP software.