Menu
▾
▴
open-sharedroot-devel — Mailinglist for developer discussions
You can subscribe to this list here.
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(105) |
Nov
(10) |
Dec
(7) |
| 2008 |
Jan
|
Feb
(31) |
Mar
(13) |
Apr
(7) |
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(4) |
Oct
|
Nov
(23) |
Dec
|
| 2009 |
Jan
(25) |
Feb
(24) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(6) |
Jul
(27) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(7) |
Dec
(25) |
| 2010 |
Jan
|
Feb
(7) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
|
From: <go...@bo...> - 2008-02-12 11:12:31
|
On Tue, 12 Feb 2008, Marc Grimme wrote: >> Simplified drbd-lib.sh and fixed cl_checknodes so it identifies quorum >> correctly in a 2-node cluster. > > Is added find files attached. The 1.3-28 is also now in the preview channel > rhel5. # yum clean metadata # yum update results in: http://download.atix.de/yum/comoonics/redhat-el5/preview/noarch/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/primary.xml.gz from comoonics-preview: [Errno 256] No more mirrors to try. :-( Gordan |
|
From: <go...@bo...> - 2008-02-12 11:08:21
|
On Tue, 12 Feb 2008, Marc Grimme wrote: > On Monday 11 February 2008 22:26:18 Gordan Bobic wrote: >> Simplified drbd-lib.sh and fixed cl_checknodes so it identifies quorum >> correctly in a 2-node cluster. > > Is added find files attached. The 1.3-28 is also now in the preview channel > rhel5. Great, thanks. yum update didn't find it, but I'll try again in a minute. Gordan |
|
From: <go...@bo...> - 2008-02-12 11:07:28
|
On Tue, 12 Feb 2008, Marc Grimme wrote: >> I've been trying to track down the issue of a cluster with: >> two_node="1" >> expected_vodes="1" >> not coming up as quorate with just one node, and as far as I can tell, it >> is because /usr/bin/cl_checknodes is returning the wrong value. >> >> I think this bit around line 72 is causing the problem: >> >> if len(nodeelements) == 1: >> quorum=1 >> else: >> quorum=len(nodeelements)/2+1 >> >> Should that not instead be something like: >> >> if len(nodeelements) <= 2: >> quorum=1 >> else: >> quorum=len(nodeelements)/2+1 >> >> >> Please advise. > > Basically that wasn't the idea behind it. We wanted to prevent a cluster with > more then one node to not coming up with splitbrain when both nodes are > powered up initially. It's basically a way to wait until both nodes are up > and running. We didn't want to risk doublemounts for users not being very > sensitive with booting machines or just first level supporters don't > bothering much about data consistency. > > So for you I would be just add the bootoption quorumack if you don't have > anybody else being able to reboot/fence your clusternodes without much > experience. OK, that makes sense. Where should the "quorumack" option be? In cluster.conf? If so, which tag/section? Or is it a kernel boot parameter option? Gordan |
|
From: Marc G. <gr...@at...> - 2008-02-12 11:00:21
|
On Monday 11 February 2008 17:33:15 go...@bo... wrote: > I've been trying to track down the issue of a cluster with: > two_node="1" > expected_vodes="1" > not coming up as quorate with just one node, and as far as I can tell, it > is because /usr/bin/cl_checknodes is returning the wrong value. > > I think this bit around line 72 is causing the problem: > > if len(nodeelements) == 1: > quorum=1 > else: > quorum=len(nodeelements)/2+1 > > Should that not instead be something like: > > if len(nodeelements) <= 2: > quorum=1 > else: > quorum=len(nodeelements)/2+1 > > > Please advise. Basically that wasn't the idea behind it. We wanted to prevent a cluster with more then one node to not coming up with splitbrain when both nodes are powered up initially. It's basically a way to wait until both nodes are up and running. We didn't want to risk doublemounts for users not being very sensitive with booting machines or just first level supporters don't bothering much about data consistency. So for you I would be just add the bootoption quorumack if you don't have anybody else being able to reboot/fence your clusternodes without much experience. Marc. > > Gordan > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Open-sharedroot-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel -- Gruss / Regards, Marc Grimme http://www.atix.de/ http://www.open-sharedroot.org/ |
|
From: Marc G. <gr...@at...> - 2008-02-12 10:54:09
|
On Monday 11 February 2008 22:26:18 Gordan Bobic wrote: > Simplified drbd-lib.sh and fixed cl_checknodes so it identifies quorum > correctly in a 2-node cluster. > > Thanks. > > Gordan Is added find files attached. The 1.3-28 is also now in the preview channel rhel5. About cl_checknodes: Find answer in other thread. Marc -- Gruss / Regards, Marc Grimme http://www.atix.de/ http://www.open-sharedroot.org/ |
|
From: Gordan B. <go...@bo...> - 2008-02-11 21:26:21
|
Simplified drbd-lib.sh and fixed cl_checknodes so it identifies quorum correctly in a 2-node cluster. Thanks. Gordan |
|
From: Gordan B. <go...@bo...> - 2008-02-11 20:25:54
|
Marc Grimme wrote: >>>> Attached is the preliminary version of the drbd patch. It includes a new >>>> file etc/drbd-lib.sh and related changes to linuxrc.generic.sh. The >>>> patch is against the current version in the yum repository. >>>> >>>> Also attached are the drbd.list files for the rpms and files required to >>>> start up DRBD in the init root. >>>> >>>> Please advise if you encounter any problems/bugs. >>> Isn't there a problem with the listfiles? Only one drbd.list in >>> files.initrd.d/ shouldn't there also be some rpms.initrd.d/ with drbd or >>> something inside. Cause the command drbdadm wouldn't be insite the >>> initrd. Or am I missing something? > >> My apologies, I botched the tarring up of the files. I included 2x the >> files.initrd.d file instead of adding the rpms.initrd.d file. The attached >> tar ball should be better. :-) > > Yes they are. Find the new build rpms attached. If you say it works please > give me a cluster.conf for this drbd cluster That passed my "It Works For Me" (TM) test. :-) cluster.conf is attached. Will post a new mod with simplified drbd-lib.sh and the fixed cl_checknodes within the hour. Gordan |
|
From: <go...@bo...> - 2008-02-11 16:42:32
|
On Mon, 11 Feb 2008, Marc Grimme wrote: >>>> Attached is the preliminary version of the drbd patch. It includes a new >>>> file etc/drbd-lib.sh and related changes to linuxrc.generic.sh. The >>>> patch is against the current version in the yum repository. >>>> >>>> Also attached are the drbd.list files for the rpms and files required to >>>> start up DRBD in the init root. >>>> >>>> Please advise if you encounter any problems/bugs. >>> >>> Isn't there a problem with the listfiles? Only one drbd.list in >>> files.initrd.d/ shouldn't there also be some rpms.initrd.d/ with drbd or >>> something inside. Cause the command drbdadm wouldn't be insite the >>> initrd. Or am I missing something? >> >> My apologies, I botched the tarring up of the files. I included 2x the >> files.initrd.d file instead of adding the rpms.initrd.d file. The attached >> tar ball should be better. :-) > > Yes they are. Find the new build rpms attached. If you say it works please > give me a cluster.conf for this drbd cluster Will test and forward cluster.conf ASAP. There are a couple of other tweaks I'd like to do which will simplify drbd-lib.sh. It turns out that DRBD 8.0.6+ (current version 8.0.8) has a feature that allows a chunk of my init code to be dropped. Since less code is almost always a good thing, I'll test this and forward an updated patch as well. Pending a sanity cross-check on the issue in the other thread, I'll include that in the patch. It also occurs to me that some documentation on iSCSI and DRBD OSR might also be useful. Even if only it only includes a sample cluster.conf and iscsi.list/drbd.list files. Gordan |
|
From: <go...@bo...> - 2008-02-11 16:33:21
|
I've been trying to track down the issue of a cluster with:
two_node="1"
expected_vodes="1"
not coming up as quorate with just one node, and as far as I can tell, it
is because /usr/bin/cl_checknodes is returning the wrong value.
I think this bit around line 72 is causing the problem:
if len(nodeelements) == 1:
quorum=1
else:
quorum=len(nodeelements)/2+1
Should that not instead be something like:
if len(nodeelements) <= 2:
quorum=1
else:
quorum=len(nodeelements)/2+1
Please advise.
Gordan
|
|
From: <go...@bo...> - 2008-02-11 15:01:35
|
>> Attached is the preliminary version of the drbd patch. It includes a new >> file etc/drbd-lib.sh and related changes to linuxrc.generic.sh. The patch >> is against the current version in the yum repository. >> >> Also attached are the drbd.list files for the rpms and files required to >> start up DRBD in the init root. >> >> Please advise if you encounter any problems/bugs. > > Isn't there a problem with the listfiles? Only one drbd.list in > files.initrd.d/ shouldn't there also be some rpms.initrd.d/ with drbd or > something inside. Cause the command drbdadm wouldn't be insite the initrd. Or > am I missing something? My apologies, I botched the tarring up of the files. I included 2x the files.initrd.d file instead of adding the rpms.initrd.d file. The attached tar ball should be better. :-) Gordan |
|
From: Marc G. <gr...@at...> - 2008-02-11 14:44:48
|
On Monday 11 February 2008 10:59:25 go...@bo... wrote: > Hi, > > Attached is the preliminary version of the drbd patch. It includes a new > file etc/drbd-lib.sh and related changes to linuxrc.generic.sh. The patch > is against the current version in the yum repository. > > Also attached are the drbd.list files for the rpms and files required to > start up DRBD in the init root. > > Please advise if you encounter any problems/bugs. > > Gordan Isn't there a problem with the listfiles? Only one drbd.list in files.initrd.d/ shouldn't there also be some rpms.initrd.d/ with drbd or something inside. Cause the command drbdadm wouldn't be insite the initrd. Or am I missing something? -- Gruss / Regards, Marc Grimme Phone: +49-89 452 3538-14 http://www.atix.de/ http://www.open-sharedroot.org/ ** ATIX Informationstechnologie und Consulting AG Einsteinstr. 10 85716 Unterschleissheim Deutschland/Germany Phone: +49-89 452 3538-0 Fax: +49-89 990 1766-0 Registergericht: Amtsgericht Muenchen Registernummer: HRB 168930 USt.-Id.: DE209485962 Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) Vorsitzender des Aufsichtsrats: Dr. Martin Buss |
|
From: <go...@bo...> - 2008-02-11 09:59:29
|
Hi, Attached is the preliminary version of the drbd patch. It includes a new file etc/drbd-lib.sh and related changes to linuxrc.generic.sh. The patch is against the current version in the yum repository. Also attached are the drbd.list files for the rpms and files required to start up DRBD in the init root. Please advise if you encounter any problems/bugs. Gordan |
|
From: Gordan B. <go...@bo...> - 2008-02-11 01:12:26
|
Hi, Just a brief update. I now have OSR booting off DRBD. The thing that has been driving me nuts since Friday is that DRBD cannot initialize until considerably later on in the boot-up process than iSCSI. It was a rather difficult issue to troubleshoot because whenever I manually ran the commands after GFS failed to mount (due to the absence of the underlying block device), DRBD initialized fine. But when I put the same set of initialization commands in the startup script, it silently failed. It only initializes properly just before the check for enough nodes in the cluster. I suspect this has someting to do with either the device nodes or the SCSI subsystem not being quite ready before that point. The only problem I can see with that is that it means that DRBD gets initialized _after_ LVM. Not a problem for me, but it could be a problem for some. Either way, I'm reasonably happy that it now works, so I'll be making and posting a patch tomorrow. :-) One unrelated problem I appear to have is that in a two_node cluster, the quorum check always seems to fail and asks for user confirmation that it's OK to start up. I'll look into it more closely tomorrow, but I can't see how it can be related to DRBD stuff. Is this a known/reported issue? Gordan |
|
From: Gordan B. <go...@bo...> - 2008-02-10 12:48:02
|
Marc Grimme wrote: >>>> I'm trying to add support for DRBDs, and trying to stick with doing it >>>> in a way consistent with iSCSI support as far as it is possible. I'm >>>> seeing a few weird things, though. >>>> >>>> In linuxrc.generic.sh: >>>> [...] >>>> # start iscsi if apropriate >>>> isISCSIRootsource $rootsource >>>> if [ $? -eq 0 ]; then >>>> loadISCSI >>>> startISCSI $rootsource $nodename >>>> fi >>>> >>>> # start drbd if appropriate >>>> isDRBDRootSource $rootsource >>>> if [ $? -eq 0 ]; then >>>> loadDRBD >>>> startDRBD $rootsource $nodename >>>> fi >>>> [...] >>>> >>>> and in cluster.conf: >>>> [...] >>>> <clusternodes> >>>> <clusternode name="sentinel1c" nodeid="1" votes="2"> >>>> <com_info> >>>> <rootsource name="drbd"/> >>>> >>>> [...] >>> Agreed. That's the place.You also have a bootoption rootsource to >>> overwrite it. Normally we would suspect rootsource to be some kind of url >>> like for example iscsi://iscsi-host/export-name or it might be >>> drbd://slave/export or something. I cannot remember the semantics there >>> too long ago ;-) . >>> >>> Are you also aware of the com-expert bootoption? This one is quite handy >>> as it brings you to a shell before the process of the initrd is started. >>> And you can change some things to see if they work or not. >>> >>> Answer to the iscsi questioning stuff. >>> [marc@mobilix-07 boot-scripts]$ source etc/iscsi-lib.sh >>> [marc@mobilix-07 boot-scripts]$ isISCSIRootsource drbd >>> [marc@mobilix-07 boot-scripts]$ echo $? >>> 1 >>> [marc@mobilix-07 boot-scripts]$ isISCSIRootsource iscsi >>> [marc@mobilix-07 boot-scripts]$ echo $? >>> 0 >>> [marc@mobilix-07 boot-scripts]$ >>> >>> So if we are going iscsi we'll return a '0'. As a successfully executed >>> shellscript does. >>> >>>> From this, one would assume that isISCSIRootsource would return false >>>> and iSCSI not get initialized, and isDRBDRootSource would return true >>>> and get initialized. >>>> >>>> This is the opposite of what I'm seeing. iSCSI gets started, and the >>>> modules loaded. DRBD doesn't. >>>> >>>> Am I misunderstanding where $nodename is coming from? I'm not >>>> particularly bothered by iSCSI trying to start (and failing because the >>>> iscsi packages aren't in the rpm list), but that makes the drbd not >>>> starting all the more puzzling. :-/ >>> $nodename is the nodename that belongs to the node in bootprocess. But it >>> is not necessarily the hostname. The function >>> cluster-lib.sh/getClusterFSParameters returns it. It's a little bit >>> calling other functions to make it more independent from the cluster.conf >>> (that was the idea in the first place). >> Ah, I see. I think it may be necessary to do >> hostname $nodename >> in that case, since DRBD requires hostname to be matching the node name >> in the DRBD configuration. > > Hmm. That would be a way. Yes, I have that working. I just have another bug to sort out (DRBD not getting initialized correctly during boot-up, but works fine if I issue the same command after the boot fails due to DRBD not being initialized). >>>> Further on (unrelated to this), I get cman starting, but ccsd failing, >>>> so the boot-up aborts. But ps -aux | grep ccsd shows that ccsd is in >>>> fact already running. I haven't seen this behaviour before. The only >>>> thing I can think of that is different is that this is a 2-node cluster, >>>> which is much smaller than what I usually work with. (Yes I did set >>>> <cman two_node="1" expected_votes="2"/>) >>> Enable syslogging to a syslog server. <syslog name="server"/> does the >>> trick and see what it tells you. >> I'm feeling a bit silly now. The answer was in the line I pasted. For >> two_node=1, expected_votes needs to be 1 as well. :-/ >> >> On a separate note, is there a configurable way to disable LVM/CLVM, >> even if only at mkinitrd time? All it is achieving for me is throwing up >> ugly "FAILED" startup messages because I'm not using LVM. I could >> comment it out of the boot scripts, but that seems a bit nasty. > > Ok so what we did the last time was to introduce the lvm_check (Wasn't it > because of your request?! ;-) ) function in linux.generic.rc line 288. That > function checks for your rootdevice (specified in the cluster.conf) for it > being a lv or not (seeing if it exists and if it has lvm major/minors). > Doesn't that functionality work? Good point, I only saw that after I sent the last post. The problem is possibly to do with the fact that DRBD isn't getting initialized properly. I'll get that sorted out first and see if it makes the problem go away. Thanks. Gordan |
|
From: Marc G. <gr...@at...> - 2008-02-10 07:05:38
|
On Saturday 09 February 2008 19:30:48 Gordan Bobic wrote:
> Marc Grimme wrote:
> > Hi Gordan,
> >
> > On Saturday 09 February 2008 01:56:18 Gordan Bobic wrote:
> >> Hi,
> >>
> >> I'm trying to add support for DRBDs, and trying to stick with doing it
> >> in a way consistent with iSCSI support as far as it is possible. I'm
> >> seeing a few weird things, though.
> >>
> >> In linuxrc.generic.sh:
> >> [...]
> >> # start iscsi if apropriate
> >> isISCSIRootsource $rootsource
> >> if [ $? -eq 0 ]; then
> >> loadISCSI
> >> startISCSI $rootsource $nodename
> >> fi
> >>
> >> # start drbd if appropriate
> >> isDRBDRootSource $rootsource
> >> if [ $? -eq 0 ]; then
> >> loadDRBD
> >> startDRBD $rootsource $nodename
> >> fi
> >> [...]
> >>
> >> and in cluster.conf:
> >> [...]
> >> <clusternodes>
> >> <clusternode name="sentinel1c" nodeid="1" votes="2">
> >> <com_info>
> >> <rootsource name="drbd"/>
> >>
> >> [...]
> >
> > Agreed. That's the place.You also have a bootoption rootsource to
> > overwrite it. Normally we would suspect rootsource to be some kind of url
> > like for example iscsi://iscsi-host/export-name or it might be
> > drbd://slave/export or something. I cannot remember the semantics there
> > too long ago ;-) .
> >
> > Are you also aware of the com-expert bootoption? This one is quite handy
> > as it brings you to a shell before the process of the initrd is started.
> > And you can change some things to see if they work or not.
> >
> > Answer to the iscsi questioning stuff.
> > [marc@mobilix-07 boot-scripts]$ source etc/iscsi-lib.sh
> > [marc@mobilix-07 boot-scripts]$ isISCSIRootsource drbd
> > [marc@mobilix-07 boot-scripts]$ echo $?
> > 1
> > [marc@mobilix-07 boot-scripts]$ isISCSIRootsource iscsi
> > [marc@mobilix-07 boot-scripts]$ echo $?
> > 0
> > [marc@mobilix-07 boot-scripts]$
> >
> > So if we are going iscsi we'll return a '0'. As a successfully executed
> > shellscript does.
> >
> >> From this, one would assume that isISCSIRootsource would return false
> >> and iSCSI not get initialized, and isDRBDRootSource would return true
> >> and get initialized.
> >>
> >> This is the opposite of what I'm seeing. iSCSI gets started, and the
> >> modules loaded. DRBD doesn't.
> >>
> >> Am I misunderstanding where $nodename is coming from? I'm not
> >> particularly bothered by iSCSI trying to start (and failing because the
> >> iscsi packages aren't in the rpm list), but that makes the drbd not
> >> starting all the more puzzling. :-/
> >
> > $nodename is the nodename that belongs to the node in bootprocess. But it
> > is not necessarily the hostname. The function
> > cluster-lib.sh/getClusterFSParameters returns it. It's a little bit
> > calling other functions to make it more independent from the cluster.conf
> > (that was the idea in the first place).
>
> Ah, I see. I think it may be necessary to do
> hostname $nodename
> in that case, since DRBD requires hostname to be matching the node name
> in the DRBD configuration.
Hmm. That would be a way.
>
> >> Further on (unrelated to this), I get cman starting, but ccsd failing,
> >> so the boot-up aborts. But ps -aux | grep ccsd shows that ccsd is in
> >> fact already running. I haven't seen this behaviour before. The only
> >> thing I can think of that is different is that this is a 2-node cluster,
> >> which is much smaller than what I usually work with. (Yes I did set
> >> <cman two_node="1" expected_votes="2"/>)
> >
> > Enable syslogging to a syslog server. <syslog name="server"/> does the
> > trick and see what it tells you.
>
> I'm feeling a bit silly now. The answer was in the line I pasted. For
> two_node=1, expected_votes needs to be 1 as well. :-/
>
> On a separate note, is there a configurable way to disable LVM/CLVM,
> even if only at mkinitrd time? All it is achieving for me is throwing up
> ugly "FAILED" startup messages because I'm not using LVM. I could
> comment it out of the boot scripts, but that seems a bit nasty.
Ok so what we did the last time was to introduce the lvm_check (Wasn't it
because of your request?! ;-) ) function in linux.generic.rc line 288. That
function checks for your rootdevice (specified in the cluster.conf) for it
being a lv or not (seeing if it exists and if it has lvm major/minors).
Doesn't that functionality work?
It would also be possible to add a nolvm as we recently added a nousb
bootoption. How about that as an addition?
Recipe:
Add a new option to boot-lib/getBootParameters at the end of the function:
----------------------------------
echo -n ":"
getBootParm nolvm
----------------------------------
Then add to linux.generic.sh below the nousb line114:
-----------------------------------------------------------------
nolvm=$(getParm ${bootparms} 8)
-----------------------------------------------------------------
and then instead of linux.generic.rc line 290:
------------------------------------------------------------------
if [ "$lvm_sup" -eq 0 ] || [ -z "$nolvm" ]; then
-------------------------------------------------------------------
There you go. I think that'll do it.
>
> I'm about 99% there with getting a single node to boot of the
> OSR/GFS/DRBD. I just need to write a quick wrapper and it'll be ready.
> Hoping to post a patch tomorrow.
Sounds very great. We'll appreciate it very much.
>
> Gordan
Marc.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Open-sharedroot-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel
--
Gruss / Regards,
Marc Grimme
Phone: +49-89 452 3538-14
http://www.atix.de/ http://www.open-sharedroot.org/
**
ATIX Informationstechnologie und Consulting AG
Einsteinstr. 10
85716 Unterschleissheim
Deutschland/Germany
Phone: +49-89 452 3538-0
Fax: +49-89 990 1766-0
Registergericht: Amtsgericht Muenchen
Registernummer: HRB 168930
USt.-Id.: DE209485962
Vorstand:
Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.)
Vorsitzender des Aufsichtsrats:
Dr. Martin Buss
|
|
From: Gordan B. <go...@bo...> - 2008-02-09 18:30:58
|
Marc Grimme wrote: > Hi Gordan, > On Saturday 09 February 2008 01:56:18 Gordan Bobic wrote: >> Hi, >> >> I'm trying to add support for DRBDs, and trying to stick with doing it >> in a way consistent with iSCSI support as far as it is possible. I'm >> seeing a few weird things, though. >> >> In linuxrc.generic.sh: >> [...] >> # start iscsi if apropriate >> isISCSIRootsource $rootsource >> if [ $? -eq 0 ]; then >> loadISCSI >> startISCSI $rootsource $nodename >> fi >> >> # start drbd if appropriate >> isDRBDRootSource $rootsource >> if [ $? -eq 0 ]; then >> loadDRBD >> startDRBD $rootsource $nodename >> fi >> [...] >> >> and in cluster.conf: >> [...] >> <clusternodes> >> <clusternode name="sentinel1c" nodeid="1" votes="2"> >> <com_info> >> <rootsource name="drbd"/> >> >> [...] > Agreed. That's the place.You also have a bootoption rootsource to overwrite > it. Normally we would suspect rootsource to be some kind of url like for > example iscsi://iscsi-host/export-name or it might be drbd://slave/export or > something. I cannot remember the semantics there too long ago ;-) . > > Are you also aware of the com-expert bootoption? This one is quite handy as it > brings you to a shell before the process of the initrd is started. And you > can change some things to see if they work or not. > > Answer to the iscsi questioning stuff. > [marc@mobilix-07 boot-scripts]$ source etc/iscsi-lib.sh > [marc@mobilix-07 boot-scripts]$ isISCSIRootsource drbd > [marc@mobilix-07 boot-scripts]$ echo $? > 1 > [marc@mobilix-07 boot-scripts]$ isISCSIRootsource iscsi > [marc@mobilix-07 boot-scripts]$ echo $? > 0 > [marc@mobilix-07 boot-scripts]$ > > So if we are going iscsi we'll return a '0'. As a successfully executed > shellscript does. >> From this, one would assume that isISCSIRootsource would return false >> and iSCSI not get initialized, and isDRBDRootSource would return true >> and get initialized. >> >> This is the opposite of what I'm seeing. iSCSI gets started, and the >> modules loaded. DRBD doesn't. >> >> Am I misunderstanding where $nodename is coming from? I'm not >> particularly bothered by iSCSI trying to start (and failing because the >> iscsi packages aren't in the rpm list), but that makes the drbd not >> starting all the more puzzling. :-/ > > $nodename is the nodename that belongs to the node in bootprocess. But it is > not necessarily the hostname. The function > cluster-lib.sh/getClusterFSParameters returns it. It's a little bit calling > other functions to make it more independent from the cluster.conf (that was > the idea in the first place). Ah, I see. I think it may be necessary to do hostname $nodename in that case, since DRBD requires hostname to be matching the node name in the DRBD configuration. >> Further on (unrelated to this), I get cman starting, but ccsd failing, >> so the boot-up aborts. But ps -aux | grep ccsd shows that ccsd is in >> fact already running. I haven't seen this behaviour before. The only >> thing I can think of that is different is that this is a 2-node cluster, >> which is much smaller than what I usually work with. (Yes I did set >> <cman two_node="1" expected_votes="2"/>) > > Enable syslogging to a syslog server. <syslog name="server"/> does the trick > and see what it tells you. I'm feeling a bit silly now. The answer was in the line I pasted. For two_node=1, expected_votes needs to be 1 as well. :-/ On a separate note, is there a configurable way to disable LVM/CLVM, even if only at mkinitrd time? All it is achieving for me is throwing up ugly "FAILED" startup messages because I'm not using LVM. I could comment it out of the boot scripts, but that seems a bit nasty. I'm about 99% there with getting a single node to boot of the OSR/GFS/DRBD. I just need to write a quick wrapper and it'll be ready. Hoping to post a patch tomorrow. Gordan |
|
From: Marc G. <gr...@at...> - 2008-02-09 17:59:18
|
Hi Gordan, On Saturday 09 February 2008 01:56:18 Gordan Bobic wrote: > Hi, > > I'm trying to add support for DRBDs, and trying to stick with doing it > in a way consistent with iSCSI support as far as it is possible. I'm > seeing a few weird things, though. > > In linuxrc.generic.sh: > [...] > # start iscsi if apropriate > isISCSIRootsource $rootsource > if [ $? -eq 0 ]; then > loadISCSI > startISCSI $rootsource $nodename > fi > > # start drbd if appropriate > isDRBDRootSource $rootsource > if [ $? -eq 0 ]; then > loadDRBD > startDRBD $rootsource $nodename > fi > [...] > > and in cluster.conf: > [...] > <clusternodes> > <clusternode name="sentinel1c" nodeid="1" votes="2"> > <com_info> > <rootsource name="drbd"/> > > [...] Agreed. That's the place.You also have a bootoption rootsource to overwrite it. Normally we would suspect rootsource to be some kind of url like for example iscsi://iscsi-host/export-name or it might be drbd://slave/export or something. I cannot remember the semantics there too long ago ;-) . Are you also aware of the com-expert bootoption? This one is quite handy as it brings you to a shell before the process of the initrd is started. And you can change some things to see if they work or not. Answer to the iscsi questioning stuff. [marc@mobilix-07 boot-scripts]$ source etc/iscsi-lib.sh [marc@mobilix-07 boot-scripts]$ isISCSIRootsource drbd [marc@mobilix-07 boot-scripts]$ echo $? 1 [marc@mobilix-07 boot-scripts]$ isISCSIRootsource iscsi [marc@mobilix-07 boot-scripts]$ echo $? 0 [marc@mobilix-07 boot-scripts]$ So if we are going iscsi we'll return a '0'. As a successfully executed shellscript does. > > From this, one would assume that isISCSIRootsource would return false > and iSCSI not get initialized, and isDRBDRootSource would return true > and get initialized. > > This is the opposite of what I'm seeing. iSCSI gets started, and the > modules loaded. DRBD doesn't. > > Am I misunderstanding where $nodename is coming from? I'm not > particularly bothered by iSCSI trying to start (and failing because the > iscsi packages aren't in the rpm list), but that makes the drbd not > starting all the more puzzling. :-/ $nodename is the nodename that belongs to the node in bootprocess. But it is not necessarily the hostname. The function cluster-lib.sh/getClusterFSParameters returns it. It's a little bit calling other functions to make it more independent from the cluster.conf (that was the idea in the first place). > > Further on (unrelated to this), I get cman starting, but ccsd failing, > so the boot-up aborts. But ps -aux | grep ccsd shows that ccsd is in > fact already running. I haven't seen this behaviour before. The only > thing I can think of that is different is that this is a 2-node cluster, > which is much smaller than what I usually work with. (Yes I did set > <cman two_node="1" expected_votes="2"/>) Enable syslogging to a syslog server. <syslog name="server"/> does the trick and see what it tells you. > > Any ideas? Not yet ;-) Marc. > > Gordan > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Open-sharedroot-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel -- Gruss / Regards, Marc Grimme Phone: +49-89 452 3538-14 http://www.atix.de/ http://www.open-sharedroot.org/ ** ATIX Informationstechnologie und Consulting AG Einsteinstr. 10 85716 Unterschleissheim Deutschland/Germany Phone: +49-89 452 3538-0 Fax: +49-89 990 1766-0 Registergericht: Amtsgericht Muenchen Registernummer: HRB 168930 USt.-Id.: DE209485962 Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) Vorsitzender des Aufsichtsrats: Dr. Martin Buss |
|
From: Gordan B. <go...@bo...> - 2008-02-09 16:50:46
|
Gordan Bobic wrote: Update: Part 1 solved. > isISCSIRootsource $rootsource [...] > isDRBDRootSource $rootsource Serves me right for not using cut and paste more. :-/ One thing that is still causing problems is that hostname doesn't appear to get set to $nodename, at least not until later on. Where does this get set, and how difficult would it be to move it to before iSCSI/DRBD initialization? I can put hostname $nodename in drbd-lib.sh, but that seems a bit nasty if there is already a common place for all the network initialization. It still doesn't explain, however, why iSCSI is getting started up even though $rootsource is drbd and not iscsi. > Further on (unrelated to this), I get cman starting, but ccsd failing, > so the boot-up aborts. But ps -aux | grep ccsd shows that ccsd is in > fact already running. I haven't seen this behaviour before. The only > thing I can think of that is different is that this is a 2-node cluster, > which is much smaller than what I usually work with. (Yes I did set > <cman two_node="1" expected_votes="2"/>) This is still ongoing, but I think I have most of the DRBD plumbed in. I'm just waiting for a response on a DRBD issue regarding restarting from a Primary/Unknown state into a Secondary/Unknown state. If there is a built in way to configure it to come back as Primary/Unknown I'd prefer to use that, but failing that I'll write a small wrapper to force local to Primary if secondary is Unknown. Gordan |
|
From: Gordan B. <go...@bo...> - 2008-02-09 00:56:24
|
Hi,
I'm trying to add support for DRBDs, and trying to stick with doing it
in a way consistent with iSCSI support as far as it is possible. I'm
seeing a few weird things, though.
In linuxrc.generic.sh:
[...]
# start iscsi if apropriate
isISCSIRootsource $rootsource
if [ $? -eq 0 ]; then
loadISCSI
startISCSI $rootsource $nodename
fi
# start drbd if appropriate
isDRBDRootSource $rootsource
if [ $? -eq 0 ]; then
loadDRBD
startDRBD $rootsource $nodename
fi
[...]
and in cluster.conf:
[...]
<clusternodes>
<clusternode name="sentinel1c" nodeid="1" votes="2">
<com_info>
<rootsource name="drbd"/>
[...]
From this, one would assume that isISCSIRootsource would return false
and iSCSI not get initialized, and isDRBDRootSource would return true
and get initialized.
This is the opposite of what I'm seeing. iSCSI gets started, and the
modules loaded. DRBD doesn't.
Am I misunderstanding where $nodename is coming from? I'm not
particularly bothered by iSCSI trying to start (and failing because the
iscsi packages aren't in the rpm list), but that makes the drbd not
starting all the more puzzling. :-/
Further on (unrelated to this), I get cman starting, but ccsd failing,
so the boot-up aborts. But ps -aux | grep ccsd shows that ccsd is in
fact already running. I haven't seen this behaviour before. The only
thing I can think of that is different is that this is a 2-node cluster,
which is much smaller than what I usually work with. (Yes I did set
<cman two_node="1" expected_votes="2"/>)
Any ideas?
Gordan
|
|
From: <go...@bo...> - 2008-02-06 09:19:37
|
On Wed, 6 Feb 2008, Marc Grimme wrote: >> I'm about to build a 2-node cluster, and I'd like to apply OSR to it. >> Since this time I don't have a SAN, I'll be doing it using DRBD. I >> think I have a reasonably good idea about how to do it, but I thought it >> might be prudent to ask if anyone here can think of any potential >> complications. Has this been done before? Is it a "supported" >> configuration? > > I never thought about that but why not. I'm also not aware of anybody using > DRBD on top of OSR. But it should be quite independent shouldn't it. > > OHH there is something: the initrd. > > We didn't implement DRBD. There we go again. > > But if you like we can support you in a best effort manner to set it up like > last time. > > Change it and we'll take it into upstream as techpreview. Sure, sounds good. I'll send patches when I get it working. :-) Many thanks. Gordan |
|
From: Marc G. <gr...@at...> - 2008-02-06 09:08:00
|
Hi Gordan, On Tuesday 05 February 2008 18:37:33 go...@bo... wrote: > Hi, > > I'm about to build a 2-node cluster, and I'd like to apply OSR to it. > Since this time I don't have a SAN, I'll be doing it using DRBD. I > think I have a reasonably good idea about how to do it, but I thought it > might be prudent to ask if anyone here can think of any potential > complications. Has this been done before? Is it a "supported" > configuration? I never thought about that but why not. I'm also not aware of anybody using DRBD on top of OSR. But it should be quite independent shouldn't it. OHH there is something: the initrd. We didn't implement DRBD. There we go again. But if you like we can support you in a best effort manner to set it up like last time. Change it and we'll take it into upstream as techpreview. Would that be appropriate. Have fun Marc. > > Thanks. > > Gordan > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Open-sharedroot-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel -- Gruss / Regards, Marc Grimme http://www.atix.de/ http://www.open-sharedroot.org/ |
|
From: <go...@bo...> - 2008-02-05 17:39:04
|
Hi, I'm about to build a 2-node cluster, and I'd like to apply OSR to it. Since this time I don't have a SAN, I'll be doing it using DRBD. I think I have a reasonably good idea about how to do it, but I thought it might be prudent to ask if anyone here can think of any potential complications. Has this been done before? Is it a "supported" configuration? Thanks. Gordan |
|
From: <go...@bo...> - 2007-12-20 17:17:23
|
On Thu, 20 Dec 2007, Mark Hlawatschek wrote: > On Thursday 20 December 2007 17:28:04 go...@bo... wrote: >> On Thu, 20 Dec 2007, Mark Hlawatschek wrote: >>>> However, mkinitrd seems to mangle and rewrite my cluster.conf and remove >>>> all the fencing devices. Is this normal? Is there anything special I >>>> have to do to get fencing to work? I am using fence_drac, if that makes >>>> any difference. >>> >>> mkinitrd shouldn't do anything to your cluster.conf. mkinitrd will always >>> use the cluster.conf in /etc/cluster/cluster.conf. Please make sure, that >>> the version number of the latest cluster.conf is increased and it is >>> deployed to all cluster nodes using a "ccs_tool update >>> /etc/cluster/cluster.conf". >> >> I rebuilt the initrd, and the cluster.conf that ends up in >> /var/comoonics/chroot/etc/cluster/cluster.conf >> is NOT the same as the one in /etc/cluster/cluster.conf > This can happen, if the cluster.conf in the initrd has a lower version number > than the cluster version number. If this is the case, the active cluster.conf > with the higher version number will be used. Interestingly enough, I just increased the version number in cluster.conf and rebuilt the initrd, and I still get the old version in /var/comoonics/chroot... I just used ccs_tool update and that put the correct cluster.conf in /var/comoonics, so I'll try rebuilding the initrd again. Gordan |
|
From: Mark H. <hla...@at...> - 2007-12-20 17:12:42
|
On Thursday 20 December 2007 17:55:07 go...@bo... wrote: > On Thu, 20 Dec 2007, Mark Hlawatschek wrote: > >>>> However, mkinitrd seems to mangle and rewrite my cluster.conf and > >>>> remove all the fencing devices. Is this normal? Is there anything > >>>> special I have to do to get fencing to work? I am using fence_drac, if > >>>> that makes any difference. > >>> > >>> mkinitrd shouldn't do anything to your cluster.conf. mkinitrd will > >>> always use the cluster.conf in /etc/cluster/cluster.conf. Please make > >>> sure, that the version number of the latest cluster.conf is increased > >>> and it is deployed to all cluster nodes using a "ccs_tool update > >>> /etc/cluster/cluster.conf". > >> > >> I rebuilt the initrd, and the cluster.conf that ends up in > >> /var/comoonics/chroot/etc/cluster/cluster.conf > >> is NOT the same as the one in /etc/cluster/cluster.conf > > > > This can happen, if the cluster.conf in the initrd has a lower version > > number than the cluster version number. If this is the case, the active > > cluster.conf with the higher version number will be used. > > So it actually checks if the one in /etc/cluster is newer than the one on > /var/comoonics/chroot/etc/cluster? > > I hadn't expected that... > > >> It seems to me that cluster.conf ends up getting rebuilt and mangled by > >> mkinitrd before it is folded into the initrd. > > > > mkinitrd is really doing nothing to the cluster.conf. > > Hmm... Looking at the cluster config, it doesn't look like the one I > wrote, even the previous version. Does anything process it and re-create > it? > That is basically a RH cluster feature. A new member kind of arbitrates for the latest cluster.conf. The cluster.conf with the highest version number is supposed to be the latest one. I.e. the new member will receive the latest cluster.conf from another cluster member. You have to make sure, that you increase the version number inside the cluster.conf. You should send do the "ccs_tool update /etc/cluster/cluster.conf" -- Gruss / Regards, Dipl.-Ing. Mark Hlawatschek http://www.atix.de/ http://www.open-sharedroot.org/ ** ATIX Informationstechnologie und Consulting AG Einsteinstr. 10 85716 Unterschleissheim Deutschland/Germany |
|
From: <go...@bo...> - 2007-12-20 16:55:14
|
On Thu, 20 Dec 2007, Mark Hlawatschek wrote: >>>> However, mkinitrd seems to mangle and rewrite my cluster.conf and remove >>>> all the fencing devices. Is this normal? Is there anything special I >>>> have to do to get fencing to work? I am using fence_drac, if that makes >>>> any difference. >>> >>> mkinitrd shouldn't do anything to your cluster.conf. mkinitrd will always >>> use the cluster.conf in /etc/cluster/cluster.conf. Please make sure, that >>> the version number of the latest cluster.conf is increased and it is >>> deployed to all cluster nodes using a "ccs_tool update >>> /etc/cluster/cluster.conf". >> >> I rebuilt the initrd, and the cluster.conf that ends up in >> /var/comoonics/chroot/etc/cluster/cluster.conf >> is NOT the same as the one in /etc/cluster/cluster.conf > This can happen, if the cluster.conf in the initrd has a lower version number > than the cluster version number. If this is the case, the active cluster.conf > with the higher version number will be used. So it actually checks if the one in /etc/cluster is newer than the one on /var/comoonics/chroot/etc/cluster? I hadn't expected that... >> It seems to me that cluster.conf ends up getting rebuilt and mangled by >> mkinitrd before it is folded into the initrd. > mkinitrd is really doing nothing to the cluster.conf. Hmm... Looking at the cluster config, it doesn't look like the one I wrote, even the previous version. Does anything process it and re-create it? >>> If you want to use fence_drac, you need to put all required perl stuff >>> into the chroot environment. This can be either done by >>> 1) adding all perl stuff into the initrd or >>> 2) adding the perl stuff only into the chroot environment during the boot >>> process. >>> >>> to do this, create a file called perl.list with the following content: >>> >>> -->snip >>> perl >>> perl-libwww-perl >>> perl-XML-Encoding >>> perl-URI >>> perl-HTML-Parser >>> perl-XML-Parser >>> perl-libxml-perl >>> perl-Net-Telnet >>> perl-HTML-Tagset >>> perl-Crypt-SSLeay >>> ##### >>> -->snap >>> >>> >>> >>> and copy it into >>> >>> 1) /etc/comoonics/bootimage/rpms.initrd.d/ >>> and make a new rpm >> >> Not sure I follow what you mean. What rpm? > uups... I meant the initrd Ah, OK, that makes more sense. :-) >>> _or_ >>> 2) /etc/comoonics/bootimage-chroot/rpms.initrd.d/ >>> and run "service bootsr start" >> >> Run this on the booted system? What does the bootsr service do? > > Yes, you can run this on the booted systems. bootsr is just doing some updates > to the chroot environment, if not already done. OK, thanks for that. :-) Gordan |
12 messages has been excluded from this view by a project administrator.
