| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
After spending some time stress testing the opengfs and opendlm setup that I had previously posted about we came to realize that the software just isn't stable enough for our needs. We encountered frequent kernel panics under what I would consider 'normal' situations.. such as attempting to unmount the filesystem on one node and then remount it. It was difficult to establish consistency on this, but the fact that it happens at all was enough to make me leery of using it in production. Also, not sure if I mentioned this before, but if you kill dlmdu on one of the nodes you CANNOT remount the filesystem on that node after restarting dlmdu. In fact you have to restart BOTH nodes before they can both be mounted simultaneously again. These issues and the fact that most likely the opengfs developers will stop working on the existing opengfs code base in favor of the redhat code base made me take a closer look at GFS, especially after Ben pointed out that Redhat's 6.0 GFS does not require all 3 nodes to have access to the shared storage. Getting things up and running from the source RPMS available on redhat's site was a little tough and really would have been impossible without reading through the redhat-cluster mailing list for other users who are using non-redhat branded clones of RHEL 3 (We are running White Box). After a day or two of sorting out the RPM build process I finally got things setup for a test environment and thus far I've been very impressed with both the stability and speed of the software. Just to have some kind of reference point I established a set of benchmarks between opengfs, GFS, NFS, and local storage. The part that surprised me was that GFS is actually FASTER than a filesystem mounted LOCALLY via ext3(!) The method of data collection was not very scientific. I only ran a few trials and always used the same software for my tests (tiobench). Direct local SCSI disk I/O (ext3): --------------------------------- write avg: 25.119 MB/s write latency(max): 47.387ms read avg: 926.569 MB/s read latency(max): 0.118ms Open GFS + OpenDLM (node 1, both nodes mounted): --------------------------------- write avg: 21.315 MB/s write latency(max): 118.683ms read avg: 433.675 MB/s read latency(max): 0.179ms Open GFS + OpenDLM (node 2, both nodes mounted): --------------------------------- write avg: 18.963 MB/s write latency(max): 285.325ms read avg: 684.217 MB/s read latency(max): 0.090ms (For Redhat GFS, a third machine NOT connected to shared storage is required as a lock server) Redhat GFS 6.0 (RLM External, 2 mounted nodes) -------------------------------- write avg: 42.966 MB/s write latency(max): 171.008 ms read avg: 921.468 MB/s read latency(max): 0.106 ms NFS (only 1 node mounted): --------------------------------- write avg: 0.270 MB/s (!) write latency(max): 10558.377ms (!!) read avg: 495.731 MB/s read latency(max): 0.152ms We all know the performance issues with nfs.. but _WOW_.. I've never actually run numbers on it before. Just to confirm the speed when writes are occurring from both nodes I performed a restore from tape on one server and ran tiobench again on the other node. performance drops as you would expect but not bad... avg. writes were still around 20 MB/s. Thus far stability seems to be excellent, and as an added bonus the init scripts provided by redhat seem to start things up cleanly (all this after I spent half the previous week writing a perl script to control opengfs/opendlm..). I'll post more updates if I run into trouble with GFS. -Marc Swanson- ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Opengfs-users mailing list Opengfs-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/opengfs-users