Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar such that vict.jar -w 50000972081349AD shows “VMax-HK192601234-12gB” per https://community.emc.com/thread/118881
Tag Archives: Zone
Revision 551 – Suggested Nicknames for Known WWN Patterns
In deployments, very often customers zone their storage based only on a zone-name and WWPN members. Typically this causes a need for the Zone-Vote Algorithm to be used, but that’s an approximation that requires the user to be consistent in Zone names, consistent in zone membership (ie anywhere one FA or HBA is used for an entity, all the others need to be used at the same time).
There are some cases where the WWN is entirely predictable; in such cases, the option “-w” to vict.jar (such as vict.jar -w 50060482B82F9654) shows a suggested nickname or alias such as “Symm-182500953-05bA” (per http://www.emcstorageinfo.com/2007/08/how-to-decode-symmetrix-world-wide.html) which can be leveraged to provide for missing nicknames.
Revision 526 – Vote02-ZoneSplit2onTargetPrefix.awk
Every customer is different, and their nicknames of zone titles is no exception. There is no clear consistency in zone names which can then lead near-consistently to Attached Device Names. Nearly.
Zone-Vote Algorithm is always an assumption-lead guess. It poses only a slim chance of being 100% accurate.
In cases where the target in a zone title starts with the same prefix, this Stage-2 of the process can help narrow it down. I added Vote02-ZoneSplit2onTargetPrefix.awk to split zone names based on the prefix of the target device (for example if all targets start with STOR*)
Revision 515 – Added Vote02-ZoneSplit2AndOther for Zone-Voting Algorithm
Many customers choose to give each attached device (Server, Tape, Storage) a nickname or alias, and create their zones that way. Some customers choose to nickname the individual connections (FA or HBA ports) uniquely within the individual components of a fabric. These are very simple to pull out of a copy of the zoning information — whether it be via text files from switches dumping their zoning/VSANs, or reading the zone info replicated in BNA. Both of these methods are handled by the “nickname” option to “vict”.
Others choose to store the nicknames or aliases of the various fabric members in the names of the zones themselves; for example, the zone that allows a server “Oracle44”, via Host Bus Adapter “HBA0”, to communicate with “VMAX12” via Front-end Adapter “10aA”, that zone might be called “Oracle44_HBA0_VMAX12_10aA_prod_A” — the additional “prod_A” is a commonly used method of adding text/comments to the data.
In this revision, I added “Vote02-ZoneSplit2andother.awk” for use at companies who nickname zones with additional text, such as Server_HBA and Server_Name_FA_etc_etc
Revision 512 – Vict Nickname Now Parses Cisco Device-Alias Database
The vict (VI Client Tool) “nickname” action now understands the output of a “show device-alias database” command on cisco.
In past, customers and users generate these files either by running the command in a plink.exe or ssh session (ie: the simplest way), or by capturing a log from their ssh session and running the command manually (ie the more-work way). Unfortunately, in the awk-based parser, replacing spaces with tabs blows away the parser, so this smarter parser should be able to handle that now.
My commit note was simply “Added basic parser for output of Cisco ‘show device-database alias’ behind VIClientTool’s –nickname= option”, and that says it all to ME, but to expand for others, this is what that means:
Recall that with multi-column CSVs, Brocade “alishow”, and Brocade “zoneshow”, a user can ignore the format of the file and just send it in with a “nickname” long-option or “N” for the short-option aficionados.
Now, if you give VICT a cisco “show device-alias database” output, it’ll make sense of that too.
The logic is the same: throw the content scattered at all the parsers, and see who gets the most results.
Although this and other parsers will get the reformatted output from a BNA ext ration (and soon, NetApp), only the basic parser ever gets results form those, so this new parser shouldn’t affect anything adversely. ..but without much forethought, the user gets another format to use.
Revision 509 – Hard-Zone Skip-Filter in Awk but None in Parser
In Revision 509, I added a filter to skip hard-zoning in the awk-based zoneshow filtering to nicknames.
The “fix” is merely to discard them: No nicknames are present when they’re used, and only 1% of customers use them (I’ve seen it twice, ever)
Revision 502 – Obsessive Parser Retry
I’m not proud of this one. Please bear with be:
In revision 493, I wrote about how the parser for “–nickname=” actually pushes content to three separate parsers, and simply chooses the one with the best results. That was all about not trying to guess the content, but leave the guessing to the parsers. Whichever one gets the most, it wins. Too easy, and extremely scalable.
Problem is, the underlying Apache lib used to fork-off the incoming stream — to avoid downloading a file multiple times to parse it — that doesn’t always seem to work.
I put a lot of time and concern into trying to figure out why, but in the end, I just added a retry-counter.
When all parsers return a “shoot, I dunno” response, we simply run it again. And again. And again. …not so obsessive because we give up after 3 times, but you’re free to make it as psychotic/obsessive as you want.
To describe this, I verbosely wrote “add retries to the parsing so that we can thrash on a file if we need to just-get-it-done”
I promise to do better design in the future, but for now, this will only re-download a file for each full retry cycle. This doesn’t matter at all for file:// URLs, but for ftp://, bnapsql://, and http://, it will show up as multiple tries.
Revision 493 – Nickname Parses ZoneShow
For this revision, I wrote: “enable the –nickname= function to fork inbound content to a number of parsers; the one with the most results wins. Net result: the FAE or user needs not worry what they send to the tool, it will try to figure out what the file is. Supports user-selected columns in CSV, Brocade ZoneShow, and BNA”
What does that mean, in detail?
In past, the –nickname= fed directly into a single consumer that understand the user giving a “;WWN=x” or “;Nickname=y”, and uses those columns as input to nickname data.
Now, there are three parsers all feeding from the same resource, so even remote content (ie ftp:// and http:// URLs) is only downloaded once, but forked to many parsers. Without the user worrying about format, the three parsers try to interpret the stream to see what they can dig up. The “winning” parser is the one with the most results, effectively adapting to whatever the user sends it …of the three formats currently understood directly:
- WWN,Nickname (WWN=x and Nickname=y are still effective)
- Brocade
zoneshow
output (accuracy is challenged if the user sends a logdump of a screen-scraped output; for best results, treat the output as binary, and convert it directly usingplink.exe
orssh
, not a screen-capture of a log dump) - Brocade binary zone information from BNA versions 11 or 12
To re-iterate, the following URI types are understood:
- http://www.example.com/file.ext
- ftp://ftp.example.com/file.ext (anonymous FTP; have not tested user/pass)
- file://current/directory/subdir/file.ext (same as .\current\directory\subdir\file.ext in windows)
- file:///current/directory/subdir/file.ext (three slashes, same as \current\directory\subdir\file.ext in windows)
- bnapsql://bna.example.com/
- no URL: –nickname=sampleZone.zone (confirmed in testcases)
Convert Zone Info to Nicknames for VirtualWisdom
VirtualWisdom uses “Nicknames” or “Aliases” to give human-readable names to attached SAN devices, reducing the time to locate a problem device, but also to help group devices logically as being the same server or storage, and into business units for SLAs and escalation of issues.
We know that Nickname management can be a hassle, but the obvious gains make it worthwhile, so some of our work in Services is helping customers draw this data from existing repositories such as fabric Zoning information. Maintaining aliases in your zones, then converting those to nicknames, means that you only need to maintain one repository of names.
This “How-to” article is targeted at showing how to do this in common environments. As a VI Application Engineer, my content on this feed tends to be more of a lower-level “how to” in nature. This content has been in our internal self-help content, but may be difficult to find.
Collection, then Conversion
The general process tends to be collecting the data, then converting to a compatible format for import. Let’s focus first on Collection, which tends to be a script running at scheduled times during the day or week.
Scripting under Schedule
This tends to be done as a batch file that is triggered through a scheduler such as the Windows Scheduler running a BAT file, or a UNIX-like OS running a shell script from cron or as a passive check under tools such as Icinga.
Where fabric-wide data is used, only one switch per fabric needs be queried. I tend to use the least-busy switch to avoid adding any load to Core switches or other busy switches.
Will DBTools Work for You?
The easiest method if you have small switches is to use \Program FilesVirtual Instruments\VirtualWisdom\UnSupported\DBTools\DBTools.exe
tool, but running it as a batch command. This tool will connect to the switch using SSH, query the information, and convert it to the right format for import. In essence, the collection and conversion is a single step. For example, using the example username “scott”, password “tiger”, switch IP 192.168.0.1, to a file FabricA.csv in the import directory:
Brocade “alishow”: (the command is all on one line)
DBToolScript.bat -n -st brocade -u scott -p tiger -ip 192.168.0.1 D:\VirtualWisdomData\DeviceNickname\FabricA.csv
Cisco “fcalias”:
DBToolScript.bat -n -st cisco -u scott -p tiger -ip 192.168.0.1 D:\VirtualWisdomData\DeviceNickname\FabricA.csv
For example:
(In this example, my demo server has the database on the C: drive; this is not the recommended config for production servers! Also, notice how the DBToolScript cannot open a log file — running this command in your VirtualWisdomData directory will allow it to write a log to .\Log\DBToolLog\ )
Putting commands such as this into a batch file running daily via Windows Scheduler, and configuring a scheduled Import via the VirtualWisdom Scheduler, your job is complete!
The DBTools command doesn’t understand all possible nickname sources, and may have problems on some switches; if this method doesn’t work for you, then we resort to the two-stage process. This less-polished method is a bit more versatile, but isn’t as pretty. Once configured, though, it tends to work reliably.
Collection
The more manual collection can be done from four different sources:
- Brocade Switch using “zoneshow”
- Brocade Switch using “alishow”
- Cisco Switch using “show device-alias database”
- Cisco Switch using “show fcalias”
Collection requires non-interactive SSH tools such as plink.exe available from the makers of Putty; google should help you find it, but if you cannot, VI can help redirect you. The general command is:
plink.exe -l username -pw password IP.IP.IP.IP "command" > intermediate.file
For example: (using scott, tiger, 192.168.0.1, and a Brocade/zoneshow switch)
plink.exe -l scott -pw tiger 192.168.0.1 zoneshow > sw-192.168.0.1.zone
… and a Cisco/”show device-alias database” at 192.168.0.3:
plink.exe -l scott -pw tiger 192.168.0.3 "show device-alias database" > sw-192.168.0.3.cisco
These commands give no output when they run, except the first time: the plink.exe command wants you to accept a key to later ensure you are not vulnerable to a man-in-the-middle attack, which looks like the following: (accept the key once, later you won’t be asked unless it changes)
Again, you only need to collect zoning information or fabric-wide alias information from one switch per zone. With a unique filename per fabric, you’re ready to convert these files.
Conversion
Brocade and Cisco tend to use consistent formats for their outputs, but they are in text format. Most times, the two scripts work for this. These are scripts for the “awk” tool, which can be extracted from the UnxUtils project, or using Microsoft’s tools for UNIX. Either method gives you a “awk.exe” or a “gawk.exe”, which will execute these scripts:
Conversion of a Brocade zonecfg or alishow is done as:
gawk.exe -f brocade-alishow2wwncsv.awk sw-192.168.0.1.zone > D:\VirtualWisdomData\DeviceNickname\FabricA.csv
Whereas conversion of a Cisco device-alias database or fcalias is done as:
gawk.exe -f cisco-devicealias2wwncsv.awk sw-192.168.0.3.cisco > D:\VirtualWisdomData\DeviceNickname\FabricB.csv
Note: these runs are redirecting output to files, so these commands give no visible output to the cmd.exe screen except in the case of errors.
Complete Example
A complete example of collection and conversion may look like the following code. Be aware, we tend to recommend using full pathnames (i.e. C:\Program Files\something\else\plink.exe
) to ensure the commands are found regardless %PATH% variable and working directory. This example is simplified to be more readable but does run as-is given the right environment and working directory.
@echo off
plink.exe -l scott -pw tiger 192.168.0.1 "show device-alias database" > sw-192.168.0.1.cisco
plink.exe -l scott -pw tiger 192.168.0.2 "show fcalias" > sw-192.168.0.2.cisco
plink.exe -l scott -pw tiger 192.168.0.3 "zoneshow" > sw-192.168.0.3.zone
plink.exe -l scott -pw tiger 192.168.0.4 "alishow" > sw-192.168.0.4.zone
gawk.exe -f brocade-alishow2wwncsv.awk sw-192.168.0.3.zone sw-192.168.0.4.zone > nicknames.csv
gawk.exe -f cisco-devicealias2wwncsv.awk sw-192.168.0.1.cisco sw-192.168.0.2.cisco >> nicknames.csv
This example generates a single file; the configuration to import this one file is as follows (briefly shown here because the User Guide has more detail regarding Schedules):
- Views Application, Setup tab:
- “Schedules” page, roughly 5th item down:
- Create a new Schedule, with the action “Import WWN Nicknames”:
- …and configure it to use a new WWN Importing Configuration, as follows. NOTE we only use a local filename, all files are in the
\DeviceNickname
directory of your VirtualWisdomData folder: