Dynamox already pointed the "source" of all knowledge regarding GNS .. however as stated a lot of times here in our forums, talkiing about GNS is harder then implementing it
Change a couple of lines in your "options" file, issue a symdg -inactive list command and activate your DGs (thus moving them into GNS)... Now jump on another host, change options file and issue symdg list .. and enjoy the magic
One thing that is not clearly documented that I'd recommend doing is making sure before you enable GNS that you export/delete your local DGs on your hosts where you might already have them.
The quirk is if GNS gets disabled/locked for some reason (not that this is a common occurrence - this has worked great for us since we've deployed it) then you will default back to your local files.
If you happen to say have an old DG with the same name but maybe not the same devices you'll end-up using that old file. The "quirk" is I don't think you can manipulate "local" non-GNS DG files while GNS is active - at least if they have the same name.
So in short - clear your host of DGs before enabling GNS - it could eliminate some confusion down the road
GNS will take care of renaming devices when pushing DGs to R2 box.. thus looking at the DG from "the other side" of your RDF link will always give you a valid DG. Remote BCV will become local and vice versa. There is a whole section "How to mirror remote device group definitions" in Solution Enabler manuals (Symmetrix Array Management CLI) explaining how to enable remote mirroring of dgs.
Dynamox already pointed the "source" of all knowledge regarding GNS .. however as stated a lot of times here in our forums, talkiing about GNS is harder then implementing it
Change a couple of lines in your "options" file, issue a symdg -inactive list command and activate your DGs (thus moving them into GNS)... Now jump on another host, change options file and issue symdg list .. and enjoy the magic
Does the topic get any more complex when you are talking about an SRDF environment? While I agree using GNS locally is pretty straightforward I believe you do need to do a little more thinking about replicating GNS don't you?
GNS will take care of renaming devices when pushing DGs to R2 box.. thus looking at the DG from "the other side" of your RDF link will always give you a valid DG. Remote BCV will become local and vice versa. There is a whole section "How to mirror remote device group definitions" in Solution Enabler manuals (Symmetrix Array Management CLI) explaining how to enable remote mirroring of dgs.
I'll have to see what sort of updates are now available, when I began using GNS you had to use a host based solution to manage syncing of the device groups to remote symms which meant being careful about things such as how many and which servers would manage your replication.
Normally you'll enable GNS on all of your hosts but there were specific and valid warnings about making sure you did not enable GNS replication on too many servers.
Back then you could easily turn on GNS and use it but you had to be a little more careful about replicating GNS in a real world situation.
dynamox
11 Legend
•
20419 Posts
•
87439 Points
1438
0
Posted October 9th, 2008 08:00