Gatekeepers - All You Need to Know

Article Number:000074113 Version:1 Key Information

Audience: Level 30 = Customers Article Type: Break Fix

Last Published: Wed May 29 19:04:34 GMT 2013 Validation Status: Final ApprovedSummary:

Article Content

Impact: Gatekeepers Explained Gatekeepers - All You Need to Know

How do I configure Gatekeepers?

1. What are the most important things to know about Gatekeepers?

2. What is a Gatekeeper?

3. Do I really need to use Gatekeepers?

4. Do I need to create Gatekeepers?

5. Why does the Symmetrix use Gatekeepers and not some other means of control?

6. Are there devices that should be used as Gatekeepers?  Can thin devices be used? not

7. How many Gatekeepers do I need?

8. How big should Gatekeepers be?

9. Can I share Gatekeepers across servers?

10. Can I share server resources like HBAs between production applications and Gatekeepers?

11. Does the number of needed Gatekeepers change for different software releases?

12. How do Open Systems and Mainframe Gatekeepers differ?

13. Besides creating Gatekeepers, are there other things I need to set up to use them correctly?

14. Can I use PowerPath with Gatekeepers and is there a reason to do so?

15. Can I use other multi-pathing products with Gatekeepers?

16. Virtualization, Cluster, Migration, or Application Specific Gatekeeper Requirements (Clusters,Virtual Servers, Migrations)

17. Can I configure GateKeeper's on Unisys Mainframe host ports? Refer to  84279

18. What are the Gatekeeper requirements for RecoverPoint and Splitter appliance with theSymmetrix System?

Issue:A Gatekeeper cannot be opened because it (or they) are either locked or inaccessible.

Environment: Product: Symmetrix

Resolution: 1. What are the most important things to know about Gatekeepers?

If the system selects and uses a data or system device as a Gatekeeper, applicationson the application host can be impacted! EMC STRONGLY recommends thatdedicated Gatekeepers be created and used. This is particularly important withOpen Systems operation. See below.Gatekeeper operation for Open Systems and Mainframe operation is similar in principlebut there are major differences. Read below for more information about Open Systemsoperation and refer to EMC Knowledgebase solution  for more information about51197Mainframe Gatekeeper operation.PowerPath be used with Gatekeepers and there is a great reason to do so (refer to itemcan15 below). No other multi-pathing products can be used to define multiple paths to thoseGatekeeper devices.

2. What is a Gatekeeper?

Solutions Enabler and Mainframe Enabler are EMC software components used tocontrol the features of Symmetrix arrays. They receive user requests from CLI,GUI, or other means, and generate low-level commands (syscalls) that aretransmitted into the Symmetrix array for action.

Gatekeeper devices are Symmetrix devices that act as the target of commandrequests to Enginuity based functionality. These commands arrive in the form ofdisk I/O requests (and so a "disk" must be named by the host as the "address" ortarget of that command). The more commands that are issued from the host, and themore complex the actions required by those commands are, the more gatekeepersand/or array processor resources that are required to handle those requests in atimely manner.

3. Do I really need to use Gatekeepers?

If Symmetrix commands are running successfully requesting aSymmetrix command, it means that a device is being used as a Gatekeeper; thecommand has to be sent to something the Host Bus Adaptor can address, that is, adevice. The larger question is what is the nature of that Gatekeeper? Is it a userdevice used to hold data or is it a system paging disk? If so, there is a serious risk ofapplication impact. This is why EMC strongly recommends the use of dedicatedGatekeepers, as described below.

4. Do I need to create Gatekeepers?

Open Systems:

Open Systems servers should use dedicated Symmetrix devices (that is, dedicated tobeing a Gatekeeper with no other purpose) for Gatekeeper purposes. SolutionsEnabler selects a Gatekeeper device for a given command based upon a hierarchy of

choices (found in Solutions Enabler documentation) and could be forced to utilizea device that is used by a database or by the operating system if notenough dedicated Gatekeepers are defined. If this happens, it can significantlyimpact applications that may be operating on a server.

A Gatekeeper device may not respond to an application or server I/O request until aSymmetrix command request is completed. If a Symmetrix is executing a complexor time-consuming command, such as a query of the Remote R2 Symmetrix, linelatency may cause a delay and the device can, in effect, be locked for some time. Ifthe time is too long, the application using that Gatekeeper as a data device mayexperience I/O timeouts or perform poorly.

Mainframe:

Mainframe generally requires users to name a device that is used as a target of asyscall. Some mainframe commands and applications can select devices from apool. Refer to EMC Knowledgebase solution   for more information. The51197mainframe information in this Knowledgebase solution is only to illustratedifferences between mainframe and open systems and is not complete.

Gatekeepers should be created if there are no existing devices already dedicated toGatekeeper use. Refer to EMC Knowledgebase solution  for "How to use15432Solutions Enabler to create Mainframe Gatekeeper devices".

5. Why does the Symmetrix use Gatekeepers and not some other means of control?

The Symmetrix is a high performance storage system that scales up to the largeststorage capacities available in the industry. It also has very comprehensivemonitoring, performance and diagnostic capabilities. As a result, command dialogswith the system can be extensive and can involve a good deal of data. Symmetrixuses Gatekeepers as a scalable, high-performance means of command and control,suitable to the capabilities of the array. The deterministic nature of disk I/O isparticularly powerful when used for array-wide or multi-array operations suchas consistent splits, in which conventional networking may encounter packetcollisions or retries, which could prevent the timely operation of disaster recoverycommands.

6. Are there devices that should NOT be used as Gatekeepers?  Can thin devices be used?

Open Systems:

There are devices that should not be used as Gatekeepers. The rule of thumb is,"donot use devices that have user or system data on them" to avoid conflict and I/Operformance issues when operating Symmetrix features. This is why EMC makesthe strong recommendation to dedicate devices exclusively for Gatekeeperuse. There are three means to explicitly control what devices will or will not be usedas Gatekeepers:

Devices that absolutely should not be used as Gatekeepers can be put into agkavoid file as part of the Solutions Enabler setup.  This prevents devices inthat file from being used as Gatekeepers, yet still permits Solutions Enablerthe freedom to select other devices as Gatekeepers as required. Note thatadding new devices to a server or application may require updating this file

with those devices. Refer to EMC Knowledgebase solution 4160for Setting up gkavoid files.Devices intended for Gatekeeper use only can be put into the gkselect file.Devices in this file will take priority in the selection process. SolutionsEnabler may choose data devices as a Gatekeeper for a particular Symmetrixif none its Gatekeepers in the gkselect file exist, or are offline.After determining how many gatekeepers are needed, create dedicatedGatekeepers, and set the storapid daemon  option, gk_use in thedaemon_options file to specify dedicated only.(storapid:gk_use=dedicated_only)Meta Devices cannot be configured as Gatekeepers.Thin devices, aka Virtual Devices used with EMC Virtual Provisioning, CANbe used as gatekeepers.  All the existing gatekeeper rules apply, and the thingatekeeper device does not need to be bound to any storage pool.

7. How many Gatekeepers do I need?

Open Systems:

The answer is, "Enough to perform all concurrent Symmetrix commands andqueries without running into a condition in which commands are delayed or rejectedfor lack of a gatekeeper resource." Practically speaking, any server issuingcommands to a Symmetrix, physical or virtual, should have six Gatekeeper devicesuniquely available to it. Details of their creation and characteristics are foundelsewhere in this Knowledgebase solution.

Six Gatekeepers should prove sufficient for any Open Systems control server(meaning a server that is sending control syscalls to the Symmetrix instead of, or inaddition to, data), except those running Consistency Groups (more in the paragraphbelow). More than six can be needed under very heavy management workloads,such as heavy use of ControlCenter Performance Manager and/or SymmetrixPerformance Manager, or for certain other circumstances (refer to item 16 below).

For those locations utilizing Consistency Groups, add the following device count tothe six devices mentioned above. Here is how to calculate the required Gatekeepercount:

Solutions Enabler 7.0:In addition to the six above, another fourteen Gatekeepers must be added ifthere is performance-critical SRDF operation, plus for [Number of CGs] * 0.5= Gatekeepers needed for Consistency Group operation.Solutions Enabler 7.1:[Number of CGs] * 0.5 = Gatekeepers needed for Consistency GroupoperationSolutions Enabler 7.2:[Number of CGs] * 0.3 = Gatekeepers needed for Consistency Groupoperation

Round up the result of calculations in bullets 2 and 3 above to whole integers andthen do the following addition:6 + (those needed for 7.0 with SRDF) + (GKs needed for CG operation) = totalnumber of Gatekeepers to specify.

8. How big should Gatekeepers be?

Gatekeepers require only a small amount of space, 3 MB (3 cyl) for Enginuitylevels 57xx, 58xx and higher, and 3 MB (6 cyl) for Enginuity levels of 56xx andlower. Users are encouraged to build Gatekeepers in larger sizes as the smallnotsize is used by Enginuity to automatically identify and use devicesas Gatekeepers. Devices under 8 MB have the indication GK in syminqoutput. Gatekeeper devices must be mapped and masked to single servers only andshould  be shared across servers. For Virtual Server and Cluster environments,notrefer to the important additional information in item 16 below.

Gatekeepers should be RAID protected in some way so if the device were to fail,the syscall would be directed to the "mirror" of the failed device.  Any RAID formatwill provide this protection, but a simple mirror (RAID 1) is suggested.  OtherRAID configurations take a bit more space, for example, to make it 7+1 involvesspreading the gatekeeper across 8 drives (no actual I/O goes to the disk, so there isno 'I/O' penalty).  In such a case, your 3 cyl gatekeeper will take (7+1)*3= 24cylinders.  A nit, but for completeness' sake...

9. Can I share Gatekeepers across servers?

Gatekeeper devices must be mapped and masked to single hosts  and should only be shared for concurrent I/O across hosts. For Virtual Server and Clusternot

environments, refer to the important additional information in item 16 below. Seethe note about Multi-pathed Gatekeeper support with Symmetrix Enginuity 5876.

10. Can I share server resources like HBAs between production applications andGatekeepers?

Many configurations have Solutions Enabler and control commands running from aproduction control server. Just as production applications have requirements forminimal response times, certain Symmetrix management and control operationsshould be deemed real time and critical (consistency protection is a good example).

While gatekeepers can share HBAs and FA ports with production hosts, thereare good reasons to isolate them to separate HBAs and FA ports.

Perhaps most critical, consistency related commands needed for properdisaster protection may be held up by pending I/O's previously issued bya shared HBA (some HBAs will stop sending until some of the pending I/Osfinish).Applications on that HBA could be impacted by syscall traffic. Anoverworked server can also cause Symmetrix control issues, because theserver itself can be too busy to send a time-critical control operation to theSymmetrix.

It is always a best practice to isolate Gatekeepers on production servers to HBA andFA ports that are not response time sensitive and are not busy with production I/O.It is possible for gatekeepers to share FA ports as long as a given Gatekeeper is usedonly by a given control server.

11. Does the number of needed Gatekeepers change for different software releases?

Open Systems:

The minimum number of Gatekeepers needed does change over time as EMC worksto make control software more efficient. The numbers provided in thisKnowledgebase solution can be used with available releases.

12. How do Open Systems and Mainframe Gatekeepers differ?

While the underlying principles involved are identical, the differing nature ofMainframe I/O and SCSI I/O results in behaviors that are not identical. Refer toEMC Knowledgebase solution  for Mainframe Gatekeeper information. This51197Knowledgebase solution is written with a focus on Open Systems and contains onlypartial Mainframe information.

13. Besides creating Gatekeepers, are there other things I need to set up to use themcorrectly?

Yes. Make them a suitable size (see above). Be sure they are not SRDF, or virtualor snap devices, or devices in a save pool or thin pool.

14. Can I use PowerPath with Gatekeepers and is there a reason to do so?

Yes, and there is good reason to do so. Many Open Systems customers double theGatekeeper count, with half on each of two paths. With this configuration, in theevent of path failure, the Symmetrix could still receive commands. PowerPathprotects against path failure without the need to double the device count.

15. Can I use other multi-pathing products with Gatekeepers?

No. Other multi-pathing products may be used to define multiple paths withnotGatekeepers. PowerPath uniquely recognizes Symmetrix commands and treats themin a special manner when multiple paths are available to the Gatekeeper device.Products without this awareness can, for example, retry the I/O and causesignificant issues with the command processing.

16. Virtualization/Cluster/Migration or Application Specific Gatekeeper Requirements.

Virtual Server EnvironmentsVirtual Server environments often permit the movement of a guest operating systeminstance from one physical server to another. If that instance is doing Symmetrixmanagement or control, the Gatekeepers being used must be visible to that instance onwhatever physical server it is running upon. As a result, the Gatekeeper devices must bemade visible to the various physical servers the guest may operate upon. Note that the rulefor sharing Gatekeepers remains, and that the guest operating system image with itsnotSolutions Enabler instance must run on only one physical machine at any given time, andonly one instance using the Gatekeeper at any one time. Please also see EMCKnowledgebase solution  .72599Clustered EnvironmentsClustered environments also involve the movement of Symmetrix management andcontrol from one server to another as part of a failover process. There are different typesof clusters and the reader should look at the ELab Host Connectivity Guide of theparticular operating system for details of their cluster configuration. With shared nothingclusters, the Gatekeepers should be visible to all the physical servers that may issue

commands to the Symmetrix, in order to continue operations after a failover from thecontrolling node.  And as above, commands to a given Gatekeeper must be issued by onlyone control server instance at a time. In a share everything cluster (OpenVMS forexample), a Gatekeeper must me mapped and masked to only one, and only one, server, inorder to restrict Gatekeeper usage to the one controlling server.SRDF/CEEach Symmetrix must be configured with the recommended number of gatekeepers pernode, per SRDF side for SRDF/CE exclusive use, and must be configured per the aboveinformation. They should also have Windows disk signatures so that they are fully visibleto the cluster. For performance reasons, it is recommended that an additionalgatekeeper be associated with every SRDF/CE device group.PowerPath Migration Enabler (PPME)Gatekeeper devices should  be migrated. Gatekeepers should not be migrated by anynotmeans because the new location will have a different context than the old location, andcommands issued to the migrated Gatekeeper could result in unintended consequences inthe new array.ControlCenter Agent and Symmetrix Management Console (SMC)Both be serviced by the recommended Gatekeeper count above. Note that large specificworkloads, such as often collecting performance data for Symmetrix PerformanceAnalyzer or Performance Manager, could require more Gatekeepers for proper operation.

17. Can I configure GateKeeper's on Unisys Mainframe host ports? Refer to 84279

18. What are the Gatekeeper requirements for RecoverPoint and Splitter appliance withthe Symmetrix System?

Starting with RecoverPoint 3.5 and Enginuity microcode 5876, tagging all VMAX devicesexposed to RecoverPoint (including production and replica volumes, journal volumes, therepository, and gatekeepers) is required. Untagged volumes will not be available inRecoverPoint for host-based, fabric-based, and Symmetrix splitters. RecoverPoint manages the Symmetrix splitter using Solutions Enabler. Solutions Enablercommands are sent to the Symmetrix array via gatekeepers. Gatekeepers are small,3-cylinder devices (approximately 3 MB) that are used to send control commands to theSymmetrix. RecoverPoint site control manages the resources of the RecoverPoint cluster, including theSymmetrix splitter. The active instance of RecoverPoint cluster site control can run onlyon either RPA1 or RPA2, even if there are more RPAs in the cluster. As a result, thegatekeepers must be presented to RPA1 and RPA2 only.  RPA1 must have access to eight gatekeepers; RPA2 must have access to eight differentgatekeepers. A gatekeeper should not be shared with any other RPA or host. RPAs musthave access to their gatekeepers via multiple redundant paths. If a site comprises multipleSymmetrix splitters or multiple RecoverPoint clusters, a total of 16 gatekeepers is requiredfor each Symmetrix-splitter/RecoverPoint-cluster combination.  Host-based Access Control is an optional feature used by a Symmetrix administrator to setup and restrict host access to defined sets of devices (access pools). If Access Control isused, RecoverPoint appliances must be granted access to their devices (gatekeepers,repository, journals, and production and replica volumes). To accommodate RecoverPoint,a new access right, RPA, has been added. For more information, refer to EMC Solutions

Enabler Symmetrix Array Management Product Guide, section Host-based access control. Journal volumes, repository, and gatekeepers may use dedicated FA ports. Add these FAports into the same RPA-to-Symmetrix zones.  For Symmetrix splitter only, expose gatekeepers (3-cylinder devices), 16 perRecoverPoint cluster:   

Create a port group for RPA1 gatekeepers or use an existing port group. For optimalperformance, use 8 FA ports.Create RPA1 gatekeeper storage group with 8 gatekeepers designated for RPA1.Create a masking view with the RPA1 gatekeeper port group, RPA1 gatekeeperstorage group, and RPA1 initiator group.Create a port group for RPA2 gatekeepers or use an existing port group. For optimalperformance, use 8 different FA ports from those used for the RPA1 gatekeepers.Create RPA2 gatekeeper storage group and add 8 different gatekeepers from theones exposed to RPA1.Create a masking view with the RPA2 gatekeeper port group, RPA2 gatekeeperstorage group, and RPA2 initiator group.   

If the host storage group contains any gatekeepers, RecoverPoint will incorrectly assumethat these are the dedicated gatekeepers it can use with the Symmetrix splitter. Therefore,host gatekeepers should be separated into a different host storage group, not accessible byRPA™s. To display the Symmetrix gatekeepers, use the RecoverPoint CLI command

.show_symmetrix_gate_keepers

Refer to EMC RecoverPoint Deploying with Symmetrix Arrays and Splitter Technical Notes foradditional information.

Notes: Update - May 2012 - New for Solutions Enabler 7.4 and Enginuity 5876.

Thin devices are now supported as gatekeeper candidates.The gatekeeper selection algorithim now ignores the fact that a device happens to be a thindevice when slecting gatekeeper candidates. This makes all thin devices candidates forGatekeeper Selection so we still recommed using dedicated Gatekeeper devices. The thinGatekeeper device does not have to be bound to a pool.The following restrictions apply: 

Hyper-V thin devices must be bound to a poolNO AS400 Support for using thin devices as Gatekeepers. 

Rules for Multi-Pathing GateKeepersUntil now, we have only supported multipathed Gatekeepers when running EMC Powerpath.Beginning with Enginuity 5876 and Solutions Enabler 7.4, we will support a limited set of thirdparty multipathing solutions on a limited set of platforms. The following Multipathing Softwareapplications is will be supported; Powerpath, Veritas, and Native Multipathing. These aresupported, on AIX, HPUX, Linux, Solaris, and Windows.As always, See E-Lab Navigator for an up-to-date list of supported versions of what EMCsupports.

If a host does not have dedicated Gatekeepers (devices 10 Cyls or less), SolutionsEnabler selects Gatekeepers as described in the install guide.  If the selected Gatekeeper islarger than 10 Cyls, multipathed (non-Powerpath), and Enginuity is below 5876, unexpectedresults may occur. With Solutions Enabler 7.4 and Enginuity 5876, these devices will berejected as Gatekeeper candidates. Therefore, it is recommended that you mapSTRONGLYseveral dedicated Gatekeepers to the host as described in this solution.

The recommeded size for the ACLX device is 10 cylinders or less. This allows the ACLXdevice to take advantage of the multipathed gatekeeper support in Enginuity 5876. If an ACLXdevice is multipathed and it is more than 10 cylinders, it will not benefit from all themultipathing benefits that 5876 provides.

Prior to SE 7.4 and Enginuity 5876, multipathed Gatekeepers without PowerPath may  Starting with Solutions Enabler 7.4, Gatekeeper selection has become stricterhave worked.

when running third party multipathing software. What may have worked before may not workwith Solutions Enabler 7.4 and Enginuity versions prior to 5876. New log filesA new log file is automatically created in the symapi/log directory. The Gatekeeper Selection

provides details about all physical devices mapped to the host. The report will beReportupdated every time a discover is performed or when the base daemon (AKA Storapid Daemon)detects a change in the topology. Important NoteIf using thin Gatekeepers with Hyper-V, the Gatekeepers MUST be bound to a pool. You mustweigh the pros/cons of using thin Gatekeepers in this environment, vs the traditional way.

Article Metadata

Product: Symmetrix, TimeFinder, Solutions Enabler, Symmetrix Remote Data Facility (SRDF), SymmetrixVMAX Series

Primus/Webtop solution ID: emc255976

Requested Publish Date: 5/25/2013 4:43 PM

External Source: Primus