VirtualWisdom UDCs for Script Variables

howto Add comments

I worked with a user of a SAN monitoring product called VirtualWisdom, and it allows the user to define a matric for devices based on filters — basically, evaluating unrelated filter expressions in order, stopping at the first hit found, and providing a “catch-all”.

We wanted to allow the SAN administrator to keep migrating content off EVAs to remove an interposing virtualization product, with alerts to indicate when some content was in critical state without the admin having to continuously poll it. We wanted to work with user-visible response-time of the SAN (ie keep response time below 8ms) but had to settle for Capacity/Utilization metrics.

On our case, we looked at running evaperf on a disk array showing poor throughput — as soon as the user-visible response time drops (we call this “Exchange Completion Time”), the evaperf is run against that array. The problem is that the name of the array (ie the parameter to evaperf that indicates which array) is uppercase, and doesn’t match the various names of users ( ie servers named such as oradb07a2) or arrays (arrays named such as westeva8). We used UDC:

  1. if the ITL target is “wdceva1”, UDC “EVA” value is “EVA01”
  2. if the ITL target is “edceva2”, UDC “EVA” value is “EVA02”
  3. if the ITL target is “wdceva3”, UDC “EVA” value is “EVA03”
  4. if the ITL target is “edceva4”, UDC “EVA” value is “EVA04”
  5. if the ITL target is “westeva7”, USD “EVA” value is “EVA07” (yes, change in naming format)
  6. if the ITL target is “easteva8”, USD “EVA” value is “EVA08”
  7. … etc …
  8. otherwise, UDC value is “EVA00” as a catch-all

What this allowed us to do is create an alarm:

  1. groups by link, channel
  2. filter: EVA is not “EVA00” to avoid running the script where we don’t know the EVA
  3. if utilization exceeds 80%, run the evaperf external-script
  4. script parameters include $EVA$, which is defined as the value of the UDC “EVA” when the alarm triggers
  5. the “re-arm” stage sends an email to alert the administrator that evaperf was run and there is a report to pick up

This alarm forms the basis of an ECT-based alarm, but the metrics do not coincide, so we’re still looking at how to do that.

Currently, the administrator can apply this alarm to all switches, and as EVA utilization gets too high, the alarm automatically runs the evaperf tool to show what LUNs are being heavily used. The re-arm is set fairly long so that the running of evaperf (which we expect to cause some slowdown in overall processing) doesn’t get detected (via performance impact) as ANOTHER reason to run the evaperf script.

This alarm as it is allows the administrator to focus on migrating content off the EVAs, but proceed at an orderly pace until utilization on an existing link needs to be distributed off to another link — and the evaperf tool tells him which LUNs to move.

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in