Module 1 VMAX Performance Workshop

Welcome to VMAX3 Performance Workshop.
Copyright ©2015 EMC Corporation. All Rights Reserved. Published in the USA. EMC believes the information in this
publication is accurate as of its publication date. The information is subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR
WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
The trademarks, logos, and service marks (collectively "Trademarks") appearing in this publication are the property of EMC
Corporation and other parties. Nothing contained in this publication should be construed as granting any license or right to
use any Trademark without the prior written permission of the party that owns the Trademark.
Acartus, Access Logix, AdvantEdge, AlphaStor, ApplicationXtender, ArchiveXtender, Atmos, Authentica, Authentic
Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Captiva, Catalog Solution, C-Clip,
Celerra, Celerra Replicator, Centera, CenterStage, CentraStar, ClaimPack, ClaimsEditor, CLARiiON, ClientPak, Codebook
Correlation Technology, Common Information Model, Configuration Intelligence, Configuresoft, Connectrix, CopyCross,
CopyPoint, Dantz, DatabaseXtender, Data Domain, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, Document
Sciences, Documentum, elnput, E-Lab, EmailXaminer, EmailXtender , EMC2, EMC, EMC Centera, EMC ControlCenter, EMC
LifeLine, EMC OnCourse, EMC Proven, EMC Snap, EMC SourceOne, EMC Storage Administrator, Enginuity, eRoom, Event
Explorer, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File Virtualization, Graphic Visualization,
Greenplum, HighRoad, HomeBase, InfoMover, Infoscape, Infra, InputAccel, InputAccel Express, Invista, Ionix, ISIS, Max
Retriever, MediaStor, MirrorView, Navisphere, NetWorker, nLayers, OnAlert, OpenScale, PixTools, Powerlink, PowerPath,
PowerSnap, QuickScan, Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, the RSA logo, SafeLine, SAN
Advisor, SAN Copy, SAN Manager, Smarts, SnapImage, SnapSure, SnapView, SRDF, StorageScope, SupportMate,
SymmAPI, SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix VMAX, TimeFinder, UltraFlex, UltraPoint, UltraScale,
Unisphere, VMAX, Vblock, Viewlets, Virtual Matrix, Virtual Matrix Architecture, Virtual Provisioning, VisualSAN, VisualSRM,
Voyence, VPLEX, VSAM-Assist, WebXtender, xPression, xPresso, YottaYotta,
Revision Date: January 2016
Revision Number: MR-1XP-VMAX3PW.5977.1
Copyright 2015 EMC Corporation. All rights reserved. VMAX3 Performance Workshop 1
This Specialist level course introduces participants to the methodology for analyzing the
performance of the VMAX3 family of storage arrays.
The agenda on this and the following slide lists the modules, lessons, and labs covered in the
VMAX3 Performance workshop. This is the recommended agenda for day one.
This is the recommended agenda for day two.
This module focuses on VMAX3 architecture and configuration best practices for optimal
performance.
Copyright 2015 EMC Corporation. All rights reserved. VMAX3 Architecture and Configuration Best Practices 5
This lesson covers the architecture of VMAX3.
The high level architecture of the VMAX has not changed with the VMAX3 but how it is
implemented has. Hosts still connect through the frontend, physical disks are connected through
the backend, and I/Os go through cache. The key to achieving optimum system performance is
maintaining a balanced workload across system components. The challenge is how to achieve this
when the array typically handles many different workloads that are constantly changing.
On the VMAX3, the system is 100% virtual provisioned and the pools are preconfigured from the
factory following proven best practices for size, protection, and layout. The value of virtual
provisioning is well known and, when configured following best practices, will achieve the best
possible workload distribution. FAST (Fully Automated Storage Tiering) is always on to ensure that
as workloads change, data is placed in the correct pools in order to get the best overall
performance and maintain compliance with Service Level Objectives.
Global memory sizes have increased on the VMAX3; the intelligent cache management algorithms
ensure that more I/Os are serviced from cache, thus providing the best possible response time.
Workloads tend to come in bursts. While on average, the system may show low utilization, when
bursts of activity come in, which is typical of many environments, the system can become
stressed. The VMAX3 addresses this by pooling CPU resources. Rather than dedicating CPU cores
to ports, CPU cores are pooled and work together to handle the workload across ports.
All VMAX3 systems use the Intel Ivy Bridge processors with speeds of 2.1, 2.6, and 2.7 GHz, and
6, 8, or 12 cores. Cache also scales up the family with 512GB or 1024GB for 100K, and 512GB,
1024GB, or 2048GB per director on the 200K and 400K. Cache is mirrored so the amount of
available cache is half. However with an 8 Engine 400K, there could be 8TB of usable cache.
Within an engine, both directors must have the same amount of cache and different engines could
have a different cache configuration; however, the difference between engines can only be one
size different. For example, you can mix 512 and 1024, or 1024 and 2048, but not 512 and 2048
within the same system.
All three members of the VMAX3 family support the same Gen3 PCIe I/O modules, 6Gbps SAS
backend, and InfiniBand based Virtual Matrix.
With the VMAX3, there is a single instance of backend emulation code and one instance of
frontend emulation code for emulation time on the system. The VMAX3 also has two additional
emulation codes: Infrastructure Manager (IM) and Enginuity Data Services (EDS).
The IM is the code that performs all of the environmental monitoring and services environmental
commands, syscalls, and component monitoring. IM will always be the “A” emulation.
EDS emulation consolidates other functionality that was previously performed primarily by the
backend code. This new emulation makes it easier to change functionality and add features
without impacting core code. EDS provides data services not directly in the data path, such as
FAST processing, write misses, destaging data, and allocation of cache space. EDS is always
emulation “B”.
Traditional backend services are now split between the EDS emulation and the new backend Data
Services (DS) emulation. DS is always emulation “C”.
Emulations D through H are used for frontend emulations as well as SRDF.
Ports on I/O modules are mapped to frontend emulation code. Ports on one or more Fibre
Channel I/O modules can be mapped to the FA emulation.
CPU cores are also mapped to the emulation code in the IMPL.bin file and provide a dynamic and
flexible way to allocate CPU resources.
With the VMAX3, a pool of CPU resources services the multithreaded frontend and backend
emulation code. This allows the system to better respond to bursts of I/O activity on a subset of
the ports. This ensures maximum utilization of all system resources.
For example, a single engine VMAX3 has 2 directors. Each director has 2 CPUs. Each CPU has 6
physical cores. So there are (2x2x6) 24 physical cores. With hyperthreading, this provides 48
(2x24) logical cores.
The allocation of CPU cores is also dynamic and, through a bin file parameter, the assignment of
cores can be biased to frontend or backend. The default is to have a balanced core assignment. In
general using the backend bias will be useful if you have a lot of RAID 6 writes and few read hits.
Otherwise the balanced layout is the best option.
With the VMAX3, ports are dynamically assigned to frontend emulations and there is a pool of CPU
resources that services the multithreaded emulation code. This allows the system to better
respond to bursts of I/O activity on a subset of the ports, which is typical of most host
environments and ensures maximum utilization of all system resources.
The VMAX3 InfiniBand provides high speed messaging between directors and is used to
implement Global Memory. It is through the Virtual Matrix that memory on one director can be
accessed by other directors forming a single global memory address space that consists of
metadata and cache slots for staging reads and writes.
Through this implementation of global memory, it is possible to have a host perform a read
request on a frontend port attached to one director in one engine, have the data fetched from
disk on another director in a different engine, and have the data stored in a cache slot on a third
director in a third engine.
On the VMAX3, single engine systems use the CMI interface and do not require a Virtual Matrix.
The VMAX3 introduces 6Gb SAS (Serial Attached SCSI). This is implemented with a network-like
star topology and provides full duplex point-to-point connections between the director and each
disk drive. While the topology is different, SAS supports the standard SCSI command set as well
as the dual initiator/shadow partner configuration used in previous generations of Symmetrix.
Part of SAS initialization is discovery, where routing tables are created to define paths to each
disk.
Within the DAE, the LCC includes SAS expanders that provide a point-to-point connection
between any drive and any port on the LCC. This provides both redundancy and scale.
The size of a track on a VMAX3 is 128KB. This is the unit of allocation of Cache.
Local Raid
• Improves BE performance
– Faster rebuild - stays local on one director (no I/Os across matrix )
• No impact to availability
– Supports dual-initiator failover/failback model as in VMAX
This lesson covered the architecture of the VMAX3.
This lesson covers the best practices for designing VMAX3 arrays for optimal performance.
Numerous choices are available when designing a VMAX3. The choices give flexibility in design to
meet unique requirements. But not all choices would be best practices. In this module we will
present the best practices among the available choices.
Solutions Architects gather information about customer requirements such as capacity,

applications, and performance expectations, among other things. They can then use existing
performance data (if available) or model workload based on the gathered information as input to
the VMAX3 Sizer. Based on the requirements, the tool provides the optimal configuration that
follows all the best practices.
The key to designing a VMAX3 array for highest performance is to balance resources and
components through the entire system.
FLASH drives and RAID groups should be balanced across the engines. Configuring a minimum of
1 RAID group per director and 2 RAID groups per engine is the recommended best practice.
FLASH drives per engine should be added in multiples of 8 for RAID 5 (3+1) and multiples of 16
for RAID 5 (7+1).
The maximum number of IOPS at good response times that can be expected from different disk
drive types is shown in this slide. Of course the drives themselves are capable of achieving much
higher IOPS but at the expense of higher response times.
It is best to configure all 2.5” drives for best performance. 2.5” DAE supports twice the number of
drives compared to the 3.5” DAE – 120 to 60. As a result the 2.5” DAE can deliver at least twice
as many IOPS as the 3.5” DAE in same footprint.
The recommended RAID protection for two- and three-tier configurations is shown in the slide. As
we are aware, RAID 6 has a higher write overhead in exchange for the higher availability it offers.
Data access skew indicates the percentage of total capacity that supports the majority of the
workload. A skew of 85/15 is typical of most workloads. Understanding data access skew helps in
designing tiered storage solutions.
Traditional tiering in VMAX used a drive mix of 3%(EFD)/27%(10K FC)/70%(7200 SATA). At
different skew levels, the workload on the SATA drive increases. This, compounded with the write
overhead for RAID 6, poses a challenge.
For VMAX3, the two-tier configuration is the new default configuration with 10% FLASH and 90%
10K drives. At the typical 85/15 workload skew, the FLASH drives will support 71% of the IOPS
and the 10K drives will support the remaining 29% of the IOPS.
For low skew or very high write workloads, the three-tier configuration is recommended.
The two-tier configuration is the predominant solution being configured and delivered for the
VMAX3 arrays. It eliminates the RAID 1 tier and provides a vastly superior and cost effective
performance compared to the traditional three-tier configuration.
The three-tier configuration is recommended for workloads with low skew or high write rates.
With the new drive mix, even at a skew as low as 75/25 only 10% of the IOPS have to be
supported by 10K R6 devices.
VMAX3 and its components have performance limits. It is important to configure enough system
resources so that no component hits a 100% utilization. As the utilization level increases, the
response time increases dramatically.
For performance critical configurations, utilization levels should be maintained at 50% or less.
Higher utilization can be tolerated if only IOPS or total throughput matters and response time is
not critical.
The best practice sizing guidelines are shown in this slide. It is always best to do on-going
performance monitoring with Unisphere for VMAX to ensure that none of the components are
consistently over utilized.
It is recommended to start with Optimized SLO if you are not sure about the workload. This
ensures that the 10K will be used first, the EFD next, and as a last resort the 7.2K drives. Single
SRP will always be configured. Multiple SRPs are supported as exceptions.
In a VMAX3 array all cores in the emulation can service one port. This greatly reduces contention
when ports are shared. Bursts of I/O are handled much better. For OLTP workloads, you should
start with at least two ports across two directors. For DSS workloads, providing four ports will
give maximum port level aggregate bandwidth.
XtremIO is attached to VMAX3 using the DX emulation. The two available configuration options for
DX emulation assign a different number of backend cores to the DX. It is a best practice to use all
internal or all external EFDs. For arrays with only external EFDs, DX heavy emulation should be
selected. The configuration is set/changed in the BIN file. Also note that XtremIO is supported in
the same SRP as internal disks.
Connecting CloudArray to VMAX3 requires the use of an external SRP. It is recommended to use
Host I/O limits.
Maintaining balance as the system grows is key to continue achieving maximum performance. It
is important to maintain the drive mix percentages in the tiers. When adding drives, add them to
all tiers evenly to maintain balance.
This lesson covered configuration best practices for designing VMAX3 arrays for optimal
performance.
This module covered VMAX3 architecture and configuration best practices for optimal
performance.

Module 1 VMAX Performance Workshop

Uploaded by

Copyright:

Available Formats

Module 1 VMAX Performance Workshop

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Module 1 VMAX Performance Workshop

Uploaded by

Copyright:

Available Formats

Welcome to VMAX3 Performance Workshop.

Revision Date: January 2016

Revision Number: MR-1XP-VMAX3PW.5977.1

Emulations D through H are used for frontend emulations as well as SRDF.

Solutions Architects gather information about customer requirements such as capacity,

You might also like