muffaleta at gmail
Sep 14, 2009, 4:34 PM
Post #2 of 3
(648 views)
Permalink
|
From my understanding the internal metadata write penalty in your case
is caused by seeks between the data and metadata parts of your disk.
You may experiment with metadata on a different spindle, as this will
allow you to dispatch data and metadata io in parallel.
Most people run their DRBD backing store on top of raid--in this case,
either a SAS or SATA (I'm running on FC disks). A simple 3 ware should
have BBU, which should allow you to enable write-back caching.
Good luck!
cc
On Mon, Sep 14, 2009 at 3:48 PM, Christian Iversen
<chrivers [at] iversen-net> wrote:
> Hey DRBD-list
>
> I'm trying to build a reasonably performant DRBD-minicluster (2 machines
> with heartbeat). I've got the basic setup working fine, with 2 largely
> identical servers each running a Seagate 7200.ES 500GB disk.
>
> This is exported as a HA-NFS on top of the 500GB DRBD volume with internal
> metadata. It's used in our production system, and we're generally very happy
> with the result (failover, etc), except the performance leaves a bit to be
> desired.
>
> I have a few questions:
>
> 1) It really seems internal metadata is a bad idea, since it eats 2 extra
> seeks per write. Is this always true, or can DRBD sometimes buffer these
> metadata-writes to minimize impact?
>
> 2) Suppose write latency (related to question #1) is our biggest concern. We
> are currently using protocol C. Will protocol A or B be vastly different? I
> know there's no substitute for a proper benchmarking, but we are a little
> wary of "just testing something" on our production system. Does anybody have
> experience with this they would like to share?
>
> 3) Suppose the write latency really is the biggest problem we're facing
> (we're still investigating the situation). As far as I can tell, a
> battery-backed storage controller is the way to go, since this will allow
> persistent stores to complete right away. However, this is for a normal
> server, not DRBD. How does DRBD affect this situation? Will such a
> controller even be useful at all?
>
> 4) If it will be useful, can anybody recommend a good SATA battery backed
> controller?
>
>
> I look forward to hearing any comments you might have.
>
> P.S: I should note that we are not willing to sacrifice data integrity for
> performance. If it seems that way from my comments about protocol A/B/C, let
> me assure you that we simply want to learn about the various bottlenecks in
> the system.
>
> --
> Med venlig hilsen
> Christian Iversen
> _______________________________________________
> drbd-user mailing list
> drbd-user [at] lists
> http://lists.linbit.com/mailman/listinfo/drbd-user
>
--
Chris Chen <muffaleta [at] gmail>
"The fact that yours is better than anyone else's
is not a guarantee that it's any good."
-- Seen on a wall
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user
|
signature.asc
