New Features in EMC Enginuity 5874 for Symmetrix Mainframe ... · PDF fileNew Features in EMC Enginuity 5874 for Symmetrix Mainframe Environments ... EMC Enginuity 5874 for Symmetrix

New Features in EMC Enginuity 5874 for Symmetrix Mainframe Environments

A Detailed Review

Abstract

This white paper discusses the many new features and functionality introduced with EnginuityTM 5874 for EMC® Symmetrix® VMAXTM subsystems in the IBM mainframe environment.

May 2010

Copyright © 2009, 2010 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com

All other trademarks used herein are the property of their respective owners.

Part Number h6203.1

New Features in EMC Enginuity 5874 for Symmetrix Mainframe Environments A Detailed Review 2

Table of Contents Executive summary ............................................................................................4 Introduction.........................................................................................................4

Audience ...................................................................................................................................... 5 Storage device support ......................................................................................5

Drive technologies supported ...................................................................................................... 5 FICON.......................................................................................................................................... 5 Persistent IU Pacing (Extended Distance FICON) ...................................................................... 6

Storage utilization and optimization .................................................................7 512 hypers per physical ............................................................................................................... 7 Large volume support of Extended Address Volumes and 3390 Model A .................................. 7

Track managed and cylinder-managed space......................................................................... 8 Large volume benefits .............................................................................................................. 8 Addressing performance .......................................................................................................... 9

Virtual LUN (VLUN) migration feature ......................................................................................... 9 Replication capabilities .............................................................................................................. 11

TimeFinder improvements...................................................................................................... 11 SRDF improvements .............................................................................................................. 12 SRDF/EDP in combination with SRDF/Star ........................................................................... 16

Additional capabilities......................................................................................19 RAID Virtual Architecture ........................................................................................................... 19 Serial number changed to alphabetic ........................................................................................ 19 System Management Facility record 74 subtype 8.................................................................... 20

Conclusion ........................................................................................................21 References ........................................................................................................21


Executive summary The availability of Enginuity™ 5874 with the new EMC® Symmetrix® VMAX™ platform provides the mainframe user with significantly enhanced functionality aimed at addressing a substantially higher degree of cost-effectiveness, unparalleled configurational flexibility, and higher degrees of performance, availability, reliability, and serviceability. In fact, the revolutionary design of the new hardware platform builds on the experience and robustness of the very popular Symmetrix DMX-3 and DMX-4 subsystems currently deployed at so many customer locations worldwide.

The Enginuity storage operating environment provides the intelligence that controls all components in an EMC Symmetrix storage array.

Enginuity is an intelligent, multitasking, preemptive storage operating environment that controls storage data flow. It is wholly devoted to storage operations and optimized for the service levels required in high-end environments. While it shares many traits with the operating systems typically used to run large host computers, Enginuity is more specialized and specifically optimized for storage-based functions. It is driven by realtime events related to the input and output of data. It applies self-optimizing intelligence to deliver the ultimate performance, availability, and data integrity required in a platform for advanced storage functionality. A prerequisite for complex, demanding, risk-intolerant IT infrastructures, Enginuity—coupled with Symmetrix—is the essential foundation technology for delivering advanced and cost-effective high-end storage services.

Enginuity, as a proven storage operating environment, carries all of its extended and systematic development forward in each successive Symmetrix platform generation — a major operational and investment protection benefit to users. That means that all of the reliability, availability, and serviceability features, all of the interoperability and host operating systems coverage, and all of the application software capabilities developed by EMC and its partners continue to perform productively and seamlessly even as underlying technology is completely refreshed. All of these features and capabilities are fully operational from day one in each Symmetrix release.

In short, Enginuity 5874 continues the long tradition started with its predecessor releases in continually resetting the functionality benchmarks to unparalleled levels, thereby offering its users uncompromising choices.

Introduction This white paper discusses the many new and updated mainframe features offered by Enginuity 5874. It is organized into three main sections: “Storage device support,” “Storage utilization and optimization,” and “Additional capabilities.” Within the “Storage device support” section starting on page 5, the drive technologies supported are presented followed by a discussion of FICON on Symmetrix VMAX, and also Persistent IU pacing, which is also known as Extended Distance FICON. These topics are timely in that many mainframe customers are actively involved in implementing these technologies for a number of performance and fiscal reasons. The “Storage utilization and optimization” section on page 7 opens with a discussion of the increased number of hypervolumes per physical spindle - a highly necessary requirement given the ever-increasing capacities of the individual spindles. This is followed by a detailed treatment of large volume support, which is known as Extended Address Volumes or 3390A; this feature of z/OS 1.10 announced in February 2008 is quickly becoming a sought after feature as many customers streamline their volume configuration and usage. The next topic is the Virtual LUN migration feature; this is a welcomed feature in the many advanced z/OS environments that intend to make full use of the myriad of drive technologies for cost and performance tradeoffs. The replication capabilities discussed include TimeFinder® improvements - substantial indeed, given that it is a marked departure from mirroring, which had become an EMC hallmark, concurrent R2 support (R22), cascaded clone, 64K device support, Diskless RDF devices, and FlashCopy and TimeFinder co-existence at the device level. The SRDF® improvements are many, and


include the following: an increased number of RDF groups, SRDF/Extended Distance Protection, concurrent R2 (R22) support with SRDF/Star, SRDF/EDP in combination with SRDF/Star, two-mirror RDF Enginuity Consistency Assist, remove devices from SRDF/A (consistency exempt), converting PPRC devices to SRDF devices and vice versa, and SRDF/A Secondary Consistent. The “Additional capabilities” section on page 19 covers the RAID Virtual Architecture, the subsystem Serial number change from numeric to alphabetic, and the new System Management Facility record 74 subtype 8.

Audience This white paper is intended for technology professionals who need to understand the new IBM System z support features included in Enginuity 5874.

The focus of this white paper is on the new Enginuity 5874 features for mainframe environments. For details of features for the open systems environments, see the white paper New Features in EMC Enginuity 5874 for Symmetrix Open Systems Environments.

Storage device support

Drive technologies supported Symmetrix VMAX with Enginuity 5874 will support only 4 Gb drives of various capacities and speeds as follows:

• Ultra-high performance: Flash (SSD) 200 GB 400 GB

• High performance: 4 Gb FC (15k) 146 GB 300 GB 450 GB

• Price / performance: 4 Gb FC (10k) 400 GB

• High capacity: SATA (7.2k) 3 Gb/s SATA - Adapted to 4 Gb/s FC using NorthStar 1 TB capacity

These disk drives form an extensive price performance offering that, when coupled with the capabilities of Symmetrix Virtual LUN (discussed later), offers the customer an unprecedented ability to execute on their most ambitious cost saving plans without sacrificing performance or availability. All drives are formatted at 520-byte sectors, except for System i devices, which are formatted at 528-byte sectors.

FICON FICON support on the Symmetrix VMAX platform is functionally and structurally equivalent to the FICON support on the Symmetrix DMX™ platform. Functionality is still split between the EMULATION and the LINK processes, and there is no change in the relationship and the responsibilities of either the EMULATION or the LINK. However, it is important to recognize that some terminology has changed in going from the Symmetrix DMX to Symmetrix VMAX. With the DMX, the terms “EMULATION CPU” and “LINK CPU” are used; on the Symmetrix VMAX the terms “EMULATION Instance” and “LINK Instance” are used.


A DMX slice, which consists of an EMULATION CPU and a LINK CPU, is called an EMULATION/ LINK (instance) pair on the Symmetrix VMAX. Enginuity 5874 with Symmetrix VMAX introduces two-port support for the FICON instances and provides support for a total of 64 FICON channels. Each high availability (HA) node of Symmetrix VMAX contains two directors. As illustrated in Figure 1, each director board has eight CPU cores (left side of diagram), each of which supports a static instance such that the instance is bound to its respective core. Four of those static instances provide four DA emulations for device connectivity, and when this director is configured for FICON, the other four instances provide two FICON emulations (the EF 7E and EF 7G, using director 7 as an example) per director. These two FICON emulations per director can support two FICON ports each; thus four FICON ports per director, and eight FICON ports per HA node as illustrated on the right side of Figure 1. Symmetrix VMAX can be configured with a minimum of one HA node to a maximum of eight HA nodes; thus an all FICON configured subsystem can support from eight to 64 fully provisioned independent FICON ports. This is the first multi-port solution for FICON to be offered on any Symmetrix series, and unlike earlier ESCON implementations, these two FICON ports are, and will operate as, fully provisioned independent ports. Each FICON instance pair can support either one or two ports with both physical ports managed by the LINK instance (EE slice); for any FICON instance pair, either or both of the ports may be physically cabled. The Emulex FICON I/O module has two SFP connectors - one for each port. The worldwide port names are based on EF slice.

MemoryGlobal Memory

Local mem (LM)

Inst 1 Inst 2

Inst 3 Inst 4

Inst 5 Inst 6

Inst 7 Inst 8

Core Core

Core Core

Core

Core

Core

Core

IO Module

IO Module

IO Module

Dir 7 Dir 8

EE

EF

EE

EF

EF-7G

EF-7E

DA

DA

DA

DA

DA-7DDA-7CDA-7BDA-7A

EE

EF

EE

EF

EF-8G EF-8E

DA

DA

DA

DA

DA-8DDA-8CDA-8BDA-8A

HA NODE IO Module

QUAD CORE CPU

QUAD CORE CPU

Figure 1. A single high availability (HA) node of Symmetrix VMAX

Since the Symmetrix VMAX can only be configured as control unit type 2107, all of the channel commands defined in the 2107 command and feature set are supported. Also, FICON supports a set of commands based on the 3370 command set, which allows access to Fixed Block Architecture (FBA) devices. Support is provided for all of the standard 3380 and 3390 devices sizes, in addition to the various custom sizes.

Persistent IU Pacing (Extended Distance FICON) Enginuity 5874 provides support for the recently proposed Persistent Pacing mechanism known as Persistent IU Pacing, or Extended Distance FICON.


Persistent IU Pacing is an amendment to the FICON specifications, and it describes a method for allowing a FICON channel to retain a pacing count that can be used at the start of execution of a channel program. This may improve performance of long I/O programs at higher link speeds and long distances by allowing the channel to send more IUs to the control unit, thereby eliminating the delay of waiting for the first command response.

Host support for this feature is exclusive to the IBM z10 Processors running Driver 73 with MCL F85898.003 or Driver 76 MCL N10948.001. Extended Distance FICON is transparent to the z/OS operating system and applies to all the FICON Express2 and FICON Express4 features carrying native FICON traffic (CHPID type FC).

For exploitation of this feature, the control unit must support the new IU pacing protocol, which is detected during the ELP – LPE sequence. The channel will default to current pacing values when operating with control units that cannot exploit Extended Distance FICON.

XRC configurations typically utilize channel extenders between the remote host and the primary controller. These channel extenders normally use a form of "spoofing" to analyze the CCW chains and they modify them to avoid data droop, which is caused by the extra round trips required in a long distance environment. Persistent IU Pacing will allow the same functionality and performance benefit without the additional cost of the channel extenders.

Storage utilization and optimization

512 hypers per physical Enginuity 5874 introduces a sizable increase in the number of hypervolumes configurable per physical disk drive; it is now possible to configure up to 512 hypervolumes - up from 256. Increasing the number of hypervolumes is mandated due to the ever increasing drive capacities being offered. This feature offering, referred to as splitting or slicing, makes it possible for the customer to retain their ability to customize the logical volume capacities to sizes that are suitable, and appropriate, for the respective applications, thereby ensuring minimal loss of usable space on the physical drive.

Large volume support of Extended Address Volumes and 3390 Model A Enginuity 5874 also introduces the ability to create and utilize logical volumes that can be up to 262,668 cylinders in size. This large volume size matches the capacity announced in z/OS 1.10 for 3390 Extended Address Volumes (EAV). These large volumes are supported as an IBM 3390 format with a capacity of up to 223 GB and are configured as 3390 Model As. Note that a 3390 Model A can be defined with 1 to 262,688 cylinders, but IBM defines an EAV to be any volume with greater than 65,520 cylinders, thus an EAV is just a proper subset of a 3390 Model A. An EAV, though currently limited to 262,668 cylinders, has a defined architectural limit of 268,434,453 cylinders.

With Enginuity 5874, large volumes may be configured and used in a similar manner to the old, regular devices that users are already familiar with. While large volumes can co-exist alongside the older volumes there are limitations to their use imposed by certain access methods (operating system restrictions), and other independent vendors’ software.

The collected reference to the space above 65,520 cylinders is known as the extended addressing space (EAS), while the space below 65,520 cylinders is referred to as the base addressing space. Today, the major exploiter of the EAS portions of EAVs are applications using any form of VSAM (KSDS, RRDS, ESDS and linear); this covers DB2, IMS, CICS, zFS, and NFS. A few restrictions are notable with z/OS 1.10 with respect to VSAM datasets not supported in the EAS; they are catalogs, pagespaces, VVDS datasets, and those with KEYRANGE or IMBED attributes.


Track managed and cylinder-managed space As illustrated in Figure 2, the current implementation of EAVs is such that it is managed as “track-managed” space and “cylinder-managed” space. Track-managed space, also known as the base addressing space, is referred to in tracks and cylinders and is the same as what already exists in non-EAV volumes - it is what a user is already comfortable with today. Track-managed space uses the old 16-bit cylinder addressing (CCHH) scheme. All dataset types are supported in track-managed space – just as they are in non-EAV environments.

Cylinder-managed space is new with EAVs in that it references the space above 65,520 cylinders (the EAS mentioned earlier) in multi-cylinder units with each unit currently consisting of 21 cylinders; cylinder-managed space exists only on EAVs. Also new with EAVs is the introduction of two new DSCBs, the Format 8 and Format 9 DSCBs – the extended address DSCBs, new track addressing (CCCCcccH), new mappings, and changed macros. Cylinder-managed space is addressed using the 28-bit cylinder addressing (CCCCcccH) scheme.

for Symmetrix Mainframe Environments A Detailed Review 8

EAV

Cylinder-managed space (cylinders above 65,520)

Extended Addressing

Space (EAS)

Track-managed space (cylinders below 65,520)

Base Addressing

Space

Figure 2. Extended Address Volume (EAV) – space designation

Large volume benefits Large volumes offer the ability to consolidate many smaller volumes onto a single device address. This, in turn, goes a long way in solving the sprawling device configurations that placed users at the Logical Partition (LPAR) device limit of 65,280 devices. In fact, the two main culprits of device sprawl in many environments are the excessive and prolonged use of very small volume sizes (3390-3, 3390-9, etc.), and the significant and growing business continuity requirements as business applications proliferate.

Not only are large volumes an important component in the device consolidation strategy, but it is quickly recognized as an even more vital component in providing the very high z/OS subsystem capacities required by the newer class of applications running on the ever more powerful processors. In short, even with a few addresses configured with these large capacities, the result is very large subsystem capacities.

One of the stated goals of large volumes and the accompanying reduction of device addresses required to support them is the overall simplification of the storage subsystem and hence, the reduction of storage management costs. This has a direct impact on storage personnel productivity, and proves to be a strong determinant in its adoption.

Last, but certainly not least, is the reduction of processor resources associated with multi-volume usage and processing since datasets and clusters can now be wholly contained within large enough single extents, thereby relegating multi-volume extents and their drawbacks to something of user preference and choice

New Features in EMC Enginuity 5874

rather than necessity. The reduction in frequency of OPEN/CLOSE/End of Volume processing will help expedite many currently long running batch jobs.

Addressing performance A large volume is defined to a single device address as described earlier, and hence will suffer performance degradation if unable to sustain the required level of I/O parallelism either on a sustained basis, or on those demanding peak occasions. Fortunately, the use of HyperPAVs, available on DMX since Enginuity 5773, and with continued support on Symmetrix VMAX with Enginuity 5874, can provide truly dynamic levels of I/O parallelism to suit the large volume’s levels of activity. In fact, the combination of FICON channel access coupled with HyperPAV ensures high I/O parallelism to any or all volumes with the subsystem; this forms a binding basis for a performance guarantee.

EAV support has been added to the SQ VOL and SQ MIRROR commands of the SRDF Host Component for z/OS. Invalid track counts greater than 9999 are displayed in K units (thousands) up to 999K, and counts greater than 999K are displayed in M units (millions). The usage of K and M are such that 1K = 1024 and 1M = 1000*1K. Please refer to the EMC SRDF Host Component for z/OS Version 7.0 Product Guide for further details.

Virtual LUN (VLUN) migration feature This new feature offered across open systems, System z, and System i environments enables the migration of Symmetrix logical volumes between disk types as well as protection types, thereby providing the ability to nondisruptively change either, or both, the disk type and the protection type of the volumes. These FBA, CKD, or System i volumes, respectively, can be migrated to either unallocated space, also referred to as unconfigured space (space for which there are no hypers assigned), or to configured space, which is defined as existing Symmetrix volumes that are not currently assigned to a host - existing, not-ready volumes - within the same subsystem. The data on the original source volumes is cleared using instant VTOC once the migration has been deemed successful. The migration does not require swap or DRV space, and is nondisruptive to the attached hosts and other internal Symmetrix applications such as TimeFinder and SRDF.

The valid migration combinations are summarized in the following tables in Figure 3; they encompass a change in drive type (blue table) or protection type (yellow table), or a combination of drive type and protection type.



Figure 3. Virtual LUN Eligibility Tables The device migration is completely transparent to z/OS since the operation is executed against the Symmetrix device; thus the Unit Control Block (UCB) address, or the Symmetrix internal device number (SYMDV#), are not changed and accessing applications and storage management personnel need not be actively involved in the process itself. Further, in SRDF environments, the migration does not require customers to re-establish their disaster recovery protection after the migration. Note that the SYMDV# is the Symmetrix internal device number that is a unique value – device address – assigned to each logical volume present within a Symmetrix subsystem; this number is used internally by Enginuity, and is never seen by any accessing host or application. This Virtual LUN feature leverages the newly composed virtual RAID architecture in Enginuity 5874, which abstracts the device protection from its logical representation to a host. This powerful approach allows a device to have more simultaneous protection types such as BCVs, SRDF, concurrent SRDF, and spares. It also enables seamless transition from one protection type to another while hosts and their associated applications and Symmetrix software are accessing the device. This new architecture is a significant, discontinuous change from previous RAID implementations and is only available with the Symmetrix VMAX platform.

This feature offers the z/OS community a long awaited capability to utilize SATA storage - a much cheaper, yet reliable, form of capacity storage. It also enables a true fluid movement of data across the various storage tiers present within the subsystem – the realization of true “tiered storage in the box.” Thus, Symmetrix VMAX becomes the first enterprise storage subsystem to offer a comprehensive “tiered storage in the box,” ILM capability that complements customers’ SMS and HSM initiatives completely. Customers can now achieve varied cost/performance initiatives by moving lower priority application data to less expensive storage, or conversely, moving higher priority or critical application data to higher performing storage as their needs dictate.

DRIVE TYPE

yyySATA

yyyFibreChannel

yyyFlash

SATAFibreChannelFlash

xyyyUN-PROTECTED

xyyyRAID-6

xyyyRAID-5

xyyyRAID-1

UN-PROTECTED

RAID-6RAID-5RAID-1

PROTECTION TYPETO:

FROM:

TO:

FROM:

DRIVE TYPE

yyySATA

yyyFibreChannel

yyyFlash

SATAFibreChannelFlash

xyyyUN-PROTECTED

xyyyRAID-6

xyyyRAID-5

xyyyRAID-1

UN-PROTECTED

RAID-6RAID-5RAID-1

PROTECTION TYPETO:

FROM:

TO:

FROM:


Replication capabilities

TimeFinder improvements The classic underlying Enginuity mechanism responsible for creating mirrored local replicas will no longer be supported with Enginuity 5874 microcode. However, the classic TimeFinder/Mirror user command sets will continue to be supported by TimeFinder/Clone using TimeFinder/Mirror’s Clone Emulation capabilities. This is illustrated in Figure 4. Thus, starting with Enginuity 5874, there is a single technology in use, clone emulation. Further, whenever TimeFinder/Mirror detects a Symmetrix subsystem running at Enginuity level 5874 and later, it will automatically set the mode to clone emulation. The TimeFinder family products may be used with SRDF/Automated Replication for z/OS and SRDF/Star for z/OS.

Prior to 5874

With 5874

Figure 4. TimeFinder/Mirror and TimeFinder/Clone relationship with Enginuity 5874 TimeFinder/Clone for z/OS is documented as the TimeFinder/Clone Mainframe SNAP Facility. It is the code and documentation associated with making full-volume snaps and dataset-level snaps; these are space-equivalent copies, meaning that the source and the target consume equal space.

TimeFinder/Snap uses the code and documentation from TimeFinder/Clone Mainframe SNAP Facility, but with an important difference. Snaps made with this product are virtual snaps. Virtual snaps take a smaller portion of the space that a full-volume snap would and makes use of a feature known as virtual devices (VDEVs). VDEVs are space-efficient copies that consist of tables and pointers to capture a point in time. In general, virtual devices can be either CKD or FBA. Virtual devices are host accessible and do not consume physical storage. However, because they are host addressable, virtual devices require host addresses; they also consume Symmetrix internal device numbers.

TimeFinder/Snap is implemented through the keyword VDEV, and the operation requires the existence of a snap pool. When the VDEV argument is used, only the pre-update image of the changed data plus a pointer is kept on the target; this reduces disk space usage on the target side considerably. A snap pool is a collection of snap pool devices that are used as the physical devices upon which the pre-update images of the tracks changed on the source device, or new writes to the virtual devices are stored. As specific virtual device sessions are terminated, the space associated with them is returned as free space in the snap pool. The Symmetrix subsystem must be sufficiently configured with virtual and snap pool devices in order to use TimeFinder/Snap.


Concurrent R2 (R22) support Starting with TimeFinder version 7.0, and available with Enginuity 5874, TimeFinder/Mirror recognizes concurrent R2 devices. A concurrent R2 device is a special R2 device that has the unique properties of having two RDF mirrors ascribed to it such that each R2 mirror is paired with a different R1 mirror, and only one of the R2 mirrors can be read/write on the SRDF links at any given time. While designed primarily for enhancing the robustness of the SRDF/Star topology, R22 devices can be used for both concurrent and cascaded operations. TimeFinder/Mirror treats R22 devices like R2 devices. However, an R22 device cannot be a BCV device. Enginuity does not support BCVs with more than one RDF Mirror.

Cascaded clone TimeFinder/Clone Mainframe SNAP Facility now supports “cascaded” full volume clone operations. Cascaded clones is the ability for a clone operation to take place with a device that is already involved in a clone operation. For example, if a full volume clone exists from device A B, Enginuity will now allow another clone operation from device B C without requiring that the A B relationship be terminated. This means that subsequent differential resynchronizations can now be performed from A B. Note that while the B C session can be created after A B is in session, it cannot be activated until all data has been copied from A B.

TimeFinder/Mirror version 7.0 with Enginuity 5874 also provides some support for cascaded clones via its clone emulation feature. Please refer to TimeFinder/Mirror documentation for details.

EAV support TimeFinder/Mirror version 7.0 with Enginuity 5874 provides support for Extended Address Volumes (EAVs). EAVs are discussed in the section “Large volume support of Extended Address Volumes and 3390 Model A” on page 7. Also in this version and with Enginuity 5874, the QUERY command will provide support for EAVs; the extended QUERY output will show EAV devices in under #CYLS and the extended mode TRACK COUNT field.

64k device support TimeFinder/Mirror version 7.0 with Enginuity 5874 now supports up to 64k device addresses.

Diskless RDF devices TimeFinder/Mirror version 7.0 with Enginuity 5874 recognizes diskless R21 devices. However, it does not allow any I/O operations to be executed to any of these devices, and any attempt to do so results in an error message. Diskless RDF devices are discussed in more detail in the “SRDF/Extended Distance Protection ” section on page 13.

Thin devices TimeFinder/Mirror with Enginuity 5874 does not support thin device operations. A thin device cannot be an STD or BCV device.

FlashCopy and TimeFinder With Enginuity 5874, FlashCopy and TimeFinder operations can be done to the same device, where previously this would have been problematic unless the default for TimeFinder had specified the use of FlashCopy CCWs. With Enginuity 5874 this no longer needs to be specified.

SRDF improvements Enginuity 5874 and the new platform support a number of SRDF enhancements, which are discussed in this section.

RDFGRPs With Enginuity 5874, the per-port RDFGRP limit has been increased from 32 to 64, and the total subsystem limit increased from 128 to 250 as indicated in Figure 5. These increased limits, which were in direct response to many customers’ suggestions, offer significantly enhanced configuration capabilities and will help in maintaining SRDF as the premier business continuity topology of choice. Collectively, these increases provide for better granular control of data center applications, even as customers continue to scale out the subsystems to encompass higher and higher capacities; customers will be able to separate applications into independent SRDF groups and manage them accordingly – this contributes in a big way to overall operational simplicity. New Features in EMC Enginuity 5874 for Symmetrix Mainframe Environments A Detailed Review 12

63 Groups per

63 Groups per

62 Groups per

62 Groups per

63 Groups per

63 Groups per

62 Groups per

62 Groups per

= 250

Figure 5. RDFGRP increased limits with Enginuity 5874

The number of SRDF logical links supported per RA port will remain at 251 links. A “link” is defined as the combination of a local RA, remote RAs, and an SRDF group. For example, if the local RA is connected to four remote RAs, and the local RA as well as the remote RAs all support the same 10 RDF groups, then the local RA would have 40 SRDF logical links. If the local RA supports the maximum of 64 RDF groups, and all four remote RAs support the same 64 RDF groups then the local RA would have 256 links; however, since an RA can only support 251 links, some of the connections would not be made.

SRDF/Extended Distance Protection Enginuity 5874 supports a new feature called SRDF/Extended Distance Protection (SRDF/EDP). This feature allows a much more optimized and efficient structure to a three-site SRDF topology in that it allows the intermediate site – Site B, in an A to B to C topology – to have a new device type known as a diskless R21 as illustrated in Figure 6. This arrangement requires that the Secondary (Site B) subsystem to be at Enginuity 5874, while Sites A and C could be running either Symmetrix DMX-4 with Enginuity 5773 or Symmetrix VMAX with Enginuity 5874. Thus, SRDF/EDP allows replication between the primary Site A and tertiary Site B without the need for BCV/R1s, or any local replication, at the secondary Site B.



Primary Site A

Enginuity 5773 or

Secondary Site B

Enginuity 5874

Tertiary Site C

Enginuity 5773 or 5874 5874

Figure 6. SRDF/Extended Distance Protection (SRDF/EDP) and diskless R21 This diskless R21 differs from the real disk R21 that was introduced in Enginuity 5773 and had three copies of user data – one at each of the three sites. The diskless R21 device is a new type of device that does not have any local mirrors. Further, it has no local physical disk space on which to store the user data, hence it reduces the cost of having disk storage in the site B subsystem. This results in only two full copies of data, one on the primary Site A and one on the tertiary Site C.

The purpose of a diskless R21 device is to cascade data directly to the remote R2 disk device. When using a diskless R21 device, the changed tracks received from the R1 mirror are saved in cache until these tracks are sent to the R2 disk device. Once the data is sent to the R2 device and the receipt of the transmission is acknowledged, the cache slot is freed and the data no longer exists on the R21 Symmetrix.

This meritorious approach to three-site SRDF means that a customer will only need a Symmetrix VMAX subsystem with vault, spares, and SFS drives (minimum 48 drives per node – 40 for vault and 8 for permanent spares) and sufficient cache, thereby reducing the overall three-site solution cost. This highlights a serious attempt to address a “greener alternative” to the device sprawl brought about by multi-site business continuity requirements and is sure to be welcomed by many customers deploying three-site DR solutions. The R21 diskless device will consume a Symmetrix internal device number. Further, the R21 is not addressable by a host, nor is it assigned to a device adapter (DA) and hence, it cannot be accessed for any host system I/Os. Other restrictions on diskless R21 devices include the following:

They can only be supported on GigE and Fibre Channel directors. (Note that Symmetrix VMAX does not support ESCON.)

They cannot participate in dynamic sparing. They cannot be SRDF paired with other diskless devices, so cascaded R21 to another R21 is not

permitted. When diskless R21 devices are used for SRDF/A operations, all devices in that particular SRDF/A

session must be diskless; diskless devices cannot be mixed with non-diskless device types (real devices) in the same SRDF/A session - no mix of diskless and legacy R21s.

All Symmetrix replication technologies other than SRDF (TimeFinder, Snap, and Clone) will not function with diskless devices configured as either the source or the target of the intended operation.

The following table summarizes the legitimate modes of SRDF on the various recovery legs when using the diskless R21 (DL R21), that is, R1 DL R21 R2:


Table 1. SRDF modes for diskless R21

R1 R21 R21 R2

Synchronous Asynchronous

Adaptive Copy – DISK Asynchronous

Adaptive Copy – WP Asynchronous

Synchronous Adaptive Copy – WP

Adaptive Copy – DISK Adaptive Copy – WP

Adaptive Copy – WP Adaptive Copy – WP

Concurrent R2 (R22) support with SRDF/Star With Enginuity 5874 and SRDF Host Component 7.0, SRDF/Star configurations with concurrent R2 SRDF sites are possible. Similar to concurrent R1 devices that are referred to as R11 devices, concurrent R2 devices are referred to as R22 devices.

As shown in Figure 7, this functionality is based on a new concurrent R2 feature that allows an R2 device to have two SRDF mirrors. Each R2 mirror is paired with a different R1 mirror and only one of the R2 mirrors can be R/W on the SRDF links at a time.

Figure 7. Concurrent R2 (R22) support with SRDF/Star


The intended use for R22 devices is to simplify failover situations in SRDF/Star configurations and to improve the resiliency of SRDF/Star applications. The use of R22 devices in an SRDF/Star environment significantly reduces the amount of steps involved in some of the long running procedures (such as reconfigure, switch, connect), thus enabling the command sequences to finish quicker than was the case previously. While designed primarily for SRDF/Star, R22 devices can be used for both concurrent and cascaded SRDF operations.

In the current three-site SRDF/Star environment, the recovery and protection of the remaining two surviving sites require the following operational steps to achieve protection: Delete Pair – Clears previous pair relationships, Create Pair – Creates new pair relationships, Differential Synchronization, Protection. Using the R22 approach, the steps are simplified to just: Differential Synchronization, and Protection.

Operational simplicity is achieved through the R22’s ability to act as a "pre-create" of the failover environment, thereby removing the current requirement of deciding what devices to pair up at the time of failure. Operational resiliency is achieved through differential resynchronizations using the R22 during failure. Prior to the existence of an R22, if there was a failure during the "delete pair, create pair" reconfiguration steps, customers could have to perform a full data synchronizations for the failed pairs - a sizable disadvantage.

In Figure 7, assuming concurrent SRDF (Site A to B with SRDF/S, and Site A to C with SRDF/A), a site-level disaster event at A would only require differential resynchronization between Sites B and C. There would no longer be a need to do the Createpair or Deletepair as was done in legacy environments.

In a similarly advantageous manner, again referring to Figure 7, but assuming a cascaded SRDF relationship (Site A to B with SRDF/S, and Site B to C with SRDF/A), a site-level disaster event at B would only require differential resynchronization between Sites A and C, and again, there would no longer be a need to do the Createpair or Deletepair required by legacy environments.

SRDF/EDP in combination with SRDF/Star SRDF/EDP, discussed earlier, can be combined with SRDF/Star to offer a robust three-site solution leveraging the flexibility of the diskless R21. From a pure cost perspective, it reduces the overall investment in the hardware required while potentially simplifying the operational requirements for this three-site business continuity solution.

Figure 8 illustrates a cascaded SRDF/Star EDP diskless environment with an R2 device at the asynchronous remote target site. The diskless R21 device streamlines the linkage connections out to the remote R2 at the asynchronous target site in cascaded mode. No data copies are available at the diskless Site B.

All three-site advanced replication solutions for z/OS require the use of EMC’s Geographically Dispersed Disaster Restart (GDDR) product. GDDR is outside the scope of this paper and the reader is referred to the GDDR documentation on Powerlink.



Figure 8. Cascaded SRDF/Star and SRDF/EDP environment

Two-mirror RDF Enginuity Consistency Assist Two-mirror RDF ECA facilitates independent Congroup protection in a concurrent SRDF/S/S configuration (concurrent SRDF with both legs synchronous). Essentially, it allows the customer to disarm the protection on one leg of SRDF/S while allowing the other synchronous leg to remain active and continue protecting the primary production site. Prior to the availability of this feature, if one leg had to be disarmed for any reason, the other one would be disarmed also; this was deemed a risk by some customers since it left them momentarily unprotected. This adds to the robustness of the SRDF offering in that there are now two options for managing Congroups in a concurrent SRDF/S/S configuration: independent congroup protection, and joint congroup protection.

Add/Remove devices from SRDF/A (consistency exempt) Enginuity 5874 allows for the dynamic addition or deletion of devices in an SRDF/A relationship. The new flag “CEXMPT” of the SC VOL command triggers Enginuity to set the "consistency exempt" flag at the SRDF mirror level. This removes the device(s) from consistency consideration by Enginuity. This allows group membership changes while maintaining consistency with SRDF/A active and supersedes the "TOLERANCE" setting. TOLERANCE_ON allows SRDF/A to “tolerate” volumes in the group that are not consistent and remain active (single session only, not MSC). Devices can now be removed from an SRDF/A group altogether, or they can be removed from one group and added to another. All of this occurs while maintaining consistency of the remaining (unaffected) members of the group.

The CEXMPT flag is turned off by Enginuity after synchronization plus two SRDF/A cycle switches. It is strongly emphasized that devices in the “consistency exempt” state should not be used by the application until this state is cleared; this is a user responsibility.

Converting PPRC devices to SRDF devices, and vice versa Enginuity 5874 supports two types of conversion procedures to convert PPRC device(s) to SRDF device(s), and SRDF device(s) to PPRC device(s). Currently, if a customer wants to convert from PPRC to SRDF, or vice versa, it would require them to terminate the primary to secondary relationship, create the new primary to secondary relationship, and then perform a full copy between the new primary and secondary devices.


These two new procedures facilitate the conversion from PPRC devices to SRDF devices, or vice versa, in a manner that requires only minimal downtime between the primary and secondary devices using differential copy; this provides for a quick conversion with minimal impact on the customer’s environment.

Each conversion procedure has its own script in SymmWin as there is no provision to do the conversion utilizing EMC Mainframe Software. These scripts are executed from the primary subsystem and must be done by EMC Customer Service Personnel. The links must be active between the primary and secondary subsystems.

After the PPRC to SRDF conversion, either the CE or the customer must issue the commands that will resume the SRDF relationship After the SRDF to PPRC conversion, the CESTPATH and CESTPAIR commands must be run by the customer.

PPRC to SRDF The customer will first issue the CSUSPEND command to the devices to be converted. The CE then runs the SymmWin script on the primary subsystem (with the primary devices) to be converted. Upon completion, the script will return either a status of success or failure of the conversion. If the conversion is successful the customer then runs the CDELPATH command to remove the old PPRC path information. Either the CE or the customer must then issue commands that will resume the SRDF relationship between the SRDF Primary and Secondary devices.

SRDF to PPRC The customer first issues the SUSPEND SRDF command to the devices to be converted. The CE then runs the SymmWin script on the primary subsystem (with the primary devices) to be converted. Upon completion, the script will either return a status of success or failure of the conversion. If the conversion is successful, the conversion mode indicator will be set. The customer then issues the PPRC CESTPATH and CESTPAIR commands. Once the CESTPAIR command finishes, the conversion mode indicator will be removed. Note that these two commands would normally result in a full copy; however, when Enginuity detects that the conversion mode indicator is on, it will invoke a differential copy instead. Upon completion of the conversion, Enginuity will remove the conversion mode indicator.

Conversion Mode Indicator The Conversion Mode Indicator is a new bit in the dv_header that will indicate that the SRDF to PPRC conversion mode can be run. Note however, that setting the SRDF to PPRC Conversion Mode Indicator to on will not prevent actions to devices that would hinder successful conversion. In short, it is possible for a device to meet all the criteria (outlined next) to convert from SRDF to PPRC, then the SRDF to PPRC Conversion Mode Indicator is set to on, and then have the actual conversion fail because something changed between the time that the Conversion Mode Indicator was turned on and conversion began. Hence it is strongly advised that when the conversion is being run, the customer should not be running anything, or submitting any commands that would prevent, or otherwise interfere, with the successful completion of the conversion.

As expected there are certain rules and constraints that need to be obeyed for the conversion to be successful. Both the primary and secondary subsystems must be running Enginuity 5874. An EMC Customer Service Representative is required to execute the procedure. Even though these conversions apply only to mainframe environments, the only EMC mainframe host software involved is for the issuance of the resume once the script is complete – the vast majority of the operation is strictly SymmWin. Conversion from PPRC to SRDF, or from SRDF to PPRC, requires the device(s) to be dynamic SRDF defined as a DRX device – no DR1 or DR2 is allowed. Further, the SRDF group can be either static or dynamic.

Prior to conversion from SRDF to PPRC the following must be true:

• CKD devices must be either 3380 or 3390. No FBA devices are allowed. • The Symmetrix device must be configured as fully dynamic SRDF capable (DRX, not DR1 or DR2). • Only single mirror SRDF devices R1 and R2 are allowed, no R11, R21, or R22. • The relationship between the R1 and the R2 must be suspended. • The R1 device must not be in a Consistency Group.


• The device cannot be in a Star relationship. • The device cannot be in an SRDF/A group. • Links Domino mode must not be enabled. • Device Domino mode must not be enabled. • The Device must be in Synchronous (J0) or ADCOPY-DISK mode. • Supported SRDF groups are 0x00 - 0x3F (PPRC restriction). • All device pairs in an SSID pair must be in the same RDF group (PPRC requirement).

Prior to conversion from PPRC to SRDF the following must be true:

• The relationship between the R1 and the R2 must be Suspended Duplex – Primary side only. • CRIT must be set to No – Primary side only. • Long Busy State must not be active – Primary side only. • The device must not have XRC active.

SRDF/A Secondary Consistent In earlier releases of Enginuity (5670 through 5773 inclusive), the SRDF/A Session R2 Consistency State was exported via the SECONDARY CONSISTENT field in SQ SRDFA. It was set to "Y" when the SRDF/A session became consistent. The SECONDARY CONSISTENT indication was only available when SRDF/A was active, and it was maintained by Enginuity on the R1 side only. This presented a major shortcoming in that the customer could not explicitly determine if the R2 data was consistent after a loss of the R1 site, and hence the need for SRDF/A Secondary Consistent.

Starting with Enginuity 5874, the SRDF/A R2 Consistency Indicator is maintained on both the R1 and R2 Symmetrix subsystems, and Enginuity "remembers" the SRDF/A R2 Consistency Indicator after the session drops.

Additional capabilities

RAID Virtual Architecture With Enginuity 5874, the RAID-X naming changed to RAID Virtual Architecture. RAID Virtual Architecture extends the DMX-4 RAID 6 design to support all current RAID types in a single back-end engine. It is not a new RAID protection level in that you still have unprotected, RAID 1 (mirrored), RAID 5 and RAID 6 as before; and the CKD RAID 10 is still four RAID 1 devices grouped together with metastriping.

What is new is that the RAID Virtual Architecture hides the back-end management of the RAID groups such that the RAID protection is now associated with individual mirrors of a device and not the whole device itself. RAID Virtual Architecture is a significant enabling technology for Symmetrix; it has been used to implement other features such as enhanced Symmetrix Virtual LUN migrator (discussed earlier), and the expectation is that it will be used with other features in the future.

Serial number changed to alphabetic The 2107 control unit support allows for an all alphabetic, or all numeric, or a mixture of alphabetic and numeric characters in its serial number; there are certain rules that apply. This is a marked difference from the 2105 control unit, which allowed only a numeric serial number.

Currently the Symmetrix serial number is 12 ASCII numbers with the right-most five digits being unique; however, with 2107 support on Symmetrix VMAX, the new converted serial number will be returned as entirely all alphabetic characters with leading zeroes. The Inline E7,CF command on a FICON director New Features in EMC Enginuity 5874 for Symmetrix Mainframe Environments A Detailed Review 19

will show the original serial number and the translated 2107 serial number. Also, the z/OS DEVSERV and other D M=DEV commands also show the new serial number. This is illustrated in Figure 9.

Display at the Host – Split 1, CUADD 00, UA 01

Figure 9. z/OS operator command display of alphabetic serial number

System Management Facility record 74 subtype 8 Enginuity 5874 supports the collection and reporting of relevant FICON, PPRC, and SRDF statistics; these statistics are reported in the SMF record 74 subtype 8. The following information is externalized in this record for FICON channel connections and both GigE and FCP SRDF and PPRC connections:

• Read and write activity in units of 128 KB

• Number of read and write (or send and receive for SRDF/PPRC) operations

• Accumulated time for read and write activity in units of 16 milliseconds

This fulfills a long-standing requirement cited by many customers at large enterprises who find this data vital to the sophisticated modeling and analysis undertaken by their capacity planning and provisioning personnel. Note that information on SCSI activity is not provided.


Conclusion Enginuity 5874 delivers new software functionality that supports the new hardware capabilities of Symmetrix VMAX, thereby improving performance and lowering operational cost while simplifying subsystem management and boosting data availability locally and remotely.

References • EMC SRDF Host Component for z/OS Version 7.0 Product Guide • EMC Solutions Enabler Symmetrix TimeFinder Family CLI Version 7.0 Product Guide • EMC TimeFinder/Clone Mainframe SNAP Facility Version 7.0 Product Guide • EMC Mainframe Enablers Version 7.0 Installation and Customization Guide • EMC Mainframe Enablers Version 7.0 Release Notes • EMC TimeFinder/Mirror for z/OS Version 7.0 Product Guide


Documents

New Features in EMC Enginuity 5874 for Symmetrix Mainframe ... · PDF fileNew Features in EMC Enginuity 5874 for Symmetrix Mainframe Environments ... EMC Enginuity 5874 for Symmetrix