Professional Documents
Culture Documents
Symmetrix
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.
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 4
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
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 5
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
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.
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 17
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.
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 18
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).
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 19
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
# Phys Disks Disk Type Avg. Txn/Min % Change
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.
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 20
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
# Phys Disks Disk Type Avg. Txn/Min % Change
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
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 21
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
# Phys Disks Disk Type Avg. Txn/Min % Change
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.
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 22
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.
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 23
Figure 15. Create a Storage Group for DB3 FAST control Step 1
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 24
Figure 16. Create a Storage Group for DB3 FAST control Step 2
Figure 17. Create a Storage Group for DB3 FAST control Step 3
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 25
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
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 26
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
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 27
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.
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 28
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
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 29
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
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 30
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%
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 31
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%
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 32
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.
Storage Tiering for SAP and EMC Symmetrix VMAX with Enginuity 5874
Applied Technology 33