EMC Storage Product Knowledge Sharing

This is new series of Symmetrix family with many new features a high performance, DMX (Direct Matrix Architecture). I will discuss what DMX Architecture is later.

There are two models in DMX-4 series the DMX-4 and the DMX-4 950. DMX-4 supports full connectivity to open system and mainframe hosts like ESCON and FICON.
The DMX-4 950 represents a lower entry point for DMX technology providing open system connectivity with FICON connection for mainframe hosts.

The DMX-4 is the world’s largest high end storage array, allowing configure from 96 to 2400 drives in a single system. Yes, 2400 drives!! Means you can have peta-byte storage in one box.

Main Features of DMX 4 are:

Mainframe Connectivity
4 Gb/s back-end support
Point to Point connection
SATA II drives support
Support Enginuity 5772 ( Enginuity is the Operating System for DMX)
Improved RAID 5 performance via multiple location RAID XOR calculation
Partial sector read hit improvement
128 TimeFinder/Snap session of the same source volume.
Improvements in TimeFinder/Clone create and terminate times upto 10 times.
For SRDF, synchronous response time improvement up to 33 times.
Avoiding COFW (Copy on First Write) for TimeFinder/Clone target devices.
Symmetrix Virtual LUN
Clone to larger target device
RSA technology integrate called new feature Symmetrix Audit Log.
Improve Power Efficiency
RAID 6 supports
Separate Console to manage Symmetrix Management Console

DMX -4 Performance Feature:

Data Path: - 32-128
Data Bandwidth:- 32-128 GB/s
Message Bandwidth:- 4-6.4 GB/s
Global Memory:- 16-512 GB

DMX-4 Storage Capacity:

DMX-4 offers 73 GB, 146 GB, 300 GB and 400 GB FC Drives
DMX-4 offers 73 GB, 146 GB Flash Drives, 500 GB and 1 TB SATA II disk drives

Storage Protection:

Mirrored (RAID 1) – Not supported with Flash Drives
RAID 10, RAID 1/0 – Not supported with Flash Drives
SRDF
RAID 5(3+1) or RAID 5(7+1)
Raid 6 (6+2) or RAID 6 (14=2)- Not supported with Flash Drives.

In normal customer environment, You do day to day activity like allocation storage to different Operating System. If you do not follow best practice then you will see the host facing performance issue. Because in SAN environment, there are so many things to be consider before we present any SAN storage to any HOST. Now, I am discussing what is the best practice for DMX/SYMM? First understand Customer requirement like what application they are running, what is protection level like DMX support RAID 1/0.RAID 5(3+1) , RAID 5(7+1) etc, Are they using different disk alignment. Once you understand the Customer environment then you need to plan about disk configuration at back-end means on DMX.
In Summary decision need to be taken balance off all:

1)The number of physical disk slices
2)The number of meta volume members
3)Channel capacity
4)Host administration required
5)Performance required
6)Suitability for future expansion

As a simple general guide use the following:
(Ideal) Create 18570 volumes, all volumes striped @1MB in host stripe set
(Good) Create 18570 volumes, create metas with 4-8 members
(OK) Create 18570 volumes, create metas with 16 members
(Warn) Create 18570 volumes, create metas with 17+ members

Smaller split sizes can be used for small datasets, and combined into meta volumes for extra-performance with high-load but small-capacity applications.
Larger split sizes are more suitable for larger datasets.A good tip is to have the volumes for an application spread over a minimum 8 physical disks where possible, with only 1 volume per physical.Note most hosts can only see max 512 host volumes (1 metavolume = 1 host volume, 1 non-meta volume = 1 host volume) per channel.

Most of time you end up thinking that we had 500 GB disk but it finish without utlizing full capacity. Answer for this that whatever size you buy you do not get full amount of size becuase DMX size calculation on cylinder basis. Lets understand how DMX calculation size of disk:

1) How DMX 2 and Symmetrix Covert cylinder to GB?
GB = Cylinders * 15 * 64 * 512 divided by 1024 * 1024 * 1024
for example 18570 cylinders is 8.5 GB

2) How DMX 2 and Symmetrix Covert GB to cylinder?
Cylinders = GB / 15 / 64 / 512 then multiply result by 1024*1024*1024

3) How much capacity do I get from a drive ?
This depends on the drive and splits required.
For example a 73GB drive with 8 splits gives 8 x 18570 cyl volumes = 68 GB.

4) How DMX 3 Covert cylinder to GB?
GB = Cylinders * 15 * 128 * 512 divided by 1024 * 1024 * 1024
for example 18570 cylinders is 17,00 GB

5) How DMX 2 and Symmetrix Covert GB to cylinder?
Cylinders = GB / 15 / 128 / 512 then multiply result by 1024*1024*1024

6) How much capacity do I get from a drive ?
This depends on the drive and splits required.
For example a 73GB drive with 4 splits gives 4 x 18570cyl volumes = 68 GB.

Now, you must have understand the formula of calcuating the actual size of disk you can use on any symmetrix or DMX.

EMC on Root Cause Analysis Moves into the Storage Domain

Here we are looking at only three possible ways in which a host can be attached to a Clariion. From talking with customers in class, these seem to be the three most common ways in which the hosts are attached.
The key points to the slide are:1. The LUN, the disk space that is created on the Clariion, that will eventually be assigned to the host, is owned by one of the Storage Processors, not both.2. The host needs to be physically connected via fibre, either directly attached, or through a switch.




CONFIGURATION ONE:

In Configuration One, we see a host that has a single Host Bus Adapter (HBA), attached to a single switch. From the Switch, the cables run once to SP A, and once to SP B. The reason this host is zoned and cabled to both SPs is in the event of a LUN trespass. In Configuration One, if SP A would go down, reboot, etc...the LUN would trespass to SP B. Because the host is cabled and zoned to SP B, the host would still have access to the LUN via SP B. The problem with this configuration is the list of Single Point(s) of Failure. In the event that you would lose the HBA, the Switch, or a connection between the HBA and the Switch (the fibre, GBIC on the switch, etc...), you lose access to the Clariion, thereby losing access to your LUNs.

CONFIGURATION TWO:

In Configuration Two, we have a host with two Host Bus Adapters. HBA1 is attached to a switch, and from there, the host is zoned and cabled to SP B. HBA2 is attached to a separate switch, and from there , the host is zoned and cabled to SP A. The path from HBA2 to SP A, is shown as the "Active Path" because that is the path data will leave the host from to get to the LUN, as it is owned by SP A. The path from HBA1 to SP B, is shown as the "Standby Path" because the LUN doesn't belong to SP B. The only time that the host would use the "Standby Path" is in the event of a LUN Trespass. The advantage of using Configuration Two over Configuration One, is that there is no single point of failure.
Now, let's say we install PowerPath on the host. With PowerPath, the host has the potential to do two things. First, it allows the host to initiate the Trespass of the LUN. With PowerPath on the host, if there is a path failure (HBA gone bad, switch down, etc...), the host will issue the trespass command to the SPs, and the SPs will move the LUN, temporarily, from SP A to SP B. The second advantage of PowerPath on a host, is that it allows the host to 'Load Balance' data from the host. Again, this has nothing to do with load balancing the Clariion SPs. We will get there later. However, in Configuration Two, we only have one connection from the host to SP A. This is the only path the host has and will use to move data for this LUN.

CONFIGURATION THREE:

In Configuration Three, hardware wise, we have the same as Configuration Two. However, notice that we have a few more cables running from the switches to the Storage Processors. HBA1 is into the switch and zoned and cabled to SP A and SP B. HBA2 is into the switch and zoned and cabled to SP A and SP B. What this does now is to give HBA1 and HBA2 an 'Active Path' to SP A, and HBA1 and HBA2, 'Standby Paths' to SP B. Because of this, the Host now can route data down each active path to the Clariion, allowing the host "Load Balancing" capabilities. Also, the only time a LUN should trespass from one SP to another is if there is a Storage Processor failure. If the host were to lose HBA1, it still has HBA2 with an active path to the Clariion. The same goes for a switch failure and connection failure.

The purpose of a MetaLUN is that a Clariion can grow the size of a LUN on the ‘fly’. Let’s say that a host is running out of space on a LUN. From Navisphere, we can “Expand” a LUN by adding more LUNs to the LUN that the host has access to. To the host, we are not adding more LUNs. All the host is going to see is that the LUN has grown in size. We will explain later how to make space available to the host.There are two types of MetaLUNs, Concatenated and Striped. Each has their advantages and disadvantages, but the end result which ever you use, is that you are growing, “expanding” a LUN. A Concatenated MetaLUN is advantageous because it allows a LUN to be “grown” quickly and the space made available to the host rather quickly as well. The other advantage is that the Component LUNs that are added to the LUN assigned to the Host can be of a different RAID type and of a different size. The host writes to Cache on the Storage Processor, the Storage Processor then flushes out to the disk. With a Concatenated MetaLUN, the Clariion only writes to one LUN at a time. The Clariion is going to write to LUN 6 first. Once the Clariion fills LUN 6 with data, it then begins writing to the next LUN in the MetaLUN, which is LUN 23. The Clariion will continue writing to LUN 23 until it is full, then write to LUN 73. Because of this writing process, there is no performance gain. The Clariion is still only writing to one LUN at a time.A Striped MetaLUN is advantageous because if setup properly could enhance performance as well as protection. Let’s look first at how the MetaLUN is setup and written to, and how performance can be gained. With the Striped MetaLUN, the Clariion writes to all LUNs that make up the MetaLUN, not just one at a time. The advantage of this is more spindles/disks. The Clariion will stripe the data across all of the LUNs in the MetaLUN, and if the LUNs are on different Raid Groups, on different Buses, this will allow the application to be striped across fifteen (15) disks, and in the example above, three back-end buses of the Clariion. The workload of the application is being spread out across the back-end of the Clariion, thereby possibly increasing speed. As illustrated above, the first Data Stripe (Data Stripe 1) that the Clariion writes out to disk will go across the five disks on Raid Group 5 where LUN 6 lives. The next stripe of data (Data Stripe 2), is striped across the five disks that make up RAID Group 10 where LUN23 lives. And finally, the third stripe of data (Data Stripe 3) is striped across the five disks that make up Raid Group 20 where LUN 73 lives. And then the Clariion starts the process all over again with LUN6, then LUN 23, then LUN 73. This gives the application 15 disks to be spread across, and three buses. As for data protection, this would be similar to building a 15 disk raid group. The problem with a 15 disk raid group is that if one disk where to fail, it would take a considerable amount of time to rebuild the failed disk from the other 14 disks. Also, if there were two disks to fail in this raid group, and it was RAID 5, data would be lost. In the drawing above, each of the LUNs is on a different RAID group. That would mean that we could lose a disk in RAID Group 5, RAID Group 10, and RAID Group 20 at the same time, and still have access to the data. The other advantage of this configuration is that the rebuilds are occurring within each individual RAID Group. Rebuilding from four disks is going to be much faster than the 14 disks in a fifteen disk RAID Group.The disadvantage of using a Striped MetaLUN is that it takes time to create. When a component LUN is added to the MetaLUN, the Clariion must restripe the data across the existing LUN(s) and the new LUN. This takes time and resources of the Clariion. There may be a performance impact while a Striped MetaLUN is re-striping the data. Also, the space is not available to the host until the MetaLUN has completed re-striping the data.