Naren I think it's easier to understand why we do need GateKeepers if you recall to your mind what's the main job of a DMX. It will offer disks to the hosts. Nothing else .. No TCP/IP, no bluetooth, no wifi If you remember that simple concept it's easier to understand what does GateKeepers do for you
If a DMX offers disks to the hosts, the only way our software have to talk to the storage is to use some of those disks. If you look at the behaviour of a SCSI disk you'll quickly understand why we need dedicated devices.
Let's speak SCSI for just one minute... In SCSI terms, the host is the initiator and the DMX is the target .. Every time an Initiator wants to talk with a Target, it will pack a frame (CDB in SCSI terms) and send the frame to the selected Target. What can you do to a Target ?? You can READ .. maybe you can READ16 or even READ32 .. And you can also WRITE .. But there are also other commands that a SCSI device can "understand". The strange thing is that when a target receives reads and writes it's allowed to put them in cache and reorder them. But when it receives some special commands, the target will suspend every other operation and will execute what have been requested in the CDB, replying to the original request with an acknowledgement frame that will contain also the "result" of the operation.
Now guess what type of CDB uses our Solution Enabler .. Yes the last one ..
Think at your beautyfull Oracle Database while it is working .. issuing READs and WRITEs against the disks .. And now imagine that you issue a single simple symdev command on the Oracle host .. Solution Enabler will send the appropriate CDB to the storage (the disks where your Oracle is working) and the "lucky" disk will stop working while retriving the informations requested from "symdev".
Do you think that your Oracle database will love this ??
To put a complex issue in simple terms, GK are the gate that Solution Enabler uses when sending commands to the storage. If you don't give GK to an host, Solution Enabler will work anyway .. But it will use your DATA DISKS while sending commands to the storage.
VCMDB = access database stored on the Symmetrix/DMX FA controllers which controls which Symmetrix Devices presented on an FA are accessible by the WWN devices granted access to these devices. Basically a mapping of WWN xx:yy:zz:etc can access Symmetrix Devices 001, 002, etc.
If you have VCMDB control disabled on an FA then this database is not created or required and any WWN (a host fiber card) that is zoned to that FA port will have access to every device presented on that FA. The VCMDB is what allows you to have multiple servers with different applications sharing an FA without stepping on each others data.
A gatekeeper device is a small disk used exclusively by EMC applications and utlities to communicate with the Symmetrix/DMX from a host system. An example would be Solutions Enabler using a gatekeeper device to send Timefinder commands to the DMX where that operation is taking place. There is nothing special about a gatekeeper other than it not being used for normal I/O which could interrupt this communication. For that reason gatekeepers are usually created from small left-over pieces of disks and kept at a very small size to avoid wasting too much space.
Naren could you please tell us what's confusing between what you find in the manuals and what you find in the forum about Gatekeepers ??
Things are getting a little complex since now we have also DMX3 and DMX4 that "changes" the cards on the table .. But please explain your doubt and we'll try to give a better explanation
xe2sdc
6 Operator
•
2831 Posts
957
0
Posted October 6th, 2007 12:00
If you remember that simple concept it's easier to understand what does GateKeepers do for you
If a DMX offers disks to the hosts, the only way our software have to talk to the storage is to use some of those disks. If you look at the behaviour of a SCSI disk you'll quickly understand why we need dedicated devices.
Let's speak SCSI for just one minute... In SCSI terms, the host is the initiator and the DMX is the target .. Every time an Initiator wants to talk with a Target, it will pack a frame (CDB in SCSI terms) and send the frame to the selected Target.
What can you do to a Target ?? You can READ .. maybe you can READ16 or even READ32
Now guess what type of CDB uses our Solution Enabler .. Yes the last one ..
Think at your beautyfull Oracle Database while it is working .. issuing READs and WRITEs against the disks .. And now imagine that you issue a single simple symdev command on the Oracle host .. Solution Enabler will send the appropriate CDB to the storage (the disks where your Oracle is working) and the "lucky" disk will stop working while retriving the informations requested from "symdev".
Do you think that your Oracle database will love this ??
To put a complex issue in simple terms, GK are the gate that Solution Enabler uses when sending commands to the storage. If you don't give GK to an host, Solution Enabler will work anyway .. But it will use your DATA DISKS while sending commands to the storage.