Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 01/24/2011 04:08 PM, Nick Couchman wrote: > >> Hi, >> >> what level of asynchrony do you need? And (out of curiosity) why? >> >> Cheers, >> Felix > > I'll tell you what I'm trying to do, and maybe that will answer both > questions. I'm trying to roll my own disk-based backup solution. > Basically, I'll have a Solaris-based system using ZFS to serve volumes > out to the systems that I want to back up over iSCSI. This way I can > use the ZFS snapshot management capabilities to snapshot the volumes at > various points in time, and use the clone capability to represent that > volume somewhere in the event that I need a restore done. Also, because > ZFS supports remote send/receive out of the box, it gives me a way to > send those backups off-site very easily for DR purposes. > > On the servers I'm trying to back up, I need some form of asynchronous > replication. These systems will connect over iSCSI to the ZFS system in > order to replicate the volumes. The reason for the asynchronous > requirements is because I need to make sure that the replication of the > data to the secondary (iSCSI ZFS) disk does not block I/O for the > primary volume - I don't want the fact that I'm replicating the data to > interfere with performance of the volume. A second concern is that I > need to make sure that all I/O operations are actually being done to the > primary storage on each of those systems and not to the secondary iSCSI > volume, again, mostly for performance reasons. Finally, I want to be > able to shut down the ZFS backup system and the iSCSI links without > worrying about the system going into any kind of degraded state - it > needs to be able to pick the synchronization right back up when it comes > back up. > > The built-in Linux RAID1 driver offers the ability to mark a volume in a > RAID1 set as "write mostly", which takes care of most of the concern for > having I/O operations occur on the primary device, but does not > necessarily insure that write operations will not be blocked by Linux > waiting on them to occur on both volumes. Ah, I see. So you want to retain Read-Only access even when iSCSI is disconnected? That's problematic, as DRBD will probably detect possible split-brains and refuse to resume synchronization. You can of course discard your local backing device upon each reconnect, but that will trigger (I think) a full sync from the iSCSI device. You may want to consider hosting the local copy on an LV instead, make a snapshot when your link goes down and mount the snapshot read-only instead (bypassing DRBD at those times). I'm not sure wether either idea is quite clean, but something along those lines should be doable. Cheers, Felix