Unsolved
This post is more than 5 years old
109 Posts
0
2026
November 21st, 2011 13:00
Does a Rolling Window System Still Apply with FAST VP?
A rolling window system is one approach a DBA can use to manually position data across different tiers of disks. This question came up as I was reading the white paper, “h8177 Deploying EMC VNX Unified Storage Systems for Data Warehouse Applications – Best Practices for Adoption and Deployment” which can be found here: https://community.emc.com/docs/DOC-12631 A rolling window system (RWS) is by design a way a DBA can create a new highly active partition on extremely fast disk (think EFD), move recent data to fast disk (15k SAS or FC) and archive less active data to high density disk (NL-SAS). The goal of RWS is “right data placement for performance” and doesn’t represent a significant demand on DBA time when it becomes a proven routine. We have FAST VP (Fully Automated Storage Tiers Virtual Provisioning) which automates movement of hot blocks to EFDs and moves cold blocks to high density slower disks. RWS and FAST VP upon initial inspection seem redundant as both are about right data placement. Can they be effectively used together?
BartS
46 Posts
1
November 22nd, 2011 05:00
Hi Sam,
I frequently have this discussion with customers. My take:
With manual tiering (what you call RWS) you can force certain parts of the database on fast disk (EFD). Thereby you guarantee fast response times (~ 1ms or less). The alternative is letting the system move blocks (FAST-VP) but FAST-VP only looks at performance history (it cannot predict the future) and therefore some of the I/O will be served from non-EFD. So "pinning" certain data in EFD can outperform auto-tiering. The drawback is that it requires a lot of DBA, Storage Admin and maybe Apps admin effort to make it work. One of my customers has 3000+ Oracle databases and manual tiering for all of those is definately a no-go.
So my recommendation these days is to go with auto-tiering (i.e. FAST-VP) for 90% or more of all databases and use manual tiering (RWS) for the top performance sensitive databases where you need that bit extra horsepower.
I don't see what the benefit would be to do both together (maybe if the standard is FAST-VP then manual tiering on top of that is better in line with administration standards? Performance wise it would not provide any benefits I guess)
By the way, I am opposed to using 15k RPM drives anywhere except when there is a very good reason to do so. 15k consume more energy/power/cooling and are more expensive than 10k rpm disks. And I claim that performance should be achieved with EFD's; not with (faster) spinning rust... I wrote a blog post on that issue BTW.
Cheers
Bart
reseach
2 Intern
•
225 Posts
0
November 22nd, 2011 23:00
From result respective, FAST and RWS is for same goal, RWS requires admin to manually create Tablespace on EFD (faster dev) and relocate high IO density table or index on it, it involve too much manual analysis and effort, and granularity might be high and can’t be agile with data updates. FAST VP does this well, monitoring @ sub-lun level and moving data actively as monitoring result.
I think FAST VP is good, don’t need use them together, a bit duplicated.
Eddy
jeff_browning
256 Posts
1
November 23rd, 2011 12:00
According to my understanding FAST VP and manual tiering, or RWS as you call it, are competing, orthogonal solutions to the same problem.
In the case of FAST VP, periodic, policy based rebalance will move hot blocks onto fast storage.
In the case of RWS, your manual scripts will create a new partition, where current, hot data will reside, and will migrate older partitions onto successively slower and higher-density storage, using the rat-through-the-python approach.
The good news is that if RWS will work, FAST VP will also work, since your workload is consistent, predictable and repeatable. FAST VP does not work for workloads that vary significantly over time. The rebalance will kill you. A traditional OLTP system involving entry of new orders (say in the form of a online catalog), is a great candidate for FAST VP.
FAST VP also works better than RWS, because RWS only addresses a subset of the data. Thus, in an OLTP context, new order entry and invoice rows would be placed on fast storage, but inventory data for extremely active products (which may be older products) would not necessarily go on this storage, since the approach is temporally based. An example would be a clearance sale on an older product.
FAST VP will find active data whereever it resides (provided that this data is in a large enough chunk), and migrate it onto faster storage. Similarly, it will migrate less active data onto cheaper, fatter storage thereby saving space and costs.