Symmetrix Gatekeeper device

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, applicat
ions on the application host can be impacted! EMC STRONGLY recommends that dedic
ated Gatekeepers be created and used. This is particularly important with Open S
ystems operation. See below.
Gatekeeper operation for Open Systems and Mainframe operation is similar in prin
ciple but there are major differences. Read below for more information about Ope
n Systems operation and refer to EMC Knowledgebase solution emc195898 for more i
nformation about Mainframe Gatekeeper operation.
PowerPath can be used with Gatekeepers and there is a great reason to do so (ref
er to item 15 below). No other multi-pathing products can be used to define mult
iple paths to those Gatekeeper devices.--GateKeeper disk
2. What is a Gatekeeper?
Solutions Enabler and Mainframe Enabler are EMC software components used to cont
rol the features of Symmetrix arrays. They receive user requests from CLI, GUI,
or other means, and generate low-level commands (syscalls) that are transmitted
into the Symmetrix array for action.
Gatekeeper devices are Symmetrix devices that act as the target of command reque
sts 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 targ
et of that command). The more commands that are issued from the host, and the mo
re complex the actions required by those commands are, the more gatekeepers and/
or array processor resources that are required to handle those requests in a tim
ely manner.---gatekeeper device
3. Do I really need to use Gatekeepers?
If Symmetrix commands are running successfully requesting a Symmetrix command, i
t means that a device is being used as a Gatekeeper; the command has to be sent
to something the Host Bus Adaptor can address, that is, a device. The larger que
stion is what is the nature of that Gatekeeper? Is it a user device used to hold
data or is it a system paging disk? If so, there is a serious risk of applicati
on impact. This is why EMC strongly recommends the use of dedicated Gatekeepers,
as described below.
4. Do I need to create Gatekeepers?
Open Systems:
Open Systems servers should use dedicated Symmetrix devices (that is, dedicated
to being a Gatekeeper with no other purpose) for Gatekeeper purposes. Solutions
Enabler selects a Gatekeeper device for a given command based upon a hierarchy o
f choices (found in Solutions Enabler documentation) and could be forced to util
ize a device that is used by a database or by the operating system if not enough
dedicated Gatekeepers are defined. If this happens, it can significantly impact
applications that may be operating on a server.
A Gatekeeper device may not respond to an application or server I/O request unti
l a Symmetrix command request is completed. If a Symmetrix is executing a comple
x or time-consuming command, such as a query of the Remote R2 Symmetrix, line la
tency may cause a delay and the device can, in effect, be locked for some time.
If the time is too long, the application using that Gatekeeper as a data device
may experience I/O timeouts or perform poorly.
Mainframe:

Mainframe generally requires users to name a device that is used as a target of

a syscall. Some mainframe commands and applications can select devices from a po
ol. Refer to EMC Knowledgebase solution emc195898 for more information. The main
frame information in this Knowledgebase solution is only to illustrate differenc
es between mainframe and open systems and is not complete.
Gatekeepers should be created if there are no existing devices already dedicated
to Gatekeeper use. Refer to EMC Knowledgebase solution emc287007 for "How to us
e Solutions 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 largest
storage capacities available in the industry. It also has very comprehensive mo
nitoring, performance and diagnostic capabilities. As a result, command dialogs
with the system can be extensive and can involve a good deal of data. Symmetrix
uses Gatekeepers as a scalable, high-performance means of command and control, s
uitable to the capabilities of the array. The deterministic nature of disk I/O i
s particularly powerful when used for array-wide or multi-array operations such
as consistent splits, in which conventional networking may encounter packet coll
isions or retries, which could prevent the timely operation of disaster recovery
commands.
6. Are there devices that should NOT be used as Gatekeepers? Can thin devices b
e used?
Open Systems:
There are devices that should not be used as Gatekeepers. The rule of thumb is,"
do not use devices that have user or system data on them" to avoid conflict and
I/O performance issues when operating Symmetrix features. This is why EMC makes
the strong recommendation to dedicate devices exclusively for Gatekeeper use. Th
ere are three means to explicitly control what devices will or will not be used
as Gatekeepers:
Devices that absolutely should not be used as Gatekeepers can be put into a gkav
oid file as part of the Solutions Enabler setup. This prevents devices in that
file from being used as Gatekeepers, yet still permits Solutions Enabler the fre
edom to select other devices as Gatekeepers as required. Note that adding new de
vices to a server or application may require updating this file with those devic
es. Refer to EMC Knowledgebase solution emc11514 for Setting up gkavoid files.
Devices intended for Gatekeeper use only can be put into the gkselect file. Devi
ces in this file will take priority in the selection process. Solutions Enabler
may choose data devices as a Gatekeeper for a particular Symmetrix if none its G
atekeepers in the gkselect file exist, or are offline.
After determining how many gatekeepers are needed, create dedicated Gatekeepers,
and set the storapid daemon option, gk_use in the daemon_options file to speci
fy dedicated only. (storapid:gk_use=dedicated_only)
Meta Devices cannot be configured as Gatekeepers.
Thin devices, aka Virtual Devices used with EMC Virtual Provisioning, CAN be use
d as gatekeepers. All the existing gatekeeper rules apply, and the thin gatekee
per 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 and queries
without running into a condition in which commands are delayed or rejected for l
ack of a gatekeeper resource." Practically speaking, any server issuing commands
to a Symmetrix, physical or virtual, should have six Gatekeeper devices uniquel
y available to it. Details of their creation and characteristics are found elsew
here in this Knowledgebase solution.
Six Gatekeepers should prove sufficient for any Open Systems control server (mea
ning a server that is sending control syscalls to the Symmetrix instead of, or i
n addition to, data), except those running Consistency Groups (more in the parag
raph below). More than six can be needed under very heavy management workloads,
such as heavy use of ControlCenter Performance Manager and/or Symmetrix Performa
nce Manager, or for certain other circumstances (refer to item 16 below).
For those locations utilizing Consistency Groups, add the following device count
to the six devices mentioned above. Here is how to calculate the required Gatek
eeper count:
Solutions Enabler 7.0:
In addition to the six above, another fourteen Gatekeepers must be added if ther
e is performance-critical SRDF operation, plus for [Number of CGs] * 0.5 = Gatek
eepers needed for Consistency Group operation.
Solutions Enabler 7.1:
[Number of CGs] * 0.5 = Gatekeepers needed for Consistency Group operation
Solutions Enabler 7.2:
[Number of CGs] * 0.3 = Gatekeepers needed for Consistency Group operation
Round up the result of calculations in bullets 2 and 3 above to whole integers a
nd then do the following addition:
6 + (those needed for 7.0 with SRDF) + (GKs needed for CG operation) = total num
ber of Gatekeepers to specify.
8. How big should Gatekeepers be?
Gatekeepers require only a small amount of space, 3 MB (3 cyl) for Enginuity lev
els 57xx, 58xx and higher, and 3 MB (6 cyl) for Enginuity levels of 56xx and low
er. Users are encouraged to not build Gatekeepers in larger sizes as the small s
ize is used by Enginuity to automatically identify and use devices as Gatekeeper
s. Devices under 8 MB have the indication GK in syminq output. Gatekeeper device
s must be mapped and masked to single servers only and should not be shared acro
ss servers. For Virtual Server and Cluster environments, refer 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 fo
rmat will provide this protection, but a simple mirror (RAID 1) is suggested. O
ther RAID configurations take a bit more space, for example, to make it 7+1 invo
lves spreading the gatekeeper across 8 drives (no actual I/O goes to the disk, s
o there is no 'I/O' penalty). In such a case, your 3 cyl gatekeeper will take (
7+1)*3= 24 cylinders. A nit, but for completeness' sake...
9. Can I share Gatekeepers across servers?
Gatekeeper devices must be mapped and masked to single hosts only and should not
be shared for concurrent I/O across hosts. For Virtual Server and Cluster envir
onments, refer to the important additional information in item 16 below. See the
note about Multi-pathed Gatekeeper support with Symmetrix Enginuity 5876.
10. Can I share server resources like HBAs between production applications and G

atekeepers?
Many configurations have Solutions Enabler and control commands running from a p
roduction control server. Just as production applications have requirements for
minimal response times, certain Symmetrix management and control operations shou
ld be deemed real time and critical (consistency protection is a good example).
While gatekeepers can share HBAs and FA ports with production hosts, there are g
ood reasons to isolate them to separate HBAs and FA ports.
Perhaps most critical, consistency related commands needed for proper disaster p
rotection may be held up by pending I/O's previously issued by a shared HBA (som
e HBAs will stop sending until some of the pending I/Os finish).
Applications on that HBA could be impacted by syscall traffic. An overworked ser
ver can also cause Symmetrix control issues, because the server itself can be to
o busy to send a time-critical control operation to the Symmetrix.
It is always a best practice to isolate Gatekeepers on production servers to HBA
and FA ports that are not response time sensitive and are not busy with product
ion I/O. It is possible for gatekeepers to share FA ports as long as a given Gat
ekeeper is used only 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 works to m
ake control software more efficient. The numbers provided in this Knowledgebase
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 of
Mainframe I/O and SCSI I/O results in behaviors that are not identical. Refer to
EMC Knowledgebase solution emc195898 for Mainframe Gatekeeper information. This
Knowledgebase solution is written with a focus on Open Systems and contains onl
y partial Mainframe information.
13. Besides creating Gatekeepers, are there other things I need to set up to use
them correctly?
Yes. Make them a suitable size (see above). Be sure they are not SRDF, or virtua
l or 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 the G
atekeeper count, with half on each of two paths. With this configuration, in the
event of path failure, the Symmetrix could still receive commands. PowerPath pr
otects 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 not be used to define multiple paths with G
atekeepers. PowerPath uniquely recognizes Symmetrix commands and treats them in
a special manner when multiple paths are available to the Gatekeeper device. Pro
ducts without this awareness can, for example, retry the I/O and cause significa
nt issues with the command processing.
16. Virtualization/Cluster/Migration or Application Specific Gatekeeper Requirem

ents.
Virtual Server Environments
Virtual Server environments often permit the movement of a guest operating syste
m instance from one physical server to another. If that instance is doing Symmet
rix management or control, the Gatekeepers being used must be visible to that in
stance on whatever physical server it is running upon. As a result, the Gatekeep
er devices must be made visible to the various physical servers the guest may op
erate upon. Note that the rule for not sharing Gatekeepers remains, and that the
guest operating system image with its Solutions Enabler instance must run on on
ly one physical machine at any given time, and only one instance using the Gatek
eeper at any one time. Please also see EMC Knowledgebase solution emc248427.
Clustered Environments
Clustered environments also involve the movement of Symmetrix management and con
trol from one server to another as part of a failover process. There are differe
nt types of clusters and the reader should look at the ELab Host Connectivity Gu
ide of the particular operating system for details of their cluster configuratio
n. With shared nothing clusters, the Gatekeepers should be visible to all the ph
ysical servers that may issue commands to the Symmetrix, in order to continue op
erations after a failover from the controlling node. And as above, commands to
a given Gatekeeper must be issued by only one control server instance at a time.
In a share everything cluster (OpenVMS for example), a Gatekeeper must me mappe
d and masked to only one, and only one, server, in order to restrict Gatekeeper
usage to the one controlling server.
SRDF/CE
Each Symmetrix must be configured with the recommended number of gatekeepers per
node, per SRDF side for SRDF/CE exclusive use, and must be configured per the a
bove information. They should also have Windows disk signatures so that they are
fully visible to the cluster. For performance reasons, it is recommended that a
n additional gatekeeper be associated with every SRDF/CE device group.
PowerPath Migration Enabler (PPME)
Gatekeeper devices should not be migrated. Gatekeepers should not be migrated by
any means because the new location will have a different context than the old l
ocation, and commands issued to the migrated Gatekeeper could result in unintend
ed consequences in the new array.
ControlCenter Agent and Symmetrix Management Console (SMC)
Both be serviced by the recommended Gatekeeper count above. Note that large spec
ific workloads, such as often collecting performance data for Symmetrix Performa
nce Analyzer or Performance Manager, could require more Gatekeepers for proper o
peration.
17. Can I configure GateKeeper's on Unisys Mainframe host ports? Refer to emc292
180
18. What are the Gatekeeper requirements for RecoverPoint and Splitter appliance
with the Symmetrix System?
Starting with RecoverPoint 3.5 and Enginuity microcode 5876, tagging all VMAX de
vices exposed to RecoverPoint (including production and replica volumes, journal
volumes, the repository, and gatekeepers) is required. Untagged volumes will no
t be available in RecoverPoint for host-based, fabric-based, and Symmetrix split
ters.
RecoverPoint manages the Symmetrix splitter using Solutions Enabler. Solutions E
nabler commands are sent to the Symmetrix array via gatekeepers. Gatekeepers are
small, 3-cylinder devices (approximately 3 MB) that are used to send control co
mmands to the Symmetrix.

RecoverPoint site control manages the resources of the RecoverPoint cluster, inc
luding the Symmetrix splitter. The active instance of RecoverPoint cluster site
control can run only on either RPA1 or RPA2, even if there are more RPAs in the
cluster. As a result, the gatekeepers must be presented to RPA1 and RPA2 only.
RPA1 must have access to eight gatekeepers; RPA2 must have access to eight diffe
rent gatekeepers. A gatekeeper should not be shared with any other RPA or host.
RPAs must have access to their gatekeepers via multiple redundant paths. If a si
te comprises multiple Symmetrix splitters or multiple RecoverPoint clusters, a t
otal of 16 gatekeepers is required for each Symmetrix-splitter/RecoverPoint-clus
ter combination.
Host-based Access Control is an optional feature used by a Symmetrix administrat
or to set up and restrict host access to defined sets of devices (access pools).
If Access Control is used, RecoverPoint appliances must be granted access to th
eir devices (gatekeepers, repository, journals, and production and replica volum
es). To accommodate RecoverPoint, a new access right, RPA, has been added. For m
ore information, refer to EMC Solutions Enabler Symmetrix Array Management Produ
ct Guide, section Host-based access control.?
Journal volumes, repository, and gatekeepers may use dedicated FA ports. Add the
se FA ports into the same RPA-to-Symmetrix zones.
For Symmetrix splitter only, expose gatekeepers (3-cylinder devices), 16 per Rec
overPoint cluster:
Create a port group for RPA1 gatekeepers or use an existing port group. For opti
mal performance, 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 gatekeeper stora
ge group, and RPA1 initiator group.
Create a port group for RPA2 gatekeepers or use an existing port group. For opti
mal performance, use 8 different FA ports from those used for the RPA1 gatekeepe
rs.
Create RPA2 gatekeeper storage group and add 8 different gatekeepers from the on
es exposed to RPA1.
Create a masking view with the RPA2 gatekeeper port group, RPA2 gatekeeper stora
ge group, and RPA2 initiator group.
If the host storage group contains any gatekeepers, RecoverPoint will incorrectl
y assume that 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 by RPA s.
To display the Symmetrix gatekeepers, use the RecoverPoint CLI command show_symm
etrix_gate_keepers.
Refer to EMC RecoverPoint Deploying with Symmetrix Arrays and Splitter Technical
Notes for additional information.
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 t
o be a thin device when slecting gatekeeper candidates. This makes all thin devi
ces candidates for Gatekeeper Selection so we still recommed using dedicated Gat
ekeeper devices. The thin Gatekeeper device does not have to be bound to a pool.
The following restrictions apply:
Hyper-V thin devices must be bound to a pool

NO AS400 Support for using thin devices as Gatekeepers.

Rules for Multi-Pathing GateKeepers
Until now, we have only supported multipathed Gatekeepers when running EMC Power
path. Beginning with Enginuity 5876 and Solutions Enabler 7.4, we will support a
limited set of third party multipathing solutions on a limited set of platforms
. The following Multipathing Software applications is will be supported; Powerpa
th, Veritas, and Native Multipathing. These are supported, on AIX, HPUX, Linux,
Solaris, and Windows.
As always, See E-Lab Navigator for an up-to-date list of supported versions of w
hat EMC supports.
If a host does not have dedicated Gatekeepers (devices 10 Cyls or less), Solutio
ns Enabler selects Gatekeepers as described in the install guide. If the select
ed Gatekeeper is larger than 10 Cyls, multipathed (non-Powerpath), and Enginuity
is below 5876, unexpected results may occur. With Solutions Enabler 7.4 and Eng
inuity 5876, these devices will be rejected as Gatekeeper candidates. Therefore,
it is STRONGLY recommended that you map several dedicated Gatekeepers to the ho
st as described in this solution.
The recommeded size for the ACLX device is 10 cylinders or less. This allows the
ACLX device to take advantage of the multipathed gatekeeper support in Enginuit
y 5876. If an ACLX device is multipathed and it is more than 10 cylinders, it wi
ll not benefit from all the multipathing benefits that 5876 provides.
Prior to SE 7.4 and Enginuity 5876, multipathed Gatekeepers without PowerPath ma
y have worked. Starting with Solutions Enabler 7.4, Gatekeeper selection has be
come stricter when running third party multipathing software. What may have work
ed before may not work with Solutions Enabler 7.4 and Enginuity versions prior t
o 5876.
New log files
A new log file is automatically created in the symapi/log directory. The Gatekee
per Selection Report provides details about all physical devices mapped to the h
ost. The report will be updated every time a discover is performed or when the b
ase daemon (AKA Storapid Daemon) detects a change in the topology.
Important Note
If using thin Gatekeepers with Hyper-V, the Gatekeepers MUST be bound to a pool.
You must weigh the pros/cons of using thin Gatekeepers in this environment, vs
the traditional way.