On Fri, Mar 26, 2021 at 12:17 AM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote:
> >>> Andrei Borzenkov <arvidj...@gmail.com> schrieb am 26.03.2021 um 06:19 > in > Nachricht <534274b3-a6de-5fac-0ae4-d02c305f1...@gmail.com>: > > 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? > > That's a big problem with the SAP design (basically it's just too complex). > +1000 to this. In the past I had written a kind of resource agent that worked without that > overly complex overhead, but since those days SAP has added much more > complexity. > If the NFS server is external, pacemaker could fence your nodes when the > NFS > server is down as first the monitor operation will fail (hanging on NFS), > the > the recover (stop/start) will fail (also hanging on NFS). Even when > fencing the > node it would not help (resources cannot start) if the NFS server is still > down. So you may end up with all your nodes being fenced and the fail > counts > disabling any automatic resource restart. > > > > >> 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. > > > > 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. > > > >> 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/ > >>> > >> > >> > > > > _______________________________________________ > > 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
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/