Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[RFE] Backport The Distributed Replicated Block Device (DRBD) to 2.6.32|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Robin R. Price II <rprice>|
|Component:||kernel||Assignee:||Red Hat Kernel Manager <kernel-mgr>|
|Status:||CLOSED CANTFIX||QA Contact:||Red Hat Kernel QE team <kernel-qe>|
|Version:||6.1||CC:||aaron.mcsorley, adam.murphy, agk, ajb, alanr, alexander, alvin, anielsen, anton, apiemont, ari.tilli, ask, astrachan, brianwitt, colin.coe, coughlan, csimpson, dag, daniel.brnak, danstoner, d-bugzilla, derks, diegoliz, digimer, dijuremo, dkelson, donhoover, drewskiwooskie, drjohnson1, fabian.arrotin, fdc, fge, florian, frank, gergnz, gerrit.slomma, gholms, greg.procunier, heinzm, iainonthemove, jamesb, jjneely, joe, jordi, jv, jwest, kbsingh, k.georgiou, knweiss, kskmori, linux, luc, mark, mishu, mmahut, mmcgrath, mpoole, myamazak, ndevos, ojab, partner, pbatkowski, pep, phil, pinto.elia, rchidamb, redhat-bugzilla, rene.purcell, ricardo.arguello, rvandolson, rwheeler, scott.m.mcdermott, ssaha, stefanwiederoder, sublimino, tak, tao, toracat, troels, tru, tscherf, williama_lovaton|
|Target Milestone:||rc||Keywords:||FutureFeature, Reopened, Triaged|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-03-10 12:20:58 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Robin R. Price II 2010-04-23 12:45:28 EDT
Description of problem: DRBD refers to block devices designed as a building block to form high availability (HA) clusters. This is done by mirroring a whole block device via an assigned network. DRBD can be understood as network based raid-1. Version-Release number of selected component (if applicable): NA How reproducible: NA Steps to Reproduce: 1. 2. 3. Actual results: NA Expected results: Ability to use DRBD Additional info: Contents from http://www.drbd.org/ The Distributed Replicated Block Device (DRBD) is a software-based, shared-nothing, replicated storage solution mirroring the content of block devices (hard disks, partitions, logical volumes etc.) between servers. DRBD mirrors data * In real time. Replication occurs continuously, while applications modify the data on the device. * Transparently. The applications that store their data on the mirrored device are oblivious of the fact that the data is in fact stored on several computers. * Synchronously or asynchronously. With synchronous mirroring, a writing application is notified of write completion only after the write has been carried out on both computer systems. Asynchronous mirroring means the writing application is notified of write completion when the write has completed locally, but before the write has propagated to the peer system.
Comment 2 RHEL Product and Program Management 2010-04-23 13:57:00 EDT
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.
Comment 7 Colin Simpson 2010-04-28 09:33:50 EDT
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.
Comment 8 dijuremo 2010-04-28 15:08:54 EDT
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
Comment 9 Ray Van Dolson 2010-04-28 16:52:42 EDT
Opened SR #2017052 for this as an RFE and also will notify our TAM.
Comment 10 dijuremo 2010-04-29 13:11:12 EDT
Our people with support contracts have opened SR #2017020
Comment 11 Colin Simpson 2010-04-29 20:26:59 EDT
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.
Comment 12 Vincent S. Cojot 2010-05-03 07:27:08 EDT
Would be of much interest to us as well.
Comment 13 email@example.com 2010-05-11 09:38:36 EDT
I use DRBD quite often... Not having it as an installable option from core repos will be a pain.
Comment 14 Christopher Grello 2010-05-11 12:48:10 EDT
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
Comment 15 Kris Buytaert 2010-05-11 14:29:03 EDT
+1 for having DRBD
Comment 16 alvin 2010-05-11 14:53:26 EDT
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.
Comment 17 Mark Grennan 2010-05-11 16:30:35 EDT
+1 for DRBD. I've used it in Fedora and Gentoo. I'd love to have it in production systems here at WDTinc.
Comment 18 Greg Cockburn 2010-05-12 04:46:26 EDT
+1 for DRBD. Would save having to manage our own packages outside of Redhat.
Comment 19 Iain Miller 2010-05-12 05:07:26 EDT
+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.
Comment 20 Antonello Piemonte 2010-05-12 05:15:27 EDT
+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.
Comment 21 Frank Fejes 2010-05-12 07:49:45 EDT
+1 for DRBD. I was rather surprised to find that it was the one glaring omission from the RHEL6 Beta.
Comment 22 Colin Simpson 2010-05-12 07:59:15 EDT
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
Comment 23 Andy 2010-05-12 09:40:40 EDT
+1 currently used in production, would make maintenance much easier.
Comment 24 Brian Witt 2010-05-12 12:13:36 EDT
+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!
Comment 25 Keisuke MORI 2010-05-13 06:28:13 EDT
+1 for DRBD. We also want to use DRBD in production on RHEL.
Comment 26 Alex Strachan 2010-05-13 21:35:38 EDT
Please add DRBD into RHEL - Thanks
Comment 27 Dagan McGregor 2010-05-13 22:15:00 EDT
+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.
Comment 29 wiedernix 2010-05-17 03:21:42 EDT
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
Comment 31 Daniel Brnak 2010-05-18 10:45:28 EDT
We also use DRBD in production, please add it to RHEL6.
Comment 34 Alan Robertson 2010-05-25 16:22:11 EDT
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.
Comment 35 Dan Stoner 2010-05-26 16:24:28 EDT
+1 DRBD should be in RHEL6.
Comment 36 Jeremy West 2010-05-27 12:15:55 EDT
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
Comment 37 Ray Van Dolson 2010-05-27 12:37:44 EDT
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.
Comment 38 Colin Simpson 2010-05-27 12:52:45 EDT
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".
Comment 39 Ray Van Dolson 2010-05-27 12:54:36 EDT
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.
Comment 40 dijuremo 2010-05-27 13:00:54 EDT
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.
Comment 41 Alan Robertson 2010-05-27 13:09:48 EDT
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.
Comment 42 Jeremy West 2010-05-27 13:29:47 EDT
(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.
Comment 43 Florian Haas 2010-05-28 12:53:14 EDT
(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.
Comment 45 Ari Tilli 2010-06-18 03:16:03 EDT
+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.
Comment 46 Fabian Arrotin 2010-07-20 08:39:24 EDT
+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.
Comment 47 Alexander Lindqvist 2010-07-22 09:49:35 EDT
+1 for DRBD inclusion. We use it in production on several servers, please add it to RHEL6.
Comment 48 d. johnson 2010-08-03 08:56:48 EDT
+1 DRBD should be in RHEL6.
Comment 49 François Cami 2010-08-03 09:26:57 EDT
+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.
Comment 50 BJ Dierkes 2010-08-13 12:45:42 EDT
Logged SR #1263773 in favor of request as well.
Comment 51 adam.murphy 2010-08-25 18:49:06 EDT
+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).
Comment 52 Colin Coe 2010-11-03 21:09:01 EDT
Just logged 'Case 00371503'. +1 to DRBD for RHEL6
Comment 53 drewskiwooskie 2010-11-11 14:48:39 EST
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).
Comment 54 Aaron McSorley 2010-11-11 16:06:39 EST
DRBD in RHEL6 would be a great incentive for us to upgrade, unlike dm-replicator, DRBD is documented, stable and, proven for replicating data.
Comment 55 Sayan Saha 2010-11-11 17:52:47 EST
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.
Comment 56 RHEL Product and Program Management 2010-11-11 17:54:39 EST
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Comment 58 Colin Simpson 2010-11-12 05:21:55 EST
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.
Comment 59 dijuremo 2010-11-12 06:55:39 EST
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...
Comment 60 Alan Robertson 2010-11-13 12:42:29 EST
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.
Comment 61 Alan Robertson 2010-11-13 12:46:33 EST
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.
Comment 62 Luc de Louw 2010-11-13 17:07:40 EST
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?
Comment 63 Colin Coe 2010-11-23 00:53:47 EST
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 <firstname.lastname@example.org> 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 ---
Comment 64 Gris Ge 2010-11-23 01:32:55 EST
(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.
Comment 66 Florian Haas 2010-11-23 06:02:09 EST
Could someone please share the URL of the public git tree that carries the dm-replicator patches?
Comment 67 Colin Coe 2010-11-23 06:12:41 EST
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
Comment 68 Heinz Mauelshagen 2010-11-23 08:55:55 EST
(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
Comment 69 Colin Simpson 2010-11-23 09:57:58 EST
> 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!
Comment 71 Colin Coe 2010-11-23 18:45:08 EST
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
Comment 72 Heinz Mauelshagen 2010-11-24 05:25:00 EST
(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
Comment 73 Heinz Mauelshagen 2010-11-24 05:27:59 EST
Created attachment 462593 [details] dm-replicator targets usage description, table syntax and configuration examples
Comment 74 William Lovaton 2010-11-26 00:21:16 EST
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.
Comment 75 LINBIT 2010-11-26 03:33:51 EST
(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.
Comment 76 William Lovaton 2010-11-26 15:30:20 EST
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.
Comment 77 LINBIT 2010-11-26 15:37:50 EST
(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.
Comment 78 Phil Perry 2010-12-05 04:36:07 EST
ELRepo now has DRBD packages available for RHEL6 (and RHEL5) here: http://elrepo.org http://elrepo.org/linux/elrepo/el6/ Hope that helps.
Comment 79 Colin Simpson 2010-12-05 13:17:02 EST
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.
Comment 80 devzero2000 2011-01-12 09:15:41 EST
I also agree with the comment 79. BTW, i also have open the SR 00401653 to the support.
Comment 82 William Lovaton 2011-01-31 11:18:14 EST
(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.
Comment 83 Phil Perry 2011-01-31 13:47:38 EST
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.
Comment 84 LINBIT 2011-02-24 03:35:51 EST
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
Comment 85 Greg Procunier 2011-03-09 14:26:49 EST
+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.
Comment 86 Sayan Saha 2011-03-10 12:20:58 EST
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
Comment 87 dijuremo 2011-03-10 12:31:50 EST
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.
Comment 88 Greg Procunier 2011-03-10 12:57:21 EST
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?
Comment 89 Fabian Arrotin 2011-03-10 13:34:42 EST
(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
Comment 90 Phil Perry 2011-03-10 14:20:02 EST
[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.
Comment 91 dijuremo 2011-03-10 14:43:47 EST
(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.
Comment 92 Florian Haas 2011-03-10 14:48:15 EST
(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.
Comment 93 dijuremo 2011-03-10 15:08:58 EST
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).
Comment 94 Greg Procunier 2011-03-10 15:13:03 EST
(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.
Comment 95 Dag Wieers 2011-03-10 16:20:22 EST
"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.
Comment 96 Robert Scheck 2011-06-22 15:39:15 EDT
(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: 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: *** [/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.
Comment 97 digimer 2011-06-22 15:45:44 EDT
(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.
Comment 98 Phil Perry 2011-06-22 17:45:25 EDT
(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.
Comment 99 Robert Scheck 2011-06-22 18:16:43 EDT
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...
Comment 100 Jeff Vier 2011-06-23 15:08:42 EDT
The exclusion of DRDB is the only reason we (Mozilla Services) have Ubuntu in our otherwise pure-RHEL environment.
Comment 101 Rene Jr Purcell 2011-07-12 15:35:48 EDT
+1 same as comment #100 here... The only reason we have and still install ubuntu is the lack of support for drbd with RHEL!
Comment 102 Alasdair Kergon 2011-07-12 16:07:31 EDT
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.
Comment 103 Gerrit Slomma 2011-12-06 05:22:43 EST
That doesn't say why you are not shipping drbd as a rpm for RHEL6.
Comment 104 digimer 2011-12-06 09:47:31 EST
(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.