This revision reduces some clutter in that some checks that don’t apply — such as ProbeVM checks in a ProbeSW-only environment — are avoided. In that way, the content shown has higher signal-to-noise ratio.
Author Archives: Allan Clark
Revision 529 – Check Summary Average Delay
Revision 529 is where the FileSystem Layout Detection (r527) is used to start highlighting risks in Summary Insertion Delay.
I would prefer to also look at the insertion time rather than delay, as delay may well remain constant while the actual insertion cost can lead to longer delay. That’s like addressing speed difference rather than distance between two race cars: looking at differences in speed can alert more quickly and predict changes in distance. Similarly, more metrics can be watched once I figure them out. Just like most users, I’m looking from the outside, but I can fake up the interpreted content in a known-ciphertext-attack -like method of using conditioned input to the parser to tell me what I’m seeing.
Revision 527 – Improved FileSystem Layout Detection
internal: the detection of filesystem layout and file relative locations was all twisted, and was flakey. So I’m ripping it out. It’s mostly refactored, but in order to leverage it sooner, there are currently both methods active. The flakey one will finish dying very soon, but in the meantime, only most of the code benefits from this structure change rather than all of it.
The way I’m doing it now is a straight Booch-ian method of taking multiple objects and using them to encapsulate the logic. They are interchangeable. The most applicable will be chosen by — you guessed it — voting. Whichever one looks most likely will be used. This allows me to abstract off discovery of pathnames and locations as they change from live server, PortalLogs, and database backup without huge changes in code and whackloads of if/else loops.
The behavior I wanted to leverage more quickly is the reading of summarymon log to check performance at the database insertion side.
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 521 – Dump-Config for ESX HBAs to Check PHC
In revision 521, I added the ability to dump out the esx hbas as esxhbas.csv, esxhbas.xml, vminventoryraw.csv, or vminventoryraw.xml similar to dumping roving.xml and roving.csv. The outputs are self-documenting in #comments in the CSV, or as XML self-documents already. The benefit of this function is that when the PHC seems to miscalculate the HBA speeds in phc-vm.csv, the raw data can be debugged. Note that the XML has no whitespace, so “xmllint -format esxhbas.xml” is your friend.
For example:
(typically running locally: the MySQL is configured to only accept local connections)
java -jar vict.jar -D esxhbas.csv
or
java -jar vict.jar -D esxhbas.xml
…and in long-options too:
java -jar vict.jar --dump-config esxhbas.xml
…but since the JRE is typically hidden below the VirtualWisdom directory, use vict.bat:
VICT.BAT -D esxhbas.xml
VICT.BAT --dump-config esxhbas.xml
Revision 516 – Added parsing of OnCommand Data for Nicknames
In revision 516, the basic capability to ask an OnCommand/NetApp management console for the Nickname/WWPN mapping has been added. This allows the reuse of the information it has collected by various device-specific methods to add meaning and facility to VirtualWisdom.
The ability to avoid re-polling and re-querying data essentially reduces the load to the devices polled and reduces the management effort: re-using the effort already expressed to configure one tool means that no additional effort is required — so long as the information is usable.
In this case, the same parser logic is used as was added for BNA in BNA Query later expanded to both “pools” in BNA. Like the BNA work, the OnCommand query simply reformats a query and sends it through the array of parsers to vote upon:
java -jar vict.jar --nickname=osmsql://user:pass@server:port/ --nicknameout=\VirtualWisdomData\DeviceNickname\nicknames.csv
Default user/pass are not accurate, so that still needs to be resolved. Like the BNA parser, this method hits the underlying database directly, so it needs (firewalls/filters) direct access to the server, and is vulnerable to schema changes.
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 514 – WBDCopyByFilterPrefixed for UDC2FilterLaconic
Added a WBDCopyByFilterPrefixed.xsl that (compared to WBDCopyByFilter.xsl) prefixes the filtername to copied dashboards (sans parentheses); used with UDC2FilterLaconic.xsl, results in much shorter replicated dashboard names.
The original pair of “WBDCopyByFilter” and “UDC2Filter” together with a dashboard called “ProbeSW – Summary” and a UDC called “Array_SW” would — for the value “DMX001901”, create copies of the prototype including “ProbeSW – Summary (Array_SW = DMX001901)”.
The new pair of “WBDCopyByFilterPrefixed” and “UDC2FilterLaconic” would create copies of the prototype including “DMX001901 ProbeSW – Summary”. Clearly shorter, yet scriptable and deterministic.
Revision 513 – UDC2FilterLaconic
Added a UDC2FilterLaconic.xsl to create filters from UDCs with shorter names; in past, the filters created are “UDCName = UDCValue”, such as “ArraySW = DMX001901” or (in the , Filters for VirtualWisdom UDC) “Application_SW = SVCS Analysis Cluster”.
This variant only produces filters named for the value: “DMX001901” or “SVCS Analysis Cluster”. I’ve called it “Laconic” because it is clearly less verbose that its model.
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.