On Tue, May 23, 2017 at 9:04 PM, Raman Gupta <[email protected]> wrote:
> > *why* > > > DRBD would not do that by itself, > > so likely pacemaker decided to do that, > > and you have to figure out *why*. > > Pacemaker will have logged the reasons somewhere. > > The crm-fence-peer.sh script could not find the status of peer node (which > went down) and assumed its status was "unknown" and thus placed a > constraint on DRBD with -INFINITY score which essentially demotes and stops > DRBD. The demotion failed because GFS2 was already mounted. This failure > was construed as error by Pacemaker and it scheduled stonith for itself > when the down node was back. > > > "crm-fence-peer.sh" assumes that the result of "uname -n" > > is the local nodes "pacemaker node name". > Yes. > > > If "uname -n" and "crm_node -n" do not return the same thing for you, > > the defaults will not work for you. > > For my network the replication network (and its hostname) is different > from client facing network (and its hostname): > [root@server7]# uname -n > server7 > [root@server7]# crm_node -n > server7ha > > However things seems to be working with these settings. > > > >Then in addition to all your other trouble, > > you have missing dependency constraints. > > The proper integration of DRBD+GFS2+DLM+CLVM resources into Pacemaker was > the issue. > Which is the very thing pointed in my answer to your previous thread, http://marc.info/?l=drbd-user&m=149040000721736&w=2, the *proper integration*.There is no compromise regarding this it *ALL* has to be managed by pacemaker not just parts of this and that like in your case and started/stopped/collocated in proper order by pacemaker. Period. -- Igor Cicimov | DevOps p. +61 (0) 433 078 728 e. [email protected] <http://encompasscorporation.com/> w*.* www.encompasscorporation.com a. Level 4, 65 York Street, Sydney 2000
_______________________________________________ drbd-user mailing list [email protected] http://lists.linbit.com/mailman/listinfo/drbd-user
