Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hello Brent, with drbd stored data exists replicated (the 'r' in drbd is for replicated) in all the nodes of the cluster and that is arguably the central aim of drbd: to have data consistently replicated on each node. in typical clustered filesystems scenarios you'dd have many nodes participating in the cluster but only a single storage. Although there might be ways to add redundancy to the "single storage" approach, the design in itself, contains what is known as a single point of failure: if the shared storage fails or crashes, then none of the nodes has access to data. With drbd data is replicated on all nodes (typicaly 2 nodes); there is no single point of failure. If storage at node A fails, node B can continue operating. This is commonly used for redundancy/failover scenarios but the approach with drbd is independent of what u use it for. Also with drbd, even if the network fails, the nodes can still operate on the data. This is, generaly speaking, also not valid for the single-shared-storage approach. How you recover from that situation (called split-brain) is another matter. Some discussion can be raised around this. But I think this is the main idea. You need to focus on exactly what you application requirements really are, and from there, determine what is the best solution. Joao On Thu, 2010-05-20 at 09:53 +0200, Brent Clark wrote: > Hiya > > I hoping someone would be kind enough to help me understand this or > least provide a follow back answer. > > Someone asked me yestersday "What is the added advantage of using DRBD > with a clustered filesystem (e.g. OCFS), as opposed to using just a > clustered filesystem" . I didnt have the answer. > > Would someone be so kind as to answer this for me. > > Kind Regards > Brent Clark > > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user