110 likes | 118 Views
Tiered Storage. Chris Naddeo Sr Technical Product Manager, Storage Foundation. Dynamic Storage Tiers (formerly known as QoSS). Qualifying the environment Objections & (if appropriate) how we address them in 5.0 Competitive Issues you are facing. Qualifying a DST sale.
E N D
Tiered Storage Chris Naddeo Sr Technical Product Manager, Storage Foundation
Dynamic Storage Tiers (formerly known as QoSS) • Qualifying the environment • Objections & (if appropriate) how we address them in 5.0 • Competitive Issues you are facing
Qualifying a DST sale • Today’s known DST customers run the following applications: • Email • Medical research files • ‘pre-structured’ data • Large scale records store (billions of miscellaneous files) • There has been interest from customers running these additional applications: • Customer Billing Records (CBRs) • Call Detail Records (CDRs)
Qualifying a DST sale • The sales cycle is shorter with unstructured data • More on structured, relational data in a bit. • Applications with a mix of active and inactive data are a good fit • More storage makes the economics more compelling
Clarity on DST and Relational Data • Do not run from positioning DST with relational data • What we can do today with 4.1 and QoSS • Put tablespaces in read only mode. • Use mtime as the criteria to move *.dbf files. • Applicable for DSS architectures where read only is realistic • Older billing records partitioned by time (TBS schema supports this) • Nextel is going to be kicking off a POC on this in a few weeks • Use explicit or wildcard naming to move specific dbf files
5.0 New Capabilities in Editions Products for DST and Databases • DBA user can now create and manage placement policies. • Root will still have to set-up volume sets. • Analogous to Flashsnap and DB Flashsnap • There are some new placement polices that the editions team created to handle older archive logs • The DBED GUI has some performance statistics that understand component volumes
5.0 New “base VxFS” capabilities not used by Editions • These are exposed in the core VxFS 5.0 offering • You could use IOTEMP or ACCESSTEMP to move a *.dbf file and keep it in read/write mode since if you only did a few writes to the header region we would still move the file. • Come see me if you want details on this • You could “load balance” a filesystem across multiple volumes in a MVFS using the exposed base VxFS 5.0 sub-file allocation mechanism. • This would give you an ASM like construct. It would also bring the benefit of reduced on-line relayout times • 1 large volume, on-line relayout time = x • Many smaller volumes with files stripped across volumes and now you add or remove a few volumes. Relayout time = y • Assumption (and from testing?) is that x >> y • Sub-file DST was NOT consumed by the Editions team for 5.0
DST Objections – heard from the field in 2005 • If you lose the Tier 2 volume you lose the file system. SPOF. • No longer an issue: 5.0 keeps all VxFS metadata on Tier 1 by default, and adds ability to mount even if the Tier 2 volume is missing • It’s too transparent. How do I know which volume a file is on? • 5.0 adds a reporting tool to map from file to volume (and vice versa) • I can’t set relocation policies if I have any allocation policies set. • 5.0 lets users set both initial placement and relocation in one place • Atime/mtime is bogus. Relocation should be based on frequency. • 5.0 lets you specify policy based on access frequency • IOTEMP and ACCESSTEMP • NBU should restore files to the tier from which they were backed up • Still an issue. Call Paul Mayer, NBU PM at 651-746-7022 and let him know your customers need this. He plans priorities for NBU futures.
What else is new in DST 5.0? • Allocation policies can be set on files before they are created • *.jpg should be created on tier 2 • files created by user=oracle should be on tier 1 • files in directory /critical should be on tier 1 • Deletion policies can be set on files • *.mp3 not accessed within 60 days should be deleted • Be careful, especially if you’re Warner Music • An optional wizard steps you through creating policies for common scenarios • Policies are now stored in XML • Open format, not a proprietary one
Other FAQ • Can I upgrade an existing VxFS file system to DST? • Yes, although it requires an unmount • Can I convert it back if I decide I don’t like it? • Yes, you can back out all the way back to a single file system/volume • Do we have any references? • None public. We may be able to arrange a phone call, and we have one customer who may be able to serve as an internal-to-government reference. • Why don’t I just choose a tier for each application rather than put this complex thing in? • Why couple storage and capacity if you don’t have to and it’s not hard? • Setting DST up is simple – fewer than 10 commands, all but two of which can be done online • Many apps need performance for their current data, and capacity for their historic data. Why pay millions of extra dollars for performance when you just need capacity?
Final Thoughts • Competition • Creates tiers with vLUNs and can move data at the LUN level between back end physical storage frames. • No FS intelligence • No Automation • What are your sales inhibitors? • Are you “loosing” to competition? • What else do you need from DST?