Two devices detected by Linux Server

[XiangAlephas]

I am new about the MSA file manager system and Linux server, and my issue is as followed.

As we made a new HP work station along with a MSA2060, the engineers seem to connected both controllers with a same work station, which turns into that the server detects two devices with different name, while poccessing the same UUID and PARTUUID. I was wondering that is this a normal phenomenon that any server linked by two controller would meet?

As well, I searched a post that the poster also was in similary situation, and the solution is that using multiphat-tools to mapping the two devices into A mapping device. Is that a solution for my dilemma?

## the output of lsblk and blkid instruction are listed below:

// lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 10.9T 0 disk
└─sda1 8:1 0 10.9T 0 part
└─md127 9:127 0 54.6T 0 raid5 /data
sdb 8:16 0 10.9T 0 disk
└─sdb1 8:17 0 10.9T 0 part
└─md127 9:127 0 54.6T 0 raid5 /data
sdc 8:32 0 10.9T 0 disk
└─sdc1 8:33 0 10.9T 0 part
└─md127 9:127 0 54.6T 0 raid5 /data
sdd 8:48 0 10.9T 0 disk
└─sdd1 8:49 0 10.9T 0 part
└─md127 9:127 0 54.6T 0 raid5 /data
sde 8:64 0 10.9T 0 disk
└─sde1 8:65 0 10.9T 0 part
└─md127 9:127 0 54.6T 0 raid5 /data
sdf 8:80 0 10.9T 0 disk
└─sdf1 8:81 0 10.9T 0 part
└─md127 9:127 0 54.6T 0 raid5 /data
sdg 8:96 0 128T 0 disk
└─sdg1 8:97 0 128T 0 part
sdh 8:112 0 128T 0 disk
└─sdh1 8:113 0 128T 0 part
nvme0n1 259:0 0 476.9G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
├─nvme0n1p2 259:2 0 954M 0 part /boot
├─nvme0n1p3 259:3 0 119.2G 0 part [SWAP]
└─nvme0n1p4 259:4 0 356.3G 0 part /

// blkid

/dev/sdf1: UUID="63f1cf24-61a5-f90a-27be-bc35f6c21f47" UUID_SUB="46226779-c301-5f47-e14e-a2802bf8f1db" LABEL="debian:0" TYPE="linux_raid_member" PARTLABEL="Linux RAID" PARTUUID="a431b1c1-123a-4205-a7a3-929686c22a0b"
/dev/nvme0n1p3: UUID="02d9e192-4633-4192-b8ff-57479ff0d16e" TYPE="swap" PARTUUID="ad560b91-17f8-468d-8df6-328a46d2d850"
/dev/nvme0n1p1: UUID="C8DD-58BA" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="d270dee3-0476-4e8a-94b7-14fe89b76048"
/dev/nvme0n1p4: UUID="658db337-c76c-4567-adf7-e20e155612c5" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="754eac4c-01eb-4efa-ad2e-21c6f92a1d2f"
/dev/nvme0n1p2: UUID="097c2919-864e-4167-a9e4-a231cb8070e3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="e37bd16e-dc6f-4b1f-88f4-7e56e2f88f62"
/dev/sdd1: UUID="63f1cf24-61a5-f90a-27be-bc35f6c21f47" UUID_SUB="fc57f281-e06c-5415-4a98-e06026f63565" LABEL="debian:0" TYPE="linux_raid_member" PARTLABEL="Linux RAID" PARTUUID="12809c66-60be-4189-b705-81c5fd93c39e"
/dev/md127: UUID="2ec5d1f3-46ce-4d24-a177-7c0296a27ff3" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sdb1: UUID="63f1cf24-61a5-f90a-27be-bc35f6c21f47" UUID_SUB="7e268556-c0c3-dcf7-f45d-6846e33cce0e" LABEL="debian:0" TYPE="linux_raid_member" PARTLABEL="Linux RAID" PARTUUID="2f44695c-e185-4372-b5e7-d0d2a35d621b"
/dev/sdg1: UUID="1c48b0b5-b331-41e3-a228-d73d3bc948ea" BLOCK_SIZE="4096" TYPE="xfs" PARTUUID="626ce9d6-397a-424f-b5f8-c7589c629eb7"
/dev/sde1: UUID="63f1cf24-61a5-f90a-27be-bc35f6c21f47" UUID_SUB="150bd9ff-7f04-9736-7b26-dd3c5b4dbe3c" LABEL="debian:0" TYPE="linux_raid_member" PARTLABEL="Linux RAID" PARTUUID="598498d9-ad5d-4854-8483-0ec7c08893bf"
/dev/sdc1: UUID="63f1cf24-61a5-f90a-27be-bc35f6c21f47" UUID_SUB="d6d36c64-9241-3ae2-7322-c88ca00049bf" LABEL="debian:0" TYPE="linux_raid_member" PARTLABEL="Linux RAID" PARTUUID="b7d88a3e-4ebf-4601-9d68-6d98eb1ae0ea"
/dev/sda1: UUID="63f1cf24-61a5-f90a-27be-bc35f6c21f47" UUID_SUB="d7227cfb-a779-c9ea-a47c-23e121703d65" LABEL="debian:0" TYPE="linux_raid_member" PARTLABEL="Linux RAID" PARTUUID="1f00844e-bbbc-49ce-8382-c63bd8a9e1c3"
/dev/sdh1: UUID="1c48b0b5-b331-41e3-a228-d73d3bc948ea" BLOCK_SIZE="4096" TYPE="xfs" PARTUUID="626ce9d6-397a-424f-b5f8-c7589c629eb7"

[XiangAlephas]

What's  more, if the multipath-tools is the ultimate solution, I would request your kindly instruction of formating the correct multipath.conf information.

Deep gratitude as well.

[ArunKKR]

Hi,

This response is purely from MSA storage perspective as I have very limited expertise with Linux.
Below sample multipath config is listed in MSA best practices guide:

https://www.hpe.com/psnow/doc/a00105260enw  - Page 6

Add the following to /etc/multipath.conf devices section:

device {
vendor “HPE"
product “MSA 1060 iSCSI"
path_grouping_policy “group_by_prio"
prio “alua"
path_selector “round-robin 0"
failback “immediate"
no_path_retry 18
}

Duplicate LUNs would appear if multipath is not configured.
You may wait for any inputs from other storage consultants with Linux expertise.

[JonPaul · Accepted solution]

@XiangAlephas 
Yes you need to install DEVICE MAPPER multipath software on the Linux system.  The latest versions (the last 2 years) of device mapper include a default section for HPE MSA products which will have the correct settings.  
The MSA will present the LUNs as specified by the mapping process.  The default is to map a volume to a LUN from every host port on the MSA.  This will generate a SCSI device for every path found (looks like you have 4 PATHs to a volume, likely 2 HBA ports to 2 array Host Ports == 4 PATHs).  Once device mapper is installed you will have one dm device:  /dev/mapper/mpath_   (Typically mpatha)  Which should be used instead of the /dev/sd_ . Device mapper handles all failover and load balancing.  In your current setup you would likely lose access to your application in a controller shutdown as the /dev/sd_  for a path would no longer be available.  Device mapper will retry paths and failover to other paths as needed.

[XiangAlephas]

That helps a lot, thank you for your support with my greatest gretitude

[Sunitha_Mod]

Hello @XiangAlephas,

That's Excellent!

We are delighted to hear your concern has been adressed and we appreciate you for keeping us updated.