SAN Storage for Database Systems Future storage subsystem options for database systems

Topics Current CSS SAN Unaddressed Issues Next Generation Arrays NFS Costs

Current CSS SAN Conventional RAID Groups –Standard Luns (<=2TB) Centralized Management Dynamically allocate storage Cluster able

Unaddressed Issues Downtimes –Maintenance Tuning/Optimization Restructuring –Unscheduled Amount of storage use Cost

Next Generation Arrays 3PAR Data and Compellent –Reduce amount of storage use Thin provisioning R/W snapshots –Reduce maintenance outages Dynamic Optimization/Tuning Non-disruptive upgrades –Reduce cost Non-disruptive tiered-storage

3TB2TB 4TB5TB6TB3.25TB4.35TB5.25TB Reducing Amount of Storage Use: Thin Provisioning 1TB Year 1Year 2Year 3Year 4 Existing Projects New Projects

Reducing Amount of Storage Use: R/W Snapshots Production Development Integration Development R/W Snapshot Integration R/W Snapshot Delta from Developers 3x Storage Needed 1+x storage needed Traditional New Refresh DB for Dev and Int much faster Much smaller in size than production DB Delta from Integrators

Reduce Amount of Storage Use Thin Provisioning –Recover unused storage which has been allocated –Allows projects to purchase storage as needed vs. all up front R/W Snapshots –Copy of actual data but much smaller –Can be used for development, integration and/or DR recovery –Guidelines for using snapshot storage systems for Oracle Databases

Reducing Maintenance Downtimes 4+1 RAID5 Group I/O Bound/Disk Change Copy Data off Recreate RAID Group Repopulate new storage Traditional Downtime Dynamic Optimization 4+1 RAID5 Group I/O Bound/Disk Change Add Storage Dynamically Optimize across new storage NO DOWNTIME Add Storage

Reducing DR Recovery: R/W Snapshots for near CDP 2:00PM 2:15PM 2:30PM 2:45PM 3:00PM 3:15PM 3:30PM 3:45PM SNAP Production DB Corruption at ~3:00PM? New 2:35PM Detection at 3:15PM Recover to 2:30 PM Snapshot Determine course of action Mount 2:45 + 3:00PM Snapshots for analysis

Reduce maintenance outages Dynamic Optimization/Tuning –Increase bandwidth, IOPS, size of storage dynamically w/o disrupting application –Move from one RAID level to another as needed Non-disruptive upgrades –F/W upgrades are non-disruptive to application if multi-attached

Reduce Cost: Non-disruptive Tiered Storage High Value Data Older Data Fibre Channel Storage Lower-Cost FATA Storage Hold current FC growth Move older data to lower Tier storage Expand only in lower Tier? ~2.5:1 cost advantage New, high-value data on Fibre-Channel disk

Reduce Cost Non-disruptive Tiered Storage –Tiered storage = Place data on appropriate storage type relative to datas importance and requirements –Move from expensive Fibre-Channel disk to lower-cost Fibre ATA drives as data ages. Movement is transparent to applications.

Oracle over NFS Subnet 111 FCC2 Core Rest of FNAL Network CSS SAN Storage FC and IMAP Services File services for: Directorate, CD, FESS, ESH, LSS, etc. IP FCP

Oracle over NFS –Best if CPUs are < 70% utilized –Snapshots, thin provisioning, dynamic growth –Virtualized across many disks –Non-disruptive tiering on a lun basis –Lower-cost connection option

Oracle over NFS Titan SiliconServer for Oracle 9i Database Performance with NAS: Optimizing Oracle on NFS Oracle Compatible NAS storage

Costs + Risks See handouts for quotes HDS –AMS-500: 4.38TB FC, 12TB SATA –NSC55+WMS100: 4.67TB FC, 12TB SATA (NSC55 has 100% uptime guarantee) EMC –CX500: 4.38TB FC, 2.5TB SATA

Costs + Risks Compellent: 4.67TB FC, 12TB FATA 3PAR: 4.67TB FC, 12TB FATA Risks: –Newer, privately held companies –Longevity? –Buyout?

Costs + Risks NFS: –Cost of one of the HDS options Risks: –Oracle + NFS unknown at lab –Network switch not redundant

Questions Send to