On Thu, Mar 25, 2021 at 11:35 PM Reid Wahl <nw...@redhat.com> wrote: > > > On Thu, Mar 25, 2021 at 10:20 PM Andrei Borzenkov <arvidj...@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...@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 >> >> <arvidj...@gmail.com> wrote: >> >> On Thu, Mar 25, 2021 at 10:31 AM Strahil Nikolov < >> hunter86...@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.wi...@rz.uni-regensburg.de> wrote: >> >>>>>> Ken Gaillot <kgail...@redhat.com> schrieb am 24.03.2021 um 18:56 >> in >> >>> Nachricht >> >>> <5bffded9c6e614919981dcc7d0b2903220bae19d.ca...@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 <kgail...@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
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/