12 juni 2012 Fort Voordorp. What is Performance? Dependencies in Performance? What is expected? Jan Sterk en Jeroen Kleinnibbelink

Transcription

1 EMC CUSTOMER UPDATE 12 juni 2012 Fort Voordorp What is Performance? Dependencies in Performance? What is expected? Jan Sterk en Jeroen Kleinnibbelink 1

2 Performance Impact Hierarchy Request Application Code Database Layer File System Logical Volume Manager OS Kernel HBA drivers SAN Storage 2

3 Virtualisation impact Request Measure Measure Measure Measure Measure VM/LPAR ESX/VIOS VPLEX/SVC SAN Storage 3

4 What is Skew? 4

5 (Sublun) Skew Skew is the distribution of I/Os over a defined capacity. The concept can be associated to the 80/20 rule or the "Pareto law". In this sample, the Workload Skew is 88% / 12%, indicating that 82% of I/Os executed are in 12% of the used capacity. 5

6 General Skew Factors 6

7 Basic Tier Advisor 7

8 Scenario Skew 80/20 8

9 VMAX 9

10 Thin Terminology VMAX Multiple Thin Devices Storage Pool TDAT TDEV Enabling technologies: 1.TDEV,TDAT, and Pools 2.IVTOC Allocation units (768 KB = 12 tracks) extents or chunks 10

11 FAST VP VMAX 5875/5876 FAST VP tunes application I/O with sub-lun moves (minimal 6 extents) Improve performance with fine-grained data placement and VP wide striping Reduce drive contention Adapt to workload and policy changes Reduce TCO with precise FLASH SATA Capacity Balancing Push more data to economical SATA drives Maximize the benefits of FLASH Drives Only move the high performance data to FLASH Drives Optimize performance in Oracle, SQL, SAP and VMware environments Virtual LUN VP Mobility provides full user control for re-tiering 11

12 Initial Performance Analysis DMX-3 SAP Analysis August 2010 Frame DMX 128 GB Cache 32 Front-end ports 16 Disk channels GB10 K GB 15 K GB 15 K Enginuity 5773 Max throughput for batch 12

13 Post Migration Analysis Pre FAST-VP March 19, 2011 Initial Post Migration workload to the VMAX SATA drives are hot due to data migrating all of the SAP Test/Dev environment to the SATA drive pool Initial throughput is at 1 GB/s for Batch Initial IOPS is approximately 30,000 IOPS SATA drives are hot as all Test/Dev is put on the slow pool with NO FAST policy Initially the EFD drives are idle Frame VMAX-2 128GB Cache 32 Front end ports GB EFD Drives GB FC Drives 90 2TB SATA 30% Less Drives 13

14 Post Migration Analysis FAST VP Initiated March 23, 2011 Initial Post Migration workload with first FAST VP Policy applied to VMAX SATA Drives are hot due to their conservative policy for the EFD drives 14

15 Post Migration Analysis FAST VP Policy Adjusted April 7, 2011 Workload with adjusted FAST-VP Policy applied to the VMAX. SATA Drives are cooling off and the EFD drives are starting to get more workload applied. More importantly, the workload doubled! Virtual LUN Migrator is used to do on the fly migrations of hot tables. 2x Through put 15

16 VNX 16

17 FAST VP Principles Pools are the new paradigm for storage An association of drives to be shared among many workloads Pool LUNs can be Thin or Fully Provisioned Thin for space efficiency Thick for performance bias Pools are easy to set up, and distribute Any kind of disks, in any (back-end) location Thin and thick LUNs can share a pool Pool LUNs can be EXPANDED Pool LUNs can be SHRUNK (windows VDS) Pool LUNs can be COMPRESSED Pools can be made of multiple tiers SSD, SAS, NL-SAS 17

18 Pools and Allocation Thin LUNs allocate 3 GB at creation Over 1 GB is metadata; allocates more 1 GB slices as needed Allocates subunits within 1 GB slice as small as 8 KB: packs together sparse allocation Best for lower performance, high TCO Thick LUNs allocate 2 GB, reserve full space and a third GB at creation Over 1 GB is metadata; allocates in 1 GB slices as needed Smallest allocation is 1 GB, contiguous address Best for higher performance applications Note: metadata added as allocation increases Many disks in pool Thin LUN 100 GB Thick LUN 100 GB Allocate 3 GB Reserve 99 GB Allocate 2 GB 3 GB 99 GB RESERVED 2 GB 18

19 Pool Structure Private RAID Groups are created to host the virtual LUNs RAIDgroups will hold drives of one technology SSD, SAS, NL-SAS Different sizes and speeds can be combined, best if not Preferred disk count: RAID 5 multiples of 5, and RAID 6 and 1/0 multiples of 8 Zero and Verify when pool is created (or when slice is freed) LUNs carved from hidden RAID groups Depends on number of drives LUNs = 2 x (Pool Private RAID Group Disk Count) The 1 GB Slice Like a very thickly sliced metalun: data in that slice is serviced from a single RAID group. Imagine a metalun with a stripe multiplier of 4096 Tracking Granularity Thin LUNs: 8 KB unit of allocation Thick LUNs: 1GB unit of allocation and effective stripe element from each underlying RAID group 19

20 Pool Structure: RAID 5 example 10 disks 2 Raid Groups (4+1), private (not shown in GUI) RAIDgroup 1 RAIDgroup 2 SA S SA S SA S SA S SA S SA S SA S SA S SA S SA S Virtual LUN hosted on SPA From each RG: 10 LUNs private; Half to SPA, half to SPB LUN 12 SPB SPA Slices are taken evenly from all RAIDgroups in the pool 20

21 Pool Structure: Allocation LOGICAL 50 th GB 6 th 1GB 5 th 1GB 4 th 1GB 3 rd 1GB If any part of this 1GB LBA ordered slice is written to, the whole 1GB slice will be allocated Example, pool with single 50 GB LUN 2 nd 1GB 1 st 1GB LBA-0 LBA User accessed space: undetermined. Could be as little as 24 KB! User allocated space, 3 GB. Physical space consumed Total 6 GB PHYSICAL n th 1GB slice (n-1) th 1GB slice 4 th 1GB slice 3 rd 1GB slice 2 nd 1GB slice 1 st 1GB slice RG-1 FLU-10 RG-1 FLU-11 RG-2 FLU-20 RG-2 FLU-21 Legend LUN 1 User Data Metadata Virtual space reserved but not allocated Physical pool space unallocated yet 21

22 Pool Structure: Allocation Example: Pool with multiple LUNs last 1GB LOGICAL 6 th 1GB 5 th 1GB 4 th 1GB 3 rd 1GB LUN 1 LUN 2 LUN 3 2 nd 1GB 1 st 1GB Note that data is interleaved, but concentrated at the bottom of the RAIDgroups unlike old-style FLUs which would have the disks seeking large distances between each LUN start LBA. PHYSICAL n th 1GB slice (n-1) th 1GB slice 4 th 1GB slice 3 rd 1GB slice 2 nd 1GB slice 1 st 1GB slice RG-1 FLU-10 RG-1 FLU-11 RG-2 FLU-20 RG-2 FLU-21 Legend LUN 1 User Data LUN 2 User Data LUN 3 User Data Metadata Virtual space reserved but not allocated Physical pool space unallocated yet 22

23 FAST VP Mechanics: Policies Three policies control movement of slices (+ No Movement) These can be used to finesse your storage if needed But first we should learn a bit about how they work Tier Policy effect at slice allocation Tiering Policy effect at relocation Auto Tier Distributed across tiers randomly Highest Tier Available Place as much data as possible on highest tier Lowest Tier Available Place as much data as possible on lowest tier Auto Tier Moves data according to temperature Highest / Lowest Tier Available Moves data into preferred tier as possible; can move down No Movement No data movement after initial allocation New allocations will follow tier policy set at LUN creation 23

24 FAST VP Mechanics Auto allocation is for general purpose, ease-of-use SPA SPB Slices allocated in random distribution across all tiers CORE CPU CACHE CORE CORE CPU CACHE CORE Distribution of new slices is in proportion to capacity of each tier SAS SAS SAS SAS SAS SAS 24

25 FAST VP Mechanics Auto allocation is for general purpose, ease-of-use SPA SPB Slices allocated in random distribution across all tiers, weighted by free capacity CORE CPU CACHE CORE CORE CPU CACHE CORE Distribution of new slices is in proportion to capacity of each tier SAS SAS SAS SAS SAS SAS Tier relocation is initiated by temperature and space Relocation of Auto LUN slices cannot allocate all of an upper tier (some held in reserve) 25

26 FAST VP Mechanics Auto allocation is for general purpose, ease-of-use Slices allocated in random distribution across all tiers, weighted by free capacity Distribution of new slices is in proportion to capacity of each tier Tier relocation is initiated by temperature and space Relocation of Auto LUN slices cannot allocate all of an upper tier (some held in reserve) Improve determinism with Highest Tier policy Highest slices get priority over any Auto slice SPA CORE SAS SAS Auto slice will not move up if top close to full CPU CACHE SAS CORE CORE CPU CACHE SAS SPB CORE SAS SAS Highest priority Example: highest tier near full 26

27 Tiering Summary Watch your CPU (keep below 60%) when migrating to FAST Tiers FAST will use resources, and if EFD are in the tier, allow higher rates but that will require higher CPU usage Adjust watermarks down to make up for DRAM cache lost when FAST is installed AUTO TIER is best for Moderate-performance LUNs -- because new slices are busiest, and mission-critical apps should have more deterministic allocation TCO: use with SAS and NL-SAS Simplicity High-performance environments will take a little more planning Use Highest, Lowest, No Movement options for data that clearly requires prioritization Manage your migrations into a pool You may need more than one pool Multiple failure domains: don t put logs & data in same pool, etc. Pools with FAST Cache and those without (Fcache is a pool-based attribute) Separate unlike workloads (sequential from random etc.) 27

28 Conclusion Know your workload Size the array according the workload Balance across every available component Use Performance Health Check to confirm that your array setup is correct 28

29 SAVE THE DATE - EMC FORUM 11 september 2012 Spant! Bussum 29