M11res01 Managing FAST VP With SYMCLI

This module focuses on managing FAST VP with SYMCLI.
With the increased level of

customer interest in FAST VP, FAST DP has declined in popularity and application. Therefore,
this module focuses on the implementation of FAST VP only.
Copyright 2013 EMC Corporation. All rights reserved Module 11: Managing FAST VP with SYMCLI 1
This lesson covers the setting of time windows and FAST control parameters.
These are the steps a user would go through in order to implement FAST.
FAST requires a license key. License keys for each Enginuity software products are obtainable
from EMC, and entered and viewed using the symlmf command. A detailed description of
the software commands and features enabled by each license is provided in the EMC
Solutions Enabler Installation Guide.
FAST and FAST VP control parameters have been discussed in an earlier module. This is a
recap to show the parameter names as they appear on the SYMCLI command line.
This is a view of the default values for the control parameters.
Using the shell script shown, the FAST and FAST VP control parameters are set on the
Symmetrix.
This is the initial setting on a VMAX with no user defined Time Windows. Performance
statistics are collected round the clock, whereas there are no defined move windows.
This page shows an example of setting an inclusive window. The start and end time are in 30
minute increments from 00:00 to 24:00. In the example, performance moves are enabled
round the clock every day.
If an exclusive time window had been set, it would have the highest priority, and it would
override any time windows that had been defined during those time periods listed in the
inclusive time window.
By default, FAST is disabled on the Symmetrix as shown by the output on left of this slide. On
enabling FAST DP and VP, the Symmetrix will start performing FAST moves once FAST policies,
tiers and associated storage groups are defined.
This lesson covers management of FAST VP with SYMCLI.
The command symdisk sid <> list dskgrp_summary lists the disk groups in the Symmetrix.
As the output shows, there are 20, 15000 RPM FC disks in disk group 3, 22, 10000 RPM FC
disks in disk group 2, 14 SATA drives in disk group 1 and 4 external drives in disk group 512.
Note that it is possible to assign names to disk groups using the symconfigure command.
An example would be:
symconfigure sid 72 cmd set disk_group 3,
disk_group_name=SATA_1TB; commit
5 data devices have been created on the SATA drives. These are now placed in a pool called
ss_SATA and the pool is enabled. Next, a VP tier called Int_SATA_Tier is created and the pool
ss_SATA is added to the tier.
4 data devices have been created on the 15K RPM FC drives. These are now placed in a pool
called ss_FC15 and the pool is enabled.
Next, a VP tier called Int_FC_Tier is created and the pool ss_FC15 is added to the tier.
3 data devices have been created on the external drives. These are now placed in a pool
called ss_EXT and the pool is enabled.
Next, a VP tier called Ext_FC_Tier is created and the pool ss_EXT is added to the tier. The tier
is defined as having Fibre channel technology.
The initial performance test is known as full discovery testing. Similar testing is performed
when a change is made to the underlying eDisks for the tier or if the technology type is
modified in the tier definition.
Once the full performance discovery completes, an ongoing task periodically executes a
lighter performance discovery. This is known as discovery validation testing. The purpose of
this discovery is to validate or incrementally adjust the previously discovered performance.
At any point, if the performance of an external tier falls below expectations, an event is
triggered, alerting users to this fact.
The event (event ID 1511) is triggered when the performance of an external tier changes,
dropping below the expected level.
Theres no published list of expected performance responses for different kinds of storage. If
you choose to assign a higher tier to externally connected storage, you should monitor the
audit log to see how the external tier is performing.
We now add four thin devices to our SATA pool and fill them up, so as to create allocations in
the SATA pool.
Here is a display of the pools and the associated tiers. The SATA tier has all the allocations,
since the 4 thin devices are bound to that pool and tier.
Here, we create a policy that states that 50% of thin device storage associated with the
policy must be on the tier Int _SATA_Tier, 25% on Int_FC_Tier and 25% on ext_FC_Tier.
The storage group had all its storage associated with the SATA pool at the time it was
created. Consequently, the association of the storage group with the policy
25FC25EXT50SATA will cause the storage group to be non-compliant.
This command shows that the storage group ss_FASTVPGroup has exceeded the allowed
capacity in tier Int_SATA_Tier by 2 GB, whereas there is room for it to grow 1GB in the other
two tiers.
After some time elapses and FAST VP moves enough allocated tracks, the SATA tier moves to
the other two tiers to make the SG policy compliant.
FAST VP has a tolerance level of 200 MB. A growth potential of 611 MB is not an issue, since
that shows that FAST VP usage of storage in the pool is within policy constraints.
A growth potential of -206 shows that tier usage exceeds allowable limits by 206 MB. This
falls almost within the 200 MB tolerance.
After the FAST VP move, part of the thin device allocation is hosted by pool ss_SATA, which
makes up the Int_SATA_Tier. Allocations for F1 and F2 have been migrated to other tiers.
Some tracks for devices F1 and F2 have been allocated from the Int_FC_Tier that contains
the ss_FC15 thin pool.
The rest of the storage for F1 and F2 has been allocated from the Ext_FC_Tier that contains
the ss_EXT thin pool.
Here, we create a policy 100FC50EXT100SATA that states that 100% of thin device storage
associated with the policy may be on the internal SATA tier, 50% of storage may be on the
external FC tier, and 100% could also be on the internal FC tier.
In preparation for associating the thin devices to a new policy, they are migrated back to the
original SATA pool.
After the migration, all storage allocated to TDEVS 0F1 and 0F4 are bound to pool ss_SATA.
The current FAST VP policy allows 50 percent of the allocation of the storage group to reside
on the SATA tier, 25 percent of the allocation of the storage group to reside on the internal FC
tier, and 25 percent of the allocation to reside on the external FC tier.
After re-associating the storage group with the new policy, 100 percent of the allocation of
the storage group may reside on the internal SATA tier, 100 percent of the allocation of the
storage group may reside on the internal FC tier, and 50 percent on the external FC tier.
This command shows that the storage group ss_FASTVPGroup is policy compliant. Most of
the storage is on the SATA tier, and some has been moved to the FC tier because the FAST
controller made the decision to move the allocations based on the low activity level on the
Symmetrix.
After a short period (< 30 minutes) of running I/O to the thin devices, the storage allocation
gets moved to the two FC tiers.
This module covered the management of FAST and FAST VP with SYMCLI.

M11res01 Managing FAST VP With SYMCLI

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

M11res01 Managing FAST VP With SYMCLI

Hochgeladen von

Copyright:

Verfügbare Formate

This module focuses on managing FAST VP with SYMCLI.

With the increased level of

Das könnte Ihnen auch gefallen