Name-space volume is only a cache. If lost, it will automatically rebuild.
How ever without AFR, NS-cache volume becomes a single point of failure.
My recommendation is to not put ns-cache on AFR for now. 2.0 releases
addresses this issue using "distribute".
If you starting fresh, I recommend "distribute" (in 2.0) over
"Unify".
Distribute is faster than Unify and has no centralized name space
cache requirement. 2.0.0rc2 is coming next week. It is relatively
more stable than 1.3.x.
"AFR" has been renamed to "replicate" in 2.0. It has atomic
write
support by default, which takes some performance hit. There are some
config options to disable atomic write support and make it work like
1.3's AFR. We have addressed the atomic write performance issue in rc2
release to an extent. We will continue to put a lot of priority behind
replication feature moving forward.
--
Anand Babu Periasamy
GPG Key ID: 0x62E15A31
Blog [http://ab.multics.org]
GlusterFS [http://www.gluster.org]
The GNU Operating System [http://www.gnu.org]
Lior Goikhburg wrote:> Hello
>
> Got a production environment with 4 servers: 2 pairs of AFR'ed servers
> and Unify between the pairs (raid 1+0 functionality).
> Does it make sense to put the Unify's NS volume on an AFR cluster, or
> there is no need for any redundancy for NS ?
>
> Thanks a lot in advance, for taking time to answer.
> Lior.