VMAX3 Commands
Configuring Storage Pools
The VMAX3 is much easier to configure than previous types of Symmetrix. Most of the work is already done for you as the box comes pre-configured, with all physical drives in the array already placed in Storage Resource Pools (SRPs), managed by Fully Automated Storage Tiering (FAST) and ready for you to use.
If you want to know what is going on under the covers, then physical disks of the same physical type, RAID configuration and performance characteristics are combined into Disk Groups. Disk groups with the same RAID level and emulation type are combined into thin data pools, and then the data pools are combined into an SRP. Data is then allocated and moved around within the SRP by FAST software, depending on its performance requirements. You can have up to 5 SRPs, but EMC recommends that you just have one, unless you need to physically isolate data for regulatory or performance reasons.
So all you need to do, is to define storage groups and allocated them to applications. You can define 16,384 storage groups, so it is quite reasonable to define one for every one of your applications. To define a storage group, use the symsg command:
symsg -sid 038 create app1_sg -slo silver -workload oltp
The storage group name can have of up to 64 alphanumeric characters, hyphens (-), and underscores (_) and the names are not case sensitive.
The -slo parameter is for the service level objective. You use this to tell FAST what average response time you want to see for this storage group. Options are Diamond, Platinum, Gold, Silver, and Bronze, and also the default, Optimised, which has no explicit response time target associated with it.
The -workload or -wl parameter defines what type of workload you expect for this storage groups. Options are 'oltp', which is small blocks IO, 'oltp_rep' which is oltp with replication, 'dss', which is large blocks IO, 'dss_rep' which is dss with replication and 'none' which is the default and means just let FAST work out what type of IO is running.
If you want to list out these SLO's complete with expected response times, then run the command.
symcfg list -slo -detail -by_resptime -all
If you have more than one SRP, then you simply add the -srp parameter to select the SRP you want this storage pool to be in. If you want to know what SRPs are defined, use the command
symcfg list -srp
Now you need to add some capacity to your new storage pool. Use the command
symconfigure -sid 038 -cmd "create dev count =10 config=tdev, emulation=fba size=2048 GB sg=app1_sg;" preview
This will add 10 thin devices each of 2048GB in fba emulation. Note that as they are thin devices, they do not use any space initially and will grow up to 2048GB as data is added. Also, we did not need to define any Meta devices!
Now you need to present your data to a host with a masking view by using command
symaccess -sid 038 create view -name app1_mv -sg app1_sg -pg app1_pg -ig app1_ig
If you decide later that this storage group needs a higher SLO and at the same time, let FAST analyse the IO and decide the best action to take, then you can change it easily with a command like this:
symsg -sid 038 -sg app1_sg set -slo Gold -wl none
Listing Commands
To get some information about existing SRPs and storage groups, try these commands
symsg list -srp -demand -type slo
This command will give you capacity usage data, detailing how much of your SRP capacity is being used by each of the SLO. It will also give usage data for DSE and Snapshots - more about these later.
Symsg list -by_SLO -detail
This command lists out the storage groups and shows if they are associated with an SLO.
symcfg list -srp -demand -type sg
VMAX data is thin provisioned and so each storage group will have 2 capacities, the amount of space they are actually using and the amount they can potentially grow to. This command will list out both capacities for each storage group. There is also a SnapShot Allocated (GB) Column, which can be used to identify storage groups that are using an excessive amount of snapshot space. So now it is time to talk about snapshots
Snapshots
The DMX3 uses TimeFinder SnapVX, usually just called SnapVX. SnapVX uses Redirect-On-Write (ROW) technology, which is new to TimeFinder. When an update is made to a source track, this update is asynchronously written to a new location in the SRP, and the original data is preserved for the snapshot. Pointers are used to make sure that each copy of the track is used by the correct data. SNAPVX snapshots do not require target volumes and in nocopy mode they will only use extra space when the source volume is changed. A single source volume can have up to 256 snapshots, and these snapshots also save space by sharing point-in-time (PIT) tracks, or 'snapshot deltas'. The snapshot deltas are stored in the SRP alongside the source volume and each snapshot has a set of pointers that reference the set of snapshot deltas that are needed to preserve a PIT image.
Now earlier I suggested that you define a storage group for each application. It is also possible to group storage groups together, so that one parent storage group has a number of associated child storage groups. Each child can have its own SLO (and in fact the parent group cannot be associated with an SLO). The beauty of this arrangement is that you can snap entire storage groups, or sets of storage groups with a single command, and the snap by definition will be PIT consistent. You can then define a linked target volume to make this snapshot accessible to a host, which then makes consistent PIT copy of an entire application available for offline backup, or for testing purposes.
If you define your Linked Target Volume to be in Copy Mode, then the snapshot will copy all the data in the background and create a complete set of application data.
So to create a snapshot, you use the symsnapvx establish command. Here, we take a snapshot of our app1_sg storage group, call it daily_snap, and keep it for 7 days.
symsnapvx -sid 038 -nop -sg app1_sg establish -name daily_snap -ttl -delta 7
To access this snapshot, you need to link a host mapped target volume to the snapshot data. The links may be created in Copy mode (by adding -copy after the link command) for a permanent copy of the target volume, or in default Nocopy mode for temporary use.
symsnapvx -sid 038 -sg app1_sg -snapshot_name daily_snap link -lnsg snaptarget
You can restore your original source volume from a snapshot with the symsnapvx restore command
symsnapvx -sid 038 -sg app1_sg -snapshot_name daily_snap restore
If you run the same snap create command twice, SnapVX will create a new snapshot with the same name, but a different generation number. To get some information about your snaps you can try the following command, which will list all existing snapshots, with generation numbers, space used and expiry dates.
symsnapvx -sid 038 list -sg app1_sg -detail
Older VMAX and Symmetrix SYMCLI commands
symcfg
Before you can do anything with a VMAX, you need to install the Solution enabler software, which you can get from powerlink.emc.com. You download the software, unzip or untar it, run the emc-install program and get the product licensed.
Now you have your software, but you need to run an initialisation command before you can connect to your DMX. Navigate to /usr/symcli/bin and run;
symcfg discover
symcfg list
The first command gets information from the DMX and uses it to build a configuration database on your host. The second command lists that information out.
However symcfg is a very powerful command that can be used to display and alter the configuration of a VMAX. My preference is to use symconfigure for most of this, but symcfg can be used to manage VMAX locks, RDF and director ports, gatekeeper devices, hosts and host ports, mainframe connections, and more.
Discover all VMAX arrays connected to this host, then build or refresh the Symmetrix configuration database file using this information:
symcfg discover
Display information held in the Symmetrix configuration database about all attached Symmetrix arrays
symcfg list
Display more detailed information about the attached Symmetrix arrays and their directors
symcfg list -v -dir all
Display detailed information about a specific director, in this case 0E
symcfg list -v -dir 0E
Display information about all front-end directors on Symmetrix array 824
symcfg list -SA ALL -sid 824
Display information about all the registered hosts that are connected to the Symmetrix array 824
symcfg list -connections -sid 824
To list all gatekeeper and database access locks, enter:
symcfg list -semaphores
To verify whether the Symmetrix 824 configuration and the Symmetrix configuration database are in sync, enter:
symcfg verify -sid 824
list the port flags for port 0 on director 5 position A
symcfg -sid 38 list -sa 5A -p 0 -v
Take the above port offline (necessary to change port flags - and remember this could make storage unavailable to users so use with caution)
symcfg -sid 38 offline -sa 5A -p 0
enable port flag vcm-state on the above port
symcfg -sid 38 set port 5A:0 vcm-state=enable
put the port back online
symcfg -sid 38 online -sa 5A -p 0
symconfigure
The symconfigure command lets you make changes to your Symmetrix device, for example to add new volumes, add or change port and host assignments and configure remote mirroring RDF devices. It updates the symm.bin file on the symm. device. The command cannot be shortened, symcfg is a different command
As part of making changes, symconfigure lets you save the current configuration, reserve devices to prevent others from using them, and gives you a number of query, list and verify options to check the current status of a symmetrix and validate any proposed changes before applying them.
You run symconfigure from a host server that is connected to the symmetrix, If anything happens to that host or the connection to the symm. while a change was in progress then the symm. could be left in an indeterminate state. To cater for this scenario, symconfigure has an abort option that lets you back out uncompleted changes.
symconfigure itself has a fairly small set of parameters, it does most of its powerful processing by reading a command file. The simplest command is symconfigure -h, the online help facility. The other symconfigue commands require a -sid parameter which identifies the Symmetrix that you are going to change. Before you want to start to make changes you will probably want to see your existing Symmetrix configuration.
If the query command shows that a hung session exists, then no more updates will be possible as any session puts a lock 15 on the symm.
Checking VMAX status using symconfigure and managing reserves
These examples commands are running against a VMAX with a symmetrix ID of 123
Query VMAX 123 to see what total freespace is available
symconfigure -sid 123 -freespace -unit mb list
Display the version number of the SYMCLI, SYMAPI and the configuration server. -sid is optional, leave it off and the versions for all attached symms are displayed.
symconfigure -sid 123 -version -v
The query command will check for any existing active configuration activity. If this command cannot get the information, it will keep retrying. You can control this with the -i and -c options which are interval between retries and number of retries.
Query a VMAX 8 times at 5 second intervals to see if any updates are running
symconfigure -sid 123 -i 5 -c 8 -v query
Query a VMAX for reserves
symconfigure -sid 123 -reserved list
Query a given reserve to get more details
symconfigure -sid 123 -reserve-id 4567 show
Safely attempt to release reserve 4567
symconfigure -sid 123 -reserve-id 4567 -noprompt release
Symconfigure examples using the command file
If you are planning updates to your VMAX configuration, then generally the best way to do this is to put all your updates into a command file, then run that file through the symconfigure command. The advantages of doing this is that you can get your commands peer checked by a colleague and syntax checked by the system before you run them. Each command has three options,
'preview' which checks the syntax of your command list;
'prepare', which also checks your syntax, then checks that the VMAX is in a healthy enough state to process the commands, with enough free resources to process the command,
'commit' which does the first two, then applies the updates.
The basic syntax for running symconfigure updates using a command file called command.txt is
symconfigure -sid 123 -v -file command.txt preview
symconfigure -sid 123 -v -file command.txt prepare
symconfigure -sid 123 -v -file command.txt commit
Some optional parameters are -noprompt which suppresses the 'do you really want to ...' messages and -v for verbose which means echo results back to the terminal
Command file examples
Changing devices
Create 2 small Gatekeeper devices. Gatekeepers are used to communicate with the VMAX. EMC recommends 4 gatekeepers per port and they are typically created with just 6 cylinders.
create dev count=2 size=6 emulation=fba;
Create 20 bigger Standard devices
create dev count=20,
SIZE=50 GB,
eMulation=FBA;
Note that the commands are not case sensitive, parameters can be separated by commas or spaces, can span more than one line, can contain extra white space, but must end with a semicolon ';' .
Add 6 a new spare devices
create spare count=4, format = 520;
Older symmetrix devices has 512 bytes in a block, new devices have 520 bytes in a block.
To delete disks use
delete dev Device-name
Working with Metas
EMC split a physical device into between 1 and 128 hyper volumes, which are then combined together to form meta devices. A meta corresponds to a LUN as presented to a host, so a LUN can be bigger than a physical device. A meta-device can consist of up to 1024 hypers, but all the hypers must be the same size and type and have the same protection. Valid hyper sizes range from between 0.5 and 32GB. A Meta can be concatenated, that is, it can consist of hypers strung together, or it can be striped, when the data is striped across the hypers. The first device in a meta is known as the meta head.
The starting point is to find any unmapped devices using the command symdev list -noport. If any of these devices are allocated as BCV pairs or defined to device groups, then split them out using commands like this
symmir -g group_name split
symmir -g group_name rmall
Examples of symconfigure command files working with metas
define a concatenated meta and add 2 more devices to it. Concatenated metas are best for sequential data access, and they are easier to gorw or shrink that striped metas.
form meta from device 028
config=concatenated;
add dev 015:016 to meta 028;
define a striped meta and add 2 more devices to it. Striped metas are best for random data access, but they can't be shrunk and are more difficult to grow.
form meta from device 02b
config=striped
stripe-size=1920;
add dev 017:018 to meta 02b;
Split meta 02b back into it's constituent hypers - this will destroy any data on the meta!
dissolve meta dev 02b;
remove device 016 from meta 028
remove dev 016 from meta 028;
Using SYMTIER to work with FAST tiering
Two types of FAST tier exist, disk provisioned virtual tiers and virtual provisioned storage tiers. 'Disk provisioned' is also split into static and dynamic. The following command will list all the storage tiers in array '123', including DiskGroup and Virtual Pool Tiers. If you just wanted to list DiskGroups or Virtual Pools you would add the switch -dp or -vp as appropriate.
symtier -sid 123 list
To get more detailed information about a specific tier use this command - obviously with your subsystem id and tier name.
symtier -sid 124 show -tier_name TEFD1
SYMTIER EXAMPLES
To work with FAST tiers, you need to be able to create and delete them, and also add and remove disks from them. The following command will create a static, disk provisioned pool called 'TSDP1', configured in RAID5, 3+1 format in disk array '123' from SATA disks. Alternative disk tecnology options are FC (Fiber Channel) or EFD (Enterprise Flash Drive). -dsk_grp is the disk groups to be added to the tier. In this case we are allocating a single disk group ID=2, but you can allocate a list of disk groups, and you can allocate them by name.
symtier -sid 123 create -name TSDP1 -inc_type static -tgt_raid5 -tgt_prot 3+1 -technology SATA -dsk_grp 2
This command will create a flash disk tier in RAID1 format. -vp means this tier will be allocated using virtual provisioning
symtier -sid 123 create -name TEFD1 -tgt_raid1 -technology EFD -vp
To add a disk group to an exisiting tier use the following command. This adds 'disk group 3' to existing Storage Tier 'TSDP1'.
symtier -sid 123 -tier_name TSDP1 add -dsk_grp 3
and to remove it again use
symtier -sid 123 -tier_name TSDP1 remove -dsk_grp 3
You can also rename a tier if you did not like the existing naming standard, so 'TSDP1' becomes 'Tier_qxy29p1'
symtier -sid 123 rename -tier_name TSDP1 -name Tier_qxy29p1
and finally, to delete a tier use this command.
symtier -sid 123 delete -tier_name Tier_qxy29p1
Examples of symconfigure command files for mainframe disks
Create a mainframe striped meta. This must include at least 4 meta devices. This example creates 4 * 500 cylinder metas, then uses them to create a 2000 cylinder striped CKD meta in a RAID1 configuration.
create dev count=4 size=2000
emulation=CKD-3390 config=2-way-mir
attribute=CKD-meta;
PAV aliases are used to allow multiple concurrent access to mainframe devices. See the PAV section for details. The following commands can be used to allocate PAV aliases. The first command will add 4 aliases to a specific symm. device. The second command allocates a range of aliases to a sub system
add pav alias to dev 02b alias count=4
add pav alias range 127:255 to mvs ssid=B000
Some other useful commands
symdev
One of the main uses of the symdev command is to see what free hypers are available. The command to do this is
symdev list -noport
symdev list -da all space
symdev list -meta
symdev show meta head address
The second command will show all backend space available
The third command will list out all the meta heads, and also tell you how many hypers are associated with each meta head.
The last command will list out all the details for one meta. The show command usually gives more detail than list, as it reads its information from the host database.
symapierr
Returns a string with a detailed description of any return code generated by any SYMAPI function
To return a string for error number 10, enter:
symapierr 10
The following will be output:
SYMAPI Error Symbol : SYMAPI-C-NO-DEVS-FND-UPGRADE
SYMAPI Error Message: No Symmetrix devices found with microcode version 5x63 or up.
syminq
This command checks which devices are mapped to a host
To work out directory and port mappings enter:
syminq -pdevfile