Presently I'm experimenting with the following:
/etc/zfs/vdev_id.conf alias ost01d1shasl00 /dev/disk/by-id/dm-uuid-mpath-35000cca26b825d6c alias ost01d2shasl01 /dev/disk/by-id/dm-uuid-mpath-35000cca26b860178 alias ost01d3shasl02 /dev/disk/by-id/dm-uuid-mpath-35000cca26c1e2cb4 alias ost01d4shasl03 /dev/disk/by-id/dm-uuid-mpath-35000cca2680a8280 and using that to make sure that the disks have persistent names across reboots. I still need to test pulling out one of the SAS cables to make sure that the multipathing works, and test replacing a disk. I read on http://wiki.lustre.org/ZFS_OSD_Hardware_Considerations that "The configuration of the device multi-mapper service is quite complex and can affect the performance characteristics of the solution. In some cases, JBODs can exhibit bad behavior from using load-balanced IO balancing, when in fact all the requests for a disk are expected to arrive from a single interface. For this reason, when working with JBODS it is recommended to use the path_grouping_policy that enables failover-only capability." so I presently set my systems to failover mode. w/r, Kurt ________________________________ From: lustre-discuss <[email protected]> on behalf of [email protected] <[email protected]> Sent: Thursday, May 9, 2019 4:21 PM To: [email protected] Subject: lustre-discuss Digest, Vol 158, Issue 10 Send lustre-discuss mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.lustre.org%2Flistinfo.cgi%2Flustre-discuss-lustre.org&data=02%7C01%7Cstrosahl%40jlab.org%7Caf7c47376b2d44b69a1708d6d4bbe959%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636930300867938953&sdata=rP9azd3ble3LOVL%2BXUmfghJJsD0HlAGWrk2djNP1Ty4%3D&reserved=0 or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of lustre-discuss digest..." Today's Topics: 1. Enable multipath for existing Lustre OST with ZFS backend (Tung-Han Hsieh) ---------------------------------------------------------------------- Message: 1 Date: Fri, 10 May 2019 03:25:52 +0800 From: Tung-Han Hsieh <[email protected]> To: [email protected] Subject: [lustre-discuss] Enable multipath for existing Lustre OST with ZFS backend Message-ID: <[email protected]> Content-Type: text/plain; charset=big5 Greetings, Recently we have a new storage device. It has dual RAID controllers with two fibre connections to the file server which map the LUM of the storage to the server: # lsscsi -g [5:0:0:0] disk IFT DS 1000 Series 661J /dev/sdb /dev/sg4 [6:0:0:0] disk IFT DS 1000 Series 661J /dev/sdc /dev/sg6 # /lib/udev/scsi_id -g -u /dev/sdb 3600d02310009ff8750249f7e31c5fd86 # /lib/udev/scsi_id -g -u /dev/sdc 3600d02310009ff8750249f7e31c5fd86 So /dev/sdb and /dev/sdc are actually the same LUM of the storage. We have created the Lustre OST with ZFS backend on /dev/sdb: # mkfs.lustre --ost --fsname chome --mgsnode=<host> --index=0 \ --backfstype=zfs chome_ost/ost /dev/sdb It works fine. But soon after that, I was told that I should setup multipath to take the advantage of dual fibre channel for load balance and HA. I am wondering whether it is too late or not because we already have data of Lustre file system running on it. I read the documents of multipath. It seems that after setting multipath, both /dev/sdb and /dev/sdc are re-mapped to, say, /dev/mapper/mpath0. The existing data is probably not affacted. What we need to do is just to replace the device name /dev/sdb by /dev/mapper/mpath0 (please correct me if I am wrong). So the problem seems leading to ZFS. Now my OST pool "chome_ost/ost" was created on /dev/sdb. Could we replace the pool device name to /dev/mapper/mpath0 ? Thanks very much for you suggestions in advance :) Best Regards, T.H.Hsieh ------------------------------ Subject: Digest Footer _______________________________________________ lustre-discuss mailing list [email protected] https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.lustre.org%2Flistinfo.cgi%2Flustre-discuss-lustre.org&data=02%7C01%7Cstrosahl%40jlab.org%7Caf7c47376b2d44b69a1708d6d4bbe959%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636930300867938953&sdata=rP9azd3ble3LOVL%2BXUmfghJJsD0HlAGWrk2djNP1Ty4%3D&reserved=0 ------------------------------ End of lustre-discuss Digest, Vol 158, Issue 10 ***********************************************
_______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
