[ClusterLabs] Antw: [EXT] Re: Order set troubles

Fri Mar 26 02:35:01 EDT 2021

On Thu, Mar 25, 2021 at 10:20 PM Andrei Borzenkov <arvidjaar at gmail.com>
wrote:

> On 25.03.2021 21:45, Reid Wahl wrote:
> > FWIW we have this KB article (I seem to remember Strahil is a Red Hat
> > customer):
> >   - How do I configure SAP HANA Scale-Up System Replication in a
> Pacemaker
> > cluster when the HANA filesystems are on NFS shares?(
> > https://access.redhat.com/solutions/5156571)
> >
>
> "How do I make the cluster resources recover when one node loses access
> to the NFS server?"
>
> If node loses access to NFS server then monitor operations for resources
> that depend on NFS availability will fail or timeout and pacemaker will
> recover (likely by rebooting this node). That's how similar
> configurations have been handled for the past 20 years in other HA
> managers. I am genuinely interested, have you encountered the case where
> it was not enough?
>

Yes, and I was perplexed by this at the time too.

I just went back and checked the notes from the support case that led to
this article, since it's been nearly a year now. Apparently there were
situations in which the SAPHana resource wasn't failing over when
connectivity was lost with the NFS share that contained the hdb* binaries
and the HANA data. I don't remember the exact details (whether demotion was
failing, or whether it wasn't even trying to demote on the primary and
promote on the secondary, or what). Either way, I was surprised that this
procedure was necessary, but it seemed to be.

The whole situation is a bit of a corner case in the first place. IIRC this
procedure only makes a difference if the primary loses contact with the NFS
server but the secondary can still access the NFS server. I expect that to
be relatively rare. If neither node can access the NFS server, then we're
stuck.

>
> > I can't remember if there was some valid reason why we had to use an
> > attribute resource, or if we simply didn't think about the
> sequential=false
> > require-all=false constraint set approach when planning this out.
> >
>
> Because as I already replied, this has different semantic - it will
> start HANA on both nodes if NFS comes up on any one node.
>

Ah yes, that sounds right.

But thank you for the pointer, it demonstrates really interesting
> technique. It also confirms that pacemaker does not have native means to
> express such ordering dependency/constraints. May be it should.
>

I occasionally find that I have to use hacks like this to achieve certain
complex constraint behavior -- especially when it comes to colocation. I
don't know how many of these complex cases would be feasible to make
possible natively via RFE. Sometimes the way colocation is currently
implemented is incompatible with what users want to do. Probably requires
considerable effort to change it, though such requests are worth
documenting in RFEs.

/me makes a note to do that and annoy Ken

> > On Thu, Mar 25, 2021 at 3:39 AM Strahil Nikolov <hunter86_bg at yahoo.com>
> > wrote:
> >
> >> OCF_CHECK_LEVEL 20
> >> NFS sometimes fails to start (systemd racing condition with dnsmasq)
> >>
> >> Best Regards,
> >> Strahil Nikolov
> >>
> >> On Thu, Mar 25, 2021 at 12:18, Andrei Borzenkov
> >> <arvidjaar at gmail.com> wrote:
> >> On Thu, Mar 25, 2021 at 10:31 AM Strahil Nikolov <hunter86_bg at yahoo.com
> >
> >> wrote:
> >>>
> >>> Use Case:
> >>>
> >>> nfsA is shared filesystem for HANA running in site A
> >>> nfsB is shared filesystem for HANA running  in site B
> >>>
> >>> clusterized resource of type SAPHanaTopology must run on all systems if
> >> the FS for the HANA is running
> >>>
> >>
> >> And the reason you put NFS under pacemaker control in the first place?
> >> It is not going to switch over, just put it in /etc/fstab.
> >>
> >>> Yet, if siteA dies for some reason, I want to make SAPHanaTopology to
> >> still start on the nodes in site B.
> >>>
> >>> I think that it's a valid use case.
> >>>
> >>> Best Regards,
> >>> Strahil Nikolov
> >>>
> >>> On Thu, Mar 25, 2021 at 8:59, Ulrich Windl
> >>> <Ulrich.Windl at rz.uni-regensburg.de> wrote:
> >>>>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 24.03.2021 um 18:56 in
> >>> Nachricht
> >>> <5bffded9c6e614919981dcc7d0b2903220bae19d.camel at redhat.com>:
> >>>> On Wed, 2021‑03‑24 at 09:27 +0000, Strahil Nikolov wrote:
> >>>>> Hello All,
> >>>>>
> >>>>> I have a trouble creating an order set .
> >>>>> The end goal is to create a 2 node cluster where nodeA will mount
> >>>>> nfsA , while nodeB will mount nfsB.On top of that a depended cloned
> >>>>> resource should start on the node only if nfsA or nfsB has started
> >>>>> locally.
> >>>
> >>> This looks like ad odd design to me, and I wonder: What is the use
> case?
> >>> (We are using "NFS loop-mounts" for many years, where the cluster needs
> >> the
> >>> NFS service it provides, but that's a different design)
> >>>
> >>> Regards,
> >>> Ulrich
> >>>
> >>>
> >>>
> >>>>>
> >>>>> A prototype code would be something like:
> >>>>> pcs constraint order start (nfsA or nfsB) then start resource‑clone
> >>>>>
> >>>>> I tried to create a set like this, but it works only on nodeB:
> >>>>> pcs constraint order set nfsA nfsB resource‑clone
> >>>>>
> >>>>> Any idea how to implement that order constraint ?
> >>>>> Thanks in advance.
> >>>>>
> >>>>> Best Regards,
> >>>>> Strahil Nikolov
> >>>>
> >>>> Basically you want two sets, one with nfsA and nfsB with no ordering
> >>>> between them, and a second set with just resource‑clone, ordered after
> >>>> the first set.
> >>>>
> >>>> I believe the pcs syntax is:
> >>>>
> >>>> pcs constraint order set nfsA nfsB sequential=false require‑all=false
> >>>> set resource‑clone
> >>>>
> >>>> sequential=false says nfsA and nfsB have no ordering between them, and
> >>>> require‑all=false says that resource‑clone only needs one of them.
> >>>>
> >>>> (I don't remember for sure the order of the sets in the command, i.e.
> >>>> whether it's the primary set first or the dependent set first, but I
> >>>> think that's right.)
> >>>> ‑‑
> >>>> Ken Gaillot <kgaillot at redhat.com
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Manage your subscription:
> >>>> https://lists.clusterlabs.org/mailman/listinfo/users
> >>>>
> >>>> ClusterLabs home: https://www.clusterlabs.org/
> >>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Manage your subscription:
> >>> https://lists.clusterlabs.org/mailman/listinfo/users
> >>>
> >>> ClusterLabs home: https://www.clusterlabs.org/
> >>>
> >>> _______________________________________________
> >>> Manage your subscription:
> >>> https://lists.clusterlabs.org/mailman/listinfo/users
> >>>
> >>> ClusterLabs home: https://www.clusterlabs.org/
> >>
> >> _______________________________________________
> >> Manage your subscription:
> >> https://lists.clusterlabs.org/mailman/listinfo/users
> >>
> >> ClusterLabs home: https://www.clusterlabs.org/
> >>
> >
> >
>
>

-- 
Regards,

Reid Wahl, RHCA
Senior Software Maintenance Engineer, Red Hat
CEE - Platform Support Delivery - ClusterHA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20210325/bae3b0ff/attachment-0001.htm>