On Sep 26, 2012, at 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 > zpoolwithin a zpool, including the double-checksumming and everything. But > the double-checksummingisn'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. This was described by Thorsten a few years ago. http://www.osdevcon.org/2009/slides/high_availability_with_minimal_cluster_torsten_frueauf.pdf IMHO, the issues are operational: troubleshooting could be very challenging. > > 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? If they are close enough for "crossover cable" where the cable is UTP, then they are close enough for SAS. -- richard -- illumos Day & ZFS Day, Oct 1-2, 2012 San Fransisco www.zfsday.com richard.ell...@richardelling.com +1-760-896-4422
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
