On Sep 26, 2012, at 10:54 AM, Edward Ned Harvey 
<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.

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 

zfs-discuss mailing list
  • [zfs-discuss] vm ... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
    • Re: [zfs-dis... Freddie Cash
    • Re: [zfs-dis... Tim Cook
    • Re: [zfs-dis... Richard Elling
      • Re: [zfs... Jim Klimov
        • Re: ... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
          • ... Jim Klimov
          • ... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
            • ... Jim Klimov
              • ... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
                • ... Jim Klimov
                • ... Dan Swartzendruber
                • ... Dan Swartzendruber
                • ... Richard Elling

Reply via email to