Presentation is loading. Please wait.

Presentation is loading. Please wait.

SQL Storage for the Real World Brett Roux

Similar presentations

Presentation on theme: "SQL Storage for the Real World Brett Roux"— Presentation transcript:

1 SQL Storage for the Real World Brett Roux

2 Overview Requirements Storage concepts Storage options and priorities SAN / DAS HA / DR implications Decide on a storage strategy General guidance References and more information Q/A

3 Who Am I ? I am a DBA I am not a sales person What qualifies me? I don’t have all the answers! Personal opinion: ▫Almost any reliable storage solution could be used effectively for your SQL server ▫Almost any solution could be a bad purchase if it is implemented incorrectly or does not fit in with your overall storage strategy

4 Who Should Be Here? Aimed at DBA’s responsible for small to medium SQL deployments Will NOT be focusing on extreme capacity or performance solutions Going to avoid tuning, as Kevin covered this in the previous session Focus on overall strategy and options available – so you can narrow your own focus in the future

5 Why Change Your Storage? Is your storage just old? ▫Unable to extend warranty? Is your storage the bottleneck? ▫Have you got enough RAM? Do you just need more capacity? Are you standardising or looking to fit in with the rest of the company’s storage plan? Do you have a new application to support?

6 Know Your Data! Understanding your data and storage usage is the key to everything Is your environment OLTP, DSS or OLAP? Do you need bandwidth or IO’s? What read/write ratio? How much data is there? How much of that data is active? Daily trends and monitoring Use perfmon and DMV’s to investigate Are you really using your TempDB?

7 Storage Concepts What are IO’s? ▫8KB – 1024KB What is disk latency? ▫Measured in ms ▫20ms limit not always relevant What is bandwidth? ▫Measured in Gb Cache Random vs sequential ▫No way to truly measure ▫Very little chance of absolutes ▫Virtualisation tends to make all IO’s random Queue Depth Read/Write Ratio ▫Important with SSD’s

8 IO Size vs Throughput http://

9 RAID Types Striping – fast,no redundancy and lower reliability RAID Factor: 1 RAID 0: Mirroring - no performance gain RAID Factor: 2 RAID 1: Stripping with parity – read gain, but write overhead RAID Factor: 4 RAID 5: Dual parity – higher reliability, big write overhead* RAID Factor: 6 RAID 6: Striped Mirror–best write performance, lowest capacity RAID Factor: 2 RAID10: Striped RAID 5:Good overall compromise RAID Factor: 4 RAID 50:

10 Storage Options Known quantity Reasonably predictable Fantastic capacity Can suffice for most apps 10K drive = 100 – 120 IOPS 15K drive = 150 – 180 IOPS HDD Future of storage Cost can be prohibitive Fantastic IO performance Write falloff varies between models Write endurance issue for write intensive apps All SSD’s NOT created equal IO’s vary from 1K-1M depending on the model and manufacturer SSD

11 Storage Priorities SQL Storage PerformanceCapacity Cost Effective

12 Direct Attached Storage Easy to implement Known quantity and easier to troubleshoot No longer limited in terms of performance Small footprint Potentially the cheapest solution Cannot be used for clustering by default Several SAN benefits can be achieved when using storage virtualisation on DAS Can’t be affected by other systems

13 PCIe SSD New standard in terms of latency Completely changed perceptions of DAS Limited capacity High cost/capacity, but low relative to performance Fantastic for Denali TempDB Can affect CPU and RAM utilisation Multiple vendors with varying performance and quality

14 Storage Area Networks Getting more affordable Massive benefits in large deployments Powerful functionality ▫Snapshots ▫Online capacity expansion ▫Automated tiering ▫SAN replication ▫Thin provisioning Boot from SAN can increase availability Increased redundancy is possible Shared environment, so others can affect SQL

15 Framed vs Frameless SAN Framed SANFrameless SAN Has dedicated head unit Most common High initial cost Lower expansion cost Capacity expansion only Head units can become a bottleneck Expensive head unit upgrades Each shelf has controller Newer generation Lower entry cost Higher expansion cost Increased performance with expansion Limited capacity / scalability

16 Framed SAN

17 Frameless SAN

18 Rackmount SSD Generally independent units ▫Although some can act as a SAN Individual unit capacity is limited, and is usually bought up front Incredibly fast but often lacking additional functionality Alternatively very feature rich, but without track record Possibly higher latency than PCIe SSD, but allows for clustering or expansion when slots are limited

19 SAN Technologies SAN TypeISCSI10GbE ISCSIFibre Channel Bandwidth1Gb (usually x4)10Gb (Soon 40Gb)Up to 8Gb (Soon 16Gb) ImplementationEasy Average Ongoing SupportDepends on networking Usually Set and forget ProsYou already have the infrastructure Easy to implementVery stable Known quantityGood roadmapDe facto standard ConsLow bandwidthInitial cost Easily affected by comms teamLearning curve Other SAN options: FCoESuccessor to FC in converged data centre's, similar con’s to 10GbE InfinibandIncredibly fast, low latency but not common in MS environments ATA over Ethernet (AoE) Niche option, but extremely simple to use

20 Alternative SAN Technologies Integrate existing storage Add functionality to older units Storage Virtualisation Excels at integrating local storage Ideal for remote offices Test virtualisation overhead before committing Maintain your own hardware Virtual Storage Appliances / SAN software

21 SAN vs DAS FeatureDASSAN SnapshotsNone*Yes Thin ProvisioningNoneYes ReplicationNone*Yes CloningNone*Yes InstallationEasyLonger and more intricate MaintenanceLowDepends on how you use the SAN – can be high Online expansionNoneYes CostStarts very lowSignificantly higher Additional functionality NoneASAP’s, VSA’s etc. * Possible through 3 rd party software

22 High Availability / Disaster Recovery TechnologyDASSAN StandaloneYES ClusteringNOYES MirroringYES AlwaysOnYES BackupsYESSnapshots to backup server Log shippingYESSAN Replication NDMPNOSAN dump to tape

23 Storage Layers – DR Options SQLFilter DriverOperating system HypervisorDASDiskSANArray / Storage VirtualisationDisk

24 Possible SAN Features Block or file depending on vendor Do you really want to de-duplicate everything? Varying effectiveness with SQL Inline or Asynchronous Windows 8 may have this as standard De-duplication Very effective with raw SQL data Can head units handle additional load? What performance impact in terms of latency? Not useful on compressed partitions Compression

25 SSD Acceleration Add SSD to almost any SAN Instant performance boost Potentially more cost effective for large datasets SAN Acceleration (ASAP’s) Announced by more than one vendor Only accelerates reads in clustered environment Accelerates reads and writes in standalone configuration PCIe SSD acceleration of SAN LUNS Large unknowns as this is not available yet Would give the best of both worlds SAN controlled PCIe drives

26 SSD ASAP SSD LUN Acceleration SAN Controlled PCIe

27 Choosing A Vendor Give all the vendors the same set of requirements and let them propose solutions For example: IO requirement, usable capacity, connectivity, form factor, read/write ratio, lifespan and budget for the project Feedback to vendors and allow them to improve the solution iteratively – they won’t get it right first time Make sure you are getting the best pricing! ▫Some vendors first quote is 50% off retail... Build a relationship – storage is never once off! Make sure the solution is both balanced and redundant

28 General Guidance Separate Data, Logs and TempDB Separate DB’s if performance is justified Put logs on fastest disk possible ▫For write heavy DB’s or OLTP ▫Remember that log writes are sequential... OLAP and DSS generally like bandwidth and can handle more latency Make data files of equal size Pre-size data and log files Autogrow loves to work at the worst times

29 TempDB TempDB can be very IO heavy, but is easy to move Check for contention on TempDB ▫Consider adding data files if required ▫Start at 0.25 per core and move up ▫Additional log files are not beneficial Storage engine blog on allocation bottlenecks: ▫ Denali allows for TempDB on local storage in clustered instances

30 Storage Configuration Write cache is generally more useful to SQL ▫You may need to change the number of data files to get the best from your storage ▫Check for bottlenecks in the data path CHECK PARTITON ALIGNMENT !!! ▫ Check your MPIO is working Update storage firmware and use latest drivers

31 Storage Testing Benchmark to validate, baseline and test Test the redundancy – pull some cables and drives... Ensure you test more than your cache SQLIO ▫ IOMeter ▫ SQLIOSim ▫ AS SSD Benchmark ▫

32 Diagnostic Tools Logical Disk ▫Avg Disk Sec/Read (Write) - Latency ▫Disk Read Bytes/sec (Write) – Bandwidth ▫Disk Reads/sec (Writes) – IO’s ▫Avg Disk Queue Length  Deprecated but high numbers can indicate room for improvement Boot LUN doesn’t count unless page file is being hit or you are booting from SAN sys.dm_io_virtual_file_stats(DB_ID(), NULL) ▫Itzik Ben-Gan on IO stats: sys.dm_os_wait_stats ▫Look for PAGEIOLATCH_* sys.dm_db_index_usage_stats

33 References Storage Search ▫ MS Storage Best Practices: ▫ ▫ ▫ Glenn Berry’s blog: ▫ Intel Whitepaper: Simple, Reliable Performance for iSCSI Connectivity. ▫ My Blog: ▫ Brent Ozar: ▫ MCM Training video’s: ▫ Storage Mojo ▫ AnandTech ▫ Paul Randall’s blog: ▫ Joe Chang’s blog: ▫

34 Summary Requirements Storage concepts Storage options and priorities SAN / DAS HA / DR implications Decide on a storage strategy General guidance

35 Questions? Thank You For Attending!

Download ppt "SQL Storage for the Real World Brett Roux"

Similar presentations

Ads by Google