If you're willing to try FreeBSD, there's HAST (aka high availability storage) for this very purpose.
You use hast to create mirror pairs using 1 disk from each box, thus creating /dev/hast/* nodes. Then you use those to create the zpool one the 'primary' box. All writes to the pool on the primary box are mirrored over the network to the secondary box. When the primary box goes down, the secondary imports the pool and carries on. When the primary box comes online, it syncs the data back from the secondary, and then either takes over as primary or becomes the new secondary. On Sep 26, 2012 10:54 AM, "Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)" < opensolarisisdeadlongliveopensola...@nedharvey.com> wrote: > Here's another one.**** > > ** ** > > Two identical servers are sitting side by side. They could be connected > to each other via anything (presently using crossover ethernet cable.) And > obviously they both connect to the regular LAN. You want to serve VM's > from at least one of them, and even if the VM's aren't fault tolerant, you > want at least the storage to be live synced. The first obvious thing to > do is simply cron a zfs send | zfs receive at a very frequent interval. But > there are a lot of downsides to that - besides the fact that you have to > settle for some granularity, you also have a script on one system that will > clobber the other system. So in the event of a failure, you might > promote the backup into production, and you have to be careful not to let > it get clobbered when the main server comes up again.**** > > ** ** > > I like much better, the idea of using a zfs mirror between the two > systems. Even if it comes with a performance penalty, as a result of > bottlenecking the storage onto Ethernet. But there are several ways to > possibly do that, and I'm wondering which will be best.**** > > ** ** > > Option 1: Each system creates a big zpool of the local storage. Then, > create a zvol within the zpool, and export it iscsi to the other system. Now > both systems can see a local zvol, and a remote zvol, which it can use to > create a zpool mirror. The reasons I don't like this idea are because > it's a zpool within a zpool, including the double-checksumming and > everything. But the double-checksumming isn't such a concern to me - I'm > mostly afraid some horrible performance or reliability problem might be > resultant. Naturally, you would only zpool import the nested zpool on > one system. The other system would basically just ignore it. But in the > event of a primary failure, you could force import the nested zpool on > the secondary system.**** > > ** ** > > Option 2: At present, both systems are using local mirroring ,3 mirror > pairs of 6 disks. I could break these mirrors, and export one side over > to the other system... And vice versa. So neither server will be doing > local mirroring; they will both be mirroring across iscsi to targets on > the other host. Once again, each zpool will only be imported on one > host, but in the event of a failure, you could force import it on the other > host.**** > > ** ** > > Can anybody think of a reason why Option 2 would be stupid, or can you > think of a better solution?**** > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
