> > StorageConcepts wrote: > > Hello list, > > there has been some discusstions about how to replicate ZFS. The only way > to do it synchronously (at least on OpenSolaris) is Sun AVS (SNDR). > > The "typical" Sun AVS setup looks like this: > > - Backend Disks are replicated with AVS > - ZPOOL is created on those disks > > In case you ned to switch, you disable the avs and import the pool in the > standby side.
You want to place SNDR into logging mode, and not disable AVS (SNDR), so that future re-synchronizations are possible. With ZFS storage pools often being >100GB, even TBs, one wants to avoid replicating unchanged data more than once, something that would be required if the replicas were disabled, then (re-)enabled. This involves importing the pool, created the dev nodes which all takes time > etc. Importing the pool should be fast, especially if the pool was imported previously. See references to /*etc*/*zfs*/zpool.cache, as the means to speed up the import of zpools. One should do this at least once, before putting any replication solution into production. Not sure where the "created the dev nodes" or "... which all takes time...", issues come from? > Also the performance of the pool is degraded, because by the required use > of consistency groups, a lot of parallellism is elimited (or isn't it ?). > Pool performance is degraded due to the cost of performing synchronous, replicated write I/Os, which are always slower than local write I/Os to disk. Consistency groups should only impact the performance of asynchronous replication. > > While this works for ZFS and ZVOL, for bigger setups, the failover tim may > be an issue (for iSCSI you have to be below 2 minutes to avoid tweaks I > believe). > What type of testing are you basing this statement on, and what do you mean by tweaks? - Paul > > So I though about why not do it the other way around, replicating ZVOLS. > > This has several advantages: > 1) The target pool is imported > 2) On failover, only the export of the zvol as iSCSI needs to be done > 3) The target zvol cache may be hot (at least for writes) > 4) The write order sonsistency needs to be maintained for one zvol only, > which allows for parlallism below the zvol (at the disk level) > 5) Pool integrity would not be possibly damaged if replication direction > fails, we can go back to tthe latest local pool snapshots. > > It also has disadvantages: > > 1) Probably more replication pairs (some hundred zvol environments) > 2) Snapshots are not replicated > 3) not suitable for ZFS filesystems (only zvol) >
_______________________________________________ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
