Storage Allocation Using Auto Provisioning

This module focuses on storage allocation if VMAX3 storage to hosts using auto-provisioning
groups. We will describe auto-provisioning groups, host I/O limits and host considerations while
allocating storage. We will then use Unisphere for VMAX and SYMCLI to perform SLO based
storage provisioning.
Copyright 2015 EMC Corporation. All rights reserved. Storage Allocation using Auto-provisioning Groups 1
This lesson provides an overview of auto-provisioning groups and Host I/O limits. We also
introduce the SYMCLI syntax to manage auto-provisioning groups.
As the number of volumes in a single array continues to climb higher, auto-provisioning offers a
flexible scheme for provisioning storage in large enterprises. Auto-provisioning groups allow
storage administrators to create groups of host initiators (Initiator Groups), front-end ports (Port
Groups), and logical devices (Storage Groups). These groups are then associated to form a
masking view, from which all controls are managed. This reduces the number of commands
needed for masking devices, and allows for easy management of LUN masking.
Auto-provisioning in the VMAX3 arrays is achieved through the use of the symaccess SYMCLI
command or with Unisphere for VMAX. The symaccess command can manage Storage Groups,
Port Groups, Initiator Groups and Masking Views.
The symsg SYMCLI command manages storage groups and is used for auto-provisioning and with
FAST (Fully Automated Storage Tiering) to set the required SRP, SLO and Workload Type.
In Unisphere the Storage and Hosts sections are used to manage auto-provisioning. The Storage
section has the Storage Groups Dashboard. Port Groups, Hosts (Initiator Groups) and Masking
Views are managed under the Hosts section.
Auto-provisioning Groups are used for device masking on VMAX3 family of arrays.
An Initiator Group contains the world wide name of a host initiator, also referred to as an HBA or
host bus adapter. An initiator group may contain a maximum of 64 initiator addresses or 64 child
initiator group names. Initiator groups cannot contain a mixture of host initiators and child IG
names.
Port flags are set on an initiator group basis, with one set of port flags applying to all initiators in
the group. However, the FCID lockdown is set on a per initiator basis. An individual initiator can
only belong to one Initiator Group.
However, once the initiator is in a group, the group can be a member in another initiator group. It
can be grouped within a group. This feature is called cascaded initiator groups, and is only
allowed to a cascaded level of one.
A Port Group may contain a maximum of 32 front-end ports. Front-end ports may belong to more
than one port group. Before a port can be added to a port group, the ACLX flag must enabled on
the port.
Storage groups can only contain devices or other storage groups. No mixing is permitted. A
Storage Group with devices may contain up to 4K VMAX3 logical volumes. A logical volume may
belong to more than one storage group. There is a limit of 16K storage groups per VMAX3 array.
A parent SG can have up to 64 child storage groups.
One of each type of group is associated together to form a Masking View.
Once the groups have been created, auto-provisioning represents an easy way to handle
provisioning. It allows one to mask multiple devices, ports, and HBAs by placing them into
groups. These groups can be dynamically altered to give the host access to new storage.
With the symaccess command, all groups and views are backed up to a file, and can be restored
from a backup file.
When an auto-provisioning session fails on a VMAX3 array, the system automatically rolls back
the ACLX database to the state it was in prior to initiating the session. This rollback feature
recovers the database and releases the session lock automatically. The audit log contains any
messages relating to the rollback.
The table shows the provisioning limits for VMAX3 arrays.
This is a review of storage group information we had already covered in an earlier module.
A storage group is a logical collection of VMAX3 Thin devices that are to be managed together.
Storage group definitions are shared between FAST and auto-provisioning groups (LUN masking).
A storage group can be explicitly associated with an SRP or an SLO or both. By default devices
within a SG are associated with the default SRP and managed by the Optimized SLO. While all
the data on a VMAX3 array is managed by FAST, an SG in not considered “FAST managed” if it is
not explicitly associated with an SRP or an SLO. Devices may be included in more than one SG,
but may only be included in one SG that is “FAST managed”. This ensures that a single device
cannot be managed by more than one SLO or have data allocated from more than one SRP.
HYPERMAX OS arrays provides the capability for storage groups to contain other storage groups.
These groups are called cascaded storage groups. The storage group with the other storage
groups as members is called the parent. The storage groups, containing only devices, that is
contained within the parent storage group is referred to as the child storage groups. This
cascading of storage groups allows for individual FAST policies (SRP, SLO & Workload Type
settings) for the child storage groups and a masking view for the parent storage group.
Only a single level of cascading is permitted. A parent storage group may not be a child of
another storage group. Storage groups can only contain devices or other storage groups. No
mixing is permitted.
Empty storage groups can be added to a parent storage group as long as the parent storage
group inherits at least one device when the parent storage group is in a view. A parent storage
group cannot inherit the same device from more than one child storage group. A child storage
group may only be contained by a single parent storage group.
No parent storage group can be FAST managed. An FAST managed SG is not allowed to be a
parent SG.
Masking is not permitted for a child SG which is contained by a parent SG already part of a
masking view. Masking is not permitted for the parent SG which contains a child SG that is
already part of a masking view.
A child SG cannot be deleted until it is removed from its parent SG.
The example shows how to use both symaccess and symsg commands to create storage groups.
Note that the symaccess command allows you to create the storage group and simultaneously
add devices or child storage groups. The symsg command allows one to create an empty storage
group first and then populate it with devices or child storage groups. The symsg command will
also allow one to set the SLO and Workload type and Host I/O limits while the storage group is
created.
Please refer to the EMC Solutions Enabler V8.0.1 Array Management CLI User Guide for more
details and options while creating and managing storage groups with the symaccess and symsg
commands.
Here are some other commonly performed Storage Group operations. Storage Groups can be
renamed if needed. Please refer to the EMC Solutions Enabler V8.0.1 Array Management CLI User
Guide for more details and options while creating and managing storage groups with the
symaccess and symsg commands.
By default Storage Groups will use the default SRP and be managed by the Optimized SLO. The
SG is considered FAST managed only if an SLO or SRP is explicitly set. The valid arguments for
the –slo and –wl options are listed. Of course the array should be configured with appropriate
drives to support the SLO. The –noslo option removes any explicitly set SLO and WL type, the SG
is now managed by the Optimized SLO. The –nosrp option removes any explicitly set SRP, the SG
will use the default SRP.
Host I/O Limits feature allows users to place limits on the front-end bandwidth and IOPS
consumed by applications on VMAX3 systems.
Limits are set on a per-storage-group basis. As users build masking views with these storage
groups, limits for maximum front-end IOPS or MB/s are distributed across the directors within
the associated masking view. The VMAX3 system then monitors and enforces against these set
limits.
The Host I/O Limits can be managed and monitored using both Solutions Enabler and
Unisphere for VMAX.
The benefits of Host I/O Limits are listed on this slide. Please take a moment to review them.
Host I/O limits are beneficial whenever a VMAX3 array is shared among multiple tenants by
enabling the setting of consistent performance SLAs. They prevent applications from using more
than their allotted share of VMAX3 front end resources.
For Cascaded Storage Groups, users may set up a cascaded SG configuration where there are
optional limits assigned to each individual child SG. The parent SG may also have its own
assigned limit. The sum of child limits may exceed the parent’s limit; however, the I/O rate of all
child SG’s combined will remain limited by the parent’s limit. Also, the individual child SG limits
may not exceed the parent’s assigned limit.
Host I/O distribution is governed by the Dynamic Mode setting. The default mode is Never which
implies a static even distribution of configured limits across the participating directors in the port
group. The ‘OnFailure’ mode causes the fraction of the configured Host I/O limits available to a
configured port to be adjusted, based on the number of ports that are currently online. Setting
the dynamic distribution to ‘Always’ causes the configured limits to be dynamically distributed
across the configured ports, allowing the limits on each individual port to adjust to fluctuating
demand.
As an example if the mode is set to ‘OnFailure’ in a two-director port group which is part of a
masking view, both directors are assigned half of the total limit. If one director goes offline, the
other director will automatically be assigned the full amount of the limit, making it possible to
insure the application running at full speed regardless of a director failure.
Only one limit can be set per storage group, and devices in multiple storage groups can only
adhere to one limit.
At any given time, a storage group with a Host I/O Limit can be associated with, at most, one
port group in any provisioning view. This means if the storage group with a Host I/O Limit is in a
provisioning view with a port group, the storage group and port group combination have to be
used when creating other provisioning views on the storage group.
In most cases, the total Host I/O Limits may only be achieved with proper host load balancing
between directors (by multipath software on the hosts, such as PowerPath).
Host I/O limits can be set with the symsg command when the SG is created or on an existing SG.
Options:
-bw_max – Limits the bandwidth specified in Megabytes per sec. The valid range for bandwidth is
from 1 MB/Sec to 100,000 MB/Sec. NOLIMIT removes any set limits.
-iops_max – Limits the I/Os per sec. The valid range for IOPs is from 100 IO/Sec to 2,000,000
IO/Sec and must be specified in units of 100 IO/Sec. NOLIMIT removes any set limits.
-dynamic – Sets the mode for the dynamic I/O distribution we had discussed earlier in this lesson.
NEVER is the default.
Port groups contain front-end director and port identification. A port can belong to more than one
port group. On VMAX3 arrays running HYPERMAX OS you cannot mix different types of ports (i.e.
physical FC ports and virtual FC ports) within a single port group. Ports must have the ACLX flag
enabled – as discussed before ACLX flag is enabled by default.
Ports can be added and removed. When a port group is no longer associated with a masking view,
it can be deleted.
The SYMCLI example shown creates a new PG named PG_1 containing two front-end ports.
details and options while creating and managing port groups with the symaccess command.
These are some of the operations commonly performed on a Port Group. Port Groups can be
renamed if needed. Please refer to the EMC Solutions Enabler V8.0.1 Array Management CLI User
Guide for more details and options while creating and managing port groups with the symaccess
command.
An initiator group is a container of one or more host initiators (Fibre WWNs). Each VMAX3 initiator
group can contain up to 64 initiator addresses or 64 child IG names. Initiator
groups cannot contain a mixture of host initiators and child IG names. Thus an IG contains only
host initiators or an IG contains only child IG names.
You cannot mix different types of initiators (i.e. external Fibre Channel WWNs and internal guest
Fibre Channel WWNs) within a single Initiator Group. In addition, all child IG names added to a
parent initiator group must contain the same Initiator type.
You can create an initiator group using the HBA’s WWN or a file containing WWNs or another
initiator group name. Use the -consistent_lun option if the devices of a storage group (in a view)
need to be seen on the same LUN on all ports of the port group. If the
-consistent_lun option is set on the initiator group, HYPERMAX OS will make sure that the host
LUN number assigned to devices is the same for the ports. If this is not set, then the first
available LUN on each individual port will be chosen.
details and options while creating and managing initiator groups with the symaccess command.
These are some of the operations commonly performed on a Initiator Group. Initiator Groups can
be renamed if needed. Please refer to the EMC Solutions Enabler V8.0.1 Array Management CLI
User Guide for more details and options while creating and managing initiator groups with the
symaccess command.
A Masking View is created by associating one initiator group, one port group and one storage
group. So a masking view is a container of a storage group, a port group, and an initiator group.
When you create a masking view, the devices in the storage group become visible to the host.
The devices are masked and mapped automatically. Please refer to the EMC Solutions Enabler
V8.0.1 Array Management CLI User Guide for more details and options while creating and
managing masking views with the symaccess command.
These are some of the operations commonly performed on Masking Views. Note that the
symaccess backup command will back up the entire VMAX3 masking database.
details and options while creating and managing masking views with the symaccess command.
This lesson covered an overview of auto-provisioning groups and Host I/O limits. We also
introduced the SYMCLI syntax to manage auto-provisioning groups.
This lesson covers host considerations related to storage provisioning. We will look at HBA flag
settings and the commands to rescan the SCSI bus on common server platforms.
In an earlier module we set the required SCSI and Fibre port settings at the VMAX3 Array Port
Level. These are the common SCSI bus and Fibre port settings used by the common operating
systems. The port flags settings can be overridden at the initiator or initiator group level.
VMAX3 arrays allow you to set the HBA port flags on a per initiator or initiator group basis. This
feature allows specific host flags to be enabled and disabled on the director port.
To set (or reset) the HBA port flags on an initiator group, use the following SYMCLI syntax:
symaccess -sid <SymmID> -name <GroupName> -type initiator
set ig_flags <on <flag> <-enable |-disable> |off [flag]>
A flag cannot be set for the group if it conflicts with any initiator in the group.
After a flag is set for a group, it cannot be changed on an initiator basis.
details on overriding port flags with the symaccess command.
After VMAX3 devices have been provisioned to a host by the creation of a masking view, the
operating system on the host must be made to recognize the device. To accomplish this a SCSI
bus rescan must be initiated from the host. The bus rescan commands vary from operating
system to operating system.
The commands shown here are taken from the EMC Host Connectivity Guides. While they work
reliably in most cases, they may not work for every version of a particular operating system. That
is why it is advisable to verify the accuracy of these commands by checking the vendor
documentation.
Since there are several flavors of commercially available Linux, there are a variety of ways that
the SCSI bus on those systems can be rescanned. The methods documented here are taken from
the Linux host connectivity guide.
In addition to the vendor supplied commands, EMC also has some commands in Solutions Enabler
that are designed to scan the SCSI bus. The EMC commands are convenient to use but the vendor
supplied commands are the most reliable.
The CLI commands shown here are useful for rescanning the SCSI bus. The preferred method of
using vCLI (esxcli) is to run it on a host that is network attached to the ESXi console. In addition,
the VMware vSphere GUI can be used to rescan the SCSI bus.
In the event a host adapter fails, or needs replacement, you can replace the adapter and assign a
set of devices to a new adapter by using the replace action in the following form:
symaccess replace -wwn wwn -new_wwn NewWWN [-noprompt]
symaccess replace -iscsi iscsi -new_iscsi NewiSCSI [-noprompt]
This lesson covered host considerations related to storage provisioning. We looked at HBA flag
settings and the commands to rescan the SCSI bus on common server platforms.
This lesson covers SLO based provisioning of VMAX3 storage using Unisphere for VMAX. We will
show how Unisphere is used to manage auto-provisioning groups. We also show the use of the
Storage Provisioning Wizard which greatly simplifies storage allocation.
In Unisphere for VMAX, initiator groups are called Hosts. The hosts currently configured can be
listed by clicking on the Hosts section button.. From Hosts view you can create new Hosts, Host
Groups (cascaded initiator groups) or click on a Host and Provision Storage to the Host, set flags,
delete, or view its details. The detailed view of a Host allows further actions. Hovering on the
Hosts section button will also show the Create Host and Create Host Group common tasks. The
Create Host button or Create Host common task launches the Create Host Wizard.
In order to provision storage to a Host we first use the Create Host Wizard to create the initiator
group for the Host. The Create Host wizard is available as a Common Task under the Hosts menu
or by clicking on the Create Host button in the Hosts view.
Click on the Create Host link to launch the Wizard. Then select the WWNs of the HBAs of your
host and click on the Add button to add them to the list.
In this example our Host has already been zoned to the VMAX 3 array and the WWNs of our host
are listed and can be chosen. If a host is yet to be zoned you can type in the WWN into the Add
Initiators field.
You can optionally click on the Set Host Flags button to override any port flag settings.
This is continuation of the Create Host Wizard. To set host flags you can click on the Set Host
Flags button. In this example we want consistent LUNs so we have checked the Consistent LUNs
box. You can choose to override any of the other port flags listed as well. In this example we are
not doing any overrides. Click on OK to close the Set Host Flags dialog.
To complete Create Host process you can add the task to a Job List or choose to Run Now.
To view the details of a Host select the host in the host list view and click on View Details. The
Host has two initiators and no Masking views. The Consistent LUNs option is enabled.
From the detailed view of the Host you can Provision Storage to Host, Set Flags, Delete or Modify
the same. The Related Objects frame has various links depending on the Host. Clicking on the
Initiators link will show a listing of the initiators in the host.
The Modify button allows one to add or remove initiators from an existing Host. Modify Host can
be launched from the detailed view of a Host or from the hosts listing page.
To remove an initiator select the initiator from the lower half of the dialog box and click on
Remove. To add a new initiator select an available initiator or type in the WWN in the Add
initiators field and click on Add. Then Run Now or Add to Job List.
The Provision Storage to Host wizard simplifies the process of provisioning storage to a host. The
wizard will create the desired storage groups, port group and masking view. The storage groups
are created with the required service levels, workload type and capacity. The wizard can create
stand alone storage groups or cascaded storage groups. The wizard is typically launched from the
context of a host (initiator group), either from the hosts listing or the detailed view of a host.
In this example the Storage Provisioning Wizard has been launched from the context of an
existing Host, hence the Host does not have to be specified. The title of the dialog includes the
host we are provisioning to – Provision Storage to sun-88-31.
Type in a name for the Storage Group to be created. Click on Add Service Level if this will be a
Cascaded Storage Group with Child Storage Groups. You can specify different Service Levels for
each child storage group.
If one desires to simply create a Storage Group with devices then all one has to do is to specify
the Service Level, Workload Type, Number of Volumes and Capacity.
In this example the Add Service Level button was clicked once. This created two request entries
as shown.
Type in the desired name for each of the Child Storage Groups. In this example one is named
sun-88-31_app1 and the other sun-88-31_app2.
Use the Service Level Pick list to choose the desired SLO. In this example we will choose the
Platinum SLO for the app1 child SG.
Use the Workload Type pick list to choose the desired workload type. In this example we will
choose the OLTP for the app1 child SG.
Finally enter the desired number of volumes and the volume capacity for each storage group and
then click Next. We can see that we have created the request for two child storage groups. We
have set the desired service level, workload type, number of volumes and volume capacity for
each. The Avg. Response time column indicates the expected response time for the selected
service level and workload type. The volume capacity units can be specified in TB, GB, MB or Cyl
by clicking on the units selector.
You can also set the Host I/O Limits if needed.
To set Host I/O Limits click on the Set Host I/O Limits button. Set the desired values in the Host
I/O limits dialog and click OK to return to the Provisioning wizard. Then click Next.
In the Select Port Group screen you can choose an existing Port Group or create a new one. In
this example we are creating a new Port Group – edit the name of the new port groups as
needed. Click Next.
Note that ports that an HBA are zoned to show up automatically. You can click on the “Include
ports not visible to the host” to show all ports and choose them if necessary.
The wizard will show the Port Group recommendation dialog if the port selections do not match
the recommendation. In our example we had chosen only two ports in the port group, hence the
recommendation dialog pops up. Click OK to dismiss the dialog and continue with the provisioning
process.
On the review page click on the Run Suitability Check button to see if the array can meet the
Service Level Objectives for the provisioning request. In order for the Suitability check to work
the VMAX3 arrays must be registered for performance data collection. The review screen also
shows the names of the Storage Group, Host and Port Group. The Masking View name can be
edited as needed.
In this example the green check mark indicates that Service Level Objective for provisioning
request will be met.
Click the Add to Job List to add the Provisioning request to the Job List.
The Job has been successfully executed. The provisioning task will either find existing devices or
create new devices as needed to satisfy the provisioning request.
To see a listing of all masking views click on Masking View in the Hosts menu.
The new masking view sun-88-31_mv is listed. Select the masking view and click View
Connections to see detailed information about the view.
Storage group management is done via the Storage Groups Dashboard. Click on Storage section
button to see the Storage Groups Dashboard. The dashboard displays SLO Compliance, a listing of
Storage Groups and the Demand Report for the various SLOs. In this lesson we will focus on
managing storage groups. Click the Total icon in the top left to navigate to the Storage Groups
listing.
Click the Total Icon in the Storage Groups Dashboard to see a listing of all the Storage Groups.
From this view you can create new storage groups, modify storage groups, provision an existing
storage group to a host, view details, set Host I/O limits etc.
New storage groups can be created either by clicking on the Create SG button in the storage
groups listing page or clicking on the Provision Storage to Host common task in the Storage
section menu. Both will launch the Provisioning wizard shown on the screen. This wizard is
identical to the wizard we saw earlier in this lesson, the only difference is that one has the ability
to choose the host to which this storage should be provisioned as well.
To modify a storage group, select a storage group from the storage group listing and click on
Modify to launch the Modify Storage Group dialog. Note that for cascaded storage groups, the
dialog will always show the parent and child storage groups even if the modify button is clicked
from the context of one of the child storage groups.
You can make the desired changes, i.e., Change Service Level, Workload Type or add more
volumes, or add a new child by clicking on add Service Level.
You can run the Suitability Check when modifying storage groups. Once the desired changes are
made add the job to the job list or run now.
To set Host I/O Limits, select a storage group from the storage group listing and click on the more
button (>>) and then choose Set Host O/O Limits to launch the dialog. Note that for cascaded
storage groups, you can choose different Host I/O Limits on the parent and children.
Once the desired changes are made add the job to the job list or run now.
To view the details of a storage group, select a storage group from the storage group listing and
click on View Details. The detailed view of the storage group shows detailed information on the
storage groups and has links to the related objects and to the performance views. The related
objects has various links depending on the storage group. It will show the Volumes link – clicking
on the volumes link will list the volumes in the storage group. Other possible related objects are,
Child Storage Group (for a parent SG), Parent Storage Group (for a child SG), Masking View if the
SG in in a masking view, SRP if the SG is a child SG or a standalone SG.
You can also modify the SG or provision this SG to a host from this view. Host I/O limits can also
be set.
Choose Port Groups in the Hosts section to show the list of Port Groups currently configured on a
VMAX3 array. From this view, you can create new port groups or click a port group and delete or
view its details. The detailed view of a port group allows further actions.
To create a port group, click the Create Port Group button in the Port Groups view.
In the Create Port Group dialog, type a name for the port group and select ports from the
available list.
Click OK to complete the creation of the port group. The new port group will be listed in the Port
Groups view.
To see the details of a specific port group, select it in the Port Groups view and click View Details.
You can Delete the port group from the detailed view. The details view also shows Host I/O Limit
related information.
The Related Objects frame has various links depending on the port group. All port groups will
have the Ports link. Clicking the Ports link will show a listing of the ports.
The other possible related object is Masking Views – This link will appear if the port group is part
of one or more Masking views.
Clicking the Ports link in the Related Objects frame of a port group will show the ports listing.
You can remove a port from the port group by selecting the port from the list and clicking
Remove.
To add ports to the port group, click Add Ports.
In Unisphere for VMAX, Masking View management is done from the Masking Views page. Select
Masking View in the Hosts section to show the list of Masking Views currently configured on a
VMAX3 arrays. From this list, you can create new masking views or click a masking view and view
its details, view its connections, or delete the same. The detailed view of a masking view allows
further actions.
As we have already see the Provisioning Wizard will create masking views as part of the
provisioning process as well. Creating a masking view from this page requires the manual
selection of Host, Storage Group and Port Group.
As we have already seen, the Provisioning Wizard will create masking views as part of the
provisioning process. However you can choose to manually create a masking view by clicking on
the Create Masking View button in the masking view listing.
Creating a masking view requires the manual selection of Host, Port Group, and Storage Group.
The Host, Port Group and Storage Group must already exist.
In the Create Masking View dialog, type a name for the Masking View and pick an Initiator Group,
Port Group, and a Storage Group from the list of available groups. Optionally click the Set
dynamic LUNs button if you want to change the host LUN address. The Starting LUN number
should be specified. Click OK to close the LUN address dialog.
Click OK to complete the creation of the masking view. The new masking view will be listed in the
Masking Views page.
The masking view connections page allows you to see all the components that make up the
masking view. The connections page contains three tree lists for each of the component groups in
the masking view - initiators, ports, and storage groups.
The parent group is the default top-level group in each expandable tree view and contains a list of
all components in the masking group including child entries which are also expandable.
To filter the masking view, single or multi-select (hold shift key and select) the items in the list
view. As each selection is made, the filtered results table is updated to reflect the current
combination of filter criteria.
This view can be extremely useful for troubleshooting. As an example, you could filter the view by
choosing only one of the initiators and one of the ports and see which of the initiators is logged in
to the array.
To see the details of a specific masking view, select it in the Masking Views listing and click View
Details.
Click the Delete button to delete the masking view. The Related Objects frame has links for Host,
Port Group, Storage Group, and Volumes.
Clicking these links will show a listing of those objects.
In this demo the Unisphere for VMAX Storage Provisioning wizard will be used to perform SLO
based provisioning to an open systems host.
This lesson covered SLO based provisioning of VMAX3 storage using Unisphere for VMAX.
Management of auto-provisioning groups with Unisphere was covered. We also showed the use of
the Storage Provisioning Wizard which greatly simplifies storage allocation.
This lesson covers SLO based provisioning of VMAX3 storage using SYMCLI. We illustrate with an
example scenario.
We will illustrate the storage provisioning with SYMCLI with the use of an example scenario. In
this example we have an application server configured with two HBAs that required storage for
two different applications. The service level requirements for the two applications are different.
The server HBAs have already been zoned to a VMAX 100K array. To satisfy the requirement of
different service levels we will provision storage to this server by using cascaded storage groups.
We will perform these high level steps in the next few slides.
Zoning of the HBAs to the ports can be confirmed by looking at the switch. In this example we
use the symaccess list logins command to confirm that the servers HBAs have been zoned to the
ports of the VMAX3 array.
We see that WWN 2100001b321e9dd5 is zoned to 1D:6 and WWN 2101001b323e9dd5 is zoned
to 2D:6.
We first create a file with the WWNs of the initiators. Then we create the initiator group with the
consistent LUN option. We confirm the creation of the initiator group.
We can use the symaccess show command to confirm that the initiator group has the correct
WWNs
We create a port group call app_server_pg with ports 1D:6 & 2D:6. We then examine is contents
with the symaccess show command.
We use the symdev list command with the –notinsg option to list devices on the array which are
not in any storage groups. The output shows us a listing of devices of such devices.
The questions marks in the SA:P columns also indicate that these devices are not mapped to any
front-end port. So we can safely assume that these devices are unused.
We use devices 0063:0066 for building the required storage groups.
The storage groups are built as shown on the slide. Each child storage group is given the
appropriate SLO and WL and populated with two devices. The parent storage group is populated
with the two child storage groups.
The symsg list –detail command shows the storage groups we just created. We also see that the
child storage groups have the correct SLO and WL type set. We also see that the child SGs are
shown as FAST managed while the parent is not shown as FAST managed.
Legend:
Flags:
Device (E)mulation A = AS400, F = FBA, 8 = CKD3380,
9 = CKD3390, M = Mixed, . = N/A
(F)ast X = Fast Managed, . = N/A
(M)asking View X = Contained in Mask View(s), . = N/A
Cascade (S)tatus P = Parent SG, C = Child SG, . = N/A
Host IO (L)imit D = Defined, S = Shared, B = Both, . = N/A
We finally create the masking view with the initiator group, port group and the parent storage
groups we had recently created. We can now go to the application host and perform a SCSI bus
scan to discover the newly provisioned devices.
The symaccess show view command shows us the details of the masking view. The output is long
so we have broken the display over three slides.
This slide shows the host initiators.
This slide shows the port details.
This slide shows the storage group details.
A SCSI rescan was performed on the application server. The syminq output shows the four VMAX3
devices that were provisioned to this server.
The REV 5977 is the HYPERMAX OS version. The 25 is the Ser Num column represents the last
two digits of the VMAX3 array SID. The other highlighted column shows the VMAX3 logical volume
numbers of 63:66.
In this example we will set Host/IO limits on a parent SG. We have set a bandwidth limit in this
example, we have also set the dynamic distribution to always.
The symsg list command shows the storage groups. We can see that that Host I/O limits are
defined on the parent indicated by the D in he L column. The S in the L column of the child SGs
indicate that the children are currently sharing Host I/O limits, there is no explicit setting for the
children.
Legend:
Flags:
9 = CKD3390, M = Mixed, . = N/A
In this example we are explicitly defining Host I/O limits on a child SG. There is an explicit setting
on the parent as well. We have set a bandwidth limit in this example – this is less than that of the
parent. The show output shows us that the bandwidth limit for this SG is 100 while that on the
parent is 200.
The symsg list command shows the storage groups. Here we see that the app2 storage group
shows a B in the L column indicating that Host I/O limits are defined both on the parent and the
child.
Legend:
Flags:
9 = CKD3390, M = Mixed, . = N/A
You can execute symsg list –demand –by_pg command to view quota information sorted by
port group. The –pg option limits the output to the specified port group. The –v option is
supported for further detail.
The columns display all the available capacity and IOPS quotas and bandwidth quotas enforced
within port groups.
You can execute symsg list –demand –by_port command to view quota information sorted by
front-end director ports. The –pg option limits the output to the ports in the specified port group.
The –v option is supported for further detail.
The columns display all the available capacity and IOPS quotas and bandwidth quotas enforced by
front-end directors.
VMAX3 arrays running HYPERMAX OS allow moving devices from one SG to another SG without
disrupting host visibility for the devices. Moving a device to another SG will not disrupt the host
visibility for the device, if any one of the conditions are met:
Moves between child SGs of a parent SG, when the view is on the parent SG.
Moves between SGs when a view is on each SG, and both the initiator group (IG) and the port
group (PG) are common to the views.
Moves between SGs when a view is on each SG, and they have a common IG. They have different
PGs but the same set of ports or the target PG is a superset of the source PG.
Moves when source SG is not in a masking view.
If none of the conditions are met, the operation will be rejected, but the move can be forced by
specifying the '-force' flag. Note that forcing a move may affect the host visibility of the device.
Devices moves between FAST managed SG(s), or between a FAST managed SG and a non-FAST
managed SG, is permitted.
The symsg syntax is shown on the slide.
VMAX3 arrays running HYPERMAX OS allows the conversion of a standalone SG to Cascaded SG or
a Cascaded SG to a standalone SG to be performed non-disruptively. This allows FAST-Managed
storage groups containing devices with a single Service-Level Objective (SLO) to be expanded to
include devices in a second SLO, without disrupting the availability of those devices from host
applications.
To convert a standalone storage group to a cascaded configuration, the command supplies the
name of the standalone storage group to be converted and the name of the new child storage
group. Upon successful completion, the parent storage group retains the name of the standalone
group and the child storage group is given the new child name. If the storage group starts in one
or more masking views, at the end of the operation all of the views will be moved to the parent
storage group. If the storage group starts with Host I/O Limits configured, these limits can be
migrated to the parent storage group or to the child storage group. If the storage group starts as
FAST-Managed, at the end of the conversion only the child storage group will be FAST-Managed.
To convert a cascaded storage group to a standalone configuration, the command supplies the
name of the parent storage group to be converted to a standalone storage group. Note that this
conversion is allowed only if the cascaded SG has a single child SG. Upon successful completion,
the standalone storage group retains the name of the parent group. If the parent storage group
starts in one or more masking views, at the end of the operation all of the views will be moved to
the standalone storage group. If the parent storage group starts with Host I/O Limits configured,
these limits will be migrated to the standalone storage group. If the child storage group starts as
FAST-Managed, the standalone storage group will become FAST-Managed.
The “symsg convert –cascaded” command allows the non-disruptive conversion of a standalone
storage group to a cascaded storage group consisting of a parent SG and a single child SG. If the
standalone storage group has a Host IO Limit, then the user must specify if after the conversion
the limit will be set on the parent or the child storage group.
The “symsg convert –standalone” command allows the non-disruptive conversion of a cascaded
storage group consisting of a parent SG and a single child SG to a standalone storage group. If
either the parent SG or the child SG has a Host IO limit defined, it will be set on the standalone
SG. But if both parent and child SGs have a Host IO Limit, the user must supply the host_IO
option.
In this demo SYMCLI will be used to perform SLO based provisioning to an open systems host.
This demo covers Cascaded Storage Groups, moving devices non-disruptively between storage
groups and changing the SLO on storage groups.
This demo covers the management of Host I/O Limits.
This lesson covered SLO based provisioning of VMAX3 storage using SYMCLI. We used an example
scenario to illustrate the use of cascaded storage groups and the setting of Host I/O limits.
This module covered storage allocation of VMAX3 storage to hosts using auto-provisioning groups.
An overview of auto-provisioning groups, Host I/O limits and host considerations while allocating
storage was presented. SLO based storage provisioning with Unisphere for VMAX and SYMCLI was
covered in detail.

Storage Allocation Using Auto Provisioning

Uploaded by

Copyright:

Available Formats

Storage Allocation Using Auto Provisioning

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Storage Allocation Using Auto Provisioning

Uploaded by

Copyright:

Available Formats

This module focuses on storage allocation if VMAX3 storage to hosts using auto-provisioning

One of each type of group is associated together to form a Masking View.

A child SG cannot be deleted until it is removed from its parent SG.

symaccess -sid <SymmID> -name <GroupName> -type initiator

set ig_flags <on <flag> <-enable |-disable> |off [flag]>

After a flag is set for a group, it cannot be changed on an initiator basis.

symaccess replace -wwn wwn -new_wwn NewWWN [-noprompt]

symaccess replace -iscsi iscsi -new_iscsi NewiSCSI [-noprompt]

You can also set the Host I/O Limits if needed.

To add ports to the port group, click Add Ports.

Clicking these links will show a listing of those objects.

We use devices 0063:0066 for building the required storage groups.

Device (E)mulation A = AS400, F = FBA, 8 = CKD3380,

9 = CKD3390, M = Mixed, . = N/A

(F)ast X = Fast Managed, . = N/A

(M)asking View X = Contained in Mask View(s), . = N/A

Cascade (S)tatus P = Parent SG, C = Child SG, . = N/A

Host IO (L)imit D = Defined, S = Shared, B = Both, . = N/A

This slide shows the host initiators.

This slide shows the port details.

This slide shows the storage group details.

Device (E)mulation A = AS400, F = FBA, 8 = CKD3380,

9 = CKD3390, M = Mixed, . = N/A

(F)ast X = Fast Managed, . = N/A

(M)asking View X = Contained in Mask View(s), . = N/A

Cascade (S)tatus P = Parent SG, C = Child SG, . = N/A

Host IO (L)imit D = Defined, S = Shared, B = Both, . = N/A

Device (E)mulation A = AS400, F = FBA, 8 = CKD3380,

9 = CKD3390, M = Mixed, . = N/A

(F)ast X = Fast Managed, . = N/A

(M)asking View X = Contained in Mask View(s), . = N/A

Cascade (S)tatus P = Parent SG, C = Child SG, . = N/A

Host IO (L)imit D = Defined, S = Shared, B = Both, . = N/A

Moves when source SG is not in a masking view.

The symsg syntax is shown on the slide.

You might also like