[ClusterLabs] Filesystem Resource Device Naming Convention
Tyler Phillippe
tylerphillippe at tutamail.com
Fri Apr 21 16:41:59 EDT 2023
LVM (currently) isn't an option for us since most of the team is unfamiliar with it. We use Puppet to push out the multipath.conf and are trying to prevent against a badly written or changed config file being pushed to the PCS servers - that's what I meant by corruption, more so than actual bit corruption. Was thinking if the Filesystem resource pointed to the WWID, since that can only change on the SAN box, even if the multipath.conf was wrong or the aliases changed, the resource wouldn't know/care/fail.
Thanks!!
Respectfully,
Tyler Phillippe
Apr 20, 2023, 9:36 PM by nwahl at redhat.com:
> On Thu, Apr 20, 2023 at 1:49 PM Tyler Phillippe via Users
> <users at clusterlabs.org> wrote:
>
>>
>> Hello all,
>>
>> In my position, we are running several PCS clusters that host NFS shares and their backing disks are SAN LUNs. We have been using the /dev/mapper/<multipath-alias> name as the actual device when defining a PCS Filesystem resource; however, it was brought up that potentially the multipath configuration file could be corrupted in any number of accidental ways. It was then proposed to use the actual SCSI WWID as the device, under /dev/disk/by-id/scsi-<wwid>. There has been discussion back and forth on which is better - mostly from a peace of mind perspective. I know Linux has changed a lot and mounting disks by WWID/UUID may not strictly be necessary any more, but I was wondering what is preferred, especially as nodes are added to the cluster and more people are brought on to the team. Thanks all!
>>
>
> I almost always see users configure LVM logical volumes (whose volume
> groups are managed by LVM-activate resources) as the device for
> Filesystem resources, unless they're mounting an NFS share.
>
> I'm not aware of the ways that the multipath config file could become
> corrupted (aside from generalized data corruption, which is a much
> larger problem). It seems fairly unlikely, but I'm open to other
> perspectives.
>
>> Respectfully,
>> Tyler Phillippe
>> _______________________________________________
>> Manage your subscription:
>> https://lists.clusterlabs.org/mailman/listinfo/users
>>
>> ClusterLabs home: https://www.clusterlabs.org/
>>
>
>
>
> --
> Regards,
>
> Reid Wahl (He/Him)
> Senior Software Engineer, Red Hat
> RHEL High Availability - Pacemaker
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20230421/2c282c5e/attachment.htm>
More information about the Users
mailing list