Implementing FAST VP for SAP on VMAX, the art of creating FAST VP policies
In my first blog on “Implementing FAST VP for SAP on VMAX”, I reviewed some recommended best practices to define Storage Pools and Storage Groups, which form the foundation of implementing FAST VP in any application environment. Setting up the Storage Pools is the first step for deploying a VMAX and defining the Storage Groups is the first step to implement FAST VP.
In this blog, I am not going to expound on the wonderful benefits of deploying FAST VP for SAP since you can read about them in this white paper. While the concept of “putting the right data in the right tier at the right time” is very appealing, it runs counter to what a typical, highly disciplined SAP Basis person and their storage admin have been conditioned into thinking for years: in traditional thick LUN environments, data layout is very careful designed and implemented on SAP Production systems, yet FAST VP will change all that “static” layout since chunks of unused data will be demoted to a lower tier while hot data will be promoted to higher performing tier.
This notion of “automated” data movement by FAST VP can be unsettling to the SAP Basis team, so it is important that they completely understand not only how FAST VP works, but how it would be implemented, what are the safeguards, what are the undo options, and such technical details.
The first point to make when starting a FAST VP conversation is that the vast majority of SAP customers agree that as much as 75% to 80% of data in a SAP Production database is NOT touched during normal operations and that data could and should be archived out, but people are reluctant to undertake this work – this is why SAP databases have grown to become so large these days, and it is no longer uncommon to find SAP ECC databases to be around 10TB and SAP BW databases approaching 18TB.
What are needed are a FAST VP policy, and actually a bunch of FAST VP policies, which can retier data according to actual SAP workload, in order to save money and boost performance, if possible.
Our work with our showcase customer, and with other customers, has clearly shown that creating FAST VP policies are more art than science! Here are some interesting thoughts and observations.
First, we have learned that you will need to create different FAST VP policies for SAP ECC than for SAP BW since I/O patterns for an OLTP application is quite different than those of an OLAP application. Second, there will be the need to create different FAST VP policies for Production environments vs. non-Production environments, since once again, I/O patterns for each of those environments will be different.
Third, there will be times when FAST VP policies should NOT be applied to certain SAP applications (such as APO, SCM, or LiveCache) or to certain data stores, such as redo logs – I will discuss the reasons why NOT in future blogs. Fourth, we have to carefully review the I/O patterns on the existing SAP Production on thick LUN and even run some collected data through I/O modeling tools such as TierAdvisor in order to have a good understanding of how FAST VP policies could be designed.
Finally, and this is perhaps the most important point, the effectiveness of FAST VP policies should be VALIDATED, either by extensive load testing in a non-Production environment or if load testing is not possible, by a gradual roll-out of a series of FAST VP policies, one increasingly more “aggressive” than the previous to see how things are working out under actual Production work loads and take advantage of data movement under FAST VP control.
Monitoring the performance of the SAP systems, both at the application level (using ST03N for example), at the database level (using AWR for example), at the OS level (using NMON for example), and at the storage level (using SPA for example) is a crucial part of any successful deployment of FAST VP. The good news is that the tools needed for doing such monitoring work are plentiful and readily available, and in future blogs, I will discuss these tools and the measurement methodologies in details.
As we monitor the performance, we should not hesitate to make adjustments to FAST VP policies as part of the validation process – once again, this is more art than science since each SAP customer work load will be different from the other.
We MUST adopt an Observe & Adjust strategy when it comes to implementing FAST VP policies because the goal, indeed the first ground rule of designing good FAST VP policies is that the resulting performance (when FAST VP is initially turned on) will be at least equivalent or better than the performance of the customer’s existing storage environment.
In the next blog, I will discuss some recommended FAST VP policies which were given to customers, and comment on how they should be implemented. In future blogs, I will discuss topics ranging from measuring the effectiveness of FAST VP policies, to validating the effectiveness using load testing, to designing policies for non-Production environments, to documenting costs savings and/or performance increase which would provide a nice TCO analysis which would validate the concept that implementing FAST VP for SAP on a VMAX is the right thing to do.
Tim K. Nguyen
SAP Global Technical Evangelist & EMC Cloud Architect
EMC Solutions Group