Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: stopping pacemaker doesnt move resources to other node

  1. Re: stopping pacemaker doesnt move resources to other node

    I have it on my test SLES 15.1 cluster
    Code:
    # crm ra list stonith | grep scsi
    fence_pve                 fence_raritan             fence_rcd_serial          fence_rhevm               fence_rsa                 fence_rsb                 fence_sanbox2             fence_sbd                 fence_scsi
    # rpm -qf /usr/sbin/fence_scsi
    fence-agents-4.2.1+git.1537269352.7b1fd536-5.38.x86_64
    My patterns that I have selected during install
    Code:
    S  | Name          | Summary                    | Type
    ---+---------------+----------------------------+--------
    i  | apparmor      | AppArmor                   | pattern
    i  | base          | Minimal Base System        | pattern
    i+ | enhanced_base | Enhanced Base System       | pattern
    i+ | ha_sles       | High Availability          | pattern
    i+ | minimal_base  | Minimal Appliance Base     | pattern
    i  | yast2_basis   | YaST System Administration | pattern

  2. Re: stopping pacemaker doesnt move resources to other node

    Quote Originally Posted by strahil-nikolov-dxc View Post
    I have it on my test SLES 15.1 cluster
    Code:
    # crm ra list stonith | grep scsi
    fence_pve                 fence_raritan             fence_rcd_serial          fence_rhevm               fence_rsa                 fence_rsb                 fence_sanbox2             fence_sbd                 fence_scsi
    # rpm -qf /usr/sbin/fence_scsi
    fence-agents-4.2.1+git.1537269352.7b1fd536-5.38.x86_64
    My patterns that I have selected during install
    Code:
    S  | Name          | Summary                    | Type
    ---+---------------+----------------------------+--------
    i  | apparmor      | AppArmor                   | pattern
    i  | base          | Minimal Base System        | pattern
    i+ | enhanced_base | Enhanced Base System       | pattern
    i+ | ha_sles       | High Availability          | pattern
    i+ | minimal_base  | Minimal Appliance Base     | pattern
    i  | yast2_basis   | YaST System Administration | pattern
    Thanks. I think that will work. Let me try that.

  3. Re: stopping pacemaker doesnt move resources to other node

    Hi,

    Finally, I could test with fence_scsi and it worked to the extent it is supposed to. But in order to unfence the node it requires the node to be rebooted, which requires a manual attention (or can be automated in some ways), but thats not probably I am looking at.

    My requirement is -
    1) node should not go down with fencing
    2) unfencing operation should not require a reboot of the node
    1 could be done by fence_scsi, but 2) I couldnt find a way.

    So, if 1) and 2) both are not possible, then I am fine going for sbd based fencing, but in that case I am looking for fence operation to actually shutdown the node instead of rebooting, but rebooting of the node is actually orchestrated from some other flow.

    Is there a way I can achieve this ?

  4. Re: stopping pacemaker doesnt move resources to other node

    Can you show the fencing device configurration?
    Code:
    crm configure  show <device_name>
    Most probably you don't have the 'meta provides="unfencing"' to your fencing device.

  5. Re: stopping pacemaker doesnt move resources to other node

    Quote Originally Posted by strahil-nikolov-dxc View Post
    Can you show the fencing device configurration?
    Code:
    crm configure  show <device_name>
    Most probably you don't have the 'meta provides="unfencing"' to your fencing device.
    I dont have the configuration wrt fence_scsi right now, coz I started experimenting with something else. I will try this option, but I still dont know even if I configure this option what will trigger unfencing operation to this node ? I read at multiple places -- "The failed node will no longer be able to write to the device(s). A manual reboot is required."
    Since reboot was not an option for me, I didnt configure that. But doesnt this sentence mean that a manual reboot needs to be triggered to the node, and during the course of reboot (maybe be before rebooting), the node shall be unfenced.

    What I would want is to be able to "unfence" the node without rebooting. Is there a way to do it ? Can a node unfence itself once the issue with the node is resolved ?



    Regards
    Maneesh

  6. Re: stopping pacemaker doesnt move resources to other node

    Quote Originally Posted by mnshsnghl View Post
    I dont have the configuration wrt fence_scsi right now, coz I started experimenting with something else. I will try this option, but I still dont know even if I configure this option what will trigger unfencing operation to this node ? I read at multiple places -- "The failed node will no longer be able to write to the device(s). A manual reboot is required."
    Since reboot was not an option for me, I didnt configure that. But doesnt this sentence mean that a manual reboot needs to be triggered to the node, and during the course of reboot (maybe be before rebooting), the node shall be unfenced.

    What I would want is to be able to "unfence" the node without rebooting. Is there a way to do it ? Can a node unfence itself once the issue with the node is resolved ?



    Regards
    Maneesh
    Unfencing should be done by pacemaker itself with the meta attribute from the previous comments. Sadly my test cluster is ontop of VmWare and that doesn't support persistent SCSI-3 reservations.
    If I have time, I will deploy an iSCSI and try it myself.
    Keep in mind that the fence_scsi will automatically detect which LUNs need to be fenced/unfenced if they are part of a volume group with "c" flag (clustered) , but will require the "devices=" if you use HA-LVM (which I prefer as it supports dual corosync rings).

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •