Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Lars Ellenberg wrote: > The difficulties lie within the princible of a cluster file system, > not any specific implementation of it. > as long as we have not implemented a form of "write-quorum", which would > block any further writes, and not complete any pending writes until > otherwise directed (by re-establishing or reducing the write-quorum), if > you actively modify DRBD on more than one node, you run into diverging > data sets whenever you have any glitch in the replication communication. I'm just trying to understand, since i'm still new to clustered things :-) But the process of locking files is done by the cluster fs, right? Or not? This is why (as far as i understood) primary/primary requires a cluster fs. > ok, as long as we only support 2 nodes, "write quorum" is a bit bold. > but still, it is the same problem. > > there are several possible workarounds right now. > * never ever have a network problem when both are primary. > ok, that won't fly. I'll probably use two ethernet card with channel bonding, connected with just a cable (no switch) > * configure an "outdate-peer-handler", and then, > instead of just "outdating" the peer, really "fence" it > (power it off/reboot) in case of communication loss. Ok...it's also the behavior i'd like > * use a DRBD cluster as your SAN, then have your cluster nodes > on e.g. iSCSI clients. > drive your cluster file system on top of that. So...drbd --> iscsi and then every client access to it... Unluckily now i have just 2 servers to use...so i have to implement every service on the same machines i use as "san". > solution: > support us and push towards the implementation of this "write-quorum" thing. I's sure like to do it, but i'm not a programmer...if i can do something else to help ypu, for sure, i'll be glad to help. Sure i can test things once i finished this thing. Pier