The ease of moving data around is very beneficial and will become more beneficial as we get to the next level, in regards to federation. Other things that are beneficial, for one thing, the speed of it is very good for us. We are specifically buying full SSD arrays for our pure zero environment and that's giving us the speed and reliability that we need. The other thing is, migrations have been quite easy to move from older XP arrays to 3PAR. That's been a huge benefit and I don't think could've done that with any other product. It's been very easy. Yes, we've run into some little things here and there but overall, I think that's been our biggest strength with the 3PARs that we currently have.
Improvements to My Organization
Again, moving data around. Speed and the fact that, once we start getting into full SSD arrays, we don't really have to worry about performance issues anymore. So, to the end consumer, which in our line of work is going to be hospitals, they're getting patient data a lot faster, so we don't have to worry about that so much. Of course cost is another benefit of it. It is cheaper for us to go with a 3PAR rather than the XP line. That was a huge reason why we went to 3PAR. Just the other benefits that we found from there, I think have really provided us very good confirmation that we made the right decision on that.
Room for Improvement
The one thing I don't like so much about it is, one thing that I'm dealing with quite a bit lately is, the fact that GA releases of the code, General Availability releases, they don't feel like they're as proven as some of the other arrays that we've dealt with. When we get a GA release from another array, whether it be the XP array or the VMAX or something like that, they seem more stable. The 3PARs, when you're dealing with a GA release, they feel like they have a lot of bugs in them.
We've run into those and they say that we need an upgrade, but doesn't answer my question so much because I'm sitting there going, "OK, I can upgrade but I do a major upgrade once a year." I have many, many arrays and I can't just go, "Oh yeah, we'll just upgrade this here, this here." It doesn't really work that way because I have to go through certain change control processes, I have to go and plan everything out and then I start getting into it. That's what we're about to start here next month, our annual firmware upgrades on all the arrays. I'm hitting bugs in the current firmware and it's like things become unresponsive. I haven't had a problem with an array going down, but I have had problems with getting management to that. The GA releases just don't seem to be well proven out and that's the one thing that I really wish they would improve at some point. I know I'm not the only customer that has run into that.
As far as stability is concerned, most times they just work. That's the thing I really like about it. We just sit there and let them run. Yeah, we've run into little things here and there but most times we're not having to go through and do any troubleshooting. In fact, since we don't do it very often, you run into the question of, "How do I do this?" Now I'm having to go back through and go, "OK, well you ran into this problem; well this is how you're going to troubleshoot it." Well, three months down the road, they may have not experienced any more performance problems and then, "Oh, now we've got something else. Let's go investigate that." It's one of those things, like it's a good and bad thing, because we are performing very, very well and we don't have to do a lot of that troubleshooting but we kind of forget how to do it, you know, over time. Honestly, that's a great strength of it. We don't have to sit there and turn the dials and switches and try to get the thing to perform just as the way we want it to. Out of the box, it pretty much performs to what we need.
I have something along the lines of 65 or 70 arrays. Manageability is a big key. We're working very close with HPE trying to figure out how to manage these better because my SSMC servers are only able to handle 32 arrays at a time. I'm growing rapidly. I'm bringing in new arrays every month. I can't just do one SSMC server. In fact, what I've done is, we have different rooms per site and each one of those rooms has their own SSMC server because we need the growth. I'm sitting here with, I don't know, six or seven, maybe more than that, SSMC servers right now. It's more than that; probably 10 or so SSMC servers. So, we're obviously working with them.
Customer Service and Technical Support
Technical support really depends. It really depends upon the person you get on the first level. Some people that I talk to are incredibly smart. They will go and start tracking down things and finding things out and I am very pleased to get those people. There are other people that I get that are just like, "Oh, well you need to do this and that." Well, I've already done all that. This reminds me of an issue I ran into not very long ago. I contacted support and they were like, "Go do this and this and this." It's like, "Well, I've actually done all of that." The problem is the fact that, because I've got a lot more experience and everything, I'm starting to hit the same knowledge level as a level two guy. So I'm sitting here going, "I've already done everything you did." I'm looking at these things in the log that I don't completely understand. Can you help me understand these. It's like, "Well, we don't; I don't know what that is or whatever," and they have to escalate it. I'm like, "OK, well, you should've probably asked for an escalation first."
Don't get me wrong, there are some really, really smart people. I just run into it in the first level support sometimes where my knowledge of the situation is much more than what the level one guy is, either because I'm already in the fire or number two, I've already pretty much diagnosed it to where I need it to be and I need it to be escalated on their end.
The deployment's pretty easy. We have onsite services that build the array and then we go in and configure it.
They're coming to us on site but they're pretty much dedicated to us. They do have other companies that they help with, but since we have so many things going on, we're pretty much on a first-name basis with a lot of them, so we don't really have that problem. For us, deployment is fast. We can get an array of, if the CE's available to do it, to build it up to the point that we can take over and do our little customizations, we can easily do it in a couple of days. This is far better that what the XP arrays were. The XP arrays required a week or so of formatting. We don't have to do that formatting with the 3PARs. That is one huge thing, where we can just go: Here's another array up and running.
Other Solutions Considered
I'm not going to say we're a one vendor shop, we are primarily an HPE shop. We have probably 95 percent of our stuff is HPE. We do have a little bit of EMC and that's who was in the running. I can't speak to necessarily why that decision was made, per se.
From my personal experience between EMC and 3PAR, 3PAR's a little bit easier to manage in my aspect. It also seems to be somewhat a little bit more reliable. It has those features that you need to do some of the things such as mobility, whereas, on the EMC side, you have the XtremIO, which is all SSD; very, very fast. I don't know about reliability because I've not used it that much. In order to get the mobility out of it, you have to put a VPLEX in front of it which adds latency onto your transactions. It also adds a layer of complexity and it chews up a ton of SAN ports. With the 3PAR, we can put all that in, in a smaller SAN factor, not use so many SAN ports and we get all of that in basically a one-bundle thing. Plus, the vast majority of what we're deploying is 3PAR, so we don't need more than that. Going on the EMC route just doesn't make a lot of sense to us. It's a business decision way above my head, but from my perspective, and I think from other engineers' perspectives, since the decision was made to stay with HPE on a lot of things, it just makes more sense to us to do it that way.
There's enough bugs in it and there are a few things that I wish were a little different, and I can go into that a little bit, but from there, I feel that compared to other vendors that I've worked with, it is very easy. That's the one thing that I really like. It's not, I can easily write up some sort of work instruction and go ahead and do it this way and they'll follow it and it works. That's the thing that I think any store or any storage array really needs. It needs to just work. Yes, when you have problems with it, it has problems but overall, I want it to be easy, I want it to be fast and I want it to work.
I don't have a whole lot of experience with other products and I think that's kind of where things would have to lie; they would have to do a head-to-head battle between two different places. For me, the ease of provisioning to servers and that sort of thing is one of the key parts. The other is that the features that are involved in it, being able to do snapshots which we don't actually do yet, snapshots and replication, that sort of thing straight out of the box. The ease of doing that, the manageability of it, is what would lean me to doing more 3PAR than it would be another vendor. But again, you'd have to do a head-to-head battle with it. Of course, price is going to be another big key to that, too.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Jul 24 2016