1

  • How do I check if a LUN has been presented to my server? What are the Linux commands for that? Do the LUNs show up in a fdisk -l command like a normal /dev/sda gets listed?

  • What are other commands associated with general SAN related checks in Linux?

  • What is WWN and how does that have any relevance?

  • If we have LUNs, what is the use of multipathing?

Bit lengthy but I am not able to get a grasp on the topic. Any help would be appreciated.

Improve this question

3 Answers 3

Reset to default
8

Yes, a LUN will be presented by the HBA to the OS as just another disk; fdisk -l should list this.

Since the OS has no visibility to the SAN storage, there's no special commands in the OS that will give you any insight into the SAN environment. However, some storage vendors provide tools that will interface with the HBA cards to give you some visibility.

A device's WWN (world-wide name) is an identifier much like an MAC address in IP networking (and is essentially equivalent to the EUI in the iSCSI side of things); it should uniquely identify a member of a storage network (the SAN and the client computers' HBAs both have WWNs) and is used in both transit ("where does this data need to go?") as well as authentication ("which system gets to see this LUN?").

Multipathing is, in essence, a means for eliminating single points of failure, or for balancing load, throughout your storage network.

So, for example, say you have two controller units for your SAN shelves, so that if one goes down the other can still serve the data. Well, that doesn't do you any good if you're only being presented the LUN through a single path - through the now-deceased controller.

Same goes for SAN switches and HBA cards in servers; you don't want to lose connectivity because of the failure of a single piece of equipment. Since each piece of equipment has its own WWN, adding redundancy throughout the system will give you at least 4 paths; each of two HBAs will see each LUN through each of two controllers.

Here's the catch, though - without multipathing awareness, the OS on the client system is going to consider each of those 4 paths as separate disks (going back to the fact that the disks are just presented as-is to the host OS). So, what multipathing gives the OS is the ability to figure out that all those copies of the same disk are, in fact, just multiple paths to get to the same disk, and to either use the alternate paths as failover or to balance load over the paths.

Improve this answer
2

The commands you'll use on linux to interact with SAN storage depend on the protocol used. Storage you make available to a linux server from your SAN generally won't become visible from a command like fdisk until you discover it. For iscsi, you would do this with iscsiadm --mode discovery --portal $PORTAL --type sendtargets where PORTAL is the IP address of your SAN. For fibre channel you would write $C $T $L to /sys/class/scsi_host/host$H/scan, where C is the channel, T is the target id, L is the lun, and H is the host.

This is just a taste; you should look at Red Hat's Storage Administration Guide and DM Multipath Guide for more of the gory details.

Improve this answer
0

Another note: you can see the current state of the iscsi initiator with the command iscsiadm -m session -P 3. This will show you what block devices map to what LUNs on what targets.

The same information is also available by reviewing the sysfs filesystem. I wrote a Perl script that queries the sysfs entries and maps an iscsi block device to its target and LUN: https://gist.github.com/3154821

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .