This post is more than 5 years old
30 Posts
0
6191
How can I tell which servers have SRDF protection?
I'd like to come up with a list of all my servers that have any storage being replicated by SRDF.
I know symcfg -sid xxxx list -rdfg all will give me the names of all my RDF groups. Unfortunately, their names don't follow my company's naming convention and don't include the names of the initiators that use the symdevs in the groups.
I know symdev -sid xxxx list -rdfg yy will show me the symdevs in an RDF group, and then I can use symaccess -sid xxxx list -type stor -dev zzzzz to get the storage group to which an individual symdev belongs, and so I can work backward from there to the masking view and the initiator group and finally learn what initiator is using the SRDF-protected symdev. That's a pretty cumbersome process, though, when I have one thousand replicated symdevs spread across twenty RDF groups.
So, is there a SymCLI command to get the name of every initiator that's masked to at least one symdev protected by SRDF? (If not every initiator, I would at least settle for every storage group that includes protected symdevs, since my storage groups do tend to follow the naming convention and would give me a clue as to the name of the associated initiator.) Or do I have to learn how to script?
Thanks!
seancummins
226 Posts
0
July 29th, 2015 11:00
Hi Ben,
I'm not aware of a single command that will do this, but you could correlate the outputs from two different commands to produce what you're looking for.
The first command (symaccess list devinfo) will show you all of the devices that each initiator can "see."
The second command (symrdf list) will list all RDF-protected devices.
One way to do this correlation might be to bring the output of both commands into two different Excel tabs, and then use VLOOKUPs to match SymDev IDs from the 'symaccess' command to SymDev IDs from the 'symrdf' command.
Hope that helps...
- Sean
bhalilov1
114 Posts
1
July 29th, 2015 12:00
How about
symsg -sid 1234 show host1_sg
symdev -sid 1234 list -R1 -sg host1_sg
or symsg -sid 1234 list -v
sauravrohilla
859 Posts
0
July 30th, 2015 05:00
As Sean said, no single command to tell you the server/hosts in srdf pairing..
combine two cmd outputs and use vlookup.
regards,
Saurabh
umichklewis
1.2K Posts
1
July 30th, 2015 08:00
This looks like a job for a script! All of the SYMCLI commands include -xml in their formatting options, so with a proper XML interpreter, you can easily script in Perl, ruby or PowerCLI.
In your case, you can use symdev -sid xxxx list -rdfg yy -output xml to get a list of your devices. Each SymDev is wrapped in an XML tag, so you can use Perl to grab the devices with the right tag, then pass them to another command. Since the XML tags are pretty consistent, and easy to document, we've found this to work well for most of our scripts.
Let us know what you move forward with!
ben_brooks
30 Posts
0
August 3rd, 2015 14:00
Sean, thanks for the suggestion; this is probably what I'll do. One question about symrdf list, though: Does it show all the devices that are in RDF groups and being protected, or does it show all the RDF-type devices?
I'm new to SRDF and don't know how closely membership in RDF groups is tied to a device's being RDF-type. If an RDF-type device can only exist inside an RDF group, then a list of RDF-type devices is the same as a list of SRDF-protected devices, so symrdf list works for sure. However, if it's possible for an RDF device to exist outside an RDF group--say, if I created an RDF1+TDEV but then I decided I didn't want to protect it, and I just used it like any other TDEV without SRDF--then the list of RDF devices can be different from the list of devices protected by SRDF, and I will need to know which one of those is reported by symrdf list.
Again, I don't know SRDF well and it may be that the situation I've just described can't actually occur, but I need to ask. Thanks!
seancummins
226 Posts
0
August 3rd, 2015 15:00
Sure thing Ben.
I can't think of any scenario which would result in a device being an RDF-type but not in an RDF group.
The closest scenario I can think of would be a case where you had a pair of arrays in an SRDF configuration, but you decommissioned one array without first deleting the SRDF pairs. In this situation, your SRDF pairs would be in a Partitioned state, and the surviving array would still be configured with RDF-type devices, but they wouldn't be replicating because the "partner" array would (hypothetically) be gone. But even in this scenario, symrdf list would still show the devices -- they'd just be in a Partitioned state (instead of, for example, a Synchronized or a Consistent state).
If you're concerned about the possibility of "false positives" (i.e. incorrectly assuming a is RDF-protected), then you could also double-check the RDF state to ensure that the device in question is being actively replicated. States like "Consistent" and "Synchronized" mean that a particular device is being actively replicated and is in a healthy state... whereas states like "Suspended," "Failed Over," "Partitioned," or "Updated" are atypical.
Hope that helps,
-Sean
ben_brooks
30 Posts
0
August 14th, 2015 16:00
Bhalilov, your suggestions got me thinking and I realized there's this option:
symsg -sid xxxx list -v | egrep 'Name:|RDF'
This basically writes a list of all storage groups that have RDF devices. If I could count on my SG's to all be named after the initiator group they're masked to, it would accomplish my goal in a single command. However, because this only gets me as far as the SG and Sean's approach goes all the way to the IG, I prefer Sean's answer:
1) symaccess -sid xxxx list devinfo > devinfo.txt (I need to create a file because my PuTTY can't hold all the output.)
2) symrdf -sid xxxx list
3) Copy the outputs of the two commands above into two separate tabs in Excel.
4) On the tab that has the devinfo output, use vlookup to note which symdevs also appear on the symrdf output tab.
This shows me lists of RDF devices with IG names as headings. Very nice.
Karl, I'd love to learn to script this. Do you have any quick tips about where a total novice could pick up scripting? Thanks!
By the way, there's one more piece to my SRDF puzzle. I've written about it at https://community.emc.com/thread/218499 (no idea why it's already marked as assumed answered) and I'd be grateful if any of you had any input.
Thanks, everyone!
umichklewis
1.2K Posts
0
August 17th, 2015 05:00
The best way to pick up scripting is to find routine things that you have to do - day in and day out - and gradually learn to automate them. Basically, take one piece of something and slowly start to automate it. You'll find pieces of scripts that you build will be used over and over again (things like loops, reading input from files and command line, etc.) and will help you grow as a programmer.
Specifically around VMAX scripting, I find I do most of my work in UNIX shell scripts, using UNIX tools like awk, and grep. As I mentioned, VMAX commands can product output in XML, and there are awk and perl extensions for that. However, unless you work regularly in UNIX/Linux, that's probably not very useful to you. I'd suggest learning Python - there are tons of online resources for learning the language and many, many script examples you can grab and modify to quickly get started.
There are Python modules for easily parsing XML, so you could quickly grab output from the VMAX and do real work with it. In your example above, you could replace steps 3 and 4 with a list or array of the output, that you could import into another series of commands.
Give it a try and let us know how it goes!
Karl
seancummins
226 Posts
1
August 17th, 2015 05:00
Ben,
For what it's worth, I did a SYMCLI scripting session (mainly in Python) at EMC World last year. It's no longer live on the EMC World site, so I just uploaded it to YouTube here: https://youtu.be/qGPiSrdr0wQ
Thanks,
- Sean