HPE Storage Users Group

The more we push our arrays the more we find limitations in code that should have been addressed. The latest is Remote Copy with vol IDs over 32768. Seems while the array can support creating vol IDs over 32768 then Remote Copy can't use them so you are forced to find unused vol IDs below 32768 and create things manually via the command line. Just baffles me how they QA this product supporting 64K volumes, but forget to test that in co-ordination with Remote Copy. Add that to the issue where 3.1.3 upgrade fails if a NIC is set to a fixed speed and I have to question 3par's validation of code prior to release. Damn shame we just bought 2 more 7400s and have 7 arrays total. boy do I have regrets.

So my next concern is what happens when the array hits whatever limit it has on the number of vol IDs, does it go back and find unused ones? Or does it stop creating volumes automatically and force you to manually create volumes from CLI where you can force the vol ID.

Why do you have VOL IDs over 32k? That seems insane to me...

I have no specific knowledge of this "bug", but that number is special as it is the maximum number of volumes supported on a T/F series 3PAR. Do you have any remote copy links from your V to an older T or F series unit that would require such a limitation?

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.

We do not do traditional backups, we snap every volume every night and retain it for 30 days, and do same on the replicated side, so with several hundred volumes we churn through vol Ids quickly. HP was well aware of our plans when we bought the arrays.

We only have V400s replicating and then a pair of 7200s and 7400s, but they are so new their vol ids are very low still. I think there were a lot of limits in earlier models that while they say are no longer in place, I don't think they have reviewed their code enough to realize there are limits in some areas of the code. My pet peeve here is 3.1.3 support 64K volumes, I don't know how they tested 64K volumes with RC which makes their validation methodology suspect. I have gone from being a huge 3par fan to be very skeptical of them right now. Seems like every week we have some issue that is a limitation or a bug and then it takes them forever to work it. We have about 2 dozen open cases, some going back months. I think in theory their technology is awesome, in practice and execution they need HP to gut them and truly make them an Enterprise product with a world class support organization.

Hard to argue RC not working up to the new VV limits, that's a QA fail...

I thank you and other "controlled" release testers for subjecting yourselves to the bleeding edge of software releases, someone has to be first. I know most people generally wait to see if a new release is stable, and that's industry wide, not just 3PAR.

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.

We are usually one of these wait and see companies but we now have 5 logged calls with HP on differing issues that are supposedly fixed in the 3.1.3 release.
We feel like we are being driven down this path a little.

Same here, we don't really want 3.1.3 from a storage perspective, but both HP and VMware say you need to go to 3.1.3 before you update esx to 5.5 with MSC/Peer Persistence in use. And because our ESX-guys plan that update, we need to plan our too...

_________________
When all else fails, read the instructions.

Trust me I did not want to be a controlled release or even 3.1.3 before MU1 person, but we kept hitting the wall on limits on 3.1.2. 3.1.3 was due last December and they pulled features to get it out the door even now. I have worked with 3par product management and they are good people with good intentions, I just feel 2 things hurt them. First the legacy niche background the product comes from really does not meet today;s Enterprise needs in some areas, especially with replication. The second is HP doing a horrible job of assimilating them into the HP family. They pimped out the 3par storage and never invested the resources into support or ever R&D for the explosive growth the product had, now they are in catch up. Getting a knowledgeable 3par support person is difficult. L1 in the US is virtually useless as they just staffed up those call centers and then L2 is over whelmed, but there are handful of really smart people in L2 if you are lucky to get to them. Fortunately (for the wrong reasons) I have gotten to know a few of them due to the numerous issues we have had and they really are good people, but there are so few of them and even fewer L3 that HP is overwhelmed. I do not see the support issues or QA issues going away anytime in the near (12 months) future.

hdtvguy I do feel for you and wouldn't normally comment on support issues, simply because without the timeline and all of the data to hand any view is subjective, it being difficult to correlate and provide a balanced view of what went right / wrong.

However I have to say your use case is somewhat unique and is actually outside of the design scope of remote copy today, like it or not it was never actually designed as a replacement for a backup solution. The fact that you can knock up a working remote backup with scripting doesn't make it a qualified or fully tested solution, if it were there'd probably be a separate license for it

Snapshot only based backup has always had scalability issues on every platform I've worked on, even good ol Netapp where their go to market is snap and replicate everything. So whether you like it or not you're implementation does appear to have some bleeding edge features and as such is likely to uncover limitations that are outside of the standard scope for remote copy testing.

Cleanur

I would agree, but we had extensive conversation with HP account and product teams about our use cases and they all agreed we can do what are are doing. The latest is now they think I either found a bug or because I have one array at 3.1.2 still. That will be easy since in 3 days that arry goes to 3.1.3. The bigger issue is after numerous support folks they can;t tell if this is a limit, a bug or a limitation because I have a single 3.1.2 array. I am just frustrated as 3par support has been so bad and slow slow and incompetent on so many cases lately I feel like I am dealing with a small niche provider.