> -----Ursprüngliche Nachricht-----
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> ha.org] Im Auftrag von Schmidt, Florian
> Gesendet: Montag, 21. Juli 2008 15:49
> An: General Linux-HA mailing list
> Betreff: AW: [Linux-HA] after drbd-splitbrain both primary
>
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > ha.org] Im Auftrag von Andreas Kurz
> > Gesendet: Montag, 21. Juli 2008 15:16
> > An: General Linux-HA mailing list
> > Betreff: Re: [Linux-HA] after drbd-splitbrain both primary
> >
> > On Mon, Jul 21, 2008 at 2:52 PM, Schmidt, Florian
> > <[EMAIL PROTECTED]> wrote:
> > >> -----Ursprüngliche Nachricht-----
> > >> Von: [EMAIL PROTECTED] [mailto:linux-ha-
> [EMAIL PROTECTED]
> > >> ha.org] Im Auftrag von Michael Schwartzkopff
> > >> Gesendet: Montag, 21. Juli 2008 14:39
> > >> An: General Linux-HA mailing list
> > >> Betreff: Re: [Linux-HA] after drbd-splitbrain both primary
> > >>
> > >> Am Montag, 21. Juli 2008 14:35 schrieb Schmidt, Florian:
> > >> > Hi everyone,
> > >> >
> > >> > While testing my cluster I just disconnected the DRBD-link.
> > >> > I expected the following:
> > >> >
> > >> > Because only the DRBD-link (=second heartbeat-link) was down, heartbeat
> > >> > still knows that both nodes are up and does not change anything. DRBD
> > >> > should stay in primary/secondary state but because of the
> > >> > drbd-split-brain this should be seen as primary/unknown on the first
> > >> > and
> > >> > secondary/unknown on the second node.
> > >> >
> > >> > But this didn't happen. Both nodes had primary drbd-volumes after
> > >> > disconnecting link.
> > >> >
> > >> > Can anyone tell me, why heartbeat or whoever did this?
> > >>
> > >> Hi,
> > >>
> > >> I suggest: Each DRBD does not see the other one, thinks the other died
> > >> and
> > >> promotes itself.
> > >> Use dopd to prevent this behaviour.
> > >
> > > Is DRBD able to promote itself? I thought it isn't and you can demote and
> > promote it only manually (or via heartbeat or something else...)?!?
> >
> > Unless you configure drbd to start up as primary on both nodes (e.g.
> > to use OCFS2 or another Clusterfilesystem) you have to promote a drbd
> > resource manually ... or let it promote e.g. via heartbeat
>
> Yeah, that's exactly what I knew until now. So the problem why both
> drbd-instances
> got promoted isn't really solved? I'll try if dopd prevents this behaviour,
> but I still do
> not know the reason why heartbeat acts this way?
It IS heartbeat, that wants to promote both drbd-instances:
I configured dopd and once again destroyed drbd's link. Now this messages
occure in dmesg:
drbd0: State change failed: Refusing to be Primary without at least one
UpToDate disk
drbd0: state = { cs:WFConnection st:Secondary/Unknown ds:Outdated/DUnknown
r--- }
drbd0: wanted = { cs:WFConnection st:Primary/Unknown ds:Outdated/DUnknown r---
}
After enabling the link again, drbd does a short sync and is in
primary/secondary state again, but heartbeat is broken because he wasn't able
to promote both instances.
Anyone, who could explain this reaction? Maybe my heartbeat is misconfigured
somehow?
//heartbeat-2.1.3-15.1
//drbd82-8.2.6-1.el5.centos
//RHEL5 kernel 2.6.18-53.el5
Thanks
Florian
> > One potential problem I saw in your cib: if you use the heartbeat
> > "drbddisk" RA and not the OCF RA you have to configure positional
> > parameters or the drbddisk RA will promote all drbd-resources per
> > default.
> >
> > ... as an example, change:
> >
> > <nvpair id="drbddisk_afd_resource" name="drbd_resource" value="drbd_afd"/>
> >
> > ^^^^^^^^^^^^^^^^^^
> > ... to:
> >
> > <nvpair id="drbddisk_afd_resource" name="1" value="drbd_afd"/>
> > ^
> >
> > ... because the first paramter to drbdisk has to be the drbd resource name.
>
> OK, I'll change the config to use the string "1" instead of "drbd_resource".
> I hope I understood you right. :)
>
> Thanks
> Florian
>
>
> > Regards,
> > Andreas
> >
> > >
> > > So it seems that I was wrong...
> > >
> > > Well let's repair the broken cluster and configure dopd.
> > >
> > > Thanks
> > > Florian
> > >
> > >
> > >> Michael.
> > >>
> > >> --
> > >> Dr. Michael Schwartzkopff
> > >> MultiNET Services GmbH
> > >> Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany
> > >> Tel: +49 - 89 - 45 69 11 0
> > >> Fax: +49 - 89 - 45 69 11 21
> > >> mob: +49 - 174 - 343 28 75
> > >>
> > >> mail: [EMAIL PROTECTED]
> > >> web: www.multinet.de
> > >>
> > >> Sitz der Gesellschaft: 85630 Grasbrunn
> > >> Registergericht: Amtsgericht München HRB 114375
> > >> Geschäftsführer: Günter Jurgeneit, Hubert Martens
> > >>
> > >> ---
> > >>
> > >> PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B
> > >> Skype: misch42
> > >> _______________________________________________
> > >> Linux-HA mailing list
> > >> [email protected]
> > >> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > >> See also: http://linux-ha.org/ReportingProblems
> > > _______________________________________________
> > > Linux-HA mailing list
> > > [email protected]
> > > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > > See also: http://linux-ha.org/ReportingProblems
> > >
> > _______________________________________________
> > Linux-HA mailing list
> > [email protected]
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > See also: http://linux-ha.org/ReportingProblems
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
