Thursday, November 24, 2011

EMC Symmetrix : Symm bin file


This post is just an attempt to shed some light as to what a BIN file is, how it works, what’s in it and why is it essential with the Enginuity code.
. Some EMC folks have capitalized on the BIN file as to the personality it brings to the Symmetrix, while the EMC competition always uses it against them as it introduces complexities in the storage environment with management and change control.
.
With the total number of OS’s, device types, channel interfaces and flags it supports today, sort of making it one of the most compatible storage arrays in the market. The configuration and compatibility on the Symmetrix can be verified using the E-Lab navigator available on Powerlink.
.
So here are some facts about the BIN file
  • Only used with Symmetrix systems (Enginuity Code)
    .
  • BIN file stands for BINARY file.
    .
  • BIN file holds all information about the Symmetrix configuration
    .
  • One BIN file per system serial number is required.
    .
  • BIN file was used with Symmetrix Gen 1 in 1990 and is still used in 2010 with Symmetrix V-Max systems.
    .
  • BIN file holds information on SRDF configurations, total memory, memory in slots, serial number of the unit, number of directors, type of directors, director flags, engines, engine ports, front end ports, back end ports, drives on the loop, drives on the SCSI bus, number of drives per loop, drive types in the slots, drive speeds, volume addresses, volume types, meta’s, device flags and many more settings.
    .
  • The setup for host connection if the OS is Open Systems or Mainframe environments using FICON, ESCON, GbE, FC, RF, etc is all defined in the BIN file. Also director emulations, drive formats if OSD or CKD, format types, drive speeds, etc is all defined in the BIN file.
    .
  • BIN file is required to make a system active. It is created based on customer specifications and installed by EMC during the initial setup.
    .
  • Any ongoing changes in the environment related to hardware upgrades, defining devices, changing flags, etc is all accomplished using BIN file changes.
    .
  • BIN file changes can be accomplished 3 ways.
    .
  • BIN file change for hardware upgrades is typically performed by EMC only.
    .
  • BIN file change for other changes that are device, director, flags, meta’s, SRDF configurations etc is either performed through the SYMAPI infrastructure using SymCLI or ECC (Now Ionix) or SMC (Symmetrix Management Console) by the customer. (Edited based on the comments: Only some changes now require traditional BIN file change, typically others are performed using sys calls in enginuity environment)
    .
  • Solutions enabler is required on the Symcli, ECC, SMC management stations to enable SYMAPI infrastructure to operate.
    .
  • VCMDB needs to be setup on the Symmetrix for SymCLI, ECC, SMC related changes to work.
    .
  • Gatekeeper devices need to be setup on the Symmetrix front end ports for SymCLI, ECC, SMC changes to work
    .
  • For Symmetrix Optimizer to work in your environment, you need DRV devices setup on your Symmetrix.(EDITED based on comments: Only required until DMX platform. Going forward with DMX3/4 & V-Max platforms it uses sys calls to perform these Optimizer changes).
.
Back in the day
All and any BIN file changes on the Symmetrix 3.0, Symmetrix 4.0 used to be performed by EMC from the Service Processor. Over the years with introduction of SYMAPI and other layered software products, now seldom is EMC involved in the upgrade process.
.
Hardware upgrades
BIN File changes typically have to be initiated and performed by EMC, again these are the hardware upgrades. If the customer is looking at adding 32GB’s of Cache to the existing DMX-4 system or adding new Front End connectivity or upgrading 1200 drive system to 1920 drives, all these require BIN file changes initiated and performed by EMC. To my understanding the turn around time is just a few days with these changes, as it requires change control and other processes within EMC.
.
Customer initiated changes
Configuration changes around front end ports, creating volumes, creating meta’s, volume flags, host connectivity, configuration flags, SRDF volume configurations, SRDF replication configurations, etc can all be accomplished through the customer end using the SYMAPI infrastructure (with SymCLI or ECC or SMC).
.
Enginuity upgrade
Upgrading the microcode (Enginuity) on a DMX or a V-Max is not a BIN file change, but rather is a code upgrade. Back in the days, many upgrades were performed offline, but in this day and age, all changes are online and accomplished with minimum pains.
.
Today
So EMC has moved quite ahead with the Symmetrix architecture over the past 20 years, but the underlying BIN file change requirements haven’t changed over these 8 generations of Symmetrix.
Any and all BIN file changes are recommended to be done during quite times (less IOPS), at schedule change control times. Again these would include the ones that EMC is performing from a hardware perspective or the customer is performing for device/flag changes.
.
The process
During the process of a BIN file change, the configuration file typically ending with the name *.BIN is loaded to all the frontend directors, backend directors, including the global cache. After the upload, the system is refreshed with this new file in the global cache and the process makes the new configuration changes active. This process of refresh is called IML (Initial Memory Load) and the BIN file is typically called IMPL (Initial Memory Program Load) file.
A customer initiated BIN file works in a similar way, where the SYMAPI infrastructure that resides on the service processor allows the customer to interface with the Symmetrix to perform these changes. During this process, the scripts verify that the customer configurations are valid and then perform the changes and make the new configuration active.
To query the Symmetrix system for configuration details, reference the SymCLI guide. Some standard commands to query your system would include symcfg, symcli, symdev, symdisk, symdrv, symevent, symhost, symgate, syminq, symstat commands and will help you navigate and find all the necessary details related to your Symmetrix. Also similar information in a GUI can be obtained using ECC and SMC. Both will allow the customer to initiate SYMAPI changes.
Unless something has changed with the V-Max, typically to get an excel based representation of your BIN file, ask your EMC CE.
.
Issues
You cannot run two BIN files in a single system, though at times the system can end up in a state where you can have multiple BIN files on various directors. This phenomenon typically doesn’t happen to often, but an automated script when not finished properly can put the system in this state. At this point the Symmetrix will initiate a call home immediately and the PSE labs should typically be able to resolve these issues.
Additional software like Symmetrix Optimizer also uses the underlying BIN file infrastructure to make changes to the storage array to move hot and cold devices based on the required defined criteria. There have been quite a few known cases of Symmetrix Optimizer causing the above phenomenon of multiple BIN files. , Though many critics will disagree with that statement. (EDITED based on comments: Only required until DMX platform. Going forward with DMX3/4 & V-Max platforms it uses sys calls to perform these Optimizer changes).
.
NOTE: Never run SYMCLI or ECC scripts for BIN file changes through a VPN connected desktop or laptop. Always run all necessary SymCLI / SMC / ECC scripts for changes from a server in your local environment. Very highly recommend, never attempt to administer your Symmetrix system with an iPhone or a Blackberry.
Hope in your quest to get more information on BIN files, this serves as the starting point..

Thursday, September 29, 2011

EMC Symmetrix: VCMDB and ACLX

VCMDB: Volume Control Manager Database

ACLX: Access Control Logix

VCM: Volume Control Manager device (where the database resides)

VCM Gatekeeper: Volume Control Manager Gatekeeper (database doesn’t reside on these devices)

SFS Volumes: Symmetrix File System Volumes

.
        If you work with EMC Symmetrix systems, you know the importance of VCMDB. Introduced with Symmetrix 4.0 and used in every generation after that, VCMDB stands for Volume Control Manager Database). Also in the latest generation of systems the VCM device is at times also referenced as VCM Gatekeeper.

      VCMDB is a relatively small device that is created on the Symmetrix system that allows for hosts access to various devices on the Symmetrix. VCMDB keeps an inventory of which devices have access to which host (HBA’s). Without a VCMDB in place, host systems will not be able to access the Symmetrix. The VCMDB should be backed up on regular intervals and would be helpful in a rainy day.

          The VCMDB device size grew along with new generations of Symmetrix systems that got introduced, primarily a means to keep a track of more supported devices (hypers / splits) on these platforms. With the introduction of Symmetrix V-Max, the VCMDB concept is now a bit changed to ACLX (Access Control Logix). Access Logix is being used on the Clariion systems for years now.

.

Here are a few things to consider with VCMDB
  • On the older Symmetrix systems (4.0, 4.8, 5.0 and 5.5), the VCMDB (device) is mapped to all the channels, host
  • In these systems the VCMDB access is typically restricted by Volume Logix or ACL (access control lists)
  • With the Symmetrix DMX, DMX2 Systems – Enginuity Code 5670, 5671 the VCM device only requires to be mapped to the Management stations
  • Management stations include SYMCLI Server / Ionix Control Center Server / Symmetrix Management Console
  • At all given times on the DMX, DMX2 platforms, the VCMDB would need to be mapped to at least one station to perform online SDDR changes. Alternatively this problem of not having device mapped to at least one host can also be fixed by the PSE lab
  • Mapping VCMDB to multiple hosts, channels may make the device venerable to crashes, potential tampering, device attributes and data change
  • You can write disable VCMDB to avoid the potential of the above
  • With these systems, the host can communicate to the VCMDB via Syscalls
  • The VCM Edit Director Flag (fibrepath) needs to be enabled for management stations to see VCM device
  • The database (device masking database) of the VCMDB resides on the SFS volumes. This feature was introduced with DMX-3 / DMX-4 (5772 version of microcode). A 6 cylinder VCM Gatekeeper device is okay to use with these versions of microcode.
  • Starting Symmetrix V-Max systems, the concept of ACLX was introducted for Auto Provisioning etc.
  • VCM volumes are required to be mirrored devices like SFS volumes
.

 Various different types of VCMDB

Type 0, Type 1, Type 2, Type 3, Type 4, Type 5, Type 6 :


  • Type 0: Symmetrix 4.0, 32 Director System, 16 cylinder device size, Volume Logix 2.x
  • Type 1: Symmetrix 4.8, 64 Director System, 16 cylinder device size, ESN Manager 1.x
  • Type 2: Symmetrix 5.0/5.5, 64 Director System, 16 cylinder device size, ESN Manager 2.x
  • Type 3: Symmetrix DMX, supports 32 fibre/ 32 iSCSI initiator records per port, 24 cylinder device in size. Enginuity 5569, Solutions Enabler 5.2, Support 8000 devices
  • Type 4: Symmetrix DMX/DMX-2, supports 64 fibre/ 128 iSCSI initiator records per port, 48 cylinder device in size. Enginuity 5670, Solutions Enabler 5.3, Supports 8000 devices
  • Type 5: Symmetrix DMX/DMX-2, supports 64 fibre / 128 iSCSI initiator records per port, 96 cylinder device in size, Enginuity 5671, Solutions Enabler 6.0, Supports 16000 devices
  • Type 6: Symmetrix DMX-3, DMX-4, supports 256 fibre / 512 iSCSI initiator records per port, 96 cylinder device in size, Enginuity 5771, 5772 Solutions Enabler 6.0, Supports 64000 devices
.

Notes about various Types of VCMDB

  • Type 3 of VCMDB can be converted to Type 4 VCMDB (code upgrade from 5669 to 5670 to 5671)
  • Solutions enabler 5.2 and Solutions Enabler 5.3 can read/write Type 3 VCMDB
  • Solutions enabler 5.3 can read/write Type 4 VCMDB
  • VCMDB device is recommended to be a certain size, but it is okay to use a larger size device if no choices are available.
.

Converting various types of VCMDB using SymCLI

  • If the device cylinder size is equal with a conversion you are attempting, the following will help you convert your VCMDB from type x to type y.
    • Backup the device
    • symmaskdb –sid <symmid> backup –file backup
    • Check the VCMDB type using
    • symmaskdb – sid <symmid> list database
    • Convert from type 4 to type 5
    • Symmaskdb – sid <symmid> convert –vcmdb_type 5 –file Covertfilename
.

To initialize VCMDB for the first time on a Symmetrix System

Within Ionix Control Center

  • Click on the Symmetrix array you are trying to initialize the VCMDB
  • Select Masking then VCMDB Management and then initialize
  • Select a new backup and create a file name
  • Create a file name with .sdm extenstion
  • Click on Activate the VCMDB
  • VCMDB backups are stored at \home\ecc_inf\data\hostname\data\backup\symmserial\
  • Also it will be viewable within Ionix Control Center at Systems/Symmetrix/VCMDB Backups/
.

With SymCLI


  • To query the VCMDB database
    • symmaskdb –sid <symmid> list database
    • To backup and init an existing VCMDB database
      • symmaskdb – sid <symmid> init –file backup

More technical deep dive coming soon on various other topics…including ACLX.
Cheers

Thursday, September 22, 2011

SAN Switch Migration - How to plan and what need to consider?

       The Zoning Migration within SAN Fabric can import complete zone set information and aliases without any effect on existing SAN fabrics, simplifying SAN migration between different vendors. Such as Cisco, Brocade and McData.
         Import of zone set(h/w + s/w) actually save up a lot time for the migration work but there is some preparation need to be done before the migration. Prepare of the script of zone set, check the interopmode for future fabric expansion (In case other brand of switch will be add in the fabric is required)
     Before you begin, save the current Production Fabric from all SAN Switches.
           Example of Import Zone set. Export the zoning info from the Old switches and prepare the script and import to the new SAN. One important reminder, make sure you have configured the Interoperation mode “Interopmode” before you import the zone set. As the change of Interopmode setting will reset the zoning config.  Make sure all Switch that going to merge / ISL are in the same or Compatible Interop-Mode.
Before ISL / merge the switches,  you need to make sure all Switch in the fabric have a unique DID. You need to determine the principal switch in the fabric. This is to ensure that you have a proper fabric management  for future expansion.
Migration between Brocade Switches is very Simple and easy. Below is the script that I prepared before I import to the new Brocade switch.



Create Zone
switch>zonecreate "USUNIXSAN_HBA0_CX1234_SPA0","10:00:00:00:C9:2D:10:12;50:06:01:60:39:01:2D:xx"

switch>zonecreate "USUNIXSAN_HBA0_CX1234_SPB0","10:00:00:00:C9:23:11:13;50:06:01:68:39:01:2D:xx"

switch>zonecreate "SANDUEL_HBA0_CX1234_SPA0","10:00:00:00:C9:2A:10:17;50:06:01:60:39:01:2D:xx"



switch>zonecreate "SANDUEL_HBA0_CX1234_SPB0","10:00:00:00:C9:23:12:3D;50:06:01:68:39:01:2D:xx"

switch>zonecreate "WINAPPS2008_HBA0_CX1234_SPA0","10:00:00:00:C9:2D:10:12;50:06:01:60:39:01:2D:xx"

switch>zonecreate "WINAPPS2008_HBA0_CX1234_SPB0","10:00:00:00:C9:23:11:13;50:06:01:68:39:01:2D:xx"





Config Create

switch>cfgcreate "SANDUEL_FabricA", "USUNIXSAN_HBA0_CX1234_SPA0"

switch>cfgadd "SANDUEL_FabricA", "USUNIXSAN_HBA0_CX1234_SPB0"

switch>cfgadd "SANDUEL_FabricA", "SANDUEL_HBA0_CX1234_SPA0"

switch>cfgadd "SANDUEL_FabricA", "SANDUEL_HBA0_CX1234_SPB0"

switch>cfgadd "SANDUEL_FabricA", "WINAPPS2008_HBA0_CX1234_SPA0"

switch>cfgadd "SANDUEL_FabricA", "WINAPPS2008_HBA0_CX1234_SPB0"





switch>enable the configure.

switch>cfgenable “SANDUEL_FabricA

Wednesday, September 21, 2011

EMC Symmetrix DMX-4: Supported Drive Types

In this blog post we will discuss the supported drive models for EMC Symmetrix DMX-4. Right before the release of Symmetrix V-Max systems, in early Feb 2009 we saw some added support for EFD’s (Enterprise Flash Disk) on the Symmetrix DMX-4 platform. The additions were denser 200GB and 400GB EFD’s.
The following size drives types are supported with Symmetrix DMX-4 Systems at the current microcode 5773: 73GB, 146GB, 200GB, 300GB, 400GB, 450GB, 500GB, 1000GB. Flavors of drives include 10K or 15K and interface varies 2GB or 4GB.
The drive has capabilities to auto negotiate to the backplane speed. If the drive LED is green the speed is 2GB, if its neon blue its 4GB interface.
To read a blog post on supported drive types on EMC Symmetrix V-Max System

The following are details on the drives for the Symmetrix DMX-4 Systems. You will find details around Drive Types, Rotational Speed, Interface, Device Cache, Access times, Raw Capacity, Open Systems Formatted Capacity and Mainframe Formatted Capacity.



73GB FC Drive
Drive Speed: 10K
Interface: 2GB / 4GB
Device Cache: 16MB
Access speed: 4.7 – 5.4 mS
Raw Capacity: 73.41 GB
Open Systems Formatted Cap: 68.30 GB
Mainframe Formatted Cap: 72.40 GB
73GB FC Drive
Drive Speed: 15K
Interface: 2GB / 4GB
Device Cache: 16MB
Access speed: 3.5 – 4.0 mS
Raw Capacity: 73.41 GB
Open Systems Formatted Cap: 68.30 GB
Mainframe Formatted Cap: 72.40 GB
146GB FC Drive
Drive Speed: 10K
Interface: 2GB / 4GB
Device Cache: 32MB
Access speed: 4.7 – 5.4 mS
Raw Capacity: 146.82 GB
Open Systems Formatted Cap: 136.62 GB
Mainframe Formatted Cap: 144.81 GB
146GB FC Drive
Drive Speed: 15K
Interface: 2GB / 4GB
Device Cache: 32MB
Access speed: 3.5 – 4.0 mS
Raw Capacity: 146.82 GB
Open Systems Formatted Cap: 136.62 GB
Mainframe Formatted Cap: 144.81 GB
300GB FC Drive
Drive Speed: 10K
Interface: 2GB / 4GB
Device Cache: 32MB
Access speed: 4.7 – 5.4 mS
Raw Capacity: 300.0 GB
Open Systems Formatted Cap: 279.17 GB
Mainframe Formatted Cap: 295.91 GB
300GB FC Drive
Drive Speed: 15K
Interface: 2GB / 4GB
Device Cache: 32MB
Access speed: 3.6 – 4.1 mS
Raw Capacity: 300.0 GB
Open Systems Formatted Cap: 279.17 GB
Mainframe Formatted Cap: 295.91 GB
400GB FC Drive
Drive Speed: 10K
Interface: 2GB / 4GB
Device Cache: 16MB
Access speed: 3.9 – 4.2 mS
Raw Capacity: 400.0 GB
Open Systems Formatted Cap: 372.23 GB
Mainframe Formatted Cap: 394.55 GB
450GB FC Drive
Drive Speed: 15K
Interface: 2GB / 4GB
Device Cache: 16MB
Access speed: 3.4 – 4.1 mS
Raw Capacity: 450.0 GB
Open Systems Formatted Cap: 418.76 GB
Mainframe Formatted Cap: 443.87 GB
500GB SATA II Drive
Drive Speed: 7.2K
Interface: 2GB / 4GB
Device Cache: 32MB
Access speed: 8.5 to 9.5 mS
Raw Capacity: 500.0 GB
Open Systems Formatted Cap: 465.29 GB
Mainframe Formatted Cap: 493.19 GB
1000GB SATA II Drive
Drive Speed: 7.2K
Interface: 2GB / 4GB
Device Cache: 32MB
Access speed: 8.2 – 9.2 mS
Raw Capacity: 1000.0 GB
Open Systems Formatted Cap: 930.78 GB
Mainframe Formatted Cap: 986.58 GB
73GB EFD
Drive Speed: Not Applicable
Interface: 2GB
Device Cache: Not Applicable
Access speed: 1mS
Raw Capacity: 73.0 GB
Open Systems Formatted Cap: 73.0 GB
Mainframe Formatted Cap: 73.0 GB
146GB EFD
Drive Speed: Not Applicable
Interface: 2GB
Device Cache: Not Applicable
Access speed: 1mS
Raw Capacity: 146.0 GB
Open Systems Formatted Cap: 146.0 GB
Mainframe Formatted Cap: 146.0 GB
200GB EFD
Drive Speed: Not Applicable
Interface: 2GB / 4GB
Device Cache: Not Applicable
Access speed: 1mS
Raw Capacity: 200 GB
Open Systems Formatted Cap: 196.97 GB
Mainframe Formatted Cap: 191.21 GB
400GB EFD
Drive Speed: Not Applicable
Interface: 2GB / 4GB
Device Cache: Not Applicable
Access speed: 1mS
Raw Capacity: 400.0 GB
Open Systems Formatted Cap: 393.84 GB
Mainframe Formatted Cap: 382.33 GB
Support for 73GB and 146GB EFD’s have been dropped with the Symmetrix V-Max Systems, they will still be supported with the Symmetrix DMX-4 Systems which in addition to 73 GB and 146GB also supports 200GB and 400GB EFD’s.

Monday, September 19, 2011

EMC Timefinder Commands

The following are the Timefinder Procedural Commands
It outlines everything that needs to be done from start to finish. Realize that for routine operations, some of these steps won’t be needed; however, for the sake of completeness.
Prepare EMC structures

1. Create a Symmetrix disk group

symdg -t [ Regular | RDF1 | RDF2 ] create ${group}

2. Add devices to the disk group

symld -g ${group} add pd /dev/dsk/c#t#d#

symld -g ${group} add dev 01a

3. Associate BCV devices to the disk group

symbcv -g ${group} associate pd ${bcv_ctd}

symbcv -g ${group} associate dev ${bcv_dev}


Establish BCV mirrors

1. ID the logical device names: Timefinder defaults to using the logical device names. You can id the logical device names by:

symmir -g ${group} query

2. First time establish, execute a full establish:

symmir -g ${group} -full establish ${std_log_dev} bcv ${bcv_log_dev}

3. Use symmir query to monitor progress.

symmir -g ${group} query


Break BCV mirrors

1. Types of splits:

1. Instant split: Split is performed in the background after the completion of the split I/O request.

2. Force split: Splits the pair during establish or restore operations; invalid tracks may exist.

3. Reverse split: Resyncs the BCV with the full data copy from its local or remote mirror.

4. Reverse differential split: Enables a copy of only out-of-sync tracks to the BCV from its mirror.

5. Differential split: Enables a copy of only the updated tracks to the BCV’s mirror.

2. Commands:

symmir -g ${group} split

symmir -g ${group} split -instant

symmir -g ${group} split -differential

symmir -g ${group} reverse split -differential


Reestablish or restore BCV mirrors

1. Restore copies data from BCV back to standard pair. >Reestablish, on the other hand, does a
differential update of the BCV from the standard device.

2. Commands:

symmir -g ${group} establish Differential reestablish from standard device to BCV

symmir -g ${group} -full restore Full restore of all tracks on BCV to standard device.

symmir -g ${group} restore Differential restore of BCV data to standard device.


The Timefinder Strategies are as follows

1. Maintain BCV mirrors with the standard device; break the mirrors when you want to backup, test,
or develop on a copy of the original.

This is probably the most common way of running Timefinder. The advantage is that the split operation will happen almost instantly as the mirrors are fully synced all the time. The disadvantage is that anything towards that happens to the standard device will be reflected in the BCV mirror.

2. Maintain the BCV as a split device to keep an online backup of the original data.

Thursday, September 15, 2011

How to do Connection between standard to concorent BCVs

In order to use the control functions of Solutions Enabler, you must create device groups and add/associate Symmetrix devices with the group. The following example shows how to create a device group, add a standard device to it and associate two BCV devices to the group.
The following commands will create a device group using the default type (regular). Next we will add a device to the device group and assign it a logical name. Then we associate two BCV devices with the device group so we can switch back and forth with the BCV devices.

symdg create mygroupsymld -g mygroup add dev 000 STD000
symbcv -g mygroup associate dev 110 BCV000
symbcv -g mygroup associate dev 111 BCV001

NOTE: At this point you have only added/associated devices with a device group. These actions do not in any way describe which devices should actually be paired. This may be confusing as the documentation is not very explicit. The fact is that the symmetrix may already have BCV pair information about these devices depending on how they were used in the past.
Now issue the commands to define the STD/BCV pair and actually synchronize the pair with a full establish.

symmir -g mygroup -full establish STD000 BCV dev 110
or
symmir -g mygroup -full establish STD000 BCV ld BCV000

This explicit definition of the STD device and the particular BCV device will cause any existing pair information to be disregarded and will use this new information to create a pair. This is

comparable to the older TimeFinder Command Line Interface "bcv -f filename" where the file "filename" consisted on one line entries pairing STD devices with BCV devices. And finally, split this TimeFinder pair and synchronize the STD device with a different BCV device.
symmir -g mygroup split
symmir -g mygroup -full establish STD000 BCV dev 111

Another method to establish pairs, using the "-exact" option [Available in V3.2-73-06 and higher]The -full -exact options on the symmir command instructs SYMCLI to define the STD/BCV pairs in the same order they were entered into the device group.

symdg create mygroupsymld -g mygroup add dev 000 STD000
symld -g mygroup add dev 001 STD001
symbcv -g mygroup associate dev 110 BCV000
symbcv -g mygroup associate dev 111 BCV001
symmir -g mygroup -full -exact establish

This will pair the first STD device (STD000) with the first BCV (BCV000) entered into the device group, and pair the second STD device (STD001) with the second BCV (BCV001) entered into the device group.

Monday, September 12, 2011

EMC Symmetrix DMX Models by Cabinets Types :

The below is the true breakdown of the type of the EMC Symmetrix and EMC DMX machines to the type of cabinet properties it has. 

Starting with the Symm 3.0′s EMC introduced a 1/2 Hieght cabinets, Single Full Cabinet and a 3 Cabinet machine. The same ideas went into the Symm 4.0 and 4.8. 

Starting the Symm 5.0 and into Symm 5.5, EMC introduced the Badger cabinets, which where much slimmer and about 5 ft in height, it was a disaster with those cabinets. Really no one bought it. 

Starting the DMX800′s and DMX1000′s which are the single cabinet, EMC introduced the DMX2000′s in 2 cabinets and DMX3000 in 3 cabinet style. 

Also if you ever wondered where those Symm modell numbers came from

1st Digit: 3 = Open Systems. 5 = Mainframe. 8 = Mixed.
2nd Digit: Related to Cabinet size, dependant on Generation’
3rd Digit: 00 = 5¼” Drives. 30 = 3½” Drives              

The DMX uses 31/2″ Fiber Drives

Saturday, September 3, 2011

EMC Symmetrix V-Max: Enginuity 5874

          
           EMC Symmetrix V-Max systems were introduced back in the month of April 2009. With this new generation of Symmetrix came a new name V-Max and a new Enginuity family of microcode 5874.

          With this family of microcode 5874: there are 7 major areas of enhancements as listed below.

Base enhancements

Management Interfaces enhancements

SRDF functionality changes

Timefinder Performance enhancements

Open Replicator Support and enhancements



Virtualization enhancements


    
         With Enginuity family 5874 you also need solutions enabler 7.0. The initial Enginuity was release 5874.121.102, a month into the release we saw a new emulation and SP release 5874.122.103 and the latest release as of 18th of June 2009 is 5874.123.104. With these new emulation and SP releases, there aren’t any new features added to the microcode rather just some patches and fixes related to the maintenance, DU/DL and environmentals. Based on some initial list of enhancements by EMC and then a few we heard at EMC World 2009, to sum up, here are all of those.


   RVA: Raid Virtual Architecture:


        With Enginuity 5874 EMC introduced the concept of single mirror positions. Normally it has always been challenging to reduce the mirror positions since they cap out at 4. With enhancements to mirror positions related to SRDF environments and RAID 5 (3D + 1P, 7D +1P) / RAID 6  (6D+2P, 14D+2P) / RAID 1 devices, now it will open doors to some further migration and data movement opportunities related to SRDF and RAID devices.

Large Volume Support:

       With this version of Enginuity, we will see max volume size of 240GB for open systems and 223GB for mainframe systems with 512 hypers per drive. The maximum drive size supported on Symmetrix V-Max system is 1TB SATA II drives. The maximum drive size supported for EFD on a Symmetrix V-Max system is 400GB. 

Dynamic Provisioning:

        Enhancements related to SRDF and BCV device attributes will overall improve efficiency during configuration management. Will provide methods and means for faster provisioning.  

Concurrent Configuration Changes:

        Enhancements to concurrent configuration changes will allow the customer and customer engineer to perform through Service Processor and through Solutions enabler certain procedures and changes that can be all combined and executed through a single script rather than running them in a series of changes.

Service Processor IP Interface:

        All Service Processors attached to the Symmetrix V-Max systems will have Symmetrix Management Console 7.0 on it, that will allow customers to login and perform Symmetrix related management functions. Also the service processor will have capabilities to be managed through the customer’s current IP (network) environment. Symmetrix Management Console will have to be licensed and purchased from EMC for V-Max systems. The prior versions of SMC were free. SMC will now have capabilities to be opened through a web interface.

SRDF Enhancements:

       With introduction of RAID 5 and RAID 6 devices on the previous generation of Symmetrix (DMX-4), now the V-Max offers a 300% better performance with TImefinder and other SRDF layered apps to make the process very efficient and resilient.

Enhanced Virtual LUN Technology:

        Enhancements related to Virtual LUN Technology will allow customers to non-disruptively perform changes to the location of disk either physically or logically and further simplify the process of migration on various systems.

Virtual Provisioning:

        Virtual Provisioning can now be pushed to RAID 5 and RAID 6 devices that were restrictive in the previous versions of Symmetrix. 

Autoprovisioning Groups:

       Using Autoprovisiong groups, customers will now be able to perform device masking by creating host initiators, front-end ports and storage volumes. There was an EMC Challenge at EMC World 2009 Symmetrix corner for auto provisioning the symms with a minimum number of clicks. Autoprovisioning groups are supported through Symmetrix Management Console. So the above are the highlights of EMC Symmetrix V-Max Enginuity 5874. As new version of the microcode is released later in the year stay plugged in for more info.

Sunday, August 28, 2011

Brocade switch Zoning and Fabric Operations



        When configuring zoning or other fabric-wide settings in a fabric that has products operating with different versions of FOS, it is recommended that the configuration be performed via an interface (such as WebTools) to a product with the most recent version of FOS. 


       Some older versions of FOS do not fully support newer hardware models, and problems may arise when configuring settings through these older products. 

       Zoning configuration in particular should never be performed through a switch operating with FOS v3.x in a fabric that also has products operating with newer releases of FOS firmware.

Brocade Switch Technical Support


Contact your switch supplier for hardware, firmware, and software support, including product repairs and part ordering. To expedite your call, have the following information immediately available :




1. General Information

· Technical Support contract number, if applicable

· Switch model

Fabric OS v6.1.1a Release Notes, v1.0 Page 6 of 33

· Switch operating system version

· Error numbers and messages received


· supportSave command output

· Detailed description of the problem, including the switch or fabric behavior immediately
following the problem, and specific questions

· Description of any troubleshooting steps already performed and the results

· Serial console and Telnet session logs

· Syslog message logs


2. Switch Serial Number

The switch serial number is provided on the serial number label.
 
The serial number label is located as follows:

· Brocade 200E—On the nonport side of the chassis

· Brocade 4100, 4900, and 7500/7500E—On the switch ID pull-out tab located inside the
chassis on the port side on the left

· Brocade 300, 5000, 5100, and 5300—On the switch ID pull-out tab located on the bottom of
the port side of the switch

· Brocade 7600—On the bottom of the chassis

· Brocade 48000 —Inside the chassis next to the power supply bays

· Brocade DCX—Bottom right of the port side.



3. World Wide Name (WWN)

Use the wwn command to display the switch WWN.

If you cannot use the wwn command because the switch is inoperable, you can get the
WWN from the same place as the serial number, except for the Brocade DCX. For the
Brocade DCX, access the numbers on the WWN cards by removing the Brocade logo
plate at the top of the non-port side. The WWN is printed on the LED side of both cards.

Follow By Email to get latest Blog updates.

Monday, August 22, 2011

EMC Symmetrix Management Console (SMC – For Symmetrix V-Max Systems)

        The Symmetrix Management Console is a very important step towards allowing customers take control of their Symmetrix V-Max Systems. With the new Symmetrix V-Max comes a new version of Symmetrix Management Console allowing customers to manage their EMC Symmetrix V-Max Systems through a GUI web browser interface with tons of new added features and wizards for usability.


       The Symmetrix Management Console was developed back in the day as a GUI to view customers Symmetrix DMX environment, over years it has evolved more to be a functional and operational tool to interface the machine for data gathering but also to perform changes. EMC Solutions Enabler Symcli is a CLI based interface to the DMX and V-Max Systems, but the SMC complements the CLI by allowing customers to perform more or less similar functions through a GUI. The looks & feels of SMC also resemble ECC (EMC Control Center) and customers sometime refer it as a ECC-lite (SMC).


symmetrix-management-console-in-action


EMC Symmetrix Management Console in action monitoring EMC Symmetrix V-Max Systems

Some of the important features and benefits of the SMC for V-Max are listed below:

1)    Allows customers to manage multiple EMC Symmetrix V-Max Systems

2)    Increase customer management efficiency by using Symmetrix Management Console to automate or perform functions with a few set of clicks

3)    The Symmetrix Management Console 7.0 only works with Symmetrix V-Max systems

4)    The Symmetrix Management Console is installed on the Service Processor of the V-Max System and can also be installed on a host in the SAN environment.

5)    Customers can now do trending, performance reporting, planning and consolidation using SMC

6)    SMC will help customers reduce their TCO with V-Max Systems

7)    It takes minutes to install. Windows environment running a Windows Server 2003 along with IIS would be the best choice.

8 )    The interface the customers work on is a GUI. It has the looks and feels of ECC and the Console also integrates with ECC.

9)    New Symmetrix V-Max systems are configured and managed through the Symmetrix Management Console.

10) SMC also manages user, host permissions and access controls

11) Alert Management

12) From a free product, SMC now becomes a licensed product, which the customers will  have to pay for

13) It allows customers to perform functions related to configuration changes like creating and mapping masking devices, changing device attributes, flag settings, etc

14) Perform replication functions using SMC like Clone, Snap, Open Replicator, etc

15) SMC enables Virtual Provisioning with the Symmetrix V-Max arrays

16) Enables Virtual LUN technology for automated policies and tiering.

17) Auto Provisioning Group technology is offered through wizards in SMC

18) Dynamic Cache Partitioning: Allocates and deallocates cache based on policies and utilization.

19) Symmetrix Priority Controls

20) From the SMC, customers can now launch SPA (Symmetrix Performance Analyzer), this is more on the lines of Workload Analyzer which is a standard component of ECC Suite. This allows customers to view their storage & application performance & monitoring. SPA will can be obtained as a Add-on product from EMC based on licensing.


virtual-lun-technology-in-smc1


Virtual LUN Technology in works using a wizard

21) The SMC gives the customer capabilities for Discovery, Configuration, Monitoring, Administration and Replication Management.

22) SMC can be obtained from EMC Powerlink or through your account manager from EMC if you have an active contract in place with EMC for hardware/software maintenance or if your systems are under warranty.

Highly recommended management tool for SAN Admins and yea it’s not free anymore for V-Max Systems.   

 

EMC Symmetrix: Calculations for Heads, Tracks, Cylinders, GB

Here is the quick and dirty math on EMC Symmetrix Heads, Tracks, Cylinder sizes to actual usable GB’s of space.
Based on different generations of Symmetrix systems, here is how the conversions work.
Before we jump into each model type, lets look at what the basics are, with the following calculations.
.
.
.
.
There are s number of splits (hyper) per physical device.
There are n number of cylinders per split (hyper)
There are 15 tracks per cylinder (heads)
There are either 64 or 128 blocks of 512 bytes per track
.
All the calculations discussed here are for Open Systems (FBA) device types. Different device emulations like 3380K, 3390-1, 3390-2, 3390-3, 3390-4, 3390-27, 3390-54 have different bytes/track, different bytes/cylinder and cylinders/volume.
.

Symmetrix 8000/DMX/DMX-2 Series

Enginuity Code: 5567, 5568, 5669, 5670, 5671
Includes EMC Symmetrix 8130, 8230, 8430, 8530, 8730, 8830, DMX1000, DMX2000, DMX3000 and various different configurations within those models.
GB = Cylinders * 15 * 64 * 512 / 1024 / 1024 / 1024
eg: 6140 Cylinder devices equates to 2.81 GB of usable data
6140 * 15 * 64 * 512 / 1024 / 1024 / 1024 = 2.81 GB

Cylinders = GB / 15 / 64 / 512 * 1024 * 1024 * 1024
Where
15 = tracks per cylinder
64 = blocks per track
512 = bytes per block
1024 = conversions of bytes to kb to mb to gb.
.

Symmetrix DMX-3/DMX-4 Series

Enginuity Code: 5771, 5772, 5773
Includes EMC Symmetrix DMX-3, DMX-4 and various different configurations within those models.
GB = Cylinders * 15 * 128 * 512 / 1024 / 1024 / 1024
Eg: 65520 Cylinder device equates to 59.97 GB of usable data
65540 * 15 * 128 * 512 / 1024 / 1024 / 1024 = 59.97 GB

Cylinders = GB / 15 / 128 / 512 * 1024 * 1024 * 1024
15 = tracks per cylinder
128 = blocks per track
512 = bytes per block
1024 = conversions of bytes to kb to mb to gb
.

Symmetrix V-Max

Enginuity Code: 5874
Includes EMC Symmetrix V-Max and various different configurations within this model.
GB = Cylinders * 15 * 128 * 512 / 1024 / 1024 / 1024
Eg: 262668 Cylinder device equates to 240.47 GB of usable data
262668 * 15 * 128 * 512 / 1024 / 1024 / 1024 = 240.47 GB

Cylinders = GB / 15 / 128 / 512 * 1024 * 1024 * 1024
15 = tracks per cylinder
128 = blocks per track
512 = bytes per block
8 bytes = 520-512 used for T10-DIF
1024 = conversions of bytes to kb to mb to gb
Drive format on a V-Max is 520 bytes, out of which 8 bytes are used for T10-DIF ( A post on DMX-4 and V-Max differences).

Friday, August 19, 2011

Emc Symmetrix : Volume Logix

      The order for getting fibre channel based hypervolume extentions (HVEs) viewable on systems, particularly SUN systems, is as follows:


1. Appropriately zone so the Host Bus Adapter (HBA) can see the EMC Fibre Adapter (FA).

2. Reboot the system so it can see the vcm database disk on the FA OR

    1. SUN:

            1. drvconfig -i sd; disks; devlinks (SunOS <= 5.7)

            2. devfsadm -i sd (SunOS >= 5.7 (w/patches))
     2. HP:
             
            1. ioscan -f # Note the new hw address
           

            2. insf -e -H ${hw}

3. Execute vcmfind to ensure the system sees the Volume Logix database.

4. ID mapped informationi

         1. Map HVEs to the FA if not already done.
     
         2. symdev list -SA ${fa} to see what’s mapped.

         3. symdev show ${dev} to ID the lun that ${dev} is mapped as. The display should look   something like:
 Front Director Paths (4):

{

———————————————————————————————–
POWERPATH DIRECTOR PORT
———————- —————– ————
PdevName Type Num Type Num Sts VBUS TID LUN
———————————————————————————————–
Not Visible N/A 03A FA 0 RW 000 00 70
Not Visible N/A 14A FA 0 NR 000 00 70
Not Visible N/A 03B FA 0 NR 000 00 70
Not Visible N/A 14B FA 0 NR 000 00 70

}

    The number you’re looking for is under the column LUN. Remember, it’s HEX, so the lun that’ll show up on the ctd is (0×70=112) c#t#d112

       5. On SUN systems, modify the /kernel/drv/sd.conf file so the system will see the new disks. You’ll need to do a reconfig reboot after modifying this file. If the system doesn’t see it on a reconfig reboot, this file is probably the culprit!
      
       6. fpath adddev -w ${hba_wwn} -f ${fa} -r “${list_of_EMC_devs}”
You can specify multiple EMC device ranges; just separate them by spaces, not commas
      
       7. Reboot the system so it can see the new disks on the FA OR

1. SUN:

      1. drvconfig -i sd; disks; devlinks (SunOS <= 5.7)

      2. devfsadm -i sd (SunOS >= 5.7 (w/patches))

2. HP:

       1. ioscan -f # Note the new hw address
       

       2. insf -e -H ${hw} 

Thursday, August 18, 2011

EMC Symmetrix LUN Allocation


Minimum Requirements:

 

         Knowledge on Basic Symmetrix Architecture
     
             Operating systems knowledge

             And a test Symmetrix, hosts to try


      Symmetrix Allocation Steps 

       Step 1: Create symmetrix devices from the free space.

                    

            To create a symmetrix device, first we need to know what type of device we need to create. For example, RAID-5, RAID-1 etc… I’m going to write both the commands. To start with, we need to create a simple text file and add the below line to the file.

      filename: config1

      create dev count=xx, size=17480, emulation=FBA, config=2-way-mir, disk_group=x;


      Command Explanation:

      dev count=xx
      (replace xx with the number of devices we need to create)

      emulation=FBA 
      (FBA > Fixed Block Architecture used for Open Systems which are Solaris, HP-UC and Window$)

      config=2-way-mir
      (Configure the devices as RAID-1, one of the oldest configuration available in all symmetrix models)

      disk_group=x 
      (disk groups are created to differentiate the  tiers, performance and capacity. Based on the requirements, we can select the desired disk group number to create the new symmetrix devices)


                Once you add the above line in the text file, save it and check the syntax. To make any configuration changes in the symmetrix we need to run the below mentioned commands. Ensure that the raid1.txt file in your current working directory.
        

      symconfigure -sid xxxx -f raid1.txt preview -V 

      symconfigure -sid xxxx -f raid1.txt prepare -V 

      symconfigure -sid xxxx -f raid1.txt commit -V



      Command Explanation:


       symconfigure
      (This command used to manage major configuration changes, display capacity of symmetrix and manage dynamic (hot) spares and device reservations)

      -sid
      (Symmetrix ID, always prefix with hyphen (-) )

      -f
      (filename, mention the file name to which we’ll use. In this example it is raid1.txt)

      preview
      (The preview argument verifies the syntax and correctness of each individual change defined, and then terminates the session without change execution.)

      prepare
      (The prepare argument performs the preview checks and also verifies the appropriateness of the resulting configuration definition against the current state of the Symmetrix array)

      commit
      (The commit argument completes all stages and executes the changes in the specified Symmetrix array.)
      -V (Yes, you’re right, its verbose mode)

                That’s it! After running the above the commands the new devices are created. It was to create symmetrix devices from the symcli right. Let us assume that the devices ID’s are 001 through 00A (devices created with hexadecimal numbers)


      Step 2: Search for free LUN ID on the FA (Fibre Adapters)

       

            After creating the devices, we need to map the devices to the Fibre Adapters. In legacy symmetrix, it will be SCSI Adapters (SA). IF we need to do it from ECC (EMC Control Center now called as IONIX, we need to a. Right click on the device b. Go to ‘Configure’ c. Select and Click ‘SDR Device Mapping’ and follow the wizard. Here I’ll be writing the commands to do the same. 


      symcfg -sid xxxx list -available -address -fa xy -p n |more

      Command Explanation:

      symcfg
      (Discovers or displays Symmetrix configuration information)

      list
      (Lists brief or detailed information about your Symmetrix configuration.)

      -available -address
      (Requests the next available Vbus, TID, or LUN address be appended to the output list. Used with the -address option.)

      -fa
      (Confines the action to a Fibre Adapter (FA) director number)

      xy
      (x is the director number eg. 8 and y is the processor number eg. a or b)

      -p n
      (p is the port and n is the number eg. 0 or 1)


            Up to DMX-4 we follow the RULE-17. So repeat the command for another FA in this e.g. 9.


      Step 3: Mapping a device to the FA

       

             Now, lets assume that the LUN ID’s 52 onwards are free to use on both the FA’s 8a and 9a. Also, the file map.txt contains the below commands. After saving the file, we have run the symconfigure commands as shown above in Step 1. The below command will map the device 0001 to the FA’s 8a:0 and 9a:0 which will have the LUN ID’s 52 on the FA’s. 



      map dev 0001  to dir 8a:0 target=0,lun=52;

       

      map dev 0001  to dir 9a:0 target=0,lun=52;

       

       

      Command Explanation:

      map
      (map a device to fa)

      dev
      (symmetrix device ID)

      dir 8a
      (FA:port no#)

      target
      (The SCSI target ID (hex value)

      lun
      (Specifies the LUN addresses to be used for each device that is to be added for the host HBA.)


      Step 4: LUN Masking a device to the FA

       

       

              The last but one step is to do the LUN masking. It performs control and monitoring operations on a device masking environment. After running the below command, provides RW accessibility to the server having 2 port HBA’s for the device 0001.

      symmask -sid xxxx -wwn 10000000c130880a -dir 8a -p 0 add dev 0001

       

       

      symmask -sid xxxx -wwn 10000000c131084a -dir 9a -p 0 add dev 0001

       

       

      Command Explanation:

      symmask
      (Sets up or modifies Symmetrix device masking functionality.)

      -wwn
       (World Wide Name of the Host Bus Adapter (HBA) zoned with the FA)

      add
      (Adds devices to the device masking record in the database with the matching WWN)




      Step 5: Update and refresh the Symmetrix database VCMDB 

       

      (Volume Control Manager Database) Steps to perform from the HP-UX server.

       

       

                The below command looks pretty simple but very important command to append all changes to the VCMDB. This will ensure and update the DB which protects the changes made the symmetrix.

      Symmask -sid xxxx refresh

       

       

      refresh
      (updates and refreshes the VCMDB)


                To confirm the symmetrix allocation done properly are not we can run the symcfg command as shown above in the Step 2. The output should show the LUN ID 52 being occupied by the Symmetrix device ID 0001.


       

      Steps to perform from HP-UX server 

       

              Once we finish the task from the EMC end, we need to scan for the new LUN from the operating system. First we’ll deal with HP-UX server. The following commands needs to be executed in the same order from the server to start using the new device.


      #ioscan -fnC disk

       

      The ioscan command displays a list of system disks with identifying information, location, and size.

      #insf -e

       

                The insf command installs special files in the devices directory, normally /dev. If required, insf creates any subdirectories that are defined for the resulting special file. After running this command the new devices will be added to the /dev directory as special device file. 

      #powermt config


      Configure logical devices as PowerPath devices. It will search for the EMC devices and adds it  as a power path devices.

      #powermt display dev=all


            Displays configured powerpath devices. If the previous command ran successfully then we should see the new device in the output list. 

      #powermt save


      Save a custom PowerPath configuration. Once we see the new device in the previous command output, then we can save the power path configuation database.


      After the successful completion of the above steps we can use the devices. Further by using the volume managers we can add them to the existing volume group or the new volume group.



       

       

      To Allocate LUN’s in V-Max array, following steps has to be performed. (courtesy: Sanjeev Tanwar)

       

       

      1. Create a storage groups (Containing symm devices)

      2. Create a port group (one or more director /port combinations)

      3. Create an intitors group (one or more host wwns)

      4. Creating a masking view containg the storage groups,port groups, and inititors group.
      When a masking view is created,the devices are automatically masked and mapped.

       

      Creating Storage Group

       

      #symaccess create -sid xxx -name SG1 -type storage devs 01c,03c

       

      Creating Port Group

       

      #symaccess create -sid xxx -name PG1 -type port -dirport 6d:0,7e:1

       

      Creating inititor Group

       

      #symaccess create -sid xxx -name IG1 -type inititors -file txt1

       

      txt1 conatins

      wwn:21000000008b090

      www:21000000008c090


      Creating a masking view

       

       

      #symaccess create view -name test_view -sg SG1 -pg PG1 -ig IG1

       

       

      Monday, August 15, 2011

      Netapp : How to restore data from aggregate snapshot


                Today one of our user found himself in wet pants when he noticed his robocopy job has overwritten a folder, rather than appending new data to it. Being panicked he run to me looking for any tape or snapshot backup of his original data, which unfortunately wasn't there as previously he confirmed that they don't need any kind of protection.

      Now at this time I had only place left where I can recover the data, aggregate level snapshots; so I looked at aggregate snapshots and saw it goes back to time when he had data in place. Knowing that the data deleted from volume is still locked in aggregate's snapshot I was feeling good that I have done a good job by having some space reserved for aggregate level snapshot, which no one ever advocated.


      Now the next step is to recover the data, but problem was that if I revert aggregate using "snap restore –A" then all the volumes in that aggregate will be reverted which will be bigger problem. So had to go on a different way, use aggregate copy function to copy the aggregate's snapshot to an empty aggregate and then restore the data from there.


      Here's the cookbook for this.


      Pre-checks:


      • The volume you lost data from is a flexible volume
      • Identify an aggregate which is empty so it can be used for destination (could be on another controller also)
      • Make sure the destination aggregate is either equal or larger than source aggregate
      • /etc/hosts.equiv has entry for the filer you want to copy data to and /etc/hosts has its IP address added, in case of copying on same controller loopback address (127.0.0.1) should be added in /etc/hosts file and local filername should be in hosts.equiv file
      • Name of aggregate's snapshot which you want to copy


      Example:

      Let's say the volume we lost data was 'vol1', the aggregate which has this volume is 'aggr_source', the aggregate's snapshot which has lost data is 'hourly.1' and empty aggregate where we will be storing data to is 'aggr_destination'


      Execution:


      • Restrict the destination aggregate using 'aggr restrict aggr_destination'
      • Start the aggregate data copy using 'aggr copy start –s hourly.1 aggr_source aggr_destination'
      • Once the copy is completed online the aggregate using 'aggr online aggr_destination'
      • If you have done copy on same controller, system will rename the volume 'vol1' of 'aggr_destination' to 'vol1(1)'
      • Now export the volume or lun and you have your all lost data available.
      So here's the answer to another popular question, why do I need to reserve space for aggregate level snapshot. Do you have the answer now?

      EMC Symmetrix : DRV Devices ( Dynamic Reallocation Volume)

              A dynamic Reallocation Volume is a nonuser addressable symmetrix device used by symmetrix optimizer to temporarily hold user data while recognization of devices being executed. Typically it is used in logical volume swapping operations.


              Below diagram illutrates the stages and status of volumes during a complete volume swap   ( Volume 1 with 4 )
           


      Volume Stages of DRV SWAP
       



      EMC Symmetrix : Device Masking (VCM) Devices

      Symmetrix device masking or

      VCM devices are Symmetrix devices

      that have been masked for visibility to certain hosts. The device

      masking database (VCMDB), which holds device masking records,

      typically resides on a small disk device (such as a 48-cylinder, 24 MB

      device). For more information, see the
      EMC Solutions Enabler

      Symmetrix Device Masking CLI Product Guide.

      Sunday, August 14, 2011

      EMC Symmetrix : Dynamic RDF Devices

      Since Enginuity Version 5568, devices can be configured to be dynamic RDF Capable Devices. Dynamic RDF enables you to create , delete & swap SRDF pairs while the symmetrix array in operation.

      And you can establish SRDF device pairs from non-SRDF devices, & then syncronize and manage them in the same way as you configured SRDF pairs.

      The Dynamic RDF configuration state of the Symmetrix array must be enabled in symmWin or via the Configuration Manager and the devices must be designated as dynamic RDF capable devices.


      Thank you..
      Don't forgot to leave ur valuable Comment ..

      SAN : Clariion CX4 Series

      CX4
                                                   


      Wednesday, August 10, 2011

      NAS on SAN ( Network Data Management Protocal )




             NDMP (Network Data Management Protocol) is an open protocol used to control data backup and recovery communications between primary and secondary storage in a heterogeneous network environment. 

             NDMP specifies a common architecture for the backup of network file servers and enables the creation of a common agent that a centralized program can use to back up data on file servers running on different platforms. By separating the data path from the control path, NDMP minimizes demands on network resources and enables localized backups and disaster recovery. With NDMP, heterogeneous network file servers can communicate directly to a network-attached tape device for backup or recovery operations. Without NDMP, administrators must remotely mount the network-attached storage (NAS) volumes on their server and back up or restore the files to directly attached tape backup and tape library devices.


         NDMP addresses a problem caused by the particular nature of network-attached storage devices. These devices are not connected to networks through a central server, so they must have their own operating systems. Because NAS devices are dedicated file servers, they aren't intended to host applications such as backup software agents and clients. Consequently, administrators have to mount every NAS volume by either the Network File System (NFS) or Common Internet File System (CIFS) from a network server that does host a backup software agent. However, this cumbersome method causes an increase in network traffic and a resulting degradation of performance. NDMP uses a common data format that is written to and read from the drivers for the various devices.


          Network Data Management Protocol was  originally developed by NetApp Inc., but the list of data backup software and hardware vendors that support the protocol has grown significantly. Currently, the Storage Networking Industry Association (SNIA) oversees the development of the protocol.


      Follow storageadmiins on Twitter Follow storageadmiins on Twitter