IO Fencing with 2 matrixes - Veritas Cluster Server

This is a discussion on IO Fencing with 2 matrixes - Veritas Cluster Server ; Hi, We have cluster infrastructure with two nodes based on VCS 4.1 and two matrixes EMC CX700. One of matrixes has 2 coordinator disks and the second has one coordinator disk. We had power blackout so one of our matrixes ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: IO Fencing with 2 matrixes

  1. IO Fencing with 2 matrixes


    Hi,
    We have cluster infrastructure with two nodes based on VCS 4.1 and two matrixes
    EMC CX700. One of matrixes has 2 coordinator disks and the second has one
    coordinator disk. We had power blackout so one of our matrixes with two coordinator
    disks became unavailable. That caused kernel panic on both cluster nodes
    though one of our nodes still had full access to recources which are mirrored
    by volume manager and had all FC links alive. How we can prevent that kernel
    panic in the future? Of course we would like to keep our IO Fencing functionality.

  2. Re: IO Fencing with 2 matrixes

    The problem came about with the location of the coordinator disks.

    The remaining machine knows that there are 3 coordinator disks.
    It sees that the other machine in the cluster is gone, and starts racing
    for the coordinator disks.
    It is only able to win the race for 1 disk (as the other 2 are not
    available). The machine does not know that the disks are not available
    (how should it know). It just can not put it's keys on those disks. It
    then assumes that it got fenced out from those disks and will panic.


    To resolve, make the coordinator disks available always, or accecpt that
    a panic might happen

    Adam wrote:
    > Hi,
    > We have cluster infrastructure with two nodes based on VCS 4.1 and two matrixes
    > EMC CX700. One of matrixes has 2 coordinator disks and the second has one
    > coordinator disk. We had power blackout so one of our matrixes with two coordinator
    > disks became unavailable. That caused kernel panic on both cluster nodes
    > though one of our nodes still had full access to recources which are mirrored
    > by volume manager and had all FC links alive. How we can prevent that kernel
    > panic in the future? Of course we would like to keep our IO Fencing functionality.


  3. Re: IO Fencing with 2 matrixes


    Me, Thank You for your information.

    Way the nodes cannot send information about accessibility of coordinator
    disk by interconnects or low-priority public network link?
    How can I make coordinator disks available always? Can I mirrored coordinator
    disks by volume manager?

    Kind regards,
    Adam.
    Me wrote:
    >The problem came about with the location of the coordinator disks.
    >
    >The remaining machine knows that there are 3 coordinator disks.
    >It sees that the other machine in the cluster is gone, and starts racing


    >for the coordinator disks.
    >It is only able to win the race for 1 disk (as the other 2 are not
    >available). The machine does not know that the disks are not available
    >(how should it know). It just can not put it's keys on those disks. It
    >then assumes that it got fenced out from those disks and will panic.
    >
    >
    >To resolve, make the coordinator disks available always, or accecpt that


    >a panic might happen
    >
    >Adam wrote:
    >> Hi,
    >> We have cluster infrastructure with two nodes based on VCS 4.1 and two

    matrixes
    >> EMC CX700. One of matrixes has 2 coordinator disks and the second has

    one
    >> coordinator disk. We had power blackout so one of our matrixes with two

    coordinator
    >> disks became unavailable. That caused kernel panic on both cluster nodes
    >> though one of our nodes still had full access to recources which are

    mirrored
    >> by volume manager and had all FC links alive. How we can prevent that

    kernel
    >> panic in the future? Of course we would like to keep our IO Fencing functionality.



  4. Re: IO Fencing with 2 matrixes

    Coordinator disks are used only when the links are not available !!


    So, when a node dies

    Adam wrote:
    > Me, Thank You for your information.
    >
    > Way the nodes cannot send information about accessibility of coordinator
    > disk by interconnects or low-priority public network link?
    > How can I make coordinator disks available always? Can I mirrored coordinator
    > disks by volume manager?
    >
    > Kind regards,
    > Adam.
    > Me wrote:
    >
    >>The problem came about with the location of the coordinator disks.
    >>
    >>The remaining machine knows that there are 3 coordinator disks.
    >>It sees that the other machine in the cluster is gone, and starts racing

    >
    >
    >>for the coordinator disks.
    >>It is only able to win the race for 1 disk (as the other 2 are not
    >>available). The machine does not know that the disks are not available
    >>(how should it know). It just can not put it's keys on those disks. It
    >>then assumes that it got fenced out from those disks and will panic.
    >>
    >>
    >>To resolve, make the coordinator disks available always, or accecpt that

    >
    >
    >>a panic might happen
    >>
    >>Adam wrote:
    >>
    >>>Hi,
    >>>We have cluster infrastructure with two nodes based on VCS 4.1 and two

    >
    > matrixes
    >
    >>>EMC CX700. One of matrixes has 2 coordinator disks and the second has

    >
    > one
    >
    >>>coordinator disk. We had power blackout so one of our matrixes with two

    >
    > coordinator
    >
    >>>disks became unavailable. That caused kernel panic on both cluster nodes
    >>>though one of our nodes still had full access to recources which are

    >
    > mirrored
    >
    >>>by volume manager and had all FC links alive. How we can prevent that

    >
    > kernel
    >
    >>>panic in the future? Of course we would like to keep our IO Fencing functionality.

    >
    >


+ Reply to Thread