[ClusterLabs] Filesystem Resource Device Naming Convention

[Tyler Phillippe]

Right, I agree. I was just seeing if anyone from ClusterLabs or Red Hat could give a "formal" recommendation to use WWIDs - it's just an up hill battle for us on my team without an actual recommendation or documentation from the creators/maintainers. Ha!

Thanks all!

Respectfully,
 Tyler Phillippe



Apr 21, 2023, 4:56 PM by jerome.becot at deveryware.com:

>
> Well,
>
>
> If you use friendly names bare, you can swap disk names if your      system loose connection to the SAN Array and reconnects with many      factors. If you configure static device names in the config, you      probably already configure wwids ? Then it's more reliable to not      declare them in the configure and disable friendly names, so disks      are identified by their WWID directly.
>
>
> Regards
>
> Le 21/04/2023 à 22:41, Tyler Phillippe      via Users a écrit :
>
>> 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> <mailto: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
>>>
>>
>>
>> _______________________________________________Manage your subscription:>> https://lists.clusterlabs.org/mailman/listinfo/users>> ClusterLabs home: >> https://www.clusterlabs.org/
>>
> --
> Jérôme            BECOT>  
>  > Ingénieur DevOps Infrastructure 
>  
>  > Téléphone fixe: >  > 01 82 28 37 06
>  > Mobile : +33 757 173 193
>  > Deveryware - 43 rue Taitbout - 75009          PARIS
>  >  >  https://www.deveryware.com
>  
>   <https://www.deveryware.com>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20230422/24581569/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: baniere_signature_dw_2022.png
Type: image/png
Size: 471995 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20230422/24581569/attachment-0001.png>