GlusterFS on a two-node setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 5/20/12 5:55 PM, Ramon Diaz-Uriarte wrote:
> I might have to look at DRBD more carefully, but I do not think it 
> fits my needs: I need both nodes to be working (and thus doing I/O) at 
> the same time. These are basically number crunching nodes and data 
> needs to be accessible from both nodes (e.g., some jobs will use MPI 
> over the CPUs/cores of both nodes ---assuming both nodes are up, of 
> course ;-).
DRBD will let you do read/write on both nodes, but it requires a 
clustered filesystem such as GFS2 or OCFS2 on top of it. You are also 
limited to a max of two nodes.
>
> But from the docs and the mailing list I get the impression that
> replication has severe performance penalties when writing and some
> penalties when reading. And with a two-node setup, it is unclear to me
> that, even with replication, if one node fails, gluster will continue to
> work (i.e., the other node will continue to work). I've not been able to
> find what is the recommended procedure to continue working, with
> replicated volumes, when one of the two nodes fails. So that is why I am
> wondering what would replication really give me in this case.

Gluster doing replication requires writes to hit both nodes, which may 
slow you down a lot if there is significant latency between the two. I 
run a replicated configuration, and have had nodes down for extended 
periods - Gluster will repair the missing data from the brick on the 
failed node during self-heal, so it is transparent. I've never had to 
shut down applications in order for gluster to fix something first.

David


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux