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..

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”

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

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 18^th 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.

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.

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).

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 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 : 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} 

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

 

 

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.

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

                                             

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.

Common Internet File System (CIFS)

    Common Internet File System (CIFS) is a protocol that lets programs make requests for files and services on remote computers on the Internet. CIFS uses the client/server  programming model. A client program makes a request of a server program (usually in another computer) for access to a file or to pass a message to a program that runs in the server computer. The server takes the requested action and returns a response.

    CIFS is a public or open variation of the Server Message Block Protocol developed and used by Microsoft. Like the SMB protocol, CIFS runs at a higher level than and uses the Internet's TCP/IP protocol. CIFS is viewed as a complement to the existing Internet application protocols such as the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol(HTTP). 

CIFS lets you:

• Get access to files that are local to the server and read and write to them
• Share files with other clients using special locks
• Restore connections automatically in case of network failure
• Use Unicode file names

Configuring the EMC CLARiiON controller with Access Logix installed

The SAN Volume Controller does not have access to the storage controller logical units (LUs) if Access Logix is installed on the EMC CLARiiON controller. You must use the EMC CLARiiON configuration tools to associate the SAN Volume Controller and LU.

The following prerequisites must be met before you can configure an EMC CLARiiON controller with Access Logix installed:

• The EMC CLARiiON controller is not connected to the SAN Volume Controller
• You have a RAID controller with LUs and you have identified which LUs you want to present to the SAN Volume Controller

You must complete the following tasks to configure an EMC CLARiiON controller with Access Logix installed:

• Register the SAN Volume Controller ports with the EMC CLARiiON
• Configure storage groups

The association between the SAN Volume Controller and the LU is formed when you create a storage group that contains both the LU and the SAN Volume Controller.

EMC Clariion : Access Logix

   Access Logix is an optional feature of the firmware code that provides the functionality that is known as LUN Mapping or LUN Virtualization.

    You can use the software tab in the storage systems properties page of the EMC Navisphere GUI to determine if Access Logix is installed.

  After Access Logix is installed it can be disabled but not removed. The following are the two modes of operation for Access Logix:

 

• Access Logix not installed: In this mode of operation, all LUNs are accessible from all target ports by any host. Therefore, the SAN fabric must be zoned to ensure that only the SAN Volume Controller can access the target ports.
• Access Logix enabled: In this mode of operation, a storage group can be formed from a set of LUNs. Only the hosts that are assigned to the storage group are allowed to access these LUNs.

RAID Technology in DMX / Symmetrix Continued

RAID [Redundant Array of Independent (Inexpensive) Disk]

After reading couple of Blogs from last week regarding RAID Technology from StorageSearch and StorageIO, decided to elaborate more about the technology behind RAID and its functionality across Storage Platforms.

After I almost finished writing this blog, I ran into a Wikipedia article explaining RAID TECHNOLOGY at a much length, covering different types of RAID technologies like RAID 2, RAID 4, RAID 10, RAID 50, etc.

For example purposes, let’s say we need 5 TB of Space; each disk in this example is 1 TB each.

RAID 0

Technology: Striping Data with No Data Protection.

Performance: Highest

Overhead: None

Minimum Number of Drives: 2 since striping

Data Loss: Upon one drive failure

Example: 5TB of usable space can be achieved through 5 x 1TB of disk.

Advantages:
> High Performance

Disadvantages: Guaranteed Data loss

Hot Spare: Upon a drive failure, a hot spare can be invoked, but there will be no data to copy over. Hot Spare is not a good option for this RAID type.

Supported: Clariion, Symmetrix, Symmetrix DMX (Meta BCV’s or DRV’s)

In RAID 0, the data is written / stripped across all of the disks. This is great for performance, but if one disk fails, the data will be lost because since there is no protection of that data.

RAID 1

Technology: Mirroring and Duplexing

Performance: Highest

Overhead: 50%

Minimum Number of Drives: 2

Data Loss: 1 Drive failure will cause no data loss. 2 drive failures, all the data is lost.

Example: 5TB of usable space can be achieved through 10 x 1TB of disk.

Advantages: Highest Performance, One of the safest.

Disadvantages: High Overhead, Additional overhead on the storage subsystem. Upon a drive failure it becomes RAID 0.
=”font-size:small;”>

Hot Spare: A Hot Spare can be invoked and data can be copied over from the surviving paired drive using Disk copy.

Supported: Clariion, Symmetrix, Symmetrix DMX

The exact data is written to two disks at the same time. Upon a single drive failure, no data is lost, no degradation, performance or data integrity issues. One of the safest forms of RAID, but with high overhead. In the old days, all the Symmetrix supported RAID 1 and RAID S. Highly recommended for high end business critical applications.

The controller must be able to perform two concurrent separate Reads per mirrored pair or two duplicate Writes per mirrored pair. One Write or two Reads are possible per mirrored pair. Upon a drive failure only the failed disk needs to be replaced.

RAID 1+0

Technology: Mirroring and Striping Data

Performance: High

Overhead: 50%

Minimum Number of Drives: 4

Data Loss: Upon 1 drive failure (M1) device, no issues. With multiple drive failures in the stripe (M1) device, no issues. With failure of both the M1 and M2 data loss is certain.

Example: 5TB of usable space can be achieved through 10 x 1TB of disk.

Advantages: Similar Fault Tolerance to RAID 5, Because of striping high I/O is achievable.

Disadvantages: Upon a drive failure, it becomes RAID 0.

Hot Spare: Hot Spare is a good option with this RAID type, since with a failure the data can be copied over from the surviving paired device.

Supported: Clariion, Symmetrix, Symmetrix DMX

RAID 1+0 is implemented as a mirrored array whose segments are RAID 0 arrays.

RAID 3

Technology: Striping Data with dedicated Parity Drive.

Performance: High

Overhead: 33% Overhead with Parity (in the example above), more drives in Raid 3 configuration will bring overhead down.

Minimum Number of Drives: 3

Data Loss: Upon 1 drive failure, Parity will be used to rebuild data. Two drive failures in the same Raid group will cause data loss.

Example: 5TB of usable space would be achieved through 9 1TB disk.

Advantages: Very high Read data transfer rate. Very high Write data transfer rate. Disk failure has an insignificant impact on throughput. Low ratio of ECC (Parity) disks to data disks which converts to high efficiency.

Disadvantages: Transaction rate will be equal to the single Spindle speed

Hot Spare: A Hot Spare can be configured and invoked upon a drive failure which can be built from parity device. Upon drive replacement, hot spare can be used to rebuild the replaced drive.

Supported: Clariion

RAID 5

Technology: Striping Data with Distributed Parity, Block Interleaved Distributed Parity

Performance: Medium

Overhead: 20% in our example, with additional drives in the Raid group you can substantially bring down the overhead.

Minimum Number of Drives: 3

Data Loss: With one drive failure, no data loss, with multiple drive failures in the Raid group data loss will occur.

Example: For 5TB of usable space, we might need 6 x 1 TB drives

Advantages: It has the highest Read data transaction rate and with a medium write data transaction rate. A low ratio of ECC (Parity) disks to data disks which converts to high efficiency along with a good aggregate transfer rate.

Disadvantages: Disk failure has medium impact on throughput. It also has most complex controller design. Often difficult to rebuild in the event of a disk failure (as compared to RAID level 1) and individual block data transfer rate same as single disk. Ask the PSE’s about RAID 5 issues and data loss?

Hot Spare: Similar to RAID 3, where a Hot Spare can be configured and invoked upon a drive failure which can be built from parity device. Upon drive replacement, hot spare can be used to rebuild the replaced drive.

Supported: Clariion, Symmetrix DMX code 71

RAID Level 5 also relies on parity information to provide redundancy and fault tolerance using independent data disks with distributed parity blocks. Each entire data block is written onto a data disk; parity for blocks in the same rank is generated on Writes, recorded in a distributed location and checked on Reads.

This would classify to be the most favorite RAID Technology used today.

RAID 6

Technology: Striping Data with Double Parity, Independent Data Disk with Double Parity

Performance: Medium

Overhead: 28% in our example, with additional drives you can bring down the overhead.

Minimum Number of Drives: 4

Data Loss: With one drive failure and two drive failures in the same Raid Group no data loss. Very reliable.

Example: For 5 TB of usable space, we might need 7 x 1TB drives

Advantages: RAID 6 is essentially an extension of RAID level 5 which allows for additional fault tolerance by using a second independent distributed parity scheme (two-dimensional parity). Data is striped on a block level across a set of drives, just like in RAID 5, and a second set of parity is calculated and written across all the drives; RAID 6 provides for an extremely high data fault tolerance and can sustain multiple simultaneous drive failures which typically makes it a perfect solution for mission critical applications.

Disadvantages: Very poor Write performance in addition to requiring N+2 drives to implement because of two-dimensional parity scheme.

Hot Spare: Hot Spare can be invoked against a drive failure, built it from parity or data drives and then upon drive replacement use that hot spare to build the replaced drive.

Supported: Clariion Flare 26, 28, Symmetrix DMX Code 72, 73

Clariion Flare Code 26 supports RAID 6. It is also being implemented with the 72 code on the Symmetrix DMX. The simplest explanation of RAID 6 is double the parity. This allows a RAID 6 RAID Groups to be able to have two drive failures in the RAID Group, while maintaining access to the data.

RAID S (3+1)

Technology: RAID Symmetrix

Performance:
> High

Overhead: 25%

Minimum Number of Drives: 4

Data Loss: Upon two drive failures in the same Raid Group

Example: For 5 TB of usable space, 8 x 1 TB drives

Advantages: High Performance on Symmetrix Environment

Disadvantages: Proprietary to EMC. RAID S can be implemented on Symmetrix 8000, 5000 and 3000 Series. Known to have backend issues with director replacements, SCSI Chip replacements and backend DA replacements causing DU or offline procedures.

Hot Spare: Hot Spare can be invoked against a failed drive, data can be built from the parity or the data drives and upon a successful drive replacement, the hot spare can be used to rebuild the replaced drive.

Supported: Symmetrix 8000, 5000, 3000. With the DMX platform it is just called RAID (3+1)

EMC Symmetrix / DMX disk arrays use an alternate, proprietary method for parity RAID that they call RAID-S. Three Data Drives (X) along with One Parity device. RAID-S is proprietary to EMC but seems to be similar to RAID-5 with some performance enhancements as well as the enhancements that come from having a high-speed disk cache on the disk array.

The data protection feature is based on a Parity RAID (3+1) volume configuration (three data volumes to one parity volume).

RAID (7+1)

Technology: RAID Symmetrix

Performance: High

Overhead: 12.5%

Minimum Number of Drives: 8

Data Loss: Upon two drive failures in the same Raid Group

Example: For 5 TB of usable space, 8 x 1 TB drives (rather you will get 7 TB)

Advantages: High Performance on Symmetrix Environment

Disadvantages: Proprietary to EMC. Available only on Symmetrix DMX Series. Known to have a lot of backend issues with director replacements, backend DA replacements since you have to verify the spindle locations. Cause of concern with DU.

Hot Spare: Hot Spare can be invoked against a failed drive, data can be built from the parity or the data drives and upon a successful drive replacement, the hot spare can be used to rebuild the replaced drive.

Supported: With the DMX platform it is just called RAID (7+1). Not supported on the Symms.

EMC DMX disk arrays use an alternate, proprietary method for parity RAID that is called RAID. Seven Data Drives (X) along with One Parity device. RAID is proprietary to EMC but seems to be similar to RAID-S or RAID5 with some performance enhancements as well as the enhancements that come from having a high-speed disk cache on the disk array.

The data protection feature is based on a Parity RAID (7+1) volume configuration (seven data volumes to one parity volume).