Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, 2004-07-02 at 14:15, Stefan Andersson wrote: > Hello, > > I'm in the process of building a fault tolerant system, and > have looked at drbd and the recent GFS release by redhat. > > What I ideally would like to have is > > 1. one filesystem shared among a number of nodes, with write > access at all nodes. "shared storage" (shared scsi) would > introduce a single point of failure, so I'm thinking more > in the lines of storage replication, i.e. what drbd is doing. > There are many shared storage solutions that do not introduce a SPOF. In particular the Fibre-Channel array servers I'm familiar with have duplicate everything. If a used solution works for you I know the DEC HSZ70 and HSZ80 solutions are SCSI based and don't have any SPOFs. http://netilium.org/hinv/hsz70/ I'm sure there are other more cost effective solutions as well. The real problem is the lock server. I know in OpenGFS it is a SPOF still. I don't know enough about GFS to know if they have solved that issue or not. > 2. arbitrary node(s) may fail, and be resynchronized after repair > > 3. good performance > > Now, as I understand drbd works only in a primary/secondary > configuration, where all writes at paul/primary is replicated to > silas/secondary, and their roles can switch with heartbeat software. > > The two node configuration may be sufficient for our needs, but it > would be a nice bonus to be able to mount the file system from three, > four nodes. Will perhaps GNBD (gfs network block device) solve this > instead of using drbd? (but, as far as I can tell, it will only have > one primary and is mainly for load balancing and not fault tolerance) > > Would it be possible to use GFS on top of DRBD to get write support at > both nodes? I.e. does drbd replicate writes at silas to paul? > > Another acceptable solution would be to use for example ext3 on the drbd > replicated block device. Now, I've understood that it is not adviced to mount > the filesystems at the secondary node because the FS will change under > its feed because it is not aware of another host writing. My question > is, would it be possible to mount the filesystem readonly at silas? > This would ease the burden of backup on the primary node as they instead > could be done on the secondary node. I'm not a DRBD expert, but I do know snapshots and advanced backup strategies. Maybe you could use DRBD to create "snapshots"? They are often used to provide read-only copies of volumes for backup/testing/data mining/load sharing. In particular if backups are your only issue, maybe you could do something like the below: 1) Quiese application on primary 2) Flush filesystem cache to disk and stop filesystem i/o 3) stop drbd replication from master to secondary. 4) re-enable filesystem i/o 5) Allow application to restart 6) On secondary mount drbd volume read-only 7) On secondary perform backup 8) On secondary unmount drbd volume 9) restart drbd replication Comments: step 1) This is commonly required with snapshots, so it should be fairly easy. Typically databases etc. have way to signal them to prepare for snapshot. step 2) I know XFS supports the filesystem i/o freeze/unfreeze concept form user-space. I'm not sure about others. step 3) I'm not a drbd expert, but I assume this is easy step 4) Same as 2) step 5) Same as 1) step 6) Same as 3) step 7) Trivial step 8) Trivial step 9) With drbd 0.7, only the dirty blocks should need to be copied between the servers, so the load should not be too bad. > > Thoughts? > > Regards, > Stefan HTH Greg -- Greg Freemyer