Upgrade or buy new 7400?

[JasonAntes]

Here's the scenario I have:

We are replacing our EVA4400 in our test environment. 60 disks and starving thing. I have a choice to make. What we have currently is a dual controller 7400 with 80x 400GB SED SAS disks.

Option 1: Upgrade the current 7400 with another 2 controllers, 80x 400GB SED SAS disks, license Performance Optimizer, and use the multitenancy feature of the array to separate test to it's own domain using PO to guarantee performance of the current production environment on the array. Also use PO to limit the test environment servers to performance requested by the developers. Replication, DO, and SR are licensed and would be increased for this purchase.

Option 2: Buy another 2 node 7400 with 80x 400GB SED SAS disks, license DO, SR, and replication (although do I need replication to copy LUN's within the same SAN fabric/data center?). Would not be able to get PO with this.

I'm leaning toward option 1 as it gives me PO and we aren't really pushing this array anyway with 80 (160 if upgraded) disks. Currently I see a nightly high of 8000 IOPS on the array during backups and maybe 2000-3000 IOPS during the rest of the day. The extra controllers would get me a few more benefits as well so there is that. Anything I'm missing or should consider?

Thanks,
Jason

[skumflum]

I would always vote for fewer systems and 3PAR has mutitenancy build into the design, as you already mentioned.
In addition, the next version of InservOS is improving QoS a lot. You can now specify the service time in addition to iops. You could look into Adaptive Optimization. Maybe you don’t need to buy 80 FC disk?

The total price is interesting though. HP want to push new 3PAR systems.

Do you have any performance data on the EVA usage?

[JasonAntes]

We've quoted out both scenarios and can get either for about the same price. It comes down to getting additional license packages we don't have or a new rack for the most part. Don't know that we really need AO since it's all the same disks, we don't have tiers. I know there is a lot of good changes coming in the next release of InformOS that I really want for my current arrays now.

Performance on the EVA is hard to gauge accurately because we are saturating the disks. It is all FATA disk so it is low performance and we are seeing 4-5k IOPS on the array before it slows to a crawl.

[skumflum]

. Don't know that we really need AO since it's all the same disks, we don't have tiers.

Yes, you need tiers of course. I know the result it is not as predictable but maybe you could build a business case and save money

[JasonAntes]

. Don't know that we really need AO since it's all the same disks, we don't have tiers.

Yes, you need tiers of course. I know the result it is not as predictable but maybe you could build a business case and save money

I'm looking at it as a case of 2 different CPG's with 2 sets of disks and not crossing between them (other than to make snap copies of things from production to drop into test) or 1 large pool of disks with 1 CPG. I'm still not sure where tiering comes in?

[Richard Siemers]

I am a big fan of using all those extra dev spindles for PRD performance when dev is idle, But I also like having a dev Inserv just for testing/experience online upgrades in a non-critical environment first.

Another "option 1" pro is that it will enable you to get clever with snapshots of PRD VVs and using them in DEV instances. This can save space, improve read cache hits, but also decrease the amount of time and horsepower it takes to spin up a DEV database from a copy of production, if such a thing exists in your business workflow. Refreshing a SAP dev or QA instance from a copy of prod is a major event that can be scripted and become trivial with the use of snapshots.

Adding more nodes; you will want to look at re-balancing your zones/host paths as well.

[JasonAntes]

I am a big fan of using all those extra dev spindles for PRD performance when dev is idle, But I also like having a dev Inserv just for testing/experience online upgrades in a non-critical environment first.

Another "option 1" pro is that it will enable you to get clever with snapshots of PRD VVs and using them in DEV instances. This can save space, improve read cache hits, but also decrease the amount of time and horsepower it takes to spin up a DEV database from a copy of production, if such a thing exists in your business workflow. Refreshing a SAP dev or QA instance from a copy of prod is a major event that can be scripted and become trivial with the use of snapshots.

Adding more nodes; you will want to look at re-balancing your zones/host paths as well.

For all firmware/patching updates we wind up using our DR site to stage them. We have used test as well for that but DR winds up being a better option for us to test against as I don't have a separate FC build out just for test in order to test updates end to end.

Anyone know if we have to take an outage to add in the additional controllers for option 1? From what I can tell the answer is no.

[ailean]

If the extra disks go in new trays attached to the new nodes so that the disks/node pair are balanced then I wouldn't imagine any outage. We did a similar upgrade on our old F400 array but with the added complication of having to move half the existing trays/disks over to the new pair. We had enough space to evacuate the disks that were moving so even managed that upgrade without downtime.
I'd probably not filter the CPGs to split physical disks between Dev/Prod if you're going to use PO or the hosts are all behind VMware ESX 5+ as limiting via some form of QOS will be more flexible.

[jgmke]

I like the idea of having a single 4 headed 7400 allowing PRD access to more spindles. Use PO to implement QoS. You also get the ability to lose a controller without losing write caching.

Just my 0.02...

[Cleanur]

I would avoid using a filter on the CPG if at all possible as it just creates more work going forward since you need to maintain the filter on all subsequent CPG's, use QOS and cap the dev workload or in 3.1.3 you can provide relative priorities, guaranteed minimums and latency goals for production. BTW you don't need a separate domain to do this as it can be set on a VV Group.