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

Fri Mar 26 02:36:12 EDT 2021

On Thu, Mar 25, 2021 at 11:35 PM Reid Wahl <nwahl at redhat.com> wrote:

>
>
> 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
>

(Not for this use case though, at least not right now)

>
>> > 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
>

-- 
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/f4690531/attachment.htm>