Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Doug Knight wrote: > > Thanks Gordan, > I re-read my email after your response, and realized high > availability is another big priority (hence our using > heartbeat). My thought was that an initial drive failure in > the RAID array should be handled within the current primary > system, with DRBD/heartbeat fail-over as the next tier of > failure recovery. Which brings up another question; how does > DRBD handle RAID set failures? Obviously, a mirrored drive's > failure would be transparent, but what about in the case of a > striped set? Is there a way to determine that a striped set > has failed and is in rebuild, and trigger DRBD to fail over > to the secondary system where no rebuild is taking place? > Maybe a Linux-HA question? Doug, Your strategy for tiered availability is a sound one, nobody wants to fail-over to a secondary node unless it's total storage failure or a managed rolling update after-hours. The process of node fail-over isn't completely seamless and there is a small window where transactions in a DB can be lost. As far as how DRBD handles a failure in the backing device, well DRBD works if the backing device is available and if it isn't, well it stops working, which will cause heartbeat to fail-over to the secondary node fencing this node. It is up to you as the administrator to keep all hardware and software RAID arrays healthy. Use monitoring tools to alert you when disks fail or are about to fail, have a hot-spare, use the correct RAID type for the application, etc. Using RAID10 for logs (and drbd meta-data) and RAID50 for data should work well for you, if you can't do the RAID50 and keep logs and data together then I would go for the full RAID10. I have my DBs on RAID10 over iSCSI, which should have similar performance characteristics as DRBD over prot C and the performance is perfectly acceptable for out applications (general ledger, loan management, sharepoint, data warehousing), 50-100 users, but if you are doing high-volume transactions (back-end to web application farm) then you may need more specialized hardware. -Ross On Tue, 2008-03-04 at 13:44 +0000, drbd at bobich.net wrote: > On Tue, 4 Mar 2008, Doug Knight wrote: > > > Performance is a first priority, followed by > > disk space, so I've been looking at RAID 10 and RAID 50 as possible > > setups. We're planning on using 15K drives, which limits each physical > > drive to 146GB, which is why I need the striping. The controllers will > > have battery backed up cache, which from the postgres groups I've been > > told will give us a significant performance boost. > [...] > > The system we're looking at is the Dell PowerEdge 6800, most > > likely with a non-DRBD mirrored system drive, plus a DRBD replicated > > RAID 10 or 50 array supporting around 500GB. > > If performance is your 1st priority, then do you really need more than > RAID 01? Have each machine with a RAID0 stripe (apart from possibly the > system/root partition), and then mirror it using DRBD (RAID1). RAID 51 > seems a bit OTT if you want performance first, and you'll still get > mirroring from DRBD. > > Just make sure that your bus and controller can keep up with > the throughput of so many drives. The PCI(X/e/...) bus will only handle so > much bandwidth, and you are unlikely to see more than 80% of it even under > optimal conditions. If your drives between them can sustainedly (or > even just with buffer->controller bursts - new drives have big > caches!) churn out more than that, then you might as well get > slower/bigger/cheaper (pick any two ;-) drives. ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3971 bytes Desc: not available URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20080304/3e78977c/attachment.bin>