The Dell MD3200i is a very flexible mid-level iSCSI SAN. With 12 bays (up to 3TB NearLine SAS in each) and dual quad-port controllers, it offers excellent redundancy, capacity, and expandability. The Windows or Linux MD Storage Manager provides a decent GUI from which to define disk groups of various RAID styles and virtual volumes within each disk group for future filesystems.

But for all the labeling controls that MDSM offers for groups and volumes, the LUN mappings (to allocate volumes to iSCSI IP connections) are the real exposed labels. No matter how anal-retentive you get with group/volume hierarchy, all the ‘naming’ that the iSCSI initiators will ever see are the LUN numbers 0-31.

In an iSCSI system, there could be multiple ways to reach LUNs (via multiple network interfaces). For this reason, multipath support is used to provide route management and redundancy. On CentOS, filesystems are accessed via the multipath /dev/mapper device naming, mapped to the ‘physical’ iSCSI LUN. How are these mappings managed? ‘mpatha‘, ‘mpathb‘, ‘mpathc‘, etc are assigned first-come first-served to LUNs in the order they are discovered. This can make it difficult when adding multiple LUNs at the same time, because it is not entirely obvious which /dev/mapper/mpath device corresponds to which partition (despite all that effort you employed in creatively naming your MD3200i groups and volumes).

Because of my momentary confusion in regard to this LUN mapping, I thought that I would document the iSCSI implementation steps as performed on CentOS 6:

Discover Available LUNs

After adding volumes on your MD3200i (or other iSCSI target) – and granting the necessary host mapping permissions – CentOS needs to discover what iSCSI volumes have been made available:

Now here was my moment of confusion. The discovery command essentially completes in silence. What did it find? One way to see LUN info is by reviewing the console log with ‘dmesg’ or ‘tail /var/log/messages’. I was hoping for a more tabular command output that I could later use in scripts, but the best I could find is reviewing the iscsiadm session data at a particular info/debug level:

Here we see which iSCSI LUN was mapped to which local device name. Make note of this, because multipath adds another layer of abstraction that will make knowing these important.

Update Multipath Locations

Since multipath is being employed, we need to rescan for newly available volumes and update the /dev/mapper devices:

Now we know which is which. Note that size alone would not help me identify things. I created both new volumes – one RAID0, one RAID1 – as the same size. So the key is knowing that LUN #10 (my RAID1) is mapped to ‘sdd’, and then that ‘sdd’ is multipathed to ‘mpathe’.

Now we can proceed with the filesystem initialization on my mirrored drive.

Create A Partition

Make The FileSystem

Looking at /dev/mapper, we now see that the ‘mpathe’ volume has a partition defined. Run ‘mkfs’ on the resulting partition:

Mount the FileSystem

All that remains is to mount the filesystem. This was going to be a permanent mount (persistent across reboots), so I’m going to add it to /etc/fstab and run the “mount -a” command:

Note the use of the _netdev option, which tells CentOS not to bother mounting this filesystem if networking (and thus iSCSI) is not active.