Enable/Disable auto meta using Solution Enabler SYMCLI

Product:

Solutions Enabler SYMCLI 7.x, Enginuity: 5773, 5874,5875

Description:

Procedure to enable/disable auto meta using Solution Enabler SYMCLI and SMC.

Solution:

If you want to create a single regular device larger than the maximum size, Symmetrix will create a metadevice instead when auto meta feature is enabled. If auto meta is disabled (which is by default), creating device fails. Auto meta feature was introduced with Solutions Enabler V6.5.1 running Enginuity version 5773, which allows metadevices to be created in a single configuration change session.

For Enginuity 5874, the maximum device size in cylinders is 262668.
For Enginuity 5773 and earlier, the maximum device size in cylinders is 65520.

Auto meta can be enabled only if the other auto meta parameters min_auto_meta_size, auto_meta_config and auto_meta_member_size are set to valid values. The settings are Symmetrix-wide.

Min_auto_meta_size: Specifies the size threshold that triggers auto meta creation. When you try to create a device greater than min_auto_meta_size and auto_meta is enabled then a meta will be created. The min_auto_meta_size cannot be set less than the auto_meta_member_size, and needs to be less than or equal to the value in the table below.
Auto_meta_member_size: Specifies the default meta member size in cylinders when the auto_meta feature is enabled. Needs to be less than or equal to the value in the table below.
Auto_meta_config: Specifies the default meta config when the auto_meta feature is enabled. Possible values are CONCATENATED, STRIPED, or NONE.

Enginuity version	Max single device size (CYL)	Max single device size (GB)	Min_auto-meta_size (CYL)	Auto_meta_member_size (CYL)
5874	262668	240	262669	262668
5773	65520	59	65521	65520

To enable auto meta using Solution Enabler:

1. Run the following command to verify if auto meta is disabled: symcfg list -sid xxxx -v
2. If not, create a file 1.txt and add the following text: set Symmetrix auto_meta=enable, min_auto_meta_size=xxxx, auto_meta_member_size=xxxx, auto_meta_config=xxxx;
3. Run the following command: symconfigure -sid xxxx -f 1.txt commit -nop
4. Verify if auto meta is enabled.

To enable the auto meta using SMC:

1. Right-click the Symmetrix ID and select Symmetrix Admin, Set Symmetrix Attributes
2. Enable Auto Meta feature, and enter the Minimum Auto Meta Size, Auto Meta Member Size, Auto Meta Configuration.
3. Click Add to Configure Session List and Commit the change.

NOTE:

• Auto meta feature is not applicable for CKD devices.
• Internal device types DATA, SAVE, DRV cannot be metadevices, therefore, they can't be larger than maximum size.
• You can override the auto_meta_member_size and the auto_meta_config in the create device command line only if auto_meta is ENABLED and the total device size is greater than min_auto_meta_size.

Permanent Sparing Process

Permanent Sparing:

 

An automated, self healing process that runs on the service processor to permanently replace a failing drive with a spare drive through a configuration change. Permanent Sparing can also be thought of as a “permanent replacement.”

 

Direct Sparing:

An automated, self healing process that runs on the service processor that invokes a spare drive and adds it as another member of the RAID group. The failing drive is removed when the copy process is finished.

 

Spare drive:

A physical drive that is not user accessible and is reserved for use by Replacement sparing in the event of a drive failure

 

Permanent Sparing Process

When Symmetrix Enginuity detects that a drive is about to fail, the Permanent Sparing

process begins.It looks for a spare drive of the same block size, capacity, and speed

in a good location to permanently replace the failing drive by means of a configuration change. Permanent Sparing is used in:

Enginuity 5874

Enginuity 5875

Enginuity 5876 with RAID 6(14+2)

 

The Permanent Sparing process identifies a good spare location using the following

rules:

No RAID 1 mirror or RAID 5 group member on the same loop

No more than two members of the same RAID 6 group on the same loop

Note:

If the process cannot identify a spare in a good location, or if the Permanent Sparing process cannot begin for any reason, the system calls home to the EMC Customer Support Center to inform that immediate replacement is required. When a suitable spare is identified, the Permanent Sparing process loads a new configuration file in which all the logical volumes initially configured on the failing drive are now configured on the selected spare (new) drive. The configuration change typically takes a few seconds to complete, during which time the configuration is locked. Data is then rebuilt onto the new drive. The Symmetrix system continues to process host I/O requests at the highest priority to minimize any effects on performance. The configuration is not locked during the rebuild process. The failed drive becomes a Not Ready spare in the spare pool and can be replaced at a later date. Multiple spares are planned for each array to be available for subsequent drive failures. The Not Ready state prevents the drive from being introduced onto the back-end Fibre Channel loop in the event of system power cycle, system IML, or disk director IML. The Not Ready setting will be removed once the drive is physically

replaced, at which time it will again become an available spare.

 

EMC VMAX – Solutions Enabler Versions Required For Enginuity Levels

To confirm that your Solutions Enabler version is supported for the level of Enginuity running on your Symmetrix VMAX please reference the following Knowledge Base support.emc.com/kb/52982
The following table details the Minimum required Solutions Enabler version required:

Note: Check EMC Online Support for the latest Solutions Enabler version and release notes.

calculate free space in veritas volume.

# vxdg list
NAME         STATE                ID
ossctedbdg   enabled,cds          1313610087.29.ossdhcp01

Method 1:

# vxdg -g ossctedbdg free

DISK         DEVICE       TAG            OFFSET    LENGTH   FLAGS
ossctedbdg32 xp24k0_08d4 xp24k0_08d4      10401792  256      -
ossctedbdg33 xp24k0_08d5 xp24k0_08d5      10401792  256      -
ossctedbdg34 xp24k0_08d6 xp24k0_08d6      10401792  256      -
ossctedbdg35 xp24k0_08d7 xp24k0_08d7      10401792  256      -
ossctedbdg36 xp24k0_08d8 xp24k0_08d8      10401792  256      -
ossctedbdg43 xp24k0_08ba xp24k0_08ba      419346432 256      -
ossctedbdg213 xp24k0_0081  xp24k0_0081  104943872 942862992  -


Lenth*512/(1024*1024) = value in MB

in this case :  942862992*512/1024*1024=460383

 
Method 2:

# vxassist -g ossctedbdg maxsize
Maximum volume size: 942864384 (460383Mb)

EMC VMAX Online TDEV (striped) Meta expansion (courtesey Brian)

The following took quite a bit of trial and error on my part, when EMC setup our environment, they turned the Autometa feature on, so when a DEV is created larger then 240gb, it automatically rounded up and created 100gb slices and forms striped METAs. In my understanding, striped meta volumes are not really benificial in a thin pooled environment, that EMC best practices call for concatenated METAs (as each concatenated slice is striped across the entire thin pool allready)

Unfortunatly we were already stuck in this config and hundreds of our META volumes were setup as striped. It is far easier to expand a concatenated META (concatenated METAs also dont have hyper size restrictions) I could find no easy document listing how to expand a striped meta that was a TDEV and the only other blog online I found mentioned expanding a standard Device and not a TDEV. So here you go!

         UPDATE: I've since learned from EMC that the advantage of having striped metas in a thin pool environment provides more I/O "hooks" (as our SE put it) on the front end to the host and can increase performance for high I/O intensive applications when compared to a standard TDEV or a concatenated meta.

1. For a protected (online) expansion, create a BCV+TDEV Meta the same size as the TDEV Meta you wish to expand, with the same size hypers.

· Use the "configure" command to create a copy of the original Meta's configuration (Members and hyper size and bind location which you will have to unbind from)

· symconfigure -cmd "configure 1 devices copying dev xxxx(orig meta) overriding config=BCV+TDEV;" prep

· Unbind from thin pool then bind fully allocated and with persistent flag on :::::IMPORTANT:::::

· symconfigure -cmd "unbind tdev xxxx(new BCV+TDEV meta head) from pool <thin_pool>;" prep

· symconfigure -cmd "bind tdev xxxx(new BCV+TDEV meta head) to pool <thin_pool> PREALLOCATE SIZE = ALL, allocate_type = persistent;" prep

· This will take some time (10 to 15 min depending on size) as it needs to pre-allocate all the space to the pool.  Wait for pre-allocation to complete before continuing 

Note: If you manually create the TDEV meta to be used as a BCV, you can use this to convert it: symconfigure -cmd "convert dev xxxx to BCV+TDEV;" prep

2. Create new Meta members for the original META, the same size as existing members (in cylinders), with the number to achieve amount needed for expansion (Leave them unbound)

· symconfigure -cmd "create dev count=4, size=xxxxxx,config=TDEV, emulation=fba;" commit

· Do not bind

3. Then finially run this command to expand the original META, using the BCV Meta created in step 1:

· symconfigure -cmd "add dev xxxx:xxxx to meta xxxx, protect_data=TRUE, bcv_meta_head=xxxx;" prep

It should run for quite some time, as it copies all data to the BCV, expands the original volume, then copies/re-stripes the data back, including on to the new Meta members. We have seen it bring our back end director utilization to over 80% during the entire expansion, so plan on doing it during a time of low utilization.

After the expansion completes the BCV+TDEV can be cleaned up and deleted


==========================================================================
 Convert all the existing  concatenated metas to striped metas.

Here are the steps to do a conversion:

1)    Create a new meta of the same size and number of members of the meta to be converted:   symconfigure –sid <x> -cmd “create dev count=1 size=<x> gb, emulation=FBA,         config=TDEV;” commit
2)    Bind the new meta to a pool:   symconfigure –sid <x> -cmd “bind tdev <x> to pool <pool name>;” commit
3)    Change the new meta to be a BCV:   symconfigure –sid <x> -cmd “convert dev <x> to bcv+tdev;” commit
4)    Preallocate the new BCV:  symconfigure -sid <x> -cmd "start allocate on tdev <x>, start_cyl=0 end_cyl=last_cyl allocate_type=persistent;" commit
5)    Run the conversion:  symconfigure -sid <x> -cmd "convert meta <x>, config=striped, protect_data=TRUE, bcv_meta_head=<BCV device>;" commit

The last step will take some time;  it took about 30 minutes to convert a 200GB two-member meta when I was testing. 

 

Difference between Fabric Switches and Directors

A director is a class of switch where everything is redundant. Two power supplies, two supervisors, redundant backplane, hot upgrades, etc. So that nothing should bring the director level switch down and cause outage

Port states in Brocade

Differences between port states, reported when execute the switchshow command (online, offline, no light, not sync, etc...). 
I noticed that sometimes a particular is disable and its state show "no light" and other time its state says "not sync". Why?

Online/In_Sync
Normal operating port with a connected device / ISL to other switch. "Online" is the operating state, "In_Sync" the physical state of the receiver/transmitter. (to see the in_sync you have to issue a portshow, switchshow doesn't display it)
 
No_Module 

no gbic/sfp inserted

No_Light 

gbic/sfp inserted, maybe even cable connected, but receiving no light
Disabled/Offline

If you disable a port (via portdisable) its operating state goes to offline. Fabric OS doesn't check offline ports, this means the physical port state is nt display as whatever it was

 If there was a device previously connected it displays as disabled/in_sync, if there was none it displays as disabled/no_light (or no_module). This physical state is only updated when you enable the port again.
swFCPortPhyState: noCard(1), noGbic(2), laserFault(3), noLight(4), noSync(5), inSync(6), portFault(7), diagFault(8), lockRef(9)
swFCPortOpStatus: unknown(0), online(1), offline(2), testing(3), faulty(4)

Port State in switchshow Description

No_Card No interface card present
No_Module No module (SFP or other) present
No_Light Module not receiving light
No_Sync Module receiving light but out of sync
In_Sync Module receiving light and in sync
Laser_Flt Module signaling a laser fault
Port_Flt Port marked faulty
Diag_Flt Port failed diagnostics
Lock_Ref Locking to the reference signal
Testing Running diagnostics
Online Port is up and running