Bug 585309

This feature request did not get resolved in time for Feature Freeze
for the current Red Hat Enterprise Linux release and has now been
denied. You may re-open your request by requesting your support
representative to propose it for the next release.

I'll add to this. Is there anything in RHEL6 that will give a HA storage solution without employing an external shared storage (SAN/iSCSI/FC) device between nodes? Plus the added advantage of the external shared storage being a single point of failure (even if a rather good one). 

Having DRDB would seem to bring HA to a much wider audience and lower end applications than is possible with the present RHEL solutions. 

dm-repl was being touted as a solution to this that RH appeared to be taking more interest in. This was targeted for RHEL6, did it make it and can it perform the same function.

DRBD is another feature I expected from RHEL 6. Specially since we had opened another Bugzilla to get it add it to 5 and 6...

Guess we'll have to wait till they get it in and will have to keep manually recompiling the drbd-km rpms on our own until then... zzzzz

Here is the bugzilla for RHEL 5.5

https://bugzilla.redhat.com/show_bug.cgi?id=570796

Opened SR #2017052 for this as an RFE and also will notify our TAM.

Our people with support contracts have opened SR #2017020

We've opened SR #2017164 as a RFE for DRBD as we would really benefit from this technology. 

From my reading dm-replicator (which has similar functionality to DRDB) seems to have been more RH backed, and was supposed to ship with RHEL 6. Though I don't see any evidence that it's in the beta.

Would be of much interest to us as well.

I use DRBD quite often... Not having it as an installable option from core repos will be a pain.

My company uses DRBD quite extensively and it would be a joy to have it included with RHEL. One less thing to install and maintain separately!

- Chris

+1 for having DRBD

It will save me having to install it from external repos.
We use it a fair bit for low cost 2way redundant clusters.

So my vote is add it in.

+1 for DRBD.  I've used it in Fedora and Gentoo.  I'd love to have it in production systems here at WDTinc.

+1 for DRBD.  Would save having to manage our own packages outside of Redhat.

+1 for DRBD.  I've used DRBD from RHEL4u4 and having the KM and userspace tools as part of the distribution on RHEL6 would significantly increase the acceptance of it within solutions.

+1 for DRBD here as well. We use it already (of course, se everyone else on separate/external repo/packages) and having it part of the RHEL release will be a plus for maintainability and deployment.

+1 for DRBD.  I was rather surprised to find that it was the one glaring omission from the RHEL6 Beta.

I put this in my support request to get DRDB. Maybe someone here knows about this as I'm confused if dm-replicator will provide DRDB like functionality, which RH seems keener on.

This post (from a RH engineer) to the kernel mailing list during the discussion
of whether to take DRBD into the mainline kernel alludes to the inclusion of
dm-replicator being in RHEL 6. They claim this will provide similar
functionality, which you stated earlier it doesn't? So I'm a bit confused.

To Quote:
=====
> > > > BTW, DM already has something like drbd? I thought that there is a
> > > > talk about that new target at LinuxCon.
> > > 
> > > dm-replicator is nowhere near as usable as DRBD, and not upstream yet
> > 
> > I don't think usability at this point is important. The design
> > matters. dm-replicator is built on the existing framework.
> > 
> > And my question is, if drbd and dm-replicator will provide similar
> > features, then why do we need both in mainline?
> 
> dm-replicator is not there yet, and as such has zero user base.

dm-replicator is work in progress and we're aiming to ship it with
RHEL6.

===END QUOTE===
this is from here

http://marc.info/?l=linux-kernel&m=125363035327523&w=2

+1 currently used in production, would make maintenance much easier.

+1, we use this in production.  I have been waiting a loooong time for this to be in RHEL, and since it is now upstream, I just assumed it would be in RHEL as well!

+1 for DRBD. We also want to use DRBD in production on RHEL.

Please add DRBD into RHEL - Thanks

 +1 DRBD should be in RHEL6. Main repository support is key to adoption of tools like this. 

 An analogy being Red Hat including KVM as their main virtualisation technology to drive adoption.

Novell/Suse has DRBD since SLES8, but I hope that we don´t have to wait until RHEL8 ;-)

Redhat - please listen to us (your customers) and add it to RHEL6

We also use DRBD in production, please add it to RHEL6.

IBM has many DRBD customers.  For that matter, a great many Red Hat customers have used DRBD for years. It is reliable, and stable, and gives Linux a great leg up over other operating systems.   Please include it in RHEL6.

+1 DRBD should be in RHEL6.

Red Hat Global Support Services strongly suggests that any customers looking for this feature enhancement should contact their support representatives and open a request for this.  This helps us gauge and better understand the need for enhancements such as this.  

For information on how to open a support ticket pleaser refer to our support pages:
https://www.redhat.com/apps/support/

Thanks
Jeremy West
Red Hat Support Engineering

FYI, had opened SR #2017052 to request exactly that, but got back a response from the engineering team stating that RHEL will not support DRBD and that we should seek support from Linbit.

So, at least from what I'm hearing now, the answer is no to DRBD for RHEL6.

We opened SR #2017164, do you need us to do anymore?

We were at the RFE request stage, I had passed a description of the the problem I'm trying to solve that requires DRBD. Basically I want "a solution to allow a HA cluster to be implemented without the use of a shared storage device e.g without an iSCSI/SAN/Fibre Channel device shared between nodes".

I've reopened my SR and asked that it be attached to this bugzilla.  Strongly
urge the rest of you CC'd on this issue to do the same.

In my request I asked for both 5.x and 6 and they said the RFE was denied. I told them that they had to be serious and know that the code is in the main line kernel and that they should reconsider, otherwise I was reconsidering my OS. If I cannot get what I need to do my work as a paying customer, I would rather give my money to other company that is willing to support my needs.

Have not heard back after they sent my request to "management" to be reconsidered.

This request (SR #2017164) is exactly what people have been doing with DRBD for approximately ten years.  It is stable, efficient, proven, a standard part of the Linux kernel and very, very careful with your data.  It will be many years before any other technology could catch up with it.

It also integrates very well with Pacemaker (the future of Red Hat HA software).  Pacemaker has specific features put in to model DRBD completely.  As far as I know, DRBD is currently the only replication tool to be so tightly integrated with Pacemaker.

(In reply to comment #38)
> We opened SR #2017164, do you need us to do anymore?
> 
> We were at the RFE request stage, I had passed a description of the the problem
> I'm trying to solve that requires DRBD. Basically I want "a solution to allow a
> HA cluster to be implemented without the use of a shared storage device e.g
> without an iSCSI/SAN/Fibre Channel device shared between nodes".    

Thanks Colin.  That's enough for now.

(In reply to comment #37)
> FYI, had opened SR #2017052 to request exactly that, but got back a response
> from the engineering team stating that RHEL will not support DRBD and that we
> should seek support from Linbit.

Being from LINBIT I would like to add to this comment. We certainly have no problem acting as a third-party support provider to RHEL customers. However, Red Hat's current 3rd party support policy is somewhat ambiguous as to what support RHEL customers can expect _from Red Hat_ if they run into a kernel issue on a system where a "3rd party" kernel module is loaded, in case the issue is completely unrelated to that module.

Obviously, we would like to get this rectified as soon as possible and are in touch with Red Hat PM about this. I was originally advised that a modified 3rd party support framework would be ready by March, but so far that has not materialized.

+1 We are currently making software product on Windows which relies on 2PC-functionality of a proprietary database. If I every try to convince my bosses
to migrate our product to RHEL, there has to be a supported version of DRDB (which together with PostgreSQL can be used to achieve similar functionality). 

For the bosses LINBIT really is not on the radar.

Sorry for spamming even without a support contract, but added this comment also to get myself to CC-list.

+1 for DRBD inclusion ... BTW, if it's decided to not backport DRBD to kernel 2.6.32, what will happen for RHEL7 which will use something higher than 2.6.33 (which has drbd built-in by default) ? So deciding to not backport DRBD into 2.6.32 will just postpone the discussion that the Red Hat engineers have to hold regarding DRBD support in RHEL, as the question will come back for the next release anyway.

+1 for DRBD inclusion. We use it in production on several servers, please add it to RHEL6.

+1 DRBD should be in RHEL6.

+1 from me as well. DRBD is stable. Its inclusion would allow RHEL to enter markets (replicated storage) where only proprietary SANs and other enterprise Linux distributions exist today.

Logged SR #1263773 in favor of request as well.

+1 from me as well.  My company is ramping up a huge effort based on RHEL 6 and the only bit I'm waiting on is DRBD.  It would be best to have it as a part of the Core RHEL (mostly because it means not having to wait for the CentOS Extras packages).

Just logged 'Case 00371503'.

+1 to DRBD for RHEL6

We use DRBD extensively here. Not that it is not possible to install the module separately, I can say we have packaged our own kernel (2.6.33) on some of our RHEL servers, and DRBD rocks using the native kernel module. Having it included in RHEL 6 would save us lots of time (not having to maintain separate repos for DRBD related packages).

DRBD in RHEL6 would be a great incentive for us to upgrade, unlike dm-replicator, DRBD is documented, stable and, proven for replicating data.

There is no plan to back-port DRBD to the RHEL kernel at this time. We're looking at alternative ways to support this technology.

Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request.

This on the face of it appears to be a very poor decision. 

It would be nice if RH would provide us with more details of their roadmap for the alternative way to support this technology. 

Is RH thinking dm-replicator is their preferred method ? 

Will RH support any alternate with RHCS and GFS2?

It seems a rather large breakdown in customer relations to close a popular RFE like this with a two line answer, basically saying no.

Since they do not listen, perhaps is time to find a better distro. Honestly, even after paying for a support contract, I have never gotten my request resolved to my full satisfaction, some of them being as bad as rendering machines unusable. So why pay for something they cannot fix and something for which they cannot provide the tools that we need. "WE" are the users and the ones that have to deal with all the overhead of maintaining and compiling our own rpms because they will not backport a driver somebody else is already making to enable a proven technology.

Come un redhat, stop re-inventing the wheel... The one we have (drbd)has been beaten up on and proven to work well...

I just got back from teaching an high availability class at LISA (the USENIX conference for System Admins).  Of the 40 or so people in the class, at least 35 of them used DRBD.

I would guess most of them used Red Hat - since that's typical in the US.

And I forgot to say - how many of them loved DRBD - the same people raised their hands.  I also asked them how many had trouble with it.  NO ONE raised their hands.  That's pretty incredible..

Some VERY major companies use DRBD - and at least one of them have thousands of installations.  I can't put them in a public email list, but I'd be happy to supply you a few of them via private email or phone call.  I guarantee you have done business with at least one of them - they're _that_ pervasive.

I agree with Alan.

Almost all RHEL using companies that I know are also using DRBD. Supporting DRBD would be an additional selling proposition for RHEL.

With the release of RHEL6 Red Hat also changed the subscription model (See http://www.redhat.com/rhel/purchasing_guide.html)

Users which want to use XFS have to pay an additional $199/socket-pair per year. Why not having the same model for DRBD? Why not partnering with LINBIT? (i.e with the support)

I think $199 for DRBD support will be very fair pricing. Hey Red Hat: There are some business opportunities for you, take them! Make your customers even happier and get some extra money for it, what wrong with that?

If dm-replicator is the RedHat blessed path, how does one use it?  There appears to be no documentation although it does ship with RHEL6.
---
modinfo dm-replicator
filename:       /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/md/dm-replicator.ko
license:        GPL
author:         Heinz Mauelshagen <heinzm>
description:    device-mapper remote replication target
srcversion:     ECA4D2A942A25ED1F29C53F
depends:        dm-mod,dm-registry
vermagic:       2.6.32-71.el6.x86_64 SMP mod_unload modversions
---

(In reply to comment #63)
> If dm-replicator is the RedHat blessed path, how does one use it?  There
> appears to be no documentation although it does ship with RHEL6.

Honestly, the dm-replicator in RHEL 6.0 GA only has a very limited performance.
The author Heinz Mauelshagen mentioned in BZ #594922 that they are working on the performance issue.

dm-replicator and DRBD are focus at different part of replication.

The document for dm-replicator can be found in kernele-doc Documentation/device-mapper/replicator.txt
If you need a detailed documents of dm-replicator, please file another bug.

Done:  BZ 656167

Could someone please share the URL of the public git tree that carries the dm-replicator patches?

I had an email conversation with Gris from comment 64 who when I asked about replicating devices between systems stated:
---
dm-replicator is used for replicat between two devices on SINGLE system.
---

Seems dm-replicator is not a replacement for DRBD after all.

I seriously hope the RHEL Product and Program Management people are following this and are planning DRBD's inclusion in RHEL6.1

(In reply to comment #67)
> I had an email conversation with Gris from comment 64 who when I asked about
> replicating devices between systems stated:
> ---
> dm-replicator is used for replicat between two devices on SINGLE system.

dm-replicator is a multi-site, multi-device, active-passive replicator.

Ie. it replicates a group of devices ensuring write ordering fidelity from one primary site to one or more remote sites with the minimized requirement of having networked storage in those locations (no hosts mandatory there).

> ---
> 
> Seems dm-replicator is not a replacement for DRBD after all.

It's a different approach aiming to support more sites and to group devices together (think N database devices) to allow for replicating thme consistently.

> 
> I seriously hope the RHEL Product and Program Management people are following
> this and are planning DRBD's inclusion in RHEL6.1

> dm-replicator is a multi-site, multi-device, active-passive replicator.

Well that pretty much rules out dm-replicator to replace DRBD for most people at the moment I'd have thought. To run GFS2 you require an active-active replicator such as DRBD can be.

From RH closing this report earlier, it seems unlikely they will include this in 6.1, I'm guessing.

This does though seem totally against the RH agenda, brining advanced technology down to affordable prices. The could bring clustering to even medium sized companies (that can't afford a SAN box), think of all those extra licenses for clustering and GFS that'd bring in. I don't understand why RH aren't grasping this with both hands!

Heinz, thank you for the clarification (comment 68).  Is there documentation that details how to setup dm-replicator between two systems?  I'm looking for sysadmin level docs, not kernel hacker docs.

Also, could you explain the implications of "active/passive"?  Is it active/passive by design (i.e. will it always be active passive)?

Thanks

(In reply to comment #71)
> Heinz, thank you for the clarification (comment 68).  Is there documentation
> that details how to setup dm-replicator between two systems?  I'm looking for
> sysadmin level docs, not kernel hacker docs.

There's Documentation/device-mapper/replicator.txt in the kernel source which explains the table syntax and more allowing to set it up with dmsetup.

I'll attach it for your convenience.

> 
> Also, could you explain the implications of "active/passive"?  Is it
> active/passive by design (i.e. will it always be active passive)?

No it isn't limited by design.

Active/passive was the requirement for the initial version but I designed it to be open to support active/active via additional plugins.

> 
> Thanks

Created attachment 462593 [details]
dm-replicator targets usage description, table syntax and configuration examples

Please reconsider this feature added to the RHEL kernel, it seems Linbit is trying to support 2.6.32 kernels just for SLES 11SP1 and RHEL 6:

http://www.drbd.org/home/roadmap/

My company is now relying on Mimix and I really want to use this feature with RHEL 6.  I hope Red Hat reconsider this bug report and change its mind.

(In reply to comment #74)
> Please reconsider this feature added to the RHEL kernel, it seems Linbit is
> trying to support 2.6.32 kernels just for SLES 11SP1 and RHEL 6:

Excuse me?

> http://www.drbd.org/home/roadmap/

Please reread the roadmap, it appears to me that you're coming to completely incorrect conclusions.

What the roadmap says is that _DRBD 8.4_ will only support kernels from 2.6.32 forward. That means we are dropping the compatibility wrappers for kernels earlier than 2.6.32. In other words if you need any of the new DRBD features coming in 8.4, you'll have to upgrade your systems to a recent distro.

Note, DRBD 8.4 is still a few months off; at this point we have at least one more 8.3 release to make.

And most importantly, DRBD 8.3 will remain supported in a bugfix-only stable maintenance mode on all distros we currently support.

> My company is now relying on Mimix and I really want to use this feature with
> RHEL 6.  I hope Red Hat reconsider this bug report and change its mind.

Your company always has the option of entering into a support contract with Linbit.

Sorry, my bad.  I completely misunderstood that page.

I just really hope Red Hat supports DRBD in the next RHEL 6 update.

I just entered this company a few months ago and they already were working with Mimix.  Can you point me to the appropriate link to sales or support inside Linbit? I work for a huge financial company in Colombia, is there any support for this region? may be some local partners? I'm sure my bosses are going to ask that.

Thanks.

(In reply to comment #76)

William, can I suggest that you drop us a line at http://www.linbit.com/en/contact/ -- we'll be sure to be in touch. We obviously offer DRBD support world wide.

ELRepo now has DRBD packages available for RHEL6 (and RHEL5) here:

http://elrepo.org
http://elrepo.org/linux/elrepo/el6/

Hope that helps.

It's good to get the packages. For me just providing DRBD in the disto isn't enough. I'd also like to have integration and RH support provided for using DRBD with RH Cluster Suite and GFS2.

I also agree with the comment 79. BTW, i also have open  the SR 00401653 to the support.

(In reply to comment #78)
> ELRepo now has DRBD packages available for RHEL6 (and RHEL5) here:
> 
> http://elrepo.org
> http://elrepo.org/linux/elrepo/el6/
> 
> Hope that helps.

Great Ned! I for sure will test them out.  Do you have any howto or documentation about getting started with DRBD? something more updated to RHEL 6 if possible.

Thanks.

Hi William,

I'm only the messenger - those particular packages are maintained by Dag Wieers for elrepo.

Perhaps you could head over to the elrepo mailing lists (http://lists.elrepo.org/mailman/listinfo/elrepo) and ask there as I doubt Red Hat will appreciate us cluttering their bugzilla with support related issues.

Thanks.

Just in case -- people interested in DRBD on RHEL 6 might want to take a look at the following links:

http://www.linbit.com/en/news/single-news/art/60/31/
http://www.linbit.com/redhat
https://www.redhat.com/wapps/partnerlocator/web/home.html#productId=60400

+1 for inclusion in RHEL5 / RHEL6.

This is a must have technology/software for anyone trying to create enterprise class storage services with Red Hat Linux.

The fact that it is already in the upstream kernel makes back porting this a safe bet.

Red Hat and LINBIT will jointly support customers that want to use DRBD on RHEL. Please take a look at the following links for more information:

http://www.linbit.com/en/news/single-news/art/60/31/
http://www.linbit.com/redhat
https://www.redhat.com/wapps/partnerlocator/web/home.html#productId=60400

The issue was never about getting support from Red Hat in the sense of help me configure drbd or it broke and I do not know how to fix it. 

The issue was more about the pain of having to always manually compile a new drbd module when Red Hat releases a kernel update. If the drbd code from 2.6.33 was backported to the 2.6.32 kernel, then the module would always be built in, all done in one place and constant for everyone else just the same way it is on any post 2.6.33 kernel.

Sayan Saha,

I need clarification on support, given the following situation:

I have a premium support (24x7) contract for RHEL.
I have no support arrangement with LINBIT.

I deploy DRBD in RHEL and encounter an error or problem that needs troubleshooting, Red Hat will use its relationship with LINBIT to support my incident ticket?

(In reply to comment #88)
> Sayan Saha,
> 
> I need clarification on support, given the following situation:
> 
> I have a premium support (24x7) contract for RHEL.
> I have no support arrangement with LINBIT.
>

You'd better contact your RHEL sales guy but i'm pretty sure that you'll have to take another support contract with LINBIT if you want full end-to-end support. On the other side, DRBD is still opensource and can be used on RHEL perfectly even if Red Hat drops it from the mainline kernel

[quote]
The issue was never about getting support from Red Hat in the sense of help me
configure drbd or it broke and I do not know how to fix it. 

The issue was more about the pain of having to always manually compile a new
drbd module when Red Hat releases a kernel update. If the drbd code from 2.6.33
was backported to the 2.6.32 kernel, then the module would always be built in,
all done in one place and constant for everyone else just the same way it is on
any post 2.6.33 kernel.
[/quote]

As mentioned in comment #83, there are community provided kABI-tracking kmod drivers for DRBD that are well maintained by Dag Wieers that solve exactly this situation and work seamlessly across kernel updates, available from:

http://elrepo.org
http://elrepo.org/tiki/kmod-drbd83

Ideally, we (elrepo.org) would like to see these drivers included in the RHEL kernel, but until they are this is probably the best/easiest stopgap solution for RHEL users. Packages are available for both RHEL5 and RHEL6.

If you don't trust elrepo.org, feel free to take our SRPM packages, audit/verify them and rebuild them yourself.

(In reply to comment #90)

> Ideally, we (elrepo.org) would like to see these drivers included in the RHEL
> kernel, but until they are this is probably the best/easiest stopgap solution
> for RHEL users. Packages are available for both RHEL5 and RHEL6.
> 
> If you don't trust elrepo.org, feel free to take our SRPM packages,
> audit/verify them and rebuild them yourself.

You guys do a great job and while you seem to update drivers rather quickly, there is still a slight delay in releases. If the code was in the RHEL kernel, the module would be there already at kernel release time. I am currently using some of your rpms in RHEL6 workstations for other things like nvidia drivers.

I think the most recent drbd driver you have in the rhel6 tree is for 2.6.32-71.el6. However, the current RHEL 6 kernel is already 2.6.32-71.7.1.el6. As far as I know, the packages you are building do not use dkms, so I do not think that they would work on 2.6.32-71.7.1.el6, would they?

There is really not much to building the drbd packages using the ./configure and make rpm or make km-rpm commands as provided by drbd itself, but it is always just a tedious extra step with every kernel update.

(In reply to comment #91)
> (In reply to comment #90)
> 
> > Ideally, we (elrepo.org) would like to see these drivers included in the RHEL
> > kernel, but until they are this is probably the best/easiest stopgap solution
> > for RHEL users. Packages are available for both RHEL5 and RHEL6.
> > 
> > If you don't trust elrepo.org, feel free to take our SRPM packages,
> > audit/verify them and rebuild them yourself.
> 
> You guys do a great job and while you seem to update drivers rather quickly,
> there is still a slight delay in releases. If the code was in the RHEL kernel,
> the module would be there already at kernel release time. I am currently using
> some of your rpms in RHEL6 workstations for other things like nvidia drivers.
> 
> I think the most recent drbd driver you have in the rhel6 tree is for
> 2.6.32-71.el6. However, the current RHEL 6 kernel is already 2.6.32-71.7.1.el6.
> As far as I know, the packages you are building do not use dkms, so I do not
> think that they would work on 2.6.32-71.7.1.el6, would they?
> 
> There is really not much to building the drbd packages using the ./configure
> and make rpm or make km-rpm commands as provided by drbd itself, but it is
> always just a tedious extra step with every kernel update.

(In reply to comment #90)
> [quote]
> The issue was never about getting support from Red Hat in the sense of help me
> configure drbd or it broke and I do not know how to fix it. 
> 
> The issue was more about the pain of having to always manually compile a new
> drbd module when Red Hat releases a kernel update. If the drbd code from 2.6.33
> was backported to the 2.6.32 kernel, then the module would always be built in,
> all done in one place and constant for everyone else just the same way it is on
> any post 2.6.33 kernel.
> [/quote]
> 
> As mentioned in comment #83, there are community provided kABI-tracking kmod
> drivers for DRBD that are well maintained by Dag Wieers that solve exactly this
> situation and work seamlessly across kernel updates, available from:

... and the same thing is true for any RHEL 6 DRBD packages that LINBIT support customers get. Recompiling or re-installing DRBD kernel module packages when Red Hat update the RHEL kernel is a thing of the past.

I think I missed the section about the "kABI-tracking kmod drivers" a few times, but after finding out what it means, then I will give these packages a try and forget about recompiling for every new kernel release.

http://elrepo.org/tiki/FAQ

Thanks a lot for pointing it out (again).

(In reply to comment #89)
> (In reply to comment #88)
> > Sayan Saha,
> > 
> > I need clarification on support, given the following situation:
> > 
> > I have a premium support (24x7) contract for RHEL.
> > I have no support arrangement with LINBIT.
> >
> 
> You'd better contact your RHEL sales guy but i'm pretty sure that you'll have
> to take another support contract with LINBIT if you want full end-to-end
> support. On the other side, DRBD is still opensource and can be used on RHEL
> perfectly even if Red Hat drops it from the mainline kernel

Well this is what I am trying to find out, I mean I am reacting to this comment
he made:

"Red Hat and LINBIT will jointly support customers that want to use DRBD on
RHEL."

The way I read that, and subsequently (IMO) the only way that matters from a
support perspective is if my premium support contract will envelop DRBD due to
Red Hat and LINBIT's "partnership".

If that is not the case, then Red Hat is not supporting anything.

Heh, "Jointly supporting my ability to pay another company for support ?" ..
sounds preposterous but lets see what Sayan has to say about it.

"Red Hat and LINBIT will jointly support customers that want to use DRBD on
RHEL."

The way I read this is: Red Hat will support the (modified) RHEL, while LINBIT will support DRBD on top of RHEL.

Mind you that without such partnership, LINBIT could support your DRBD setup on top of RHEL, but Red Hat would ask you to reproduce the problem without DRBD, and that's often not what you'd like.

(In reply to comment #86)
> Red Hat and LINBIT will jointly support customers that want to use DRBD on
> RHEL. Please take a look at the following links for more information:

Okay...let's figure out whether this is just a marketing joke or not: At the
moment building of DRBD 8.3.10 on RHEL 6.1 fails as follows. Maybe LINBIT is
able to help here? Because from what I got, Red Hat is only focussed to their 
super-duper-but-not-yet-ready-for-productive-usage dm-replicator... :-(

make -C /usr/src/kernels/2.6.32-131.0.15.el6.x86_64   SUBDIRS=/builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd  modules
make[1]: Entering directory `/usr/src/kernels/2.6.32-131.0.15.el6.x86_64'
  CC [M]  /builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_buildtag.o
  CC [M]  /builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_bitmap.o
  CC [M]  /builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_proc.o
  CC [M]  /builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_worker.o
  CC [M]  /builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_receiver.o
/builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_receiver.c: In function 'drbd_submit_ee':
/builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_receiver.c:1286: error: 'REQ_UNPLUG' undeclared (first use in this function)
/builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_receiver.c:1286: error: (Each undeclared identifier is reported only once
/builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_receiver.c:1286: error: for each function it appears in.)
/builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_receiver.c: In function 'wire_flags_to_bio':
/builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_receiver.c:1864: error: 'REQ_UNPLUG' undeclared (first use in this function)
make[2]: *** [/builddir/build/BUILD/drbd-kmod-8.3.10/_kmod_build_2.6.32-131.0.15.el6.x86_64/drbd/drbd_receiver.o] Error 1

Any help to get this working is highly appreciated. I'll provide information
if requested and I'm willing to fire as much builds on RHEL 6 as needed, if I
get some help here. Thank you.

(In reply to comment #96)

Linbit and RH have formed an agreement to support DRBD on RHEL 6. You can talk to your sales rep for information of getting the supported RPMs.

(In reply to comment #96)
> 
> Okay...let's figure out whether this is just a marketing joke or not: At the
> moment building of DRBD 8.3.10 on RHEL 6.1 fails as follows.

I can confirm the errors you see building against RHEL 6.1

One solution is to build it as a kABI-tracking kmod package against RHEL 6.0, and it weak-links fine against RHEL 6.1 kernels:

[phil@rhel6b64 ~]$ rpm -q kmod-drbd83
kmod-drbd83-8.3.10-2.el6.elrepo.x86_64

[phil@rhel6b64 ~]$ find /lib/modules/ -name drbd.ko
/lib/modules/2.6.32-71.el6.x86_64/extra/drbd83/drbd.ko
/lib/modules/2.6.32-131.0.15.el6.x86_64/weak-updates/drbd83/drbd.ko
/lib/modules/2.6.32-131.2.1.el6.x86_64/weak-updates/drbd83/drbd.ko
/lib/modules/2.6.32-131.4.1.el6.x86_64/weak-updates/drbd83/drbd.ko

You don't need to build it against a RHEL 6.1 kernel.

http://git.drbd.org/?p=drbd-8.3.git;a=blobdiff;f=drbd/drbd_wrappers.h;h=280f316263bbee01d7dd25325181672f3c643aad;hp=cf0caffe44e5d454724ab79583308dcfec480ad3;hb=996caf1843d453de0f76c205a9d925a3efbbd13d;hpb=8617a337b4f9309b3df612b06511177e29b5c7a9
contains a working fix for the issue mentioned in comment #96. Aside, DRBD 
8.3.11rc3 includes this fix as well. Thanks, LINBIT.


Finally: Dear Red Hat, refusing DRBD directly inside of RHEL is unfortunately
not really Enterprise-like...

The exclusion of DRDB is the only reason we (Mozilla Services) have Ubuntu in our otherwise pure-RHEL environment.

+1 same as comment #100 here... The only reason we have and still install ubuntu is the lack of support for drbd with RHEL!

As I understand it:
If you are already entitled to RHEL support from Red Hat and you also want support for DRBD on RHEL, you need to contact LINBIT and make a separate support arrangement.  LINBIT supplies and supports the DRBD pieces on RHEL.

If you subsequently have a problem that spans DRBD and RHEL, or it's not obvious on which side the problem lies, the Red Hat and LINBIT support teams will work *together* to help you resolve the problem.

That doesn't say why you are not shipping drbd as a rpm for RHEL6.

(In reply to comment #103)
> That doesn't say why you are not shipping drbd as a rpm for RHEL6.

As I understand it, Red Hat made business decisions to focus on a narrower spectrum of applications so that they could deliver those best. DRBD was not in mainline kernel for 2.6.32 so to maintain it, they would have to maintain a large set of patches.

The agreement that Linbit and Red Hat have come to, which provides a fully supported path for using DRBD in RHEL 6.