Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, Jan 24, 2011 at 08:08:09AM -0700, 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. Not that I'm advocating against DRBD usually, but just make sure you do not overlook the parts about write-intent bitmap and write-behind mode on the mdadm man page. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed