Showing posts with label EMC Symmetrix. Show all posts
Showing posts with label EMC Symmetrix. Show all posts

Organizations continually search for ways to both simplify storage management processes and improve storage capacity utilization. Several products have been released over the past few years that promise efficient use of storage space. One of the technologies that is quickly catching up is thin provisioning. 3PAR was one of the first vendors to introduce the concept while the rest quickly followed the suite.

When provisioning storage for a new application, administrators must consider that application’s future capacity requirements rather than simply its current requirements. In order to reduce the risk that storage capacity will be exhausted, disrupting application and business processes, organizations often have allocated more physical storage to an application than is needed for a significant amount of time. This allocated but unused storage introduces operational costs. Even with the most careful planning, it often is necessary to provision additional storage in the future, which could potentially require an application outage.

EMC Virtual Provisioning: - introduced with Enginuity 5773, addresses some of these challenges. It builds on the base “thin provisioning” functionality, which is the ability to have a large “thin” device (volume) configured and presented to the host while consuming physical storage from a shared pool only as needed. Symmetrix Virtual Provisioning can improve storage capacity utilization and simplify storage management by presenting the application with sufficient capacity for an extended period of time, reducing the need to provision new storage frequently and avoiding costly allocated but unused storage. Symmetrix Management Console and the command line interface (CLI) are the primary management and monitoring tools.
Symmetrix Virtual Provisioning: - introduces a new type of host accessible device called a “thin device” that can be used in the same way that a regular device has traditionally been used. Unlike regular Symmetrix devices, thin devices do not need to have physical storage completely allocated at the time the devices are presented to a host. The physical storage that is used to supply disk space for a thin device comes from a shared thin storage pool that has been associated with the thin device. A thin storage pool is comprised of a new type of internal Symmetrix device called a data device that is dedicated to the purpose of providing the actual physical storage used by thin devices. When they are first created, thin devices are not associated with any particular thin pool. An operation referred to as “binding” must be performed to associate a thin device with a thin pool.

When a write is performed to a portion of the thin device, the Symmetrix allocates a minimum allotment of physical storage from the pool and maps that storage to a region of the thin device. The storage allocation operations are performed in small units of storage called “thin device extents.” A round-robin mechanism is used to balance the allocation of data device extents across all of the data devices in the pool that are enabled and that have remaining unused capacity. The thin device extent size is 12 tracks (768 KB). That means that the initial bind of a thin device to a pool causes one thin device extent, or 12 tracks, to be allocated per thin device. So a four-member thin meta would cause 48 tracks (3078 KB) to be allocated when the device is bound to a thin pool.

When a read is performed on a thin device, the data being read is retrieved from the appropriate data device in the storage pool to which the thin device is bound. When more storage is required to service existing or future thin devices, data devices can be added to existing thin storage pools. New thin devices can also be created and associated with existing thin pools.
It is possible for a thin device to be presented for host-use before all of the reported capacity of the device has been mapped. It is also possible for the sum of the reported capacities of the thin devices using a given pool to exceed the available storage capacity of the pool. Such a thin device configuration is said to be oversubscribed.

The storage is allocated from the pool using a round-robin approach that tends to stripe the data devices in the pool. Storage Admin should keep in mind that when implementing Virtual Provisioning, it is important that realistic utilization objectives are set. Generally, organizations should target no higher than 60 percent to 80 percent capacity utilization per pool. A buffer should be provided for unexpected growth or a “runaway” application that consumes more physical capacity than was originally

Benefits of Virtual Provisioning :
Less expensive to pre-provision storage
In case one needs to preprovision storage, the entire amount of physical storage has to be configured and dedicated at the time of pre provision.
But in case of thin luns, one can exceed the amount of physical storage during provisioning. Also with time, as costs of physical storage drops consistently, it could save dollars.

Easy implementation of wide stripes
A configured thin pool ensures that a thin device will be widely stripped across the backend in 768K extends. Thus a single thin device requires no planning on part of administrator.

Performance
The performance for certain random IO workloads can be improved due to the fact that thin devices are widely stripped across the backend. Typically in a thin device implementation there is a modest response time overhead incurred the first time a write is performed on an unallocated region of a thin device. This overhead tends to disappear once the working set of thin device has been written to.
--Contributed by Suraj Kawlekar

From its inception, Symmetrix was designed with the flexibility to incorporate the latest technology in disk drives, memory and other components. This effort has enabled the storage platform to evolve to meet the ever-increasing data demands of enterprises. and has provided customers with unparalleled investment protection. The first-generation Symmetrix 4400 Integrated Cached Disk Array (ICDA), with a total capacity of 24 gigabytes, was introduced in 1990. The seventh-generation system, the Symmetrix DMX-3, was introduced in July 2005 and features a Direct Matrix Architecture® and maximum capacity of one petabyte (1,024 terabytes). The Symmetrix platform has continued to improve and evolve to meet the needs of data-intensive organizations worldwide and remains the most successful intelligent storage platform in history.

With more than 68,000 systems shipped from its introduction in 1990 through the end of June, 2005 and with more than 400 EMC patents covering its technology, Symmetrix remains the high-end storage market leader and continues to set the standard for mission-critical high-end storage innovation.

1990 – Symmetrix 4200 – ICDA (Integrated Cached Disk Array) Technology, Total Capacity 24 GB

1991 – Symmetrix 4200 – 4Mb DRAM, 5.25 HDAs, Mirroring RAID 1

1992 – Symmetrix 4400 - - Dynamic Sparing, RMP Call Home

1993 – Symmetrix 4800 – 16MB DRAM, 1 GB Global Memory,Non-disruptive microcode, Hypervolume Extension.

1994 – Symmetrix 5500-3 – SRDF

1995 – Symmetrix 3.0 Open Symmetrix- FWD SCSI- attach, 3.5’’ HDAs, RAID Protection, SRDF Host Component, Symmetrix Manager

1996 – Symmetrix ESP – Mix CKD/FBA

1997 – Symmetrix 4.0 – TimeFinder, DataReach, InfoMover, Celerra, FDRSOS, Fibre Channel, PowerPath, UltraSCSI, DMSP

1998 – Symmetrix 4.8 – FC-AL/FC-SW, Symmetrix Optimizer

1999 – Symmetrix 5.0 – 333 MHz PPC, 181 GB disks, QoS Controls

2000- Symmetrix 5.5 – 2 GB fibre Channel, 400 MHz PPC

2000-2001 – Symmetrix DMX – Direct Matrix, 500 MHz PPC, 2 GB FC, Back-End Parity RAID

2001 – 2002 – Symmetrix DMX – 2 GB FICON, Gigabit Ethernet SRDF, iSCSI, SRDF/A, TimeFinder/Snap

2003- Symmetrix DMX-2 – 1 Ghz PPC, RAID 5 Data Protection, 32 GB Memory Directors

2003-2004- Symmetrix DMX-2- SRDF Mode Change, Concurrent SRDF, SRDF/Star, TimeFinder/Clone, Open Replicator

2005 – Symmetrix DMX-3 – 8 Processors/Directors, 1.3 GHz PPC, Low Cost FC Disks, Incremental Scalable, Upto 2400 disks, Open Migrator/LM

2005-2006 – Symmetrix DMX-3 – Dynamic Cache Partitioning, Symmetrix Priority Controls, Virtual LUN Technology, Symmetrix Service Credential, Tamper Proof Audit Logs, Secure Data Eraser, RAID 6 Protections.

2007- 2008 Symmetrix DMX-4 – 4GB/s Point to point Backend, FC & SATA Intermix, RSA enVision Intergration, Flash Drives, Virtual Provisioning Cascaded SRDF.

EMC RecoverPoint

Posted by Diwakar ADD COMMENTS

EMC RecoverPoint is a comprehensive data protection and data replication solution for the entire data center. RecoverPoint provides local replication using continuous data protection (CDP) and remote replication using continuous remote replication (CRR) of the same data. RecoverPoint protects companies from data loss by enabling local recovery from common problems such as server failures, data corruption, software errors, viruses, and end-user errors. RecoverPoint also incorporates remote recovery to protect against catastrophic data loss events that can bring an entire data center to a standstill. Enterprise performance, scalability, and instant recovery are combined to guarantee data consistency with recovery that takes seconds or minutes instead of hours or days.

RecoverPoint offers bi-directional local and remote replication with no distance limitation, guaranteed data consistency, and

advanced bandwidth reduction technology designed to dramatically reduce WAN bandwidth requirements and associated costs.

• End-to-end data protection – continuously protect data locally and remotely

• Any point-in-time recovery - ultimate flexibility in selecting the optimal recovery point using user-specified or application-specific bookmarks.

• Unique bandwidth compression and bi-directional replication, combined with write-order consistency enables application restartability.

• Heterogeneous data protection - one data protection and remote replication solution for CLARiiON, Symmetrix, and third-party arrays.

• Intelligent agents for Microsoft Exchange and SQL Server facilities intelligent protection and recovery, dramatically reducing application recovery time and minimizing or eliminating data loss

• Integration with CLARiiON CX3 array-based splitter to simplify local and remote replication.

• Integration with EMC Connectrix intelligent -fabric solutions using Brocade and Cisco technology.

EMC SRDF Mode

Posted by Diwakar ADD COMMENTS

Conceptually, even operationally, SRDF is very similar to Timefinder. About the only difference is that SRDF works across Symms; while Timefinder works internally to one Symm.That difference, intersymm vs intrasym, means that SRDF operations can cover quite a bit of ground geographically. With the advent of geographically separated symms, the integrity of the data from one symm to the other becomes a concern. EMC has a number of operational modes in which the SRDF operates. The choice between these operational modes is a balancing act between how quickly the calling application gets an acknowledgement back versus how sure you need to be that the data has been received on the remote symm.

Synchronous mode

Synchronous mode basically means that the remote symm must have the I/O in cache before the calling application receives the acknowledgement. Depending on distance between symms, this may have a significant impact on performance which is the main reason that EMC suggests this set up in a campus (damn near colocated) environment only.

If you're particularly paranoid about ensuring data on one symm is on the other, you can enable theDomino effect (I think you're supposed to be hearing suspense music in the background right about now...). Basically, the

domino effect ensures that the R1 devices will become "not ready" if the R2 devices can't be reached for any reason - effectively shutting down the filesystem(s) untilthe problem can be resolved.

Semi-synchronous mode

In semi-synchronous mode, the R2 devices are one (or less) write I/O out of sync with their R1 device counterparts. The application gets the acknowledgement as soon as the first write I/O gets to the local cache. The second I/O isn't acknowledged until the first is in the remote cache. This should speed up the application over the synchronous mode. It does, however, mean that your data might be a bit out of sync with the local symm.

Adaptive Copy-Write Pending

This mode copies data over to the R2 volumes as quickly as it can; however, doesn't delay the acknowledgement to the application. This mode is useful where some data loss is permissable andlocal performance is paramount.

There's a configurable skew parameter that lists the maximum allowable dirty tracks. Once that number of pending I/Os is reached, the system switches to the predetermined mode (probably semi-synchronous) until the remote symm catches up. At that point, it switches back to adaptive copy-write pending mode.



We have storage array product from different vendor. Everyone talkes about active-active and active-passive device technology. With different types of storage arrays and host connection types, it is important to understand the difference between active-active and active-passive devices. Here is short explanation of the differences:
Active-active (for example, Symmetrix arrays)
In an active-active storage system, if there are multiple interfaces to a logical device, they all provide equal access to the logical device. Active-active means that all interfaces to a device are active simultaneously.
Active-passive (for example, CLARiiON arrays)
Active-passive means that only one interface to a device is active at a time, and any others are passive with respect to that device and waiting to take over if needed.
In an active-passive storage system, if there are multiple interfaces to a logical device, one of them is designated as the primary route to the device (that is, the device is assigned to that interface card). Typically, assigned devices are distributed equally among interface cards. I/O is not directed to paths connected to a non-assigned interface. Normal access to a device through any interface card other than its assigned one is either impossible (for example, on CLARiiON arrays) or possible, but much slower than access through the assigned interface card.
In the event of a failure, logical devices must be moved to another interface. If an interface card fails, logical devices are reassigned from the broken interface to another interface. This reassignment is initiated by the other, functioning interface. If all paths from a host to an interface fail, logical devices accessed on those paths are reassigned to another interface with which the host can still communicate. EitherApplication-Transparent Failover (ATF) or PowerPath, which instructs the storage system to make the reassignment, initiates this reassignment. These reassignments are known as trespassing. Trespassing can take several seconds to complete. However, I/Os do not fail during it. After devices are trespassed, ATF or PowerPath detects the changes and seamlessly routes data via the new route. After a trespass, logical devices can be trespassed back to their assigned interface. This occurs automatically if PowerPath's periodic autorestore feature is enabled. It occurs manually if powermt restore is run, which is the faster approach. Or if ATF is in use, a manual restore of the path can be executed to restore the original path.

We have discussed regarding Symmetric DMX-3. Lets talk about Symmetrix Device. DMX-3 system applies a high degree of virtualization between what host sees and the actual disk drives. This device has logical volume address that the host can address. Let me clear that “A symmetrix Device is not a physical disk.” Before actually hosts see the symmetrix device, you need to define path means mapping the devices to Front-end director and then you need to set FA-PORT attribute for specific Host. Let not discuss configuration details now. I am trying to explain what Symmetrix device is if this is not physical disk and how it will be created.

You can create up to four mirrors for each Symmetrix device. The Mirror positions are designed M1, M2, M3 and M4. When we create a device and specify its configuration type, the Symmetrix system maps the device to one or more complete disks or part of disks known as Hyper Volumes/Hypers. As a rule, a device maps to at least two mirror means hypers on two different disks, to maintain multiple copies of data.

There is available WWN decoder tool for EMC but I am going to discuss how to decode manually?
Each Symmetrix SAF port, RAF port, EF ficon port or DAF port (DMX only) has a unique worldwide name (WWN). The WWN is associated with the Tachyon chip on the director. It was intended to remain unique per director so that the director can be accessed on a storage area network. The Symmetrix SAF/RAF/DAF/EF WWN is dependent on the Symmetrix serial number, the director number, the processor letter, and the port on the processor. When the SAF/RAF/DAF is inserted into the Symmetrix, it discovers the Symmetrix serial number and slot number and the WWNs are set for the ports on the director.

Symm 4/4.8/5 (2-port or 4-port) Fibre Channel front directors, the WWN breakdown are as follows:

The director WWN (50060482B82F9654) can be broken down (in binary) as follows:

First 28 Bits (from the left, bits 63-36, binary) of WWN are assigned by the IEEE (5006048, the vendor ID for EMC Symmetrix)

5006048 2 B 8 2 F 9 6 5 4
0010 1011 1000 0010 1111 1001 0110 0101 0100

0 A E 0 B E 5 9 -----------------------> AE0BE59 hex = 182500953 Symm S/N

Bits 36 through 6 represent the Symmetrix serial number; the decode starts at bit 6 and works up to 36 to create the serial number. This is broken down as illustrated above.

The least signifigant 6 bits (bits 5 through 0) can be decoded to obtain the Symmetrix director number, processor and port. Bit 5 is used to designate the port on the processor (0 for A, 1 for B). Bit 4, known as the side bit, is used to designate the processor (0 for A, 1 for B). The least signifigant 4 bits, 3 through 0, represent the Symm slot number.


01 0100 = 14 hex -----> director 5b port A

In review, this WWN represents EMC Symmetrix serial number 182500953, director 5b port A

For Symm DMX product family (DMX-1/2/3), the WWN breakdown are as follows:

The director WWN (5006048ACCC86A32) can be broken down (in binary) as follows:

Again, like Symm 4/5, the first 28 bits (63-36) are assigned by the IEEE

5006048 A C C C 8 6 A 3 2

1010 1100 1100 1100 1000 0110 1010 0011 0010

B 3 3 2 1 A 8 ----------------------> B3321A8 hex = 187900328 Symm S/N

Bit 35 is now known as the 'Half' bit and is now used to decode which half the processor/port lie on the board.

Bits 34 through 6 represent the serial number; the decode starts at bit 6 and works up to bit 34 to create the serial number. This is broken down as illustrated above.

In conjunction with bit 35, the last 6 bits of the WWN represent the director number, processor and port. Bit 35, the 'Half' bit, represents either processor A and B, or C and D (0 for A and B, 1 for C and D). Bit 5 again represents the port on the processor (0 for A, 1 for B). Bit 4, the side bit, again represents the processor but with a slight change (if 0 then port A or C, if 1 then port B or D, depending on what the half bit is set to). The last 4 bits, 3 through 0, represent the Symm slot number.

1 11 0010 -------> half bit = 1 (either processor C or D), port bit = 1 (port B), side bit = 1 (because half = 1, looking at C and D processors only, side = 1 now means processor D)
0010 hex = 2 decimal (slot 2 or director 3)

In review, the WWN of 5006048ACCC86A32 represents EMC Symmetrix serial number 187900328, director 3d port B


Generally we never give thought about VCMDB database once we initialize first time. It does make sense when you messup or did some thing disaster. This database is most impppppportaaaaaaant for DMX. Once you loose this database means you can't get DMX configuration back at any cost. So, I am discussing different type of VCMDB on DMX.

We can now support up to 16,000/64000 addressable devices enginuity 5771 onward and therefore the Volume Control Manager Database needs to be physically larger. At 5670, as per EMC recommend CE's were encouraged to create 96 cylinder (minimum) VCMDB during new installs. This was to cater for future upgrades to 5671.

To summarize the VCMDB type applicable to DMX :

Type 3 - this can cater for 32 fibre or iSCSI initiators per port. Introduced with Enginuity 5669 and requires a 24 cylinder (minimum) VCMDB and Solutions Enabler v5.2.

Type 4 - this can cater for 64 fibre or 128 iSCSI initiators per port. Introduced with Enginuity 5670 and requires a 48 cylinder (minimum) VCMDB and Solutions Enabler v5.3.

• Type 5 - this can support 64 fibre or 128 iSCSI initiators per port AND cater for 16,000 devices. Introduced with Enginuity 5671 and requires a 96 cylinder (minimum) VCMDB and Solutions Enabler v6.0. (Note: without a type 5 96cyl VCMDB and SE 6.0 you will be restricted to 8192 logical volumes as in 5670).

Type 6 - this can support 128 fibre or 256 iSCSI initiators per port AND cater for 32,000 devices available on DMX-3 with Enginuity 5771 (at GA release). Currently the Type 6 database (at latest Enginuity 5771 with Solution Enabler 6.0 and above) will cater for 256 fibre or 512 iSCSI initiators and 64,000 logical devices.

What is requirement for Type 5:

The three requirements for a Type 5 VCM database on DMX (and support for up to 16,000 customer addressable volumes) is a correctly configured 96 cylinder VCMDB device, Enginuity 5671 and Solutions Enabler v6.0 or above. Note that the VCMBD “type” reflects the internal data structure of the Volume Control Manager Database. Therefore a 96 cylinder VCMDB size does NOT mean that you have a Type 5 VCMDB.

Note:
• At 5670 with a 48 cylinder VCMDB it is still type 4.
• At 5670 with a 96 cylinder VCMDB it is still type 4.
• At 5670 with a 96 cylinder VCMDB and SE 6.0 it is still type 4 - do not try to convert the database using the SYMCLI (EMC do not support more than 8192 logical volumes at 5670).
• At 5671 with a 48 cylinder VCMDB and SE 6.0 it is still type 4 - the VCMDB is NOT physically large enough.
• At 5671 with a 96 cylinder VCMDB and SE 5.5 it is still type 4 - the VCMDB is large enough but SE 5.5 does not support the Type 5 database.
• At 5671 with a 96 cylinder VCMDB and SE 6.0 it is a type 5 database - if you have run the “symmaskdb convert -vcm_type 5” command. Be aware that if you convert from a lower type database to a higher type, any hosts running a Solutions Enabler version that does not support the higher VCMDB type will NOT be able to access the "new" database.
• At 5771 (DMX-3) the VCMDB data now resides in the SFS volumes. At 5771 the VCMDB should be configured the SAME size as a standard FBA gatekeeper (this can be 3 cylinders due to the 64KB track size but 6 cylinder, as recommended in some guides, is also perfectly acceptable) but it must still be assigned the VCM fibre gatekeeper status. Note that the VCMDB "gatekeeper" on DMX-3 is no longer shown as "write disabled" (it is now a "gatekeeper" rather than a physical volume used for physical storage - the Volume Control Manager data is protected and stored on the internal SFS volumes).
• Note that Enginuity 5771 will ONLY support a Type 6 VCM database (again the data is resident on the SFS volumes). This re-location of the physical database to the SFS volumes caters for the increased host connectivity AND the increase in logical volumes supported with DMX-3.

About Me

My photo
Sr. Solutions Architect; Expertise: - Cloud Design & Architect - Data Center Consolidation - DC/Storage Virtualization - Technology Refresh - Data Migration - SAN Refresh - Data Center Architecture More info:- diwakar@emcstorageinfo.com
Blog Disclaimer: “The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.”
EMC Storage Product Knowledge Sharing