[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] General GFS Advice?

D Canfield wrote:

I'm just looking for a bit of general advice about GFS... We're basically just looking to use it as a SAN-based replacement for NFS. We've got a handful of servers that need constant read/write access to our users' home directories (Samba PDC/BDC, web server, network terminal servers, etc.), and we thought GFS might be a good replacement from a performance and security standpoint, let alone removing the SPOF of our main NFS/file server.

That should be OK, IMO.
We're still using GFS 5.2 (I think) on our small webserver-farm and it's amazing how much performance you can beat out of tualatin Tualatin-CPUs and an aging hd-array.
We're looking to move it to GFS6.1 on newer hardware.

Another place we're thinking of using it is underneath our mail servers, so that as we grow, SMTP deliveries (and virus scanning) can happen on one machine while IMAP/POP connections can be served through another.

That probably depends on your MTA.
You should, IMO, not deploy it without some real-world test-results.
GFS+small-files <=> possible nightmare.

Unfortunately, even at academic prices, Red Hat wants more per single GFS node than I'm paying for twenty AS licenses, so I've been heading down this road by building from the SRPMS. I mostly have a 2-node test cluster built under RHEL4, but a number of things have me a little bit hesitant to move forward, so I'm wondering if some folks can offer some advice. For starters, is my intended use even appropriate for GFS? It does seem as though I'm looking to put an awful lot of overhead (with the cluster management suite) onto these boxes just to eliminate a SPOF.

Indeed. And unless the storage itself is mirrored, that's still a SPOF ;-)
But on the over hand, it enables some things NFS can't do.

Another concern is that this list seems to have a lot more questions posted than answers. Are folks running into situations where filesystems are hopelessly corrupted or that they've been unable to recover from? That's the impression I feel like I'm getting, but I suppose a newbie to Linux in general could get the same impression from reading the fedora lists out of context. The last thing I want to do is put something into production and then have unexplained fencing occurences or filesystem errors.

The support-contract should deal with these.
I suppose this list is not a replacement for a support-contract - merely a feedback-list for the developers.

Finally, Red Hat sales is laying it on pretty heavy that the reason the GFS pricing is so high is because it's nearly impossible to install it yourself. That was particularly true before GFS landed in Fedora. Now the claim is just that it's very difficult to manage without a support contract. Is this just marketing, or does GFS really turn out to be a nightmare to maintain?

From my (limited) exposure - I haven't done too much with it in the sense of experimenting and tinkering - I'd say that it requires an awful lot of knowledge to really "master" it. One may get it to work with some tutorial and the mailing-list, but the technology behind is much more complex than your average NFS-setup. You should ask yourself: "In case of an alert @ 3am - can I deliver a solution?".
If the answer is no.....

Having a test-setup that is similar or (equal) to the production-system should also help tremendously in avoiding any silly "mishaps"

Any insights people could provide would be appreciated.

I think GFS does have its merrits (we really need to make some test with 6.1 next year), but only in cases where the number of concurrent (write) accesses in the same directory is small. Otherwhise, the overhead (at least by 6.0) is no longer worth the whole effort.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]