Menu
▾
▴
open-sharedroot-devel
|
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: 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-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: 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: 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: 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 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-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-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: 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: <go...@bo...> - 2008-02-11 09:59:29
Attachments:
drbd.list.tar.gz
drbd.patch
|
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: 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 15:01:35
Attachments:
drbd.list.tar.gz
|
>> 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: <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: Gordan B. <go...@bo...> - 2008-02-11 20:25:54
Attachments:
cluster.conf
|
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: Gordan B. <go...@bo...> - 2008-02-11 21:26:21
Attachments:
drbd-update.tar.gz
|
Simplified drbd-lib.sh and fixed cl_checknodes so it identifies quorum correctly in a 2-node cluster. Thanks. Gordan |
|
From: Marc G. <gr...@at...> - 2008-02-12 10:54:09
Attachments:
comoonics-bootimage-1.3-28.noarch.rpm
|
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: <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: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: Marc G. <gr...@at...> - 2008-02-12 11:13:34
|
On Tuesday 12 February 2008 12:08:17 go...@bo... wrote: > 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 > > ------------------------------------------------------------------------- > 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 Here you'll find your cluster.conf! http://www.open-sharedroot.org/faq/administrators-handbook/cluster-system-administration/example-configurations/cluster-configuration-for-drbd-based-cluster/ How about your iscsi-config? -- 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-12 11:23:37
|
On Tue, 12 Feb 2008, Marc Grimme wrote: > How about your iscsi-config? That was all good and working. I no longer have access to the said cluster because the system was deployed for the client, but there have been no reported problems. The last problem was with the node(s) coming up too quickly because of ARP propagation on managed switches, but that was solved. IIRC you put a feature in to make the post-ifcfg initialization delay carry over to the initroot to replace my ugly hack of putting "sleep 60" in iscsi-lib.sh. I _think_ I might still have a copy of the cluster.conf file from that setup, if that's of interest. Gordan |
|
From: Marc G. <gr...@at...> - 2008-02-12 11:47:32
|
On Tuesday 12 February 2008 12:23:30 go...@bo... wrote: > On Tue, 12 Feb 2008, Marc Grimme wrote: > > How about your iscsi-config? > > That was all good and working. I no longer have access to the said cluster > because the system was deployed for the client, but there have been no > reported problems. The last problem was with the node(s) coming up too > quickly because of ARP propagation on managed switches, but that was > solved. IIRC you put a feature in to make the post-ifcfg initialization > delay carry over to the initroot to replace my ugly hack of putting "sleep > 60" in iscsi-lib.sh. > > I _think_ I might still have a copy of the cluster.conf file from that > setup, if that's of interest. yes it is ;-) . > > 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: <go...@bo...> - 2008-02-12 12:03:20
Attachments:
cluster.conf
|
On Tue, 12 Feb 2008, Marc Grimme wrote: >>> How about your iscsi-config? >> >> That was all good and working. I no longer have access to the said cluster >> because the system was deployed for the client, but there have been no >> reported problems. The last problem was with the node(s) coming up too >> quickly because of ARP propagation on managed switches, but that was >> solved. IIRC you put a feature in to make the post-ifcfg initialization >> delay carry over to the initroot to replace my ugly hack of putting "sleep >> 60" in iscsi-lib.sh. >> >> I _think_ I might still have a copy of the cluster.conf file from that >> setup, if that's of interest. > > yes it is ;-) . Attached. :) Gordan |
|
From: <go...@bo...> - 2008-02-12 17:25:46
|
On Tue, 12 Feb 2008, go...@bo... 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. Digging a bit further, the timestamp of the generated checksums seems to be 1201718041, which is approximately 30/01/2008 6:34pm GMT. Looks like repomd.xml hasn't been re-generated when a package update was added to the repository. :-( Gordan |
|
From: Marc G. <gr...@at...> - 2008-02-12 17:38:06
|
On Tuesday 12 February 2008 18:25:41 go...@bo... wrote: > On Tue, 12 Feb 2008, go...@bo... 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. > > Digging a bit further, the timestamp of the generated checksums seems to > be 1201718041, which is approximately 30/01/2008 6:34pm GMT. Looks like > repomd.xml hasn't been re-generated when a package update was added to > the repository. :-( Try agian that should have been fixed ;-) > > 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X