Hi, In the last few days I've started experimenting with some advanced features in order to create a storage cluster for a relatively large setup (several servers need shared access to about 30TB of space). Basically what I am trying to set up is either a GFS or OCFS2 cluster using iSCSI devices as block-level storage.
What I noticed though is that the required tools in Fedora seem to be in a state of neglect and I'm wondering what the gameplan is both for the Server SIG and future RHEL releases that presumably are derived from these tools.
Here is what I've run into so far:
"scsi-target-utils" seems to be the recommended package to create iscsi targets but it doesn't seem to be well integrated. Configured devices aren't brought online on boot nor are they switched to offline during shutdown resulting in error messages like "Targets still in use. Cannot shutdown service.". The package "netbsd-iscsi" which also provides iscsi target functionality seems to be much better integrated.
OCFS2 seems to be broken in F10 because of a missing line in the init.d file: https://bugzilla.redhat.com/show_bug.cgi?id=476469
"system-cluster-config" has missing dependencies and references files in the wrong places: https://bugzilla.redhat.com/show_bug.cgi?id=477496 https://bugzilla.redhat.com/show_bug.cgi?id=477499
I think the Server SIG is the perfect place to address these issues and maybe come up with some recommendations/best practices regarding advanced setups involving the above tools.
Regards, Dennis
Dennis J. wrote:
I think the Server SIG is the perfect place to address these issues and maybe come up with some recommendations/best practices regarding advanced setups involving the above tools.
Regards, Dennis
Dennis check out the ACE at www.thincrust.org which is a first cut at a tool designed to aide in advanced post-install set-up for appliances.
This might be what you are looking for or something that could help you configure a cluster. If you have any questions we have a mailing list: thincrust-devel@redhat.com, or ion irc: #thincrust on freenode.
-D
On 01/05/2009 08:39 PM, David Huff wrote:
Dennis J. wrote:
I think the Server SIG is the perfect place to address these issues and maybe come up with some recommendations/best practices regarding advanced setups involving the above tools.
Regards, Dennis
Dennis check out the ACE at www.thincrust.org which is a first cut at a tool designed to aide in advanced post-install set-up for appliances.
This might be what you are looking for or something that could help you configure a cluster. If you have any questions we have a mailing list: thincrust-devel@redhat.com, or ion irc: #thincrust on freenode.
My concern right now isn't so much about the configuration of these technologies but with the fact that they don't seem to be maintained at all right now and in various states of disarray. In the regular Fedora world this isn't such a big deal I guess because a desktop user is unlikely to use OCFS2 or GFS clustering or setup iScsi shares but with the creation of the server SIG I'm wondering what the plans are with regards to bringing this stuff back to life. A Fedora for servers that lets these packages bit-rot like that doesn't look very useful.
Regards, Dennis
Dennis J. wrote:
My concern right now isn't so much about the configuration of these technologies but with the fact that they don't seem to be maintained at all right now and in various states of disarray.
ahh I see what you getting at...
In the regular Fedora world this isn't such a big deal I guess because a desktop user is unlikely to use OCFS2 or GFS clustering or setup iScsi shares but with the creation of the server SIG I'm wondering what the plans are with regards to bringing this stuff back to life.
I have always just used tgtadm for setting up iscsi targets myself. I know that scsi-target-utils is a "tech preview" in RHEL however I am not sure its status in Fedora.
I agree that the server sig may be a good place to try and get these tools more integrated for a Fedora Server.
-D
David Huff píše v St 07. 01. 2009 v 10:34 -0500:
Dennis J. wrote:
My concern right now isn't so much about the configuration of these technologies but with the fact that they don't seem to be maintained at all right now and in various states of disarray.
ahh I see what you getting at...
In the regular Fedora world this isn't such a big deal I guess because a desktop user is unlikely to use OCFS2 or GFS clustering or setup iScsi shares but with the creation of the server SIG I'm wondering what the plans are with regards to bringing this stuff back to life.
I have always just used tgtadm for setting up iscsi targets myself. I know that scsi-target-utils is a "tech preview" in RHEL however I am not sure its status in Fedora.
I agree that the server sig may be a good place to try and get these tools more integrated for a Fedora Server.
The Server SIG is the right place for these technologies, but we are in need of input from the "real world" about current deficiencies, problems, success stories etc.
Dan
On Thursday, 08 January 2009 at 15:36, Dan Horák wrote:
David Huff píše v St 07. 01. 2009 v 10:34 -0500:
Dennis J. wrote:
My concern right now isn't so much about the configuration of these technologies but with the fact that they don't seem to be maintained at all right now and in various states of disarray.
ahh I see what you getting at...
In the regular Fedora world this isn't such a big deal I guess because a desktop user is unlikely to use OCFS2 or GFS clustering or setup iScsi shares but with the creation of the server SIG I'm wondering what the plans are with regards to bringing this stuff back to life.
I have always just used tgtadm for setting up iscsi targets myself. I know that scsi-target-utils is a "tech preview" in RHEL however I am not sure its status in Fedora.
I agree that the server sig may be a good place to try and get these tools more integrated for a Fedora Server.
The Server SIG is the right place for these technologies, but we are in need of input from the "real world" about current deficiencies, problems, success stories etc.
Here's one about Fedora 9:
I needed to move a module from one modular switch to another, which meant disconnecting a couple of servers from their ethernet sockets for a couple of minutes. Their network interfaces never came back. Reason? NetworkManager never brought the interfaces up again even though the kernel logs showed "Link up" messages. Solution: switch to the old networking scripts from initscripts.
Regards, R.
On 01/08/2009 03:36 PM, Dan Horák wrote:
David Huff píše v St 07. 01. 2009 v 10:34 -0500:
[SNIP]
The Server SIG is the right place for these technologies, but we are in need of input from the "real world" about current deficiencies, problems, success stories etc.
That's how I ran into the problems I mentioned. In the near future I will have to setup approx. 30TB of storage that needs to be available for 5-10 servers. The problem is that OCFS2 seems to be just plain broken, the web configuration tool described in the RHEL 5 manual for GFS is no longer present in Fedora and the cluster configuration tool doesn't work because it tries to call command line tools in the wrong locations.
What I'm wondering is that if fedora is the basis for RHEL then what are the plans for RHEL 6 regarding these technologies. AFAIK fedora 11 will form the basis for that but right now GFS and/or clustering in general seems to suffer from bit-rot.
I'm just surprised that GFS is a cornerstone of RHEL 5 but now seems to be basically unmaintained or is the RHEL team maintaining forked versions of these tools?
Regards, Dennis
Dennis J. wrote:
On 01/08/2009 03:36 PM, Dan Horák wrote:
David Huff píše v St 07. 01. 2009 v 10:34 -0500:
[SNIP]
The Server SIG is the right place for these technologies, but we are in need of input from the "real world" about current deficiencies, problems, success stories etc.
For questions about supporting the clustering technologies in Fedora better ask on linux-cluster list (see https://www.redhat.com/mailman/listinfo/linux-cluster)
Milan
That's how I ran into the problems I mentioned. In the near future I will have to setup approx. 30TB of storage that needs to be available for 5-10 servers. The problem is that OCFS2 seems to be just plain broken, the web configuration tool described in the RHEL 5 manual for GFS is no longer present in Fedora and the cluster configuration tool doesn't work because it tries to call command line tools in the wrong locations.
What I'm wondering is that if fedora is the basis for RHEL then what are the plans for RHEL 6 regarding these technologies. AFAIK fedora 11 will form the basis for that but right now GFS and/or clustering in general seems to suffer from bit-rot.
I'm just surprised that GFS is a cornerstone of RHEL 5 but now seems to be basically unmaintained or is the RHEL team maintaining forked versions of these tools?
Hi,
On Wed, 2009-01-14 at 10:48 +0100, Milan Broz wrote:
Dennis J. wrote:
On 01/08/2009 03:36 PM, Dan Horák wrote:
David Huff píše v St 07. 01. 2009 v 10:34 -0500:
[SNIP]
The Server SIG is the right place for these technologies, but we are in need of input from the "real world" about current deficiencies, problems, success stories etc.
For questions about supporting the clustering technologies in Fedora better ask on linux-cluster list (see https://www.redhat.com/mailman/listinfo/linux-cluster)
Milan
That's how I ran into the problems I mentioned. In the near future I will have to setup approx. 30TB of storage that needs to be available for 5-10 servers. The problem is that OCFS2 seems to be just plain broken, the web configuration tool described in the RHEL 5 manual for GFS is no longer present in Fedora and the cluster configuration tool doesn't work because it tries to call command line tools in the wrong locations.
What I'm wondering is that if fedora is the basis for RHEL then what are the plans for RHEL 6 regarding these technologies. AFAIK fedora 11 will form the basis for that but right now GFS and/or clustering in general seems to suffer from bit-rot.
I'm just surprised that GFS is a cornerstone of RHEL 5 but now seems to be basically unmaintained or is the RHEL team maintaining forked versions of these tools?
I also subscribed to this list on Milan suggestion. I'll try to reply asap to your query.
Generally we prefer to discuss everything on upstream mailing list.
Fabio
Hi all,
sorry if i can't reply to each email properly as I don't have a local history of the mailing list.
To reply to http://lists.fedoraproject.org/pipermail/fedora-server-list/2009-January/000...
My concern right now isn't so much about the configuration of these technologies but with the fact that they don't seem to be maintained at all right now and in various states of disarray.
Can you please be more specific? I have been updating redhat-cluster on a regular base in Fedora 9/10/rawhide. What makes you think they are unmaintained?
A Fedora for servers that lets these packages bit-rot like that doesn't look very useful.
If you are experiencing issues, either file bug reports or talk to upstream. We have been extremely responsive to everybody so far.
To reply to http://lists.fedoraproject.org/pipermail/fedora-server-list/2009-January/000...
Reason? NetworkManager never brought the interfaces up again even though the kernel logs showed "Link up" messages. Solution: switch to the old networking scripts from initscripts.
Network Manager is a desktop/laptop technology a properly installed server shouldn't have NM at all. This is not something related to cluster of any cluster filesystem in general == off topic for this thread.
That's how I ran into the problems I mentioned. In the near future I will have to setup approx. 30TB of storage that needs to be available for 5-10 servers. The problem is that OCFS2 seems to be just plain broken,
Did you report those issues to upstream? We work with OCFS2 guys all the time and they are very responsive.
the web
configuration tool described in the RHEL 5 manual for GFS is no longer present in Fedora
conga is part of Fedora 9/10/rawhide. Look for ricci, modcluster, cluster-snmp and cluster-cim packages.
and the cluster configuration tool doesn't work because
it tries to call command line tools in the wrong locations.
system-config-cluster has been obsoleted. Unless you mean some other tools, in that case please specify which.
What I'm wondering is that if fedora is the basis for RHEL then what are the plans for RHEL 6 regarding these technologies. AFAIK fedora 11 will form the basis for that but right now GFS and/or clustering in general seems to suffer from bit-rot.
The plans for F11 are very well set for upstream and been communicated across the board through public mailing lists.
Anyway, so far I have read a lot of "bit-rot" this or "broken" that, but you didn't provide any real info on the problems. I'd be very happy to coordinate the fixes upstream and propagate them into Fedora ASAP given enough info.
I'm just surprised that GFS is a cornerstone of RHEL 5 but now seems to be basically unmaintained or is the RHEL team maintaining forked versions of these tools?
RHEL doesn't have any forked tool. You can check upstream wiki and git repositories yourself. All our development is done in the open.
Cheers, Fabio
On 01/14/2009 01:01 PM, Fabio M. Di Nitto wrote:
Hi all,
sorry if i can't reply to each email properly as I don't have a local history of the mailing list.
To reply to http://lists.fedoraproject.org/pipermail/fedora-server-list/2009-January/000...
My concern right now isn't so much about the configuration of these technologies but with the fact that they don't seem to be maintained at all right now and in various states of disarray.
Can you please be more specific? I have been updating redhat-cluster on a regular base in Fedora 9/10/rawhide. What makes you think they are unmaintained?
mounting ocfs2 partition fails due to missing load_module command in startup script: https://bugzilla.redhat.com/show_bug.cgi?id=476469 (A added the needed fix and the keyword "EasyFix" to the bug)
Missing dependency: rgmanager https://bugzilla.redhat.com/show_bug.cgi?id=477496
system-config-cluster is looking for cman_tool in the wrong place https://bugzilla.redhat.com/show_bug.cgi?id=477499
The reason I was bringing this up on the mailing-list is that bugs like the ocfs2 issue and the problem with the cman_tool location are highly visible so I was wondering why such bugs didn't seem to pop up on anyones radar.
After having the problems with system-config-cluster I tried Conga as the alternative route for configuration but "luci" seems to have gone AWOL. According to http://sourceware.org/cluster/conga/ Conga wasn't part of F7 and F8 because of python compat. issues. Is this the reason that luci isn't part of F10?
That's how I ran into the problems I mentioned. In the near future I will have to setup approx. 30TB of storage that needs to be available for 5-10 servers. The problem is that OCFS2 seems to be just plain broken,
Did you report those issues to upstream? We work with OCFS2 guys all the time and they are very responsive.
The question for me is if the problem is fixed upstream how long does it take for them to get into fedora? The fix for the ocfs2 problem was posted in Ubuntus launchpad in October and given the fact that this bug prevents ocfs2 from working completely I'm wondering why it's still present in Fedora. The only conclusion I can draw from that is that virtually nobody uses ocfs2 in fedora which is why it didn't get reported until now. That's not necessarily a big problem per se but if this technology is considered low priority in Fedora then that factors into my decision to rely on it.
the web
configuration tool described in the RHEL 5 manual for GFS is no longer present in Fedora
conga is part of Fedora 9/10/rawhide. Look for ricci, modcluster, cluster-snmp and cluster-cim packages.
What about luci?
and the cluster configuration tool doesn't work because
it tries to call command line tools in the wrong locations.
system-config-cluster has been obsoleted. Unless you mean some other tools, in that case please specify which.
What I'm wondering is that if fedora is the basis for RHEL then what are the plans for RHEL 6 regarding these technologies. AFAIK fedora 11 will form the basis for that but right now GFS and/or clustering in general seems to suffer from bit-rot.
The plans for F11 are very well set for upstream and been communicated across the board through public mailing lists.
Anyway, so far I have read a lot of "bit-rot" this or "broken" that, but you didn't provide any real info on the problems. I'd be very happy to coordinate the fixes upstream and propagate them into Fedora ASAP given enough info.
I think the basic problem is that I'm trying to feel my way into the clustering field but run into a lot of conflicting information. For example I am supposed to look upstream for info (which I generally agree with) but when I look at the Conga homepage the user manual tells me to install "luci". Apparently that information is outdated. Since I have to start somewhere I chose the latest "Red Hat Cluster Suite for Red Hat Enterprise Linux" which talks about system-config-cluster which as I learned above is basically no longer relevant.
Is there some kind of "clustering lab" site out there that contains more recent information about these technologies?
I'm just surprised that GFS is a cornerstone of RHEL 5 but now seems to be basically unmaintained or is the RHEL team maintaining forked versions of these tools?
RHEL doesn't have any forked tool. You can check upstream wiki and git repositories yourself. All our development is done in the open.
That's what I thought and that's why I was so confused when running into these problems. The trouble I ran into didn't seem to make sense given the success Red Hat is having with this stuff in the field so I decided to take this to the brand new fedora-server list so I could perhaps get some more insight into what's going on with this stuff.
Regards, Dennis
On Wed, 2009-01-14 at 20:15 +0100, Dennis J. wrote:
On 01/14/2009 01:01 PM, Fabio M. Di Nitto wrote:
Hi all,
sorry if i can't reply to each email properly as I don't have a local history of the mailing list.
To reply to http://lists.fedoraproject.org/pipermail/fedora-server-list/2009-January/000...
My concern right now isn't so much about the configuration of these technologies but with the fact that they don't seem to be maintained at all right now and in various states of disarray.
Can you please be more specific? I have been updating redhat-cluster on a regular base in Fedora 9/10/rawhide. What makes you think they are unmaintained?
mounting ocfs2 partition fails due to missing load_module command in startup script: https://bugzilla.redhat.com/show_bug.cgi?id=476469 (A added the needed fix and the keyword "EasyFix" to the bug)
I forwarded this to upstream now. It's probably already fixed in more recent versions of ocfs2-tools upstream. We were discussing to propagate them into fedora 2 days ago.
Missing dependency: rgmanager https://bugzilla.redhat.com/show_bug.cgi?id=477496
system-config-cluster is looking for cman_tool in the wrong place https://bugzilla.redhat.com/show_bug.cgi?id=477499
Jim can you please look at those bugs and decide if system-config-cluster should either be removed or fixed for Fedora in favour of conga? cman already requires conga components.
The reason I was bringing this up on the mailing-list is that bugs like the ocfs2 issue and the problem with the cman_tool location are highly visible so I was wondering why such bugs didn't seem to pop up on anyones radar.
Because clearly there is a very low user base for them. ocfs2 is "new" in fedora as we (ocfs2 guys and me) revived the package not too long ago.
system-config-cluster.. same comment as above.. it's just plain obsolete.
After having the problems with system-config-cluster I tried Conga as the alternative route for configuration but "luci" seems to have gone AWOL. According to http://sourceware.org/cluster/conga/ Conga wasn't part of F7 and F8 because of python compat. issues. Is this the reason that luci isn't part of F10?
conga/luci and modules are there from F9. I have updates some of those builds myself so I am sure they are there.
That's how I ran into the problems I mentioned. In the near future I will have to setup approx. 30TB of storage that needs to be available for 5-10 servers. The problem is that OCFS2 seems to be just plain broken,
Did you report those issues to upstream? We work with OCFS2 guys all the time and they are very responsive.
The question for me is if the problem is fixed upstream how long does it take for them to get into fedora?
Not long. If the problem is only package related it's usually less than 24 hours. If the fix need to go upstream, probably one or two weeks (time it takes to do some builds, testing and collect enough fixes to make it worth issuing an update for everybody). For rawhide it's a lot faster of course.
The fix for the ocfs2 problem was posted in Ubuntus launchpad in October and given the fact that this bug prevents ocfs2 from working completely I'm wondering why it's still present in Fedora.
Because nobody reported it to fedora so far? As upstream we cannot track all possible sources of bugs. That is why every distribution/packager has the golden rule to be the gateway for distro bugs to upstream.
The only conclusion I can draw from that is that virtually nobody uses ocfs2 in fedora which is why it didn't get reported until now.
This is entirely possible. Except that upstream does some development directly in Fedora and most of it on Debian (there are tons of bugs upstream has been trying to get fixed in Debian and that are not flowing into Ubuntu).
That's not necessarily a big problem per se but if this technology is considered low priority in Fedora then that factors into my decision to rely on it.
See.. you reported me a problem approx 10 minutes ago. Piped through the proper lines, it's being addressed as we speak. Clearly signs of user base will gather attention from the right people.
the web
configuration tool described in the RHEL 5 manual for GFS is no longer present in Fedora
conga is part of Fedora 9/10/rawhide. Look for ricci, modcluster, cluster-snmp and cluster-cim packages.
What about luci?
It's in the package list I posted before.
and the cluster configuration tool doesn't work because
it tries to call command line tools in the wrong locations.
system-config-cluster has been obsoleted. Unless you mean some other tools, in that case please specify which.
What I'm wondering is that if fedora is the basis for RHEL then what are the plans for RHEL 6 regarding these technologies. AFAIK fedora 11 will form the basis for that but right now GFS and/or clustering in general seems to suffer from bit-rot.
The plans for F11 are very well set for upstream and been communicated across the board through public mailing lists.
Anyway, so far I have read a lot of "bit-rot" this or "broken" that, but you didn't provide any real info on the problems. I'd be very happy to coordinate the fixes upstream and propagate them into Fedora ASAP given enough info.
I think the basic problem is that I'm trying to feel my way into the clustering field but run into a lot of conflicting information. For example I am supposed to look upstream for info (which I generally agree with) but when I look at the Conga homepage the user manual tells me to install "luci". Apparently that information is outdated. Since I have to start somewhere I chose the latest "Red Hat Cluster Suite for Red Hat Enterprise Linux" which talks about system-config-cluster which as I learned above is basically no longer relevant.
Jim, Ryan: can we please update the conga web site to reflect a newer status of things?
Is there some kind of "clustering lab" site out there that contains more recent information about these technologies?
Not yet but this has been discussed at Cluster Summit 2008. All information will be collected (from all different projects) in one single umbrella that will work as reference point.
I'm just surprised that GFS is a cornerstone of RHEL 5 but now seems to be basically unmaintained or is the RHEL team maintaining forked versions of these tools?
RHEL doesn't have any forked tool. You can check upstream wiki and git repositories yourself. All our development is done in the open.
That's what I thought and that's why I was so confused when running into these problems.
the problem you are hitting with system-config-cluster is packaging related. cman_tool in RHEL4/5 has a different location than F10/rawhide. This is a known issue that will be addressed in rawhide. F10 still holds some legacy bits to be backward compatible with F9.
The trouble I ran into didn't seem to make sense given the success Red Hat is having with this stuff in the field so I decided to take this to the brand new fedora-server list so I could perhaps get some more insight into what's going on with this stuff.
Well some of them are valid issues, others are old/not updated documentation that is still at RHEL5 level. Things have been evolving a lot in the meantime and generally new docs are generated when a new stable upstream release happens. So far (since RHEL5/STABLE2) there have been no new major stable releases (with 3.0.0 upcoming in a couple of months just for F11). So you are looking into a transition phase of the software and expect to be everything already settled.
Fabio
On 01/14/2009 09:03 PM, Fabio M. Di Nitto wrote:
After having the problems with system-config-cluster I tried Conga as the alternative route for configuration but "luci" seems to have gone AWOL. According to http://sourceware.org/cluster/conga/ Conga wasn't part of F7 and F8 because of python compat. issues. Is this the reason that luci isn't part of F10?
conga/luci and modules are there from F9. I have updates some of those builds myself so I am sure they are there.
But where exactly are they? I've tried finding packages like "*luci*" and "*conga*" with yum. I looked into the packages you mentioned previously (modcluster, ricci, cluster-snmp and cluster-cim). I tried a repoquery for "*luci*", "*Luci*", "*conga*" and "*Conga*" but none of the resulting packages have anything to do with clustering.
Well some of them are valid issues, others are old/not updated documentation that is still at RHEL5 level. Things have been evolving a lot in the meantime and generally new docs are generated when a new stable upstream release happens. So far (since RHEL5/STABLE2) there have been no new major stable releases (with 3.0.0 upcoming in a couple of months just for F11). So you are looking into a transition phase of the software and expect to be everything already settled.
Apparently my timing for diving into this was a bit unfortunate. A bit earlier and I would have found things to be closer to the current documentation on the web. A bit later and the documentation probably would have reflected the current state of things more.
Thanks for the pointers so far. That information definitely helped to clear some of the confusion surrounding the current state of cluster related technologies in fedora for a newbie like me.
Regards, Dennis
On Thu, 2009-01-15 at 05:48 +0100, Dennis J. wrote:
On 01/14/2009 09:03 PM, Fabio M. Di Nitto wrote:
After having the problems with system-config-cluster I tried Conga as the alternative route for configuration but "luci" seems to have gone AWOL. According to http://sourceware.org/cluster/conga/ Conga wasn't part of F7 and F8 because of python compat. issues. Is this the reason that luci isn't part of F10?
conga/luci and modules are there from F9. I have updates some of those builds myself so I am sure they are there.
But where exactly are they? I've tried finding packages like "*luci*" and "*conga*" with yum. I looked into the packages you mentioned previously (modcluster, ricci, cluster-snmp and cluster-cim). I tried a repoquery for "*luci*", "*Luci*", "*conga*" and "*Conga*" but none of the resulting packages have anything to do with clustering.
http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Everything/i3... http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Everything/i3... http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Everything/i3... http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Everything/i3...
Of course you can change i386 to whatever architecture you are running.
*conga* and *luci* are project name and one of the component names of the above packages and they are mentioned in the package description.
Well some of them are valid issues, others are old/not updated documentation that is still at RHEL5 level. Things have been evolving a lot in the meantime and generally new docs are generated when a new stable upstream release happens. So far (since RHEL5/STABLE2) there have been no new major stable releases (with 3.0.0 upcoming in a couple of months just for F11). So you are looking into a transition phase of the software and expect to be everything already settled.
Apparently my timing for diving into this was a bit unfortunate. A bit earlier and I would have found things to be closer to the current documentation on the web. A bit later and the documentation probably would have reflected the current state of things more.
I have asked people to start updating some of the conga web site information already in my previous email.
Thanks for the pointers so far. That information definitely helped to clear some of the confusion surrounding the current state of cluster related technologies in fedora for a newbie like me.
You want to spend a few minutes on our mailing list archive to read the goals for next generation cluster (the ones _after_ F11) as all our stacks (Novell - pacemaker, Oracle - ocfs2-tools and Red Hat cluster) will converge into one, killing the whole decision problem at the root. I am sure you will be interested in that process as well.
Fabio
On 01/07/2009 04:34 PM, David Huff wrote:
Dennis J. wrote:
My concern right now isn't so much about the configuration of these technologies but with the fact that they don't seem to be maintained at all right now and in various states of disarray.
ahh I see what you getting at...
In the regular Fedora world this isn't such a big deal I guess because a desktop user is unlikely to use OCFS2 or GFS clustering or setup iScsi shares but with the creation of the server SIG I'm wondering what the plans are with regards to bringing this stuff back to life.
I have always just used tgtadm for setting up iscsi targets myself. I know that scsi-target-utils is a "tech preview" in RHEL however I am not sure its status in Fedora.
I've been using "netbsd-iscsi" for setting up targets. I found that to be a lot more intuitive to setup and control. All I had to do was putting this into /etc/iscsi/targets:
# extents file start length extent0 /root/iscsistorage 0 size # target flags storage netmask target0 rw extent0 192.168.2.0/24
After that I have /root/iscsistorage available as a target and it gets setup properly on boot.
With tgtadm I couldn't get it to setup the target automatically on boot and on shutdown it complained that it couldn't get rid of the target for some reason. At least at a first glance it didn't look as well integrated as netbsd-iscsi.
Regards, Dennis
server@lists.fedoraproject.org
-
Dan Horák -
David Huff -
Dennis Jacobfeuerborn -
Dominik 'Rathann' Mierzejewski -
Fabio M. Di Nitto -
Milan Broz