SSUS scripting & EVA disk location.

[Steve Lawrence_1]

Hi all,

When using a SAN Management Appliance (OS 2.1) I can locate a disk in a disk group, click on it and it'll show me at the bottom of the disk's page which enclosure & bay the disk is located in.

I'd like to be able to do this programatically via SSUS.

Now, I can query my EVA and ask for a disk's information :

EVA> show disk "\Disk Groups\146 GB Disk Group\Disk 059"

\Disk Groups\146 GB Disk Group\Disk 059 information:
Identification:
Name : \Disk Groups\146 GB Disk Group\Disk 059
Loop_Pair : LoopPair1
Node_World_Wide_ID : 2000-000C-50A8-9E1D
rssid :
rssindex :
Loop A:
Port_World_Wide_ID : 2000-000C-50A8-9E1D
Assigned_Lun : 0
Loop_ID : 86
loopalpa : 4d
Loop B:
Port_World_Wide_ID : 2000-000C-50A8-9E1D
Assigned_Lun : 0
Loop_ID : 86
loopalpa : 4d
Condition State:
Operational_State : Normal
Migration_State : Not migrating
Failure_Prediction : No
Media_Accessible : Yes
Loop_A_State : Normal
Loop_B_State : Normal
Physical:
Type : Fibre Channel Disk
Manufacturer : HPQ
Model_Number : BD14655B2A
Firmware_Revision : HP03
Formatted_Capacity : 136.73 GB
System:
Requested_Usage : Member of StorageCell
Actual_Usage : Member of StorageCell
Disk_Group : \Disk Groups\146 GB Disk Group
Occupancy : 56.84 GB
Comments :
ID : 3a0807100c0000201d9ea8500000000000000000

However I'm not seeing here any information about it's actual location. I'm supposing I could divine this from its Loop Pair & LoopID.

I can also get information on the enclosure itself by doing a :

EVA> show monitor "\Hardware\Rack 1\Disk Enclosure 1"

And of the information that results I can see things like :

Sensor : DISK1TEMP
Status : NotInstalled
Tmp : F/ C
Alarms : N/A
Sensor : DISK2TEMP
Status : NotInstalled
Tmp : F/ C
Alarms : N/A
Sensor : DISK3TEMP
Status : OK
Tmp : 69.8 F/21.0 C
Alarms : None

Which allows me to figure out if there's a disk in a bay or not.

But I'm still unable to figure out how to determine which disk is in which enclosure/bay.

Is there something I'm missing? Can anyone help me determine how to correlate a disk's information so I can map my EVA?

Thanks in advance,
Steve Lawrence.

[Uwe Zessin]

Steve,
there simply is not enough information presented through SSSU to get that information. I have checked this myself some time ago and I have asked several people from HP who have been helpful in the past, but unfortunately they could not come up with a solution.

You might try to use the AL_PA or Loop-ID, because the EVA is now using hard addressing, but that can be screwed up if a disk is being replaced and the algorithm is not published anyway.

I have renamed the disk drives as a workaround, e.g. "Disk E01 B12". I also feel that gives a better overview when I check the Disk Groups.


Yes, yes, I know we are not supposed to 'micro-manage' the EVA. I have been through this multiple times now...

[Steve Lawrence_1]

>there simply is not enough information presented through SSSU to get that information.

So, it's not just me...

>You might try to use the AL_PA or Loop-ID

What is loopalpa : 4d?
Loop-ID's I can cope with, but loopalpa is a new one on me.

>I have renamed the disk drives as a workaround, e.g. "Disk E01 B12". I also feel that gives a better overview when I check the Disk Groups.

That's fair enough. Unfortunately it's just cosmetic. My problem is that I have multiple presentations, and they need to get striped down the EVA.

If I lose a disk, and I have the 'auto-insert' turned on, then it'll grab a spare and slap it into my group. If that spare happens to be in the same enclosure as another disk in the same group I've lost my stripe.

What ends up happening is when a disk fails a spare is swapped in, the tech pulls out the dead disk, replaces dead disk, and then physically removes the spare - all in order to keep the stripes down the EVA correct.

What *I* would like to do is, instead of manually clicking all over the SAN GUI to check that the disks are all in nice, neat lines going down the enclosures, run an SSSU script to suck out each disk's position / grouping / LUN and present it as an easy to look at web page or something.

(I'm more than proficient at the perl side of hacking apart the SSSU output... I just can't find the right output to hack.)

It *has* to be able to be done, 'cos the GUI gets the information somehow.

I suppose I could run a 'Capture configuration' and see what that tells me what to do. Theoretically that should create me a configuration *exactly* the same as the one I have now, yes? Which I'm positing would be exact down to the location of each disk...

Steve.

[Uwe Zessin]

Steve,

"loopalpa": AL_PA is for "Arbitrated Loop - Physical Address". It is how devices are addressed on an FC_AL (Fire Channel - Arbitrated Loop'). It is _somewhat_ similar to an IP address. The MAC address' equivalent is the WWN of the Fibre Channel port.

AL_PA and Loop-ID mean the same thing. AL_PAs start from 0 (reserved for the FL_Port) and then go: 1, 2, 4, 8, 15, ... (there are many holes in it due to the way FC_AL works). A low values implies a high priority on the loop. The Loop-ID is from 0..127, but a low value implies a low priority.

Loop-ID is just a user-friendly way to hide the rather crude AL_PA values.

-

Sorry, but I am afraid you misunderstand the EVA: it simply does not have a dedicated spare disk. If you set a disk group's "protection level" to 1 or 2 it reserves "spare capacity" and distributes it equally over all disks in the disk group (distributed sparing). If a disk fails, all its VRAID-1 and VRAID-5 data is recovered and written to the "spare capacity" on the other disks (it is not exactly true if there is free space in the disk group, but let's leave it simple).

When the defective disk is replaced and a new disk is added to the disk group (be it through "auto-insert" or a manual "group") the EVA will use its standard load leveling feature. There is no knowledge kept that a particular bay position was once a member of a particular disk group.

The good thing is that all disks in the group are available for I/Os. The negative thing is that each disk group has its own "spare capacity", but such is life: even breakfast is not free.

I have not played with "auto-insert", but my understanding is this:
if it is turned on, it will put _any_ new disk into _the_ disk group which has the least amount of free space!

I really suggest you do a "CAPTURE CONFIGURATION" - that should always be done after any change to the EVA, because it is THE ONLY WAY to recover the configuration. Well, if you then check the file you will see that it has nothing in it that refers to physical disk positions!

[Steve Lawrence_1]

Ahh...

You are of course, quite correct. And I am confusing myself with my HSG disks which do have spares, and suffer from the above.

Those I'd also like to map, but that's an entirely different story.

I shall soldier on and see what I can come up with. Thanks for the info.

Steve.

[Uwe Zessin]

Well, good luck or have fun - whatever you prefer ;-)

The output from the HSG can look quite entertaining sometimes, beleive me. I have written a map/reporting utility, but I can not give it away, sorry.

[Steve Lawrence_1]

Really...

I have to admit I've not even begun on *that* path.

Am I right in thinking that SSSU doesn't do HSG reporting. And if so, could you clue me in on what you *do* use to get config details on an HSG?

Steve.

[Uwe Zessin]

Hello Steve,
you are correct. SSSU can not do HSG reporting. It looks to me like it is using some XML-based protocol to talk via TCP/IP to the SMA which then talks via Fibre Channel to the EVA.

I usually connect a notebook via serial port to the HSG's maintanance port and capture the output of the CLI "SHOW" commands. In our own facility we have put the HSG's ports onto a terminal server. We then use a terminal emulator on a PC to connect via TELNET protocol to different TCP ports on the terminal server which are mapped to its physical ports. We have also put all other devices with serial ports (except for the EVA ;-) on the server. That allows us console access from any room.

It is also possible to have a host-based program that talks via the SWCC agent or directly in-band over Fibre Channel to the HSG. These days it is called the "HP StorageWorks Command Scripter", but it is an extra-cost option:
http://h18000.www1.hp.com/products/sanworks/commandscripter/index.html

[Mike Naime]

Steve:

Have you tried the LOCATE command with a UNIT name on the HSG's? I.E. LOCATE D1 will show all of the drives associated with unit D1.

We also use the CLI port plugged into a Decserver 700's to manage our HSG's. This is monitored/accessed by TDI's ConsoleWorks. Add VPN and a Wireless card to your Laptop... And you are managing from anywhere that you can get Internet Access. :-)

On the EVA. I think that you are trying to micro manage it too much. Let the EVA do it's thing! Your sparing level is the number of disks that you can easily sustain drive failures of without loosing your data. Select disks after this (Depending on RSS groups) can also be lost without data loss occuring.

Manage the space. not the spindles!

[Erwin van Londen]

Steve,

Be aware though that the only this you can do regarding redundancy is the location of the drives with regards of the RSS configuration. If you have more than 1 drive in the same shelf which belongs to the same RSS (redundant storage set) and that shelf failes you will lose you vraid5 sets.
The only thing you can do about that is keep track of the location of the drives and place each drives of an RSS in another shelf. (This implies you need a minimum of 8 shelfs)

Regards,
Erwin van Londen
HP Master ASE SAN Architect.

[Steve Lawrence_1]

> (This implies you need a minimum of 8 shelfs)

Indeed. I have 12 shelves.. :)

I haven't actually progressed with this any since I wrote the original request. I never really *did* get to find what I was looking for, and put it on the back burner for a while. Thanks for the response though.

Steve.

[Steve Lawrence_1]

>The only thing you can do about that is keep track of the location of the drives and place each drives of an RSS in another shelf.

Oky, I read this through again, and this is *exactly* what I was trying to do. I have raid sets, striped down the enclosures, and I would like to ensure that I do *not* have two drives in the same shelf.

I was hoping I could get the information on which shelf/enclosure each drive was in, so I don't get into the pickle described above.

I know it *can* be done. I've seen an HP Engineer run something which does precisely this, but after enquiring about the tool it turns out it was an internal thing that he can't give away - or somesuch.

Steve.

[Erwin van Londen]

Steve,

If your running firmware 3010 or higher and you have Command View EVA you can locate those drives.

If you give me your email adress I can send you a little tools which you can run. If you send the output back to me I can generate a nice looking html file.

Regards,
Erwin van Londen
HP Master ASE SAN Architect.

[Erwin van Londen]

I ment Command View EVA 3.1

[Derek_31]

Erwin,

There is there any way you can post the software and what you do to make it look pretty?

[Erwin van Londen]

Sorry, I cannot post the software. Again an HP Internal tool. Legal restrictions apply.

Erwin van Londen
HP Master ASE SAN Architect.

[Steve Lawrence_1]

*chuckle*

Is this internal tool available to buy?

Either way. steve.lawrence@comcast.net is my e-mail address. I'd be grateful for any help regarding this.

Steve.

[Erwin van Londen]

This tool is not on the market. It was designed for documentation purposes for internal labs. Maybe if the customers ask there HP representative often enough they will ship it. I don't know.
Sorry I cannot provide you with it.

Regards
Erwin van Londen
HP Master ASE SAN Architect.

[Steve Lawrence_1]

>Maybe if the customers ask there HP representative often enough they will ship it.

They won't. I've asked my TAM, and his response is inline with your own. It's an 'internal' tool, and we cannot provide it to you.

Which quite frankly, sucks.

I actually care less about the tool. If it were available I'd buy it. If it's not, I'm sufficiently versed in programming to be able to extract the data and write my *own* tool. However, I can't find a way to *get* that data - even though it quite clearly exists. Documentation is sparse at best.

If I understand correctly, the 'extraction of data' is something which *is* available - the tool you spoke of to create the binary file?

What *isn't* available is the tool used to map that data into a pretty representation of the EVA. Am I correct?

You mentioned that I could run a tool you could provide, e-mail you the results and from that get a pretty html map? Is this still the case?

Steve.

[Tom O'Toole · Accepted solution]

Steve,

If all you want is to know the disks
location, you can indeed divine that from
the looppair and loopID. On our (12 shelf)eva the following formula works, I don't know if they are all wired up the same way:

bay=mod(loop_id,14)+1
enclosure=7*loop_pair-loop_id/14+1
(integer arithmetic)

I wrote a command procedure which reads the output of sssu "show disk full" and creates
an sssu script to rename all the disks in the
array to sensible names reflecting location.

[Steve Lawrence_1]

Oh good grief,

This is exactly what I needed. Thanks very much for the pointers.

The bay formula works like a charm. I had some trouble interpreting the enclosure formula, but after some sitting down with a notepad came up with the same as yours, but it could perhaps be better expressed as :

((7 * loop_pair) - (int (loop_id / 14))) +1

I should mention that the loop_id involved in the formula above is that reported by sssu rather than by the San Appliance EVA clicky application (which appears to convert it into a Hex number).

I am ecstatic that you've given me the shove in the right direction - nay, to the answer I was looking for, and get a (10) for your post :)


I shall now be off to write my pretty html page. If only HP had the presence of mind to let in on this, and save me/you/us the trouble of having to reverse-engineer the damn thing.

Steve.

[Uwe Zessin]

Please be aware that this is done using hard-addressing. A disk swap causes a re-initialization of the loop-pair. I have been told that in some situations the controller might have to revert to soft-addressing - in that case the formula will not work for all bays.