EMC CUSTOMER UPDATE · PDF file12 juni 2012 – Fort Voordorp ... HBA drivers ----- SAN...

1 © Copyright 2012 EMC Corporation. All rights reserved.

EMC CUSTOMER UPDATE 12 juni 2012 – Fort Voordorp

What is Performance? Dependencies in Performance? What is expected? Jan Sterk en Jeroen Kleinnibbelink


Performance Impact Hierarchy

Application Code -----------------------------------------------------------------------------------

Database Layer -------------------------------------------------------------------------------

File System ----------------------------------------------------------------------------

Logical Volume Manager -------------------------------------------------------------------------

OS Kernel ----------------------------------------------------------------------

HBA drivers -------------------------------------------------------------------

SAN ---------------------------------------------------------------

Storage

Request


Virtualisation impact

Request

VM/LPAR ------------------------------------------------------

ESX/VIOS ----------------------------------------------------

VPLEX/SVC ------------------------------------------------

SAN --------------------------------------------

Storage

Measure ------------------------------------------------------

Measure ---------------------------------------------------

Measure ------------------------------------------------

Measure --------------------------------------------

Measure


What is Skew?


(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.


General Skew Factors


Basic Tier Advisor


Scenario Skew 80/20


VMAX


Storage Pool Multiple Thin Devices

Allocation units (768 KB = 12 tracks)

“TDAT”

“extents” or “chunks”

“TDEV”

Thin Terminology VMAX

Enabling technologies: 1.TDEV,TDAT, and Pools 2.IVTOC


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 FLASHSATA 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


Initial Performance Analysis DMX-3 SAP Analysis – August 2010

Frame DMX 128 GB Cache 32 Front-end ports 16 Disk channels 248 146 GB10 K 263 300 GB 15 K 90 300GB 15 K Enginuity 5773

Max throughput for

batch


Post Migration Analysis – Pre FAST-VP March 19, 2011

Frame VMAX-2 128GB Cache 32 Front end ports 17 400GB EFD Drives 314 450GB FC Drives 90 2TB SATA

30% Less

Drives

• 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


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


Post Migration Analysis – FAST VP Policy Adjusted April 7, 2011

2x Through

put

• 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.


VNX


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


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

Thick LUN 100 GB

Thin LUN 100 GB

Reserve 99 GB Allocate 2 GB

Allocate 3 GB

99 GB RESERVED

3 GB

2 GB


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


Pool Structure: RAID 5 example

10 disks 2 Raid Groups (4+1), private (not shown in GUI)

From each RG: 10 LUNs – private; Half to SPA, half to SPB

Virtual LUN hosted on SPA

SPA

SPB LUN 12

SAS

SAS

SAS

SAS

SAS

RAIDgroup 1 RAIDgroup 2 SAS

SAS

SAS

SAS

SAS

Slices are taken evenly from all RAIDgroups in the pool


RG-1 FLU-10 RG-2 FLU-20

1st 1GB slice

2nd 1GB slice

3rd 1GB slice

4th 1GB slice

nth 1GB slice

(n-1)th 1GB slice

1st 1GB

2nd 1GB

4th 1GB

6th 1GB

3rd 1GB

5th 1GB

50th GB

User accessed space: undetermined. Could be as little as 24 KB! User allocated space, 3 GB. Physical space consumed Total 6 GB

LOG

ICAL

PHYS

ICAL

LBA-0 LBA-2097152

Example, pool with single 50 GB LUN

If any part of this 1GB LBA ordered slice is written to, the whole 1GB slice will be allocated

Virtual space – reserved but not allocated Physical pool space – unallocated yet

LUN 1 User Data

Metadata

Legend


Pool Structure: Allocation


Pool Structure: Allocation

1st 1GB

2nd 1GB

4th 1GB

6th 1GB

3rd 1GB

5th 1GB

last 1GB

Example: Pool with multiple LUNs

LUN 1 LUN 2

Virtual space – reserved but not allocated

Physical pool space – unallocated yet

LUN 1 User Data

Metadata

Legend

LUN 2 User Data

LOG

ICAL

PHYS

ICAL


1st 1GB slice

2nd 1GB slice

3rd 1GB slice

4th 1GB slice

nth 1GB slice

(n-1)th 1GB slice


LUN 3

LUN 3 User Data

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.


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

Auto Tier Moves data according to temperature

Highest Tier Available Place as much data as possible on

highest tier

Highest / Lowest Tier Available Moves data into preferred tier as

possible; can move down

Lowest Tier Available Place as much data as possible on

lowest tier

No Movement No data movement after initial allocation New allocations will follow tier policy set

at LUN creation


FAST VP Mechanics

• ‘Auto’ allocation is for general purpose, ease-of-use

– Slices allocated in random distribution across all tiers

– Distribution of new slices is in proportion to capacity of each tier

SPA SPB

CORE CORE CPU CACHE CORE CORE CPU

CACHE

SAS SAS SAS SAS SAS SAS


FAST VP Mechanics

SPA SPB


CACHE



– Slices allocated in random distribution across all tiers, weighted by free capacity


• Tier relocation is initiated by temperature and space

– Relocation of Auto LUN slices cannot allocate all of an upper tier (some held in reserve)


FAST VP Mechanics


– Slices allocated in random distribution across all tiers, weighted by free capacity


• 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 SPB


CACHE


‘Highest’ priority ‘Auto’ slice will not move up if top close to full

Example: highest tier near full


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.)


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


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

www.facebook.com/EMCned

EMC CUSTOMER UPDATE · PDF file12 juni 2012 – Fort Voordorp ... HBA drivers ----- SAN...

Documents

Transcript of EMC CUSTOMER UPDATE · PDF file12 juni 2012 – Fort Voordorp ... HBA drivers ----- SAN...