h6731 Storage Tiering Sap Vmax WP

Storage Tiering for SAP and
EMC Symmetrix VMAX with Enginuity 5874

Applied Technology

Abstract
As the need for more information continues to explode, businesses are forced to deal with an ever-increasing
demand for storage and at the same time, a requirement to keep cost to a minimum. One way to satisfy both
needs is to effectively use low-cost SATA drives, high-performance Fibre Channel drives, and Enterprise Flash
Drives to provide high performance for mission-critical applications and cost-effective storage for non-critical
applications. Matching business needs with various drive types is known as tiering, and this paper describes
how to implement Storage Tiering using EMC
Symmetrix
VMAX Enhanced Virtual LUN Technology and

Fully Automated Storage Tiering, or FAST.

May 2010

Copyright 2009, 2010 EMC Corporation. All rights reserved.
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.
For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com
All other trademarks used herein are the property of their respective owners.
Part Number h6731.1
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 2

Table of Contents

Executive summary ............................................................................................ 4
Introduction......................................................................................................... 5
Audience ...................................................................................................................................... 6
Evolution of Storage Tiering.............................................................................. 6
SAP ...................................................................................................................... 7
Landscapes, systems, and instances.......................................................................................... 7
Products and features overview........................................................................ 8
Symmetrix VMAX......................................................................................................................... 8
Symmetrix Auto-provisioning Groups .......................................................................................... 9
Symmetrix Management Console.............................................................................................. 11
Symmetrix Enterprise Flash Drives ........................................................................................... 11
Symmetrix Enhanced Virtual LUN Technology.......................................................................... 12
Symmetrix Fully Automated Storage Tiering (FAST) ................................................................ 14
How FAST is configured......................................................................................................... 14
Device movement................................................................................................................... 15
Skewed LUN access .............................................................................................................. 15
Working with SAP, Oracle databases, and Enhanced Virtual LUN
Technology........................................................................................................ 16
Manual Storage Tiering mechanics ........................................................................................... 16
Manual Storage Tiering example............................................................................................... 16
Test methodology and configuration...................................................................................... 16
Monitoring database and storage performance ..................................................................... 18
Using Virtual LUN to up-tier DB2............................................................................................ 19
Summary of manual LUN migration benefits ......................................................................... 22
Working with SAP, Oracle databases, and Fully Automated Storage Tiering
(FAST) ................................................................................................................ 23
FAST test environment .............................................................................................................. 23
Initial FAST configuration........................................................................................................... 23
FAST test setup for DB3 (SAP ERP) management................................................................... 29
Monitoring and executing FAST recommendations for DB3 ..................................................... 31
Conclusion ........................................................................................................ 33


Executive summary
The EMC
Symmetrix
VMAX is the newest addition to the Symmetrix product family. Built on the
strategy of simple, intelligent, modular storage, it incorporates a new scalable Virtual Matrix
interconnect that connects all shared resources across all VMAX Engines, allowing the storage array to
grow seamlessly and cost-effectively from an entry-level configuration into the worlds largest storage
system. The Symmetrix VMAX provides improved performance and scalability for demanding enterprise
storage environments while maintaining support for EMCs broad portfolio of platform software offerings.
EMC Symmetrix VMAX delivers enhanced capability and flexibility for deploying SAP environments
throughout the entire range of industry-specific and business applications including ERP, CRM, and SRM.
This includes the mission-critical production systems, as well as the quality assurance and development
systems within the SAP Landscape. In order to support this wide range of performance and reliability at
minimum cost, Symmetrix VMAX arrays support multiple drive technologies including Enterprise Flash
Drives (EFD), Fibre Channel (FC) drives, both 10k rpm and 15k rpm, and 7,200 rpm SATA drives. In
addition, various RAID protection mechanisms are allowed that affect the performance, availability, and
economic impact of a given SAP system deployed on a Symmetrix VMAX array.
Since customers are under increasing pressure to improve performance as well as the return on investment
(ROI) for storage technologies, ensuring that data is placed on the most appropriate Storage Type
1
is a key
requirement. Invariably, database systems, due to the nature of the applications that they service, tend to
direct the most significant workloads to a relatively small subset of the data stored within the database and
the rest of the database is less frequently accessed. The imbalance of I/O load across the database results in
much higher utilization of the LUNs holding the active objects and therefore it is referred to as LUN access
skewing. Optimizing the placement of these LUNs to the Storage Type that best answers their needs, will
help increase performance, reduce the overall number of drives, and improve the total cost of ownership
(TCO) and ROI for storage deployments.
As companies increase deployment of multiple drive and protection types in their high-end storage arrays,
storage, SAP Basis and SAP database administrators are challenged to select the correct storage
configuration for each application. Often, a single Storage Type is selected for all the data in a given SAP
environment, effectively placing both active and idle data portions on fast FC drives. This approach is
expensive and inefficient, because infrequently accessed data will reside unnecessarily on high-
performance drives.
Alternatively, making use of high-density low-cost SATA drives for the less active data, FC drives for the
medium active data, and EFDs for the very active data enables efficient use of storage resources, and
reduces overall cost and the number of drives necessary. This, in turn, also helps to reduce energy
requirements and floor space, allowing the business to grow more rapidly.
To achieve this tiered storage approach with SAP environments, administrators can use Symmetrix
Enhanced Virtual LUN Technology to move logical devices between drive types and RAID protections
seamlessly inside the storage array. Symmetrix Virtual LUN technology does not require application
downtime. It preserves the device IDs, which means there is no need to change file system mount points,
volume manager settings, database file locations, or scripts. It also maintains any TimeFinder
or SRDF

business continuity operations even as the data migration takes place.
This manual and often time-consuming approach to Storage Tiering can be automated using Fully
Automated Storage Tiering or FAST. FAST uses policies to manage sets of logical devices and available
Storage Types. Based on the policy guidance and the actual workload profile over time, the FAST
Controller will recommend and optionally execute automatically the movement of the managed devices
between the Storage Types.
This white paper describes a tiered storage architecture approach for SAP environments, and the way in
which devices can be moved nondisruptively, using either Virtual LUN or FAST technologies, in order to
put the right data on the right storage at the right time.

1
Storage Type refers to a combination of drive type and RAID protection, as explained in the Evolution of
Storage Tiering section.

Introduction
This white paper demonstrates best practices for using Symmetrix VMAX Enhanced Virtual LUN and
Fully Automated Storage Tiering (FAST) technologies with SAP environments. Both Virtual LUN and
FAST are complementary technologies where in Virtual LUN. device movement is initiated by the user and
then executed seamlessly in the storage array, and in FAST a device movement plan is automatically
recommended (and optionally executed) by the FAST Controller, also seamlessly in the storage array.
Virtual LUN and FAST operate at a granularity of a Symmetrix logical device, so it is always a full device
(or metadevice) that is migrated between Storage Types.
The Command Line Interface (CLI) or the Symmetrix Management Console (SMC) graphic user interface
(GUI) can be used to manage both Virtual LUN and FAST operations and it is the users responsibility to
decide which management tool they prefer. However, the focus of the paper when discussing Virtual LUN
will be on CLI, and when discussing FAST the focus will be on SMC. It is assumed that manual initiated
data migrations are often called from scripts and automation tools are more easily managed using a GUI.
Other management tools that can help with Virtual LUN and FAST management and monitoring are
Ionix ControlCenter
Storage Scope, Symmetrix Performance Analyzer (SPA), and others. Their use
is not covered in this paper.
As described earlier, almost any application generates LUN access skewing. In other words, some portions
of the data are heavily accessed, some are accessed to a lesser degree, and often some portions are hardly
accessed at all and maintained only for legacy or regulatory reasons, or for lack of a better archiving and
Information Lifecycle Management strategy. Because SAP Basis and database administrators (DBA) tend
to plan for the worst-case peak workloads they commonly place almost all data into a single Storage Type
based on fast FC drives (10k or 15k rpm). While placing the entire SAP environment into a single Storage
Type makes the storage management simpler, LUN access skewing is not taken into account. This
approach is inefficient when using a high-end storage array such as Symmetrix.
EMC refines these recommendations based on the availability of multiple Storage Types and an intelligent
Storage Tiering strategy to place each SAP system, instance, or datafile (or group of systems, instances, or
datafiles if they are related business groups, and share criticality and performance requirements) into their
own set of filesystems, or other volume managers disk groups, and such skewing can be effectively used to
place the right data on the right Storage Type. This approach also helps when using local and remote
storage replication techniques and with general performance monitoring since it provides better granularity.
As described earlier, this efficient data placement reduces overall cost, energy consumption, and storage
footprint while at the same time increases database performance.
LUN access skewing can therefore be created between SAP systems or instances by placing them on
different logical devices, but also inside a database instance by using the SAP datafiles. For example, by
looking at SAP performance transactions such as ST04, or the individual database statistical information, to
identify what datafiles are heavily utilized, which system files or indexes dont fit in memory, and how
their I/O access directly affects query response times. Alternatively one can recognize datafiles that are
hardly utilized and by placing them on SATA devices, achieve cost reduction goals.
In large databases, SAP DBAs can provide optimized access to data by the use of database partitioning
available with certain databases such as Oracle. The database optimizer will recommend query access only
to those partitions with the requested data. In such databases, active partitions can reside on fast Storage
Types (FC and EFD), improving performance, while inactive partitions can reside on SATA drives,
reducing cost.
These considerations align with EMC best practices for using storage features like local and remote
replication. In that case EMC recommends for each database to separate data from log files (so when
TimeFinder is used to offload backups, during restore the logs are not overwritten), isolate temp files when
remote replications like SRDF are used (no need to replicate temp files since they are not part of database
recovery), and isolate Archive logs (which can be in a slower Storage Type).
To summarize, if no skewing exists and all storage devices are always accessed uniformly, FAST or Virtual
LUN technologies will be less effective. However, LUN access skewing is very common, either inside a

single SAP system, instance, or datafile, or between SAP systems. FAST or Virtual LUN technologies can
greatly increase storage performance and efficiency in these cases.
To keep things simple, this paper focuses on skewing between databases. The examples demonstrate three
distinct Oracle 11gR2 databases, running an OLTP type workload (~70/30 random read/write ratio) where
database 1 (DB1) workload is very low and in fact a target for storage cost reduction, database 2 (DB2) has
a medium workload and importance, and database 3 (DB3) is a very visible mission-critical database and
executes the highest workload. The goal of the examples is to show how to identify that the workloads are
on the wrong Storage Types and use each of the technologies to migrate them to their right Storage Types,
while achieving the business goals of cost reduction or improved performance.
Audience
This white paper is intended for SAP Basis (Business Application Software Integration Solution)
personnel, SAP database administrators, storage administrators and architects, customers, and EMC field
personnel who want to understand the implementation of Storage Tiering in a Symmetrix VMAX
environment.
Evolution of Storage Tiering
From a business perspective, Storage Tiering generally means that policies coupled with storage
resources having distinct performance, availability, and other characteristics are used to meet the service
level objective (SLO) for a given application. (By SLO we mean a targeted I/O service goal, that is,
performance for an application.) This remains the case with Fully Automated Storage Tiering (FAST).
For administrators, the definition of Storage Tiering is evolving. Initially, different storage platforms met
different SLOs. For example:
Gold Tier Symmetrix
; Silver Tier CLARiiON
; Bronze Tier Tape

More recently, Storage Tiering meant that multiple SLOs are achievable in the same array:
Gold Tier 15k, FC RAID 1; Silver Tier 10k, FC RAID 5; Bronze Tier 7.2k, SATA, RAID 6
FAST changes the categories further. Because multiple Storage Types can support the same application,
tier is not used to describe a category of storage in the context of FAST. Rather, EMC is using new
terms:
Storage Group logical grouping of volumes (often by application) for common management
Storage Class combination of Storage Types and FAST Policies to meet service level objectives
for Storage Groups
FAST Policies - policies that manage data placement and movement across Storage Types to
achieve service levels for one or more Storage Groups
Storage Type a shared storage resource with common technologies, namely drive type and
RAID scheme
For example, users might establish a Gold Storage Class as follows:
Service level objective Storage Class FAST Policy Storage Type
Read/write response time
objective
Gold 10%
40%
50%
15k rpm RAID 1
10k rpm RAID 5
7.2k SATA RAID 6

Figure 1 provides a quick summary of the relationship between Storage Types, FAST Policies, and Storage
Groups.

Figure 1. FAST relationships
In the rest of this paper, Storage Type at times will be referred to as Symmetrix Tier, in order to map
clearly to specific commands in tools such as SMC. "FAST Policies" and "Storage Groups" will remain the
same throughout this paper.
SAP
SAP (Systems, Applications, and Protocols) is the global market leader in collaborative, inter-enterprise
business solutions. SAPs latest release of software, SAP ERP Central Component (ECC), is built on the
SAP NetWeaver platform. SAP Business Suite software provides a variety of industry-specific applications
and five core applications of SAP Business Suite including Customer Relationship Management (CRM),
Enterprise Resource Planning (ERP), Product Lifecycle Management (PLM), Supply Chain Management
(SCM), and Supplier Relationship Management (SRM).
SAP NetWeaver is the technology platform and includes a comprehensive set of components and tools.
The components include the common runtime application server sometimes referred to as SAP WebAS,
Business Warehouse (BW), Business Process Management (BPM), Process Integration (PI), Master Data
Management (MDM), Portal, and Information Lifecycle Management (ILM). The tools include Adaptive
Computing Controller, SAP NetWeaver Developer Studio, and SAP Solution Manager. SAP NetWeaver is
the foundation and requires the business solutions.
SAP is made up of three functionally distinct layers namely: the user interface, business logic, and
database. The user interface, which is otherwise known as the presentation layer, displays the interface for
users' communication with the SAP system. It is often referred to as the SAP GUI. As a matter of fact, it is
a program called sapgui.exe. The application server, or application layer, is where the business logic and
data manipulation take place. Data processing, SAP administration tasks, and client request/feedback
management are handled within the business layer. The database layer is synonymous to the database
server and it typically acts as a data repository for tables and other database objects and structures, but it is
neutral and independent from the application servers or business logic.
Landscapes, systems, and instances
An SAP instance is defined during the installation of the SAP system. The term instance is often used
synonymously with server or application server in the SAP system. This depends on the selected
installation environment. You can install multiple instances on one application server.
An SAP instance defines a group of resources such as memory, work processes, and so on, usually in
support of a single application server or database server within a client/server environment. Application
servers share the same memory areas and are controlled by the same dispatcher process.

An SAP system can consist of one or more instances, such as an SAP system with a single instance with
only one central server or a client/server system with two or more separate instances.
They system landscape basically is the setup or arrangement of your SAP servers. Ideally, in an SAP
environment, a three-system landscape exists. A three-system landscape consists of the Development
Server (DEV), Quality Assurance Server (QAS), and the Production Server (PRD). This kind of setup is
not primarily designed to serve as server clusters in case of system failure, but the objective is to enhance
"configuration pipeline management."
The SAP systems can be installed as single stack or dual stack. A single stack runs only SAPs proprietary
code Advanced Business Application Programming (ABAP) and a dual stack runs both ABAP and JAVA
code. A single stack includes the central instance, and the database instance at a minimum. The dual stack
included the central instance, central services instance, database instance, and dialog instance(s). The
minimum distribution is a central system (everything installed on one server) or SAP can be installed in a
distributed system (separate servers for the database instance, central instance, and central services instance
and dialog instances in a dual stack).

Figure 2. SAP centralized single stack system
Products and features overview
Symmetrix VMAX
Symmetrix VMAX, the newest member of the Symmetrix family, is a revolutionary new storage system
purpose-built to meet all data center requirements as seen in Figure 3. Based on the Virtual Matrix
Architecture and new Enginuity capabilities, Symmetrix VMAX scales performance and capacity to
unprecedented levels, delivers nondisruptive operations, and greatly simplifies and automates the
management and protection of information.


1 8 redundant VMAX Engines
Up to 2.1 PB usable capacity
Up to 128 FC FE ports
Up to 64 FICON FE ports
Up to 64 GigE / iSCSI FE ports
Up to 1 TB global memory (512 GB usable)
48 2,400 drives
Enterprise Flash Drives 200/400 GB
FC drives 146/300/450 GB 15k rpm
FC drives 300/450/600 GB 10k rpm
SATA drives 1 TB 7.2k rpm

Figure 3. The Symmetrix VMAX platform

The Symmetrix VMAX design is based on individual engines with redundant CPU, memory, and
connectivity on two directors for fault tolerance. VMAX Engines connect to and scale out through the
Virtual Matrix Architecture, which allows resources to be shared within and across VMAX Engines. To
meet growth requirements, additional VMAX Engines can be added nondisruptively for efficient and
dynamic scaling of capacity and performance that is available to any application on demand.
Symmetrix Auto-provisioning Groups
Enginuity version 5874 and later provide storage and system administrators with a simplified model for
storage provisioning referred to as Auto-provisioning Groups. Auto-provisioning Groups are implemented
using the symaccess CLI command with Solutions Enabler 7.0 and later or by using the Symmetrix
Management Console (SMC).
The fundamental concept of Auto-provisioning Groups is the logical grouping of related objects and the
creation of a view that associates the related groups together. The following logical groupings are used:
Initiator groups. An initiator group is a logical grouping of up to 32 Fibre Channel initiators
(HBA ports) identified by World Wide Names or WWNs or eight iSCSI names or a combination
of both. An initiator group may also contain the name of another initiator group to allow the
groups to be cascaded to a depth of one.
Port groups. A port group is a logical grouping of Fibre Channel and/or iSCSI Symmetrix front-
end director ports.
Storage groups. A storage group is a logical grouping of up to 4,096 Symmetrix devices.
Masking views. A masking view defines an association between one initiator group, one port
group, and one storage group. When a masking view is created, the devices in the storage group
are mapped to the ports in the port group and masked to the initiators in the initiator group.
Depending on the server and application requirements, each server or group of servers may have
one or more masking views that associate a set of Symmetrix devices to an application, server, or
cluster of servers.
With Auto-provisioning Groups, related initiators (HBAs) are grouped into an initiator group, related front-
end ports are grouped into a port group, and related devices are grouped into a storage group. A masking
view associates the groups together. At the time the masking view is created, all the required mapping and

masking are performed automatically in a single operation. This approach dramatically reduces complexity
and simplifies storage allocation.
SAP systems can highly benefit from Auto-provisioning Groups as the feature makes storage device
provisioning, monitoring, and management an easy task. For example, for the SAP system, storage devices
are simply added to the storage group and automatically are masked to all the servers (initiator groups) in
the SAP environment.
Figure 4 shows an example of using Auto-provisioning Groups to mask a centralized SAP system including
the database instance devices. A storage group is created with the database devices and a port group with
the Symmetrix ports. A single initiator group can be created for all hosts HBAs (or each host can have its
own initiator group and they will be cascaded for ease of management and scalability). The Auto-
provisioning Groups masking view simply includes the storage group, port group, and initiator group. If
any hosts or HBAs are added or removed from the SAP environment they will simply be added or removed
from the initiator group. In a similar way, devices or Symmetrix ports can be added or removed from their
groups and the view will automate the device provisioning changes to the SAP system.

Port: 10E:1
Port: 07E:1
SAP system devices
Storage
SAN
SAP1_HBAs SAP2_HBAs
Figure 4. SAP and Auto-provisioning Groups
The following steps demonstrate the use of Auto-provisioning Groups, based on the example in Figure 4.

1. Create a storage group for SAP devices
symaccess -name SAP_devs -type storage devs 790:7AF create
2. Create a port group with storage ports 7E:1 and 10E:1
symaccess -name SAP_ports -type port dirport 7E:1,10E:1 create
3. Create an initiator group for each servers HBAs
symaccess -name SAP1_hbas -type initiator -file ./SAP1_hbas.txt create
The file SAP1_hbas.txt contains: WWN:10000000c975c2e4
WWN:10000000c975c336
symaccess -name SAP2_hbas -type initiator -file ./SAP2_hbas.txt create
The file SAP2_hbas.txt contains: WWN:10000000c975c31a
WWN:10000000c975c3ab
4. Cascade the servers initiator groups into a single one for the entire system
symaccess -name SAP_hbas -type initiator create
symaccess -name SAP_hbas -type initiator add ig SAP1_hbas
symaccess -name SAP_hbas -type initiator add ig SAP2_hbas
5. Create the view for the entire SAP system storage provisioning
symaccess create view -name SAP_view
-storgrp SAP_devs -portgrp SAP_ports -initgrp SAP_hbas
Symmetrix Management Console
Many large enterprise data centers have stringent change control processes that ensure reliable execution of
any modification to their IT infrastructure. Often changes are implemented using scripts that are fully
documented, have been thoroughly reviewed, and can be consistently executed by all storage
administrators. An alternative to using scripts is to use the Symmetrix Management Console (SMC).
SMC, as shown in Figure 5, is a GUI that allows storage administrators to easily manage a Symmetrix.
SMC can be run on open systems hosts connected directly or remotely to a Symmetrix VMAX that requires
management.

Figure 5. Symmetrix Management Console
Symmetrix Enterprise Flash Drives
With the Symmetrix DMX and VMAX support of Enterprise Flash Drives (shown in Figure 6), EMC has
created a new ultra-performance storage capability that removes previous performance limitations imposed
by magnetic disk drives.

Figure 6. Enterprise Flash Drive
Enterprise Flash Drives dramatically increase performance for latency-sensitive databases like Oracle, DB2
UDB, Microsoft SQL Server, and SAP MaxDB used in SAP configurations. Enterprise Flash Drives, also
known as solid state drives (SSD), contain no moving parts, which remove much of the storage latency
delay associated with traditional magnetic disk drives. A Symmetrix VMAX with Enterprise Flash Drives
can deliver single-millisecond application response times and up to 30 times more I/O operations per
second (IOPS) than traditional Fibre Channel hard disk drives (HDD). Additionally, because there are no
mechanical components, Enterprise Flash Drives consume significantly less energy than hard disk drives.
When replacing a larger number of HDDs with a lesser number of Enterprise Flash Drives, energy
consumption can be reduced by up to 98 percent for a given IOPS workload.
The high-performance characteristics of Enterprise Flash Drives eliminate the need for organizations to
purchase large numbers of traditional hard disk drives, while only utilizing a small portion of their capacity
to satisfy the IOPS requirements of database. The practice of underutilizing a hard disk drive for increased
performance is commonly referred to as short-stroking. Enterprise Flash Drives can increase database
performance and eliminate the need to short-stroke drives, thus keeping storage footprint and power
consumption to a minimum and reducing TCO.
Symmetrix Enhanced Virtual LUN Technology
Enginuity 5874 and later provide an enhanced version of Symmetrix Virtual LUN software to enable
transparent, nondisruptive data mobility of devices between Storage Tiers and/or RAID protections (as
shown in Figure 7). Virtual LUN migration technology provides users with the ability to move Symmetrix
logical devices between drive types, such as high-performance Enterprise Flash Drives (EFDs), Fibre
Channel drives, or high-capacity low-cost SATA drives and at the same time change their RAID protection.

Figure 7. Enhanced Virtual LUN
Virtual LUN migration occurs independent of host operating systems or applications, and during the
migration the devices remain fully accessible to SAP application and database transactions. While the back-
end device characteristics change (RAID protection and/or physical drive type) the migrated devices
identities remain the same to the host, allowing seamless online migration. Virtual LUN migration is fully
integrated with Symmetrix replication technology and maintains consistency of source/target device
relationships in replications such as SRDF, TimeFinder/Clone, TimeFinder/Snap, or Open Replicator.

The advantages of migrating data using storage technology are ease of use, efficiency, and simplicity. Data
is migrated in the Symmetrix back end without needing any SAN or host resources, which increases
migration efficiency. The migration is a safe operation as the target is treated internally as just another
mirror of the logical device, although with its own RAID protection and drive type. At the end of the
migration the data on the original mirror is formatted to preserve security. Finally, since the identity of
source devices doesnt change, moving between Storage Tiers is easy and doesnt require additional host
change control, backup script updates, changes in filesystem mount points, a volume manager, or others.
The migration pace can be controlled using Symmetrix quality of service (symqos) commands.
Virtual LUN migration helps customers to implement an Information Lifecycle Management (ILM)
strategy for SAP, such as the move of the entire SAP business application like an ERP, a single SAP
system or instance, SAP filesystems or datafiles, or part of the SAP Landscape such as development
(DEV), Quality Assurance (QAS), or production (PRD) between Storage Types. It also allows adjustments
in service levels and performance requirements to application data. For example, often application storage
is provisioned before clear performance requirements are known. At a later time, once the requirements are
better understood, it is easy to make any adjustment to increase user experience and ROI using the correct
Storage Type.
Figure 8 shows an example of performing a Virtual LUN migration of an SAP ERP system +ERP with
20 x 50 GB logical devices The migration source devices are spread across 40 x 300 GB drives and
protected with RAID 1. The migration target devices are spread across only 4 x 400 GB EFDs and
protected with RAID 5.

40 x 300 GB 15k rpm (RAID 1)
4 x 400 GB Enterprise
Flash drives (RAID 5)
Ease of LUN migration for:
SAP ERP
datafiles
system files
log files
+ +E ER RP P
2 20 0 x x 5 50 0 G GB B
A AS SM M m me em mb be er rs s
Figure 8. Migration example using Virtual LUN technology
The following steps demonstrate the use of Virtual LUN, based on the example in Figure 8.


1. Optional: Verify information for a migration session called ERP_mig
symmigrate -name ERP_mig file ERP.txt validate
The file ERP.txt contains the list of source and target migration devices:
0100 0C00
... ...
0113 0C13
2. Perform the migration
symmigrate -name ERP_mig file ERP.txt establish
3. Follow the migration progress and rate at 60-second intervals
symmigrate -name ERP_mig file ERP.txt query i 60
4. Terminate the migration session after completion
symmigrate -name ERP_mig file ERP.txt terminate
5. Optional: Control migration pace
Create a Symmetrix DG with the source devices
symdg create ERP_dg
symld g ERP_dg range 0100:0113 addall
Control the copy pace using the DG
symqos g ERP_dg set MIR pace 8
Symmetrix Fully Automated Storage Tiering (FAST)
Introduced in the Enginuity 5874 Q4 service release, EMC Symmetrix VMAX Fully Automated Storage
Tiering (FAST) is Symmetrix software that utilizes intelligent algorithms to continuously analyze device
I/O activity and generate plans for moving and swapping devices for the purposes of allocating or re-
allocating application data across different performance Storage Types within a Symmetrix array. FAST
proactively monitors workloads at the Symmetrix device (LUN) level in order to identify busy devices
that would benefit from being moved to higher-performing drives such as EFD. FAST will also identify
less busy devices that could be relocated to higher-capacity, more cost-effective storage such as SATA
drives without altering performance.
Time windows can be defined to specify when FAST should collect performance statistics (upon which the
analysis to determine the appropriate Storage Type for a device is based), and when FAST should perform
the configuration changes necessary to move devices between Storage Types. Movement is based on user-
defined Storage Types and FAST Policies.
The primary benefits of FAST include:
Automating the process of identifying volumes that can benefit from EFD and/or that can be kept on
higher-capacity, less-expensive drives without impacting performance
Improving application performance at the same cost, or providing the same application performance at
lower cost. Cost is defined as space, energy, acquisition, management, and operational expense
Optimizing and prioritizing business applications, allowing customers to dynamically allocate
resources within a single array
Delivering greater flexibility in meeting different price/performance ratios throughout the lifecycle of
the information stored
The management and operation of FAST can be conducted using either the Symmetrix Management
Console (SMC) or the Solutions Enabler Command Line Interface (SYMCLI). Additionally, detailed
performance trending, forecasting, alerts, and resource utilization are provided through the Symmetrix
Performance Analyzer (SPA). And if so desired, Ionix ControlCenter provides the capability for advanced
reporting and analysis that can be used for chargeback and capacity planning.
How FAST is configured
FAST is configured by defining three distinct objects:

Storage Groups. A Storage Group is a logical grouping of up to 4,096 Symmetrix devices. Storage
Groups are shared between FAST and Auto-provisioning Groups; however, a Symmetrix device may
only belong to one Storage Group that is under FAST control.
Storage Types. Storage Types are a combination of a drive technology (for example, EFD, FC 15k
rpm, or SATA) and a RAID protection type (for example, RAID 1, RAID 5 3+1, or RAID 6 6+2).
There are two types of Storage Types static and dynamic. A static type contains explicitly specified
Symmetrix disk groups, while a dynamic type will automatically contain all Symmetrix disk groups of
the same drive technology. A Storage Type will contain at least one Symmetrix disk group but can
contain more than one. If more than one disk group is contained in a Storage Type, the disk groups
must be of a single drive technology type.
FAST Policies. FAST Policies associate a set of Storage Groups with up to three Storage Types. FAST
Policy includes the maximum percentage that Storage Group devices can occupy in each of the Storage
Types. The percentage of storage specified for each type in the policy when aggregated must total at
least 100 percent and may total more than 100 percent. For example, if the Storage Groups associated
with the policy are allowed 100 percent in any of the types, FAST can recommend for all the storage
devices to be together on any one Type (capacity limit on the Storage Types is not forced). In another
example, to force the Storage Group to one of the Storage Types simply set the policy to 100 percent
on that type and 0 percent on all other Types. At the time of association, a Storage Group may also be
given a priority (between 1 and 3) with a policy. If a conflict arises between multiple active FAST
Policies, the Fast Policy priority will help determine which policy gets precedence.
Refer to Figure 1 for the relationship between Storage Groups, Storage Types, and FAST Policies.
FAST can be configured to operate in a set and forget mode (Automatic) where the system will
continually gather statistics, analyze, recommend, and execute moves and swaps to maintain optimal
configuration based on policy, or in a user approval mode (User Approved) where all configuration
change plans recommended by FAST must be approved to be executed.
Device movement
There are two methods by which a device will be relocated to another type: move or swap.
A move occurs when unconfigured (free) space exists in the target Storage Type. Only one device is
involved in a move, and a DRV (special Symmetrix device used for device swapping) is not required.
Moves are performed by creating new devices in unconfigured space on the appropriate Storage Type,
moving the data to the new devices, and deleting the old device.
A swap occurs when there is no unconfigured space in the target Type, and results in a corresponding
device being moved out of the target Storage Type. In order to preserve data on both devices involved in
the swap, a single DRV is used (DRV should therefore be sized to fit the largest FAST controlled devices).
Moves and swaps are completely transparent to the host and applications and can be performed
nondisruptively, without affecting business continuity and data availability. Symmetrix metadevices are
moved as a complete entity; therefore, metadevice members cannot exist in different Symmetrix disk
groups.
FAST optimizes application performance in Symmetrix VMAX arrays that contain drives of different
technologies. It is expected that customers will have their arrays configured with Flash, Fibre Channel,
and/or SATA drives, resulting in Storage Types with different performance levels. Rather than leave
applications and data statically configured to reside on the same Storage Type, FAST will allow customers
to establish the definitions and parameters necessary for automating data movement from one type to
another according to current data usage. The first version of FAST as is released with Enginuity 5874 Q4
service release will move data at the full device granularity.
Skewed LUN access
Skewed LUN access is a phenomenon that is present in most databases and thus affects SAP. Skewing is
when a small number of the database LUNs receive a large percentage of the I/O from the business
application. This skewed type of activity can be transient, that is to say lasting only a short period of time,

or persistent, lasting much longer periods of time. Skewed, persistent access to volumes make those
volumes good candidates to place on a higher-performing tier, if they are not already on the highest-
performing tier.
Skewing by its nature means that there are database LUNs that are receiving lower activity than others. If
these volumes are persistently receiving fewer requests than others they may be good candidates to move a
lower-performing tier.
With the first release of FAST, the granularity is a full device and therefore FAST Storage Group should
always include all the devices in any SAP system, instance, or datafile disk group that is under FAST
control. SAP instances are created by defining one or more datafiles. The datafiles can be configured to
separate LUNs to take create additional granularity to move data between Storage Types. So for SAP, the
goal will be to move or swap an entire SAP system, instance, or datafile disk group from one Storage Type
to another. If database partitioning is available, it would be beneficial to create additional tablespaces with
different datafiles that can help isolate the most current active data to older, less active data. Therefore
when planning the SAP system for use with multiple Storage Types, the SAP configuration should be
designed accordingly.
Symmetrix devices can be concatenated to simulate full physical drives or RAID groups; however, keep in
mind that currently FC 10k rpm drive size has reached 600 GB, and SATA drives have capacities between
1 and 2 TB. These are very large objects to operate on and each time additional capacity is needed
multiples of such large units will need to be acquired and added, which is not cost- or capacity-efficient. In
addition, for performance reasons it is better to present a host with multiple reasonably sized LUNs than
very few large ones. The reason is that each LUN will have its own I/O queue by the host and will make
keeping the storage devices busy with enough concurrent work easy. With few very large LUNs often
server host queuing needs to be tweaked to simulate this behavior causing performance problems.
Working with SAP, Oracle databases, and Enhanced
Virtual LUN Technology
Manual Storage Tiering mechanics
The goal of an effective Storage Tiering approach in a multi-typed storage configuration is to place the
right data on the right Storage Type at the right time. A given SAP system device may be highly active and
highly accessed when data is created on it in the first instance. But over time, its usage may drop to a level
where the device could be deployed on a Storage Type that has lower-cost and lower-performance
characteristics.
A typical manual Storage Tiering approach uses the following steps:
1. Monitor SAP system, SAP database and storage performance
2. Identify and classify hot and cold database objects that are candidates for cost reduction (down-tiering)
or performance improvement (up-tiering).
3. Identify space to be used as targets for tiering operations
4. Use database, host, or storage utilities to move the candidates to the right Storage Type
5. Validate that the tiering activities had the desired effects
6. Repeat the process at a later time
Manual Storage Tiering example
Test methodology and configuration
The following are a few examples of managing manual Storage Tiering using Symmetrix Enhanced Virtual
LUN Technology to perform SAP system migrations seamlessly inside the storage array.

The tests outlined in this white paper were performed on the following environment as shown in Table 1.
Table 1. Test environment
Configuration aspect Description
Storage array Symmetrix VMAX (2 VMAX Engines)
Enginuity 5874 service release
Oracle CRS and database version: 11gR2
EFD 8 x 400 GB Enterprise Flash Drives
HDD 120 x FC 15k rpm 300 GB drives
SATA 32 x SATA 7,200 rpm 1 TB drives
Linux Oracle Enterprise Linux 5.3
Multipathing EMC PowerPath
5.3 SP1

The test configuration used three Oracle 11gR2 databases with workloads set to emulate the I/O behaviors
typically seen on SAP ERP, CRM, and DEV systems. All three databases were the same size, roughly 1 TB
executing an OLTP workload. The focus was to manage the Storage Types between databases (that is,
placing each database in the type that best matches its business and performance needs). Since each
database had the redo logs, data files, temp, and archive logs (FRA) striped across their own set of
devices
2
, it is only the data files devices of each database that were moved between the Storage Tiers. The
redo logs and temp files remained on 15k rpm drives, and archive logs on SATA drives.
The first database, DB1, started on FC 15k rpm drives but was designed to simulate a low I/O activity
database that has very few users, low importance to the business, and is a candidate to move to a lower
Storage Type, or down-tier. The DB1 database could be one that was once active but is now being
replaced by a new application. The second database, DB2, was designed to simulate a medium active
database that was initially deployed on SATA drives, but its activity level and importance to the business
are increasing and it is a candidate to be moved to a higher Storage Type, or up-tier. The last database,
DB3, started on FC 15k rpm drives and was designed to simulate the high I/O activity level of a mission-
critical application with many users and is a candidate to up-tier from FC 15k rpm to EFD.
Each of the three databases was using host striping based on the configuration as shown in Table 2. Table 3
shows the initial storage drive types and count
3
behind each of the data files devices at the beginning of the
tests. It also shows the OLTP workload and potential business goals for each of the databases.
Table 2. Oracle storage configuration for each test database
Oracle
Database LUNs
Size
(GB) Total (GB) RAID
DATA 10 120 1,200 RAID 5 (3+1)
REDO 20 5 100 RAID 1
TEMP 5 120 600 RAID 5 (3+1)
FRA 40 120 4800 RAID 5 (3+1)

Table 3. Database storage placement (initial) and workload profile
Database # Physical
drives
Drive
Type
Workload Business goal
DB1 40 FC 15k
Very low Down-tiering / cost saving

2
Based on EMC recommendations for Symmetrix to allow better flexibility, business continuity,
replications, and performance management.
3
The Symmetrix drive count can be controlled by the number of drives in each Symmetrix disk group.

DB2 32 SATA
Medium Up-tiering / preserve SLA
DB3 40 FC 15k
High Up-tiering / improve SLA
Monitoring database and storage performance
Based on the initial test configuration and the understanding of the relative importance of each database to
the business (as seen in Table 3) we reviewed Oracle AWR data for each of the databases (Table 4), and
made a note of the OLTP transaction rate baseline for later comparison, as seen in Table 5.
Table 4. Initial Oracle AWR report inspection
Database #
Oracle AWR Top 5 Timed Foreground Events (from AWR report)
DB1
Avg
wait % DB
Event Waits Time(s) (ms) time
db file sequential read 684,271 3,637 5 84.6
db file scattered read 17,580 261 15 6.1
DB CPU 193 4.5
log file sync 51,587 30 1 .7
SQL*Net break/reset to client 9,286 0 0 .0

DB2
db file sequential read 13,382 250 19 89.2
DB CPU 5 1.7
log file sync 2,381 1 1 .5
cursor: pin S wait on X 8 0 28 .1
control file sequential read 498 0 0 .1

DB3
db file sequential read 18,786,472 163,680 9 76.2
log file sync 1,703,895 15,945 9 7.4
buffer exterminate 823,914 8,541 10 4.0
DB CPU 5,917 2.8
free buffer waits 75,387 2,889 38 1.3

Table 5. Initial performance analysis results
Initial Performance Manual Storage Tiering
# Phys Disks Disk Type Avg. Txn/Min % Change
DB1 40 FC 15k 349.20 0.00%
DB2 32 SATA 890.53 0.00%
DB3 40 FC 15k 11736.03 0.00%

Based on these results we can see that DB1 is mainly busy waiting for random read I/O (db file sequential
read Oracle event refers to host random I/O). A wait time of 5 ms is very good; however, this database
shows a low transaction rate and has no business justification to be on FC 15k rpm drives. As a result the
decision is made to down-tier it to SATA drives.
DB2 is also spending most of the time waiting for random read I/Os with an average wait time of 18 ms. It
is currently on SATA drives, and its transaction rate will surely improve by placing it on a better
performing Storage Type. In this case the business goal is to address DB2s increasing importance and
activity and in order to do it well move it to the FC 15k rpm drive type where the I/O response time and
transaction rate can be improved.
DB3 is already on FC 15k rpm drives, but based on its high I/O activity it can benefit from up-tiering to
EFD. In this test configuration we had 8 x 400 GB EFDs in RAID 5, which gives roughly 2.8 TB available
capacity. The 1 TB DATA ASM disk group of DB3 could easily fit there. This is a very visible and critical
database to the business and so it was decided to up-tier its data to EFD. Moving only portions of a
database to the EFD Storage Type is not described here and is covered in another white paper.

Finally, in this paper we used an EMC internal performance analysis tool that shows a heat map of the
drive utilization at the Symmetrix back end just to illustrate the changes. Each physical drive in the array is
represented by a single rectangle and that rectangle corresponds with the physical location of the drive in
the array. The rectangle is color-filled to represent the utilization of the physical drive as shown in the
color legend on the left side of the figure. As seen in Figure 9, the HDDs hosting DB1 are blue, showing
minimum utilization. The SATA drives hosting DB2 are primarily light-green to yellow, showing medium-
high utilization, and the FC 15k rpm drives hosting DB3 are bright red, which indicates a potential for
improvement.

DB1 on FC 15k rpm
DB3 on FC 15k rpm
DB2 on SATA
Figure 9. Initial performance analysis drive utilization map
Using Virtual LUN to up-tier DB2
We decided to up-tier DB2 from SATA to FC 15k rpm drives first. The process of migrating data from one
set of drives to another can be done via CLI using the symmigrate command for those administrators who
choose to script the migrations, but for those who prefer a GUI interface the Symmetrix Management
Console provides a very easy-to-use wizard to perform the migration.
Figure 10 shows an example of the SMC LUN Migration Wizard. An example of using the CLI commands
is shown earlier in the Products and features overview section (see Figure 8 on page 13).

Figure 10. SMC LUN Migration Wizard
After DB2 migration completed, the OLTP workload was rerun and the results of the test are shown in
Table 6. The overall transaction per minute for DB2 more than doubled and the resulting increase of load
on the system caused performance of the other two databases to degrade slightly.
Table 6. Performance analysis results after DB2 move to HDD
Move DB2 to FC 15k rpm
DB1 40 FC 15k 343.03 -1.77%
DB2 40 FC 15k 2816.43 216.26%
DB3 40 FC 15k 11181.37 -4.73%

Figure 11 shows the utilization map of the Symmetrix VMAX system taken after the migration of DB2
from SATA to FC 15k rpm drives. The utilization of DB1 did not change substantially and is still shown in
dark blue. Notice that the location of the drives for DB2 has moved from the SATA drives at the bottom of
the figure to just above the DB3 physical drives and DB2 now shows up in light yellow, indicating
moderate utilization. DB3 is still bright red and we will address that next.


DB1 on FC 15k rpm
DB2 on FC 15k rpm
DB3 on FC 15k rpm
Figure 11. Utilization map for DB2 on FC
Next we up-tiered DB3 to eight Flash drives and reran the OLTP workload. The results are shown in Table
7. Migrating the test workload from 40 physical 15k rpm drives to just eight Flash drives kept the same
overall transaction per minute rate while at the same time reduced the number of drives required and as can
be seen, no storage component is overutilized anymore. Figure 12 shows the utilization of the Flash drives
after the migration of DB3 in the green and yellow, indicating 40-60 percent utilization.
Table 7. Results after migrating DB3 to Flash
Move DB3 to 8 Flash
DB1 40 FC 15k 321.90 -6.16%
DB2 40 FC 15k 2609.03 -7.36%
DB3 8 EFD 11408.50 2.03%

DB3 on EFD
DB1 on FC 15k rpm
DB2 on FC 15k rpm

Figure 12. Utilization map for DB3 on Flash drives

Next we down-tiered DB1 to SATA. This was an intentional decision to move DB1 from FC 15k rpm
drives down to SATA drives even at a performance cost because this application workload did not require
high-performance SLAs anymore and therefore did not justify the Storage Type it was on, or needed 5 ms
I/O wait time. The results of this migration are shown in Table 8. As expected, performance of DB1
degraded because we down-tiered the database from 40 physical FC drives to 32 slower SATA drives. The
performance of the other two databases was unchanged. Figure 13 shows the utilization map with DB1 on
SATA drives. The SATA drives are shown in the light blue and light green, indicating utilization in the 30
to 50 percent range.
Table 8. Results after migrating DB1 to SATA
Move DB1 to 32 SATA
DB1 32 SATA 168.43 -47.68%
DB2 40 FC 15k 2629.87 0.80%
DB3 8 EFD 11450.17 0.37%

Moving DB1 to SATA decreased performance by about 50 percent but by moving DB1 to SATA we were
able to make 40 FC 15k rpm drives available for other uses.

DB3 on Flash
DB1 on SATA
DB2 on FC 15k rpm
Figure 13. Final manual migration map
Summary of manual LUN migration benefits
To summarize the results of the migrations, the overall performance of DB1 (simulating SAP DEV
environment), the development system, degraded as expected, but we were able to migrate the data without
interruption to the development work. Up-tiering DB2 (simulating SAP CRM system) from SATA to FC
15k rpm drives more than doubled the performance of this application and because we up-tiered the
database to FC there are now 40 free physical drives over which we can distribute this load as transaction
volume increases. DB3 (simulating SAP ERP system) was successfully moved from FC to EFD and while
the overall transaction volume did not increase dramatically, we were able to free up an additional 40
physical drives for other uses.
Also, as a note, at the start of each test iteration we restored the initial TimeFinder copy of the database
LUNs (gold copy) to ensure the initial state of the database was the same. The scripts initiating the
workload for all three databases did not need any modification despite the fact that none of the LUNs were
in the same location at the end of the tests as they were at the beginning. This is a key feature of
Symmetrix LUN migrationall Symmetrix internal device relationships are maintained at all times during
migrations, and therefore no scripts or database changes were necessary.


Working with SAP, Oracle databases, and Fully
Automated Storage Tiering (FAST)
FAST test environment
As described in the overview, FAST is controlled by defining Storage Groups, Storage Types, and FAST
Policies. Since we already had a test environment used for Virtual LUN testing we used the same host
infrastructure and database setup. Figure 14 shows the logical FAST profile we used for database 3, or DB3
(simulating an SAP ERP environment). In this case, while we have three drive types in the Symmetrix
VMAXEFD, FC 15k rpm, and SATA driveswe do not want DB3 to reside on SATA so we could
potentially not include a SATA type. However, including it and setting the allowable percentage to 0
percent has the same effect.

Figure 14. Logical FAST profile for DB3
Initial FAST configuration
The following SMC screenshots show how SMC can be used to configure FAST. Symmetrix CLI can be
used as well; however, SMC makes creating FAST Storage Types, Storage Groups, and Policies simpler by
providing the user with easy-to-understand wizard and point-and-click interface. Showing all the various
dialog boxes and sample output options is beyond the scope of this paper. The screenshots shown are the
results from the previous three databases setup, where DB3 is placed under FAST control. As you recall,
DB3 starts on the FC 15k rpm Storage Type, and we can see how FAST recommends and moves the
workload to the EFD Storage Type.
The simplest way to configure FAST for the first time is to use the SMC FAST Configuration Wizard. But
before starting the wizard, it is recommended to create the Storage Groups that FAST will operate on.
Storage Groups in Symmetrix VMAX are used for both Auto-provisioning Groups to simplify device
masking operations, as well as to group devices for FAST control. While Symmetrix devices can be in
multiple Storage Groups, no two Storage Groups under FAST control can contain the same devices. In
Figure 15 through Figure 17, we can see how the Oracle data files devices of database 3 (DB3), are placed
into a Storage Group that can later be assigned a FAST Policy.

Figure 15. Create a Storage Group for DB3 FAST control Step 1



Once the Storage Group is created we can use SMC to manage FAST. For the first time, it is recommended
to use the FAST Configuration Wizard as shown in the following images.
The first screen describes the overall operations that the wizard will help with, as shown in Figure 18.

Figure 18. FAST Configuration Wizard Welcome screen
Select the configuration activities for the wizard, as shown in Figure 19.

Figure 19. FAST Configuration Wizard activities screen

Select the Symmetrix ID for FAST configuration, automatic or user-approval mode, minimum sampling
before first analysis, and the amount of workload sampling to maintain for analysis, as shown in Figure 20.

Figure 20. Set FAST parameters
The next two screens as shown in Figure 21 help in creating time windows for the performance analysis
and moves/swaps. The Performance Time Window is when the FAST Controller samples the activity for
analysis, and the Move Time Window is when FAST can perform moves and swaps.

Figure 21. Create FAST time windows

The next screen as shown in Figure 22 is used to create the Storage Tiers that FAST can operate on. SMC
will provide a list of proposed tiers based on the current tiers available within the Symmetrix, and will
show what tiers are already configured. The tiers can be renamed to fit their usage if necessary.

Figure 22. Create FAST tiers
The next two screens are used to create FAST Policies with focus on performance improvement or cost
reduction. Figure 23 shows the Create Performance Improvement Policy screen. The separation to two
screens is done for convenience and due to the difference in the business focus for each approach.

Figure 23. Create FAST Policies
When creating policies, the Storage Groups prepared earlier for FAST control are being assigned Storage
Types they can be allocated on, and the capacity percentage the Storage Group is allowed on each of them.
The last screen in the wizard is a summary and approval of the changes. Additional modifications to FAST
configuration and settings can be done using Solutions Enabler or SMC directly, without accessing the
wizard again. Solutions Enabler uses the symfast command line syntax, and SMC uses the FAST tab.


FAST test setup for DB3 (SAP ERP) management
As shown before, the SMC FAST Wizard can help with the initial FAST configuration. The following
steps show the FAST components configured for database 3 (DB3) FAST management (if the wizard is not
used), showing an OLTP workload similar to an SAP ERP system.
The first step is to create Storage Tiers (also known as types). The result of creating the DB3 Storage Type
is shown in Figure 24. This Storage Type describes the 40 FC 15k rpm physical drives that can contain the
DB3 data files devices. These FC drives reside on Symmetrix disk group 25.

Figure 24. DB3 FC 15k rpm Storage Type properties
The next step is to create a Storage Type for the Flash drives. This is done by adding Symmetrix disk
group 10 to the EFD Storage Type and this case we have defined this to be RAID 5 (7+1).

Figure 25. DB3 EFD Storage Type properties

The next step is to create Storage Groups. Figure 26 shows properties of the DB3 Storage Group. The DB3
Storage Group properties box has three tabsGeneral, Devices, and FAST Compliance. The Devices tab
shows the 10 Symmetrix devices that belong to devices that contain DB3 data files and comprise the
DB3_SG Storage Group. The FAST Compliance tab shows what tiers of storage this Storage Group may
reside in. In this case we have defined the FC Storage Type as the place where the drives are now and the
EFD Storage Type is where FAST may choose to move this set of devices. Notice that there is no option
for a SATA Storage Type for the DB3 Storage Group. This will prohibit FAST from ever recommending a
down-tier of DB3 to SATA.

DB3 Storage Group
Figure 26. DB3 Storage Group Properties

The final step of the process is to associate the Storage Group with the FAST tiers and define a policy to
manage FAST behavior. In our case we have one Storage Group (DB3_SG), two FAST tiers (EFD and
FC), and one FAST Policy. The FAST Policy allows for up to 100 percent of the Storage Group to reside
on the Flash Storage Type and allows for 100 percent of DB3 to reside on FC. Since there is no SATA
Storage Type defined for DB3, there is not a third Storage Type option. By allowing up to 100 percent of
the DB3 Storage Group to reside on EFD we expected that if FAST was going to move any DB3 LUNs to
EFD, it would move them all because they all have the same I/O profile, and there is ample capacity
available on that Storage Type to accommodate all the capacity of those devices or the FAST Storage
Group.

Figure 27. DB3 FAST Policy
Monitoring and executing FAST recommendations for DB3
The initial FAST test configuration was exactly the same as the initial configuration of the Virtual LUN use
case described previously. It had DB2 placed on 10 LUNs on 32 physical SATA drives, with DB1 and DB3
started on 40 15k rpm drives each. The following table shows the initial performance of the databases in
their starting locations.

Table 9. Initial FAST performance analysis results
Initial Performance Manual Storage Tiering
# Phys Drives Drive Type Avg. Txn/Min % Change
DB1 40 FC 15k 349.20 0.00%
DB2 32 SATA 890.53 0.00%
DB3 40 FC 15k 11736.03 0.00%


DB1 on FC 15k rpm
DB3 on FC 15k rpm
DB2 on SATA
Figure 28. Initial performance analysis on FAST
We reran the OLTP workload and after an hour of collecting data, FAST proposed a Move/Swap plan
shown in Figure 29. FAST proposed to move all the LUNs in the DB3 disk group from FC to EFD in a
single move, which is exactly what we had expected. We approved the plan, FAST executed the move
plan, and we reran the workload. The results after the move are shown in Table 10. After the FAST move
of DB3 to EFD, overall system transaction performance improved around 13 percent and there was no
degradation in performance of the other two databases. The utilization shows both the active SATA drives
and the Flash drives in shades of yellow and green, indicating moderate usage.

Figure 29. FAST generated plan
Table 10. Results after FAST migration of DB3 to Flash
FAST Move DB3 to 8 Flash
# Phys Drives Drive Type Avg. Txn/Min % Change
DB1 40 FC 15k 358.12 2.55%
DB2 32 SATA 897.27 0.76%
DB3 8 Flash 13334.98 13.62%


DB3 on EFD
DB1 on FC 15k rpm
DB2 on SATA

Figure 30. Utilization map after FAST migration of DB3 to EFD

Conclusion
With the Enginuity 5874 Q4 service release enhancements made to Virtual LUN migration and the
introduction of FAST technology, data center administrators are now able to dynamically manage data
placement in a Symmetrix array to maximize performance and minimize costs.
In a multi-tiered Oracle storage configuration, moving the highly accessed volumes from FC drives to
EFDs can help administrators maintain or improve performance and free up FC drives for other uses.
Moving active drives from SATA to FC drives improves performance and allows for increased application
activity. Moving lightly accessed volumes from FC to SATA helps utilization and drives down cost. This
volume movement can be done nondisruptively on a Symmetrix VMAX using Virtual LUN and FAST
capabilities.


h6731 Storage Tiering Sap Vmax WP

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

h6731 Storage Tiering Sap Vmax WP

Hochgeladen von

Copyright:

Verfügbare Formate

Storage Tiering for SAP and

EMC Symmetrix VMAX with Enginuity 5874

VMAX Enhanced Virtual LUN Technology and

; Silver Tier CLARiiON

; Bronze Tier Tape

Das könnte Ihnen auch gefallen