This post is more than 5 years old
20 Posts
0
996
VMAX FAST VP and SQL Transaction Logs
we have always been told not to use FAST VP with SQL Transaction logs and to pin them to FC. I'm interested to see what others are doing and if anyone has had luck finding anything written saying yes or no to doing this.
ScottBrightwell
9 Posts
0
April 30th, 2013 08:00
I support large enterprise customers for EMC. 80% of them do not manage database workloads to that degree. They'll define a FAST VP Policy for the highest performance apps+db's, a policy for the lowest performance apps+db's, and then one or two in the middle as needed based on their chargeback needs. Any app+db that fits into that policy gets what that policy provides. What will FAST VP generally do with logs? Put them on the middle tier within your policy. That's what you want right?
It's up to you. I have a "one vmax shop" that is very happy with a single 100%/100%/100% "let the array decide" policy. They don't do chargeback or have various tiers. They just need something easy to manage that performs well and is extremely reliable.
My advice: keep it simple unless you fell like the automation is not providing what you want. Unlike many other solutions, we provide the knobs and buttons to allow you to tweak things.
ScottBrightwell
9 Posts
0
April 30th, 2013 08:00
The best practice for overall VMAX performance is a single 100%/100%/100% policy and let the array decide. The reasons to create differentiated FAST VP Policies are
To create a varied set of service offerings for chargeback / showback
To somehow prioritize production or de-prioritize test workloads (but there are a lot of ways to accomplish this)
To create the absolute best performance for any given single application (this is why we do have whitepapers for SAP, SQL, etc. on "how to lay out" these apps / db's using various tiers and FAST policies. These are valid and have their place when you want to jump in and get dirty.)
atthomas1
20 Posts
0
April 30th, 2013 08:00
We would rather just keep everything in one policy and let FAST do its magic. So basically it is ok to let SQL trans logs be managed by FAST then?