mainframe gatekeeper rules

3
EMC Knowledgebase "Mainframe Gatekeeper Rules, Requirements and Recommendations" ID: emc195898 Usage: 47 Date Created: 08/26/2008 Last Modified: 07/25/2012 STATUS: Approved Audience: Customer Knowledgebase Solution Question: Mainframe Gatekeeper Rules, Requirements and Recommendations Environment: OS: Mainframe Environment: OS: z/OS Environment: EMC SW: EMC Mainframe Enablers Environment: EMC SW: ResourcePak Base for z/OS Environment: EMC SW: Consistency Group for z/OS Environment: EMC SW: AutoSwap for z/OS Environment: EMC SW: SRDF Host Component for z/OS Environment: EMC SW: TimeFinder/Mirror for z/OS Environment: EMC SW: TimeFinder Clone Mainframe SNAP Facility for z/OS Environment: EMC SW: SRDF/STAR for z/OS Environment: EMC SW: ResourcePak Extended for z/OS Environment: EMC SW: GDDR Change: Installation or implementation of EMC Mainframe software products. Fix: This Knowledgebase solution is divided into eight sections: 1. What is a Gatekeeper? 2. What kinds of Gatekeepers are there? 3. How should I configure a Gatekeeper? 4. What are “Command Gatekeepers"? 5. What are “Software Gatekeepers"? 6. Are there special considerations for Gatekeepers used with Consistency Groups? 7. How do I verify the current Gatekeeper usage? 8. What software components utilize Gatekeepers? 1. What is a Gatekeeper? Mainframe Enabler (and Solutions Enabler on open systems) are EMC software components used to control the storage array features of Symmetrix arrays. They receive user requests and generate low-level commands (“syscalls”) that are transmitted into the Symmetrix array for action. Gatekeeper devices are Symm Devices that act as the target of command requests to Enginuity-based functionality. These commands arrive in the form of disk I/O requests (and so a 'disk' must be named by the host as the 'address' or target of that command). The more commands that are issued from the host, and the more complex the actions required by those commands, the more array processor (and channel) resources that are required to handle those requests in a timely manner. Also, these syscall I/Os are also subject to device queuing, as with any other kind of I/O operation. Mainframe enabler selects Gatekeepers, and looks for small devices or devices that are not heavily loaded. If it cannot find optimal choices, it will service the command request by selecting some device. It is also possible to issue so many requests and/or requests that involve complex operations, such as over-the-link operations or performance data acquisition, that applications on that channel or using those array facilities can be impacted. It is important that Gatekeeper usage be monitored against application or system activity to ensure there are no conflicts or operational impacts. Application, system and Gatekeeper traffic conflicts can lead to application performance impacts and or Symmetrix command delays or failures. Some Symmetrix commands such as MSC trips, etc., can be seriously limited in their effectiveness if such performance issues are encountered. 2. What kinds of Gatekeepers are there? EMC Mainframe software uses two types of gatekeepers: 2.1) Command gatekeepers to issue local or remote commands, i.e. SRDF/Host Component for z/OS TimeFinder/Mirror for z/OS TimeFinder/Clone for z/OS Consistency Group for z/OS Quality of Service Utility for z/OS Symmetrix Priority Control Dynamic Cache Partition 2.2) Software gatekeepers: Used by software components like SCF (EMC Symmetrix Control Facility) CSC (Cross System Communication) MSC (Multi-Session Control) CG (Consistency Groups) ASY (SRDF/A monitor) DSE (Delta Set Extension) 3. How should I configure a Gatekeeper? 3.1 The required attributes for all gatekeeper types are the same: Local (non-SRDF, actually not included in ANY replication process) OFFLINE and unused from all lpars, a minimum of two online paths recommended Unique 1 (no shared use between any software or command gatekeepers) Unique 2 (not shared between lpars, not used by multiple lpars) Not the first addressable device in a DMX/Symmetrix Minimum size hypervolumes are sufficient and recommended. Gatekeepers require only a small amount of space, 3 MB (3 cyl) for Enginuity levels 57xx, 58xx and higher, and 3 MB (6 cyl) for Enginuity levels of 56xx and lower. Users are encouraged to not build Gatekeepers in larger sizes as the small size can be used as characteristic to locate Gatekeepers. 3.2 Other considerations include: There is no specific local protection requirement for a gatekeeper (they can be mirrored, RAID5, RAID6, …·) If no OFFLINE-to-all-systems device is available at all, low I/O profile devices should be used Devices that are candidates for Reserves should be avoided for the following reasons: Reserve penetration may not be in effect for all Syscall I/Os An EMC Syscall I/O (using Reserve Penetration) may queue on the UCB behind an application I/O that is “Start Pending”· in the channel subsystem for the chosen device (Reserved to another system) 3.3 This is a list of attributes the gatekeepers must NOT have: SRDF/A Device R1 Device R2 Device Virtual Device Virtual Save Device BCV Device Meta Device 3.4 What else should I keep in mind when configuring Gatekeepers for the Mainframe? The first addressable CKD device in a DMX can be configured as a hypervolume with minimum size Plan for sufficient gatekeepers, especially in a multi-lpar and/or multi-sysplex environment 4. What are “Command Gatekeepers” ? Command gatekeepers are used to identify a specific DMX or VMAX to point to the desired local or remote DMX or VMAX. Command gatekeepers are ·defined· when they are specified in the JCL or when entered via a console [interface]. They should not be used to issue multiple commands in parallel. Typical use/examples: Host Component SC VOL,RMT(42B0,10),RNG-REFRESH 42B0 is the command gatekeeper, pointing to the DMX remote to the DMX containing UCB 42B0, via rdf-group 10. Device 42B0 not to be part of any replication process. Host Component SC VOL,LCL(A144,08),RDF-RSUM A144 is the command gatekeeper, pointing to the DMX containing UCB A144. Device A144 not to be part of any replication process. Mainframe Gatekeeper Rules, Requirements and Recommendations http://knowledgebase.emc.com/emcice/resultDisplay2.do?result=-1&clusterName=DefaultClust... 1 of 3 3/18/2013 6:33 PM

Upload: backspa

Post on 13-Apr-2015

80 views

Category:

Documents


1 download

DESCRIPTION

cscs

TRANSCRIPT

Page 1: Mainframe Gatekeeper Rules

EMC Knowledgebase

"Mainframe Gatekeeper Rules, Requirements and Recommendations"

ID: emc195898

Usage: 47

Date Created: 08/26/2008

Last Modified: 07/25/2012

STATUS: Approved

Audience: Customer

Knowledgebase Solution

Question: Mainframe Gatekeeper Rules, Requirements and Recommendations

Environment: OS: Mainframe

Environment: OS: z/OS

Environment: EMC SW: EMC Mainframe Enablers

Environment: EMC SW: ResourcePak Base for z/OS

Environment: EMC SW: Consistency Group for z/OS

Environment: EMC SW: AutoSwap for z/OS

Environment: EMC SW: SRDF Host Component for z/OS

Environment: EMC SW: TimeFinder/Mirror for z/OS

Environment: EMC SW: TimeFinder Clone Mainframe SNAP Facility for z/OS

Environment: EMC SW: SRDF/STAR for z/OS

Environment: EMC SW: ResourcePak Extended for z/OS

Environment: EMC SW: GDDR

Change: Installation or implementation of EMC Mainframe software products.

Fix:

This Knowledgebase solution is divided into eight sections:

1. What is a Gatekeeper?2. What kinds of Gatekeepers are there?3. How should I configure a Gatekeeper?4. What are “Command Gatekeepers"?5. What are “Software Gatekeepers"?6. Are there special considerations for Gatekeepers used with Consistency Groups?7. How do I verify the current Gatekeeper usage?8. What software components utilize Gatekeepers?

1. What is a Gatekeeper?

Mainframe Enabler (and Solutions Enabler on open systems) are EMC software components used to control the storage array features of Symmetrix arrays.They receive user requests and generate low-level commands (“syscalls”) that are transmitted into the Symmetrix array for action.

Gatekeeper devices are Symm Devices that act as the target of command requests to Enginuity-based functionality. These commands arrive in the form of disk I/O requests (and so a 'disk' must be named by the host asthe 'address' or target of that command). The more commands that are issued from the host, and the more complex the actions required by those commands, the more array processor (and channel) resources that arerequired to handle those requests in a timely manner. Also, these syscall I/Os are also subject to device queuing, as with any other kind of I/O operation.

Mainframe enabler selects Gatekeepers, and looks for small devices or devices that are not heavily loaded. If it cannot find optimal choices, it will service the command request by selecting some device. It is also possibleto issue so many requests and/or requests that involve complex operations, such as over-the-link operations or performance data acquisition, that applications on that channel or using those array facilities can beimpacted. It is important that Gatekeeper usage be monitored against application or system activity to ensure there are no conflicts or operational impacts.

Application, system and Gatekeeper traffic conflicts can lead to application performance impacts and or Symmetrix command delays or failures. Some Symmetrix commands such as MSC trips, etc., can be seriously limitedin their effectiveness if such performance issues are encountered.

2. What kinds of Gatekeepers are there?

EMC Mainframe software uses two types of gatekeepers:

2.1) Command gatekeepers to issue local or remote commands, i.e.

SRDF/Host Component for z/OSTimeFinder/Mirror for z/OSTimeFinder/Clone for z/OSConsistency Group for z/OSQuality of Service Utility for z/OSSymmetrix Priority ControlDynamic Cache Partition

2.2) Software gatekeepers: Used by software components like

SCF (EMC Symmetrix Control Facility)CSC (Cross System Communication)MSC (Multi-Session Control)CG (Consistency Groups)ASY (SRDF/A monitor)DSE (Delta Set Extension)

3. How should I configure a Gatekeeper?

3.1 The required attributes for all gatekeeper types are the same:

Local (non-SRDF, actually not included in ANY replication process)OFFLINE and unused from all lpars, a minimum of two online paths recommendedUnique 1 (no shared use between any software or command gatekeepers)Unique 2 (not shared between lpars, not used by multiple lpars)Not the first addressable device in a DMX/SymmetrixMinimum size hypervolumes are sufficient and recommended.

Gatekeepers require only a small amount of space, 3 MB (3 cyl) for Enginuity levels 57xx, 58xx and higher, and 3 MB (6 cyl) for Enginuity levels of 56xx and lower.Users are encouraged to not build Gatekeepers in larger sizes as the small size can be used as characteristic to locate Gatekeepers.

3.2 Other considerations include:

There is no specific local protection requirement for a gatekeeper (they can be mirrored, RAID5, RAID6, …·)If no OFFLINE-to-all-systems device is available at all, low I/O profile devices should be usedDevices that are candidates for Reserves should be avoided for the following reasons:

Reserve penetration may not be in effect for all Syscall I/OsAn EMC Syscall I/O (using Reserve Penetration) may queue on the UCB behind an application I/O that is “Start Pending”· in the channel subsystem for the chosen device (Reserved to another system)

3.3 This is a list of attributes the gatekeepers must NOT have:

SRDF/A DeviceR1 DeviceR2 DeviceVirtual DeviceVirtual Save DeviceBCV DeviceMeta Device

3.4 What else should I keep in mind when configuring Gatekeepers for the Mainframe?

The first addressable CKD device in a DMX can be configured as a hypervolume with minimum sizePlan for sufficient gatekeepers, especially in a multi-lpar and/or multi-sysplex environment

4. What are “Command Gatekeepers” ?

Command gatekeepers are used to identify a specific DMX or VMAX to point to the desired local or remote DMX or VMAX. Command gatekeepers are ·defined· when they are specified in the JCL or when entered via a console [interface]. They should not be used to issue multiple commands in parallel.

Typical use/examples:

Host Component SC VOL,RMT(42B0,10),RNG-REFRESH 42B0 is the command gatekeeper, pointing to the DMX remote to the DMX containing UCB 42B0, via rdf-group10. Device 42B0 not to be part of any replication process.

Host Component SC VOL,LCL(A144,08),RDF-RSUM A144 is the command gatekeeper, pointing to the DMX containing UCB A144. Device A144 not to be part ofany replication process.

Mainframe Gatekeeper Rules, Requirements and Recommendations http://knowledgebase.emc.com/emcice/resultDisplay2.do?result=-1&clusterName=DefaultClust...

1 of 3 3/18/2013 6:33 PM

Page 2: Mainframe Gatekeeper Rules

TimeFinder/Mirror RE-ESTABLISH 01,RMT(C050,050A-0589,0020-009F,10) C050 is the command gatekeeper, pointing to the DMX remote to the DMX containing UCB C050, via rdf-group10. Device C050 not to be part of any replication process.

TimeFinder/Clone SNAP VOLUME ( -SOURCE(SYMDV#(0D00))TARGET(SYMDV#(0CF0)) - REMOTE(UNIT(4890)RAGROUP(32) CONTROLLER(00429))

4890 is the command gatekeeper pointing to the DMX remote to the DMX containing UCB 4890, via rdf-group32. Device 4890 not to be part of any replication process.

SPC DISPDEVP RMT(5C89,32) A dedicated command gatekeeper is preferred

DCP DISPCCFG LCL(EC8C) DISPCCFG RMT(EC8B,32) A dedicated command gatekeeper is preferred

QOS QOSGET CUU=RMT(5C8A,0340-039F,18) A dedicated command gatekeeper is preferred

5. What are “Software Gatekeepers"?

The EMC software uses gatekeepers to perform the functions it has been configured for. Most Software gatekeepers are defined via the Initialization parms for the respective software component, some are used pernon-changeable defaults.

Component INI parm Requirements/Comments

SCF (EMCSCF) SCF.GATEKEEPER One to two gatekeepers per lpar. See also section 6, special considerations

CSC SCF.CSC.GATEKEEPER One to two gatekeepers per lpar. See also section 6, special considerations

ConGroup SCF.GATEKEEPER. SCF.CSC.GATEKEEPER See section 6, special considerations for details and how to validate that a sufficient number of gatekeepers has been defined.

MSC MSC_INCLUDE_SESSION One unique gatekeeper per RDF-Group per MSC instance. Never share MSC gatekeepers.

ASY N/A The ASY processes will use the first addressable device in a DMX for gatekeeper processing. Currently there is no possibility to specify a different device.

GNS GNS groups N/A The GNS processes will use the first addressable device in a DMX for gatekeeper processing.

Currently there is no possibility to specify a different device. Host Component Heartbeat N/A Host Component will use the first addressable device in a DMX for heartbeat operations.

This will be on the lowest SSID accessible. Host ComponentHeartbeat SCF.GATEKEEPER Starting with PTFs SR70004 and SR700C8, the SRDF heartbeat will use an available SCF gatekeeper, instead.

Host Component commands N/A Command gatekeepers are used

TimeFinder/Mirror N/A Command gatekeepers are used TimeFinder/Clone N/A Command gatekeepers are used Save Device Monitor N/A Uses SCF.GATEKEEPER devices

DSE Monitor N/A Uses SCF.GATEKEEPER devices SPC N/A Command gatekeepers are used DCP N/A Command gatekeepers are used QOS N/A Command gatekeepers are used

6. Are there special considerations for Gatekeepers used with Consistency Groups?

Starting with Consistency Groups for z/OS Version 6.3, the gatekeepers required by ConGroup and/or AutoSwap are defined in EMCSCF.

There are two different gatekeeper definitions which both need customization:

SCF.GATEKEEPER.SCF.CSC.GATEKEEPER.

The EMCSCF INI statements define these gatekeeper devices to SCF and to ConGroup. If no devices are specified, ConGroup and the CSC component will use the first device being available in each of the connected/used Symmetrix units, something that is NOT recommended practice. Pls refer to the Consistency Group for z/OS Product Guide (The gatekeeper server), and ResourcePak Base for z/OS Product Guide (INI parms for SCF.GATEKEEPER and SCF.CSC.GATEKEEPER).See also the “Best Practices” at the end of this section.

The following commands can be used to verify the current gatekeeper usage for SCF:

F emcscf,DEV,DIS,CNTRL(xxxxx) (xxxxx = last five digits of serial number of controller)

Example output returned from this command:

F EMCSCF,DEV,DIS,CNTRL(12345)SCF0421I CNTRL NAME=SCF0360I CONTROLLER 0001901-12345 HAS 23 SUBSYSTEMS AND IS AT MCLEVEL 5771.100SCF0345I - 4000 4100 4200 4300 4400 4500SCF0345I - 4600 4700 4800 4900 4A00 4B00SCF0345I - 4C00 4D00 4E00 4F00 5000 5100SCF0345I - 5200 5300 5400 5500 5600SCF4011I CONTROLLER 0001901-12345 is currently using CCUU 2004 as its SCF gatekeeper.SCF0357I CONTROLLER 0001901-12345 HAS 20 PATHS TO OTHER CONTROLLERS...SCF0356I DEVICE DISPLAY CNTRL COMMAND COMPLETED.

In ConGroup/AutoSwap, enter the following command to determine gatekeeper usage:

F emccgrp,DIS ENVIRONMENT

Example output returned from this command:F emccgrp,DIS ENVIRONMENTCGRP282I DIS ENVIRONMENT 944 *** Begin Display from system EMC8 *** TIME/GHA: 18577758/6F0F70CD VERIFY_INTERVAL=0 Work Pool Size: 10 Free: 10 Busy: 0 5 Second Request History: 0 0 0 0 0Gatekeeper Queue HWM: 2 ... ConGroup is executing in MULTI modeAutoSwap Ownerid=EMC8, LOCAL SYSTEM IS EMC8 This is the owning system *** End Display from system EMC8 ***

The ConGroup Product Guide, chapter “Determining whether there is gatekeeper queuing” should be reviewed if the “5 Second Request History” contains values other than zero or the “Gatekeeper Queue HWM” contains highvalues. This information was previously found in PRIMUS emc173688.

Best practice in a Multi-LPAR AutoSwap environment is to specify two ranges of gatekeepers and use this range in each LPAR being part of the AutoSwap environment.

The following example is for a ConGroup/AutoSwap environment with ten lpars, each accessing two local and two remote frames.The definitions are used in each of the ten participating LPARs.

* local framesSCF.GATEKEEPER.LIST=1011-101ASCF.CSC.GATEKEEPER.LIST=1021-102ASCF.GATEKEEPER.LIST=2011-201ASCF.CSC.GATEKEEPER.LIST=2021-202A

* remote framesSCF.GATEKEEPER.LIST=7011-701ASCF.CSC.GATEKEEPER.LIST=7021-702ASCF.GATEKEEPER.LIST=8011-801ASCF.CSC.GATEKEEPER.LIST=8021-802A

7. How do I verify the current Gatekeeper usage?

For MSC gatekeeper usage the STC log (or Syslog if running EMC SCF with SUB=MSTR) from all lpars should be reviewed. For command gatekeepers, the Syslog, EMC RDF STC log and/or batch job output should be reviewed. For SCF.GATEKEEPERs and SCF.CSC.GATEKEEPERs there are commands available to verify the current gatekeeper usage:

F EMCSCF,DEV,DIS,CNTRL(xxxxx) This command should be issued per locally attached controller on each lpar.

SCF0341I DEV,DIS,CNTRL(02092)SCF4011I CONTROLLER 0001901-02092 is currently using CCUU EC8F as its SCF gatekeeper.SCF0361I Gate Keeper Devices EC8F EC8E

F EMCSCF, CSC,DIS HOST CNTRL(ALL) This command should be issued on each lpar.

Mainframe Gatekeeper Rules, Requirements and Recommendations http://knowledgebase.emc.com/emcice/resultDisplay2.do?result=-1&clusterName=DefaultClust...

2 of 3 3/18/2013 6:33 PM

Page 3: Mainframe Gatekeeper Rules

SCF0663I CSC,DIS HOST CNTRL(ALL)SCF0660I CSC HOST DISPLAY 614CONTROLLER SERIAL NUMBER : 0001901-02405GATEKEEPER MVS DEVICE : 5C82 SYM DEVICE : 1CF2CONTROLLER SERIAL NUMBER : 0001901-02092GATEKEEPER MVS DEVICE : EC81 SYM DEVICE : 0CF1

After changing gatekeeper definitions for SCF.GATEKEEPER and/or SCF.CSC.GATEKEEPER the following sequence activates these changes.This command sequence should be issued on each lpar:

Modify the INI parms for EMCSCF (to specify the changed gatekeepers)F EMCSCF,INI,REFRESH (to re-read the INI parms)F EMCSCF,DEV,REFRESH,GATEKEEPERS (to actually refresh the SCF.GATEKEEPERs)F EMCSCF,CSC,REFRESH (to actually refresh the SCF.CSC.GATEKEEPERs)

SCF0663I CSC,REFRESHSCF0666I CSC REFRESH SCHEDULED FOR 2 CONTROLLERSSCF0652I CSC (0001901-02092) AREA:00010000/00030000, GATEKEEPER:EC81(SYMM07/5X72/00000/F8)SCF0652I CSC (0001901-02405) AREA:00010000/00030000, GATEKEEPER:5C82(SYMM07/5X72/00000/F8)

8. What software components utilize Gatekeepers?

Mainframe EnablersAutoSwap for z/OSConsistency Group for z/OSGDDRResourcePak Base for z/OSSRDF/Host Component for z/OSSRDF/STAR for z/OSTimeFinder Clone for z/OSMainframe SNAP Facility for z/OSTimeFinder/Mirror for z/OS

Notes: Recommendations for GDDR will follow soon. The recommendations listed above, however, also apply to GDDR.

Notes: Refer to emc255976, Gatekeepers Explained, for more information on gatekeepers.

Mainframe Gatekeeper Rules, Requirements and Recommendations http://knowledgebase.emc.com/emcice/resultDisplay2.do?result=-1&clusterName=DefaultClust...

3 of 3 3/18/2013 6:33 PM