Jonathan Tripathy put forth on 1/12/2011 8:58 AM: >> Major point is that GlusterFS is NOT another file system. GlusterFS uses a >> disk based backend and relies heavily on the underlying filesystem extended >> attributes for handling which file is more recent on one brick over another >> when performing a self heal after a split brain condition.
> Maybe this isn't really too much of an issue in mail delivery, as find > aren’t > usually modified, are they? > > I may split up the servers though to reduce split brain. As if one glusterfs > server goes down, no mail server would be able to access it GlusterFS is a distributed filesystem, not a clustered filesystem. There is a huge difference WRT acceptable uses. Distributed filesystems are fine for massive storage needs of relatively static files, not for serious transaction oriented workloads. Cluster filesystems are much more suited to the latter, and will handle the former without issue. Likely, the best solution for the OP, from both a performance and simplicity of management standpoint, is neither of these, but NFS, either a _good quality_ NFS appliance such as a NetApp et al, or if that price is too steep, a purpose built Linux server with kernel mode NFS server. If you actually run an environment where total redundancy is a requirement, then you'd already know all of these things and not be asking here. Thus, you're a small environment but you _think_ you need an exotic fail safe architecture like a big environment, which very few sites actually _NEED_ including some of the big ones. Ask Wietse about the architecture of the HA Postfix cluster that serves list mailing list. Then ask him how much downtime the list has experienced in the last 5 years due to host or storage problems (vs network). The answers may likely be both surprising and informative. -- Stan
