Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a website that is tracking towards 50 million hits per day average, and within the next 3 months should be over 100 million hits per day. We are trying to use GlusterFS v 3.0.0 (with latest patches as of 1-17-2010)

Currently, we have just upgraded to a load balancer environment that has 3 physical hosts with 6 Xen-Server 5.5u1 VM's (2 on each host) to serve webpage traffic. Each machine has 6 Raid-6 local storage drives (7200RPM-SATA). The old machine we came from had 1 mirrored SAS 10k drive.

We also set up GlusterFS currently with 3 bricks, one on each host, and it is serving the 6 VM's as clients. In testing, everything seemed fine. However when we went to production, it seemed that there just wasn't enough I/O's available to serve traffic even upwards of 15M hits. Weeks prior, our old server was able to handle traffic, maxed out, at 20M.

Is there any recommended configurations for such an application, or things to be aware of that isn't apparent with their documentation at gluster.org for a site our size?

share|improve this question

4 Answers 4

RAID-6 of 6x7.2krpm drives with no write cache (?) is going to have terrible write performance, so terrible that it'll probably bog the disks down enough to really impact read performance too if your app has a healthy mix. I mean realistically you're looking at like 250 random iops in an 80/20 read/write split out of that array. If you're doing several hundred http requests per second then something as trivial as the apache access log is going to bog that down like a DoS attack.

If you can, redo those as raid10. It'll cost you some raw space but make a huge impact on i/o performance. And if you can get battery backed write cache on the raid cards its makes a very large difference.

I'm not familiar with glusterfs in particular, but all distributed filesystems tend to have the same basic problem, network-latency + complex locking = poor performance, especially on small files and especially on substantial-write workloads.

Slow disk i/o and a slow filesystem, this cluster design simply does not fit the workload. Is it too late to return the servers or at least the disk subsystems? If this is the primary platform of a substantial-revenue company you really should engage a professional.

share|improve this answer

What medium are you moving your GlusterFS traffic over? If it's ethernet, you configuration will be severely limited due to the overheads of TCP/IP. GlusterFS is not the most efficient there. Where it really shines is over RDMA. You can achieve this with either Infiniband or 10GigE.

I'm also a bit unclear as to why you decided to put 2 virtual hosts on each physical host if they're all doing the same duties. Why not just run them on the bare metal and avoid the overhead?

share|improve this answer

What version of GlusterFs are you using? GlusterFS 3.0.0 is a major release and has many improvements including increase in small file performance.

There are many performance translators in GlusterFS that can be tuned for various workloads. For example, for increasing read performance we have read-ahead translator and for write performance we have write-behind translator. io-cache is another performance translator that can be used for caching.

What type of setup is yours? Are you using replicate or distribute or both? What is your network backend? Have you benchmarked network/disk IO between the old and the new servers to eliminate bottlenecks?

If you can share your volume files with us, we can help you tune your configuration files for optimum performance for your workloads.

Just an FYI, we offer 30 day free trial support subscription[1] where you can get your queries answered quickly and in-depth.

Cheers, Sachi

[1] http://www.gluster.com/products/trial.php

share|improve this answer

Without more insight into your setup (e.g. is your website static or dynamic? Do database transactions take place on the servers using the same storage subsystem?) but RAID 6 is generally a bad choice for write performance, never mind when you introduce even more complexity through gluster. You potentially have two sets of write stripe translation going on, one at gluster level and one at the controller level. Then you have two parity calculations which slow things down and cause I/O blocking unless you have a large write cache and periods of low I/O activity.

I'd recommend you switch to RAID 10, and back this with either fibre channel or multiple bonded GigE links.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.
{"cc_re__cc_re__cc_by_sa_3_0": ["                  <li><a href=\"//area51.stackexchange.com\" title=\"proposing new sites in the Stack Exchange network\">Area 51</a></li>\r\n                        <li><a href=\"//careers.stackoverflow.com\">Stack Overflow Careers</a></li>\r\n                    \r\n                </ol>\r\n            </td>\r\n    </tr>\r\n</table>\r\n                </div>\r\n            </div>\r\n\r\n            <div id=\"copyright\">\r\n                site design / logo &#169; 2015 stack exchange inc; user contributions licensed under <a href=\"http://creativecommons.org/licenses/by-sa/3.0/\" rel=\"license\">cc by-sa 3.0</a> \r\n                with <a href=\"http://blog.stackoverflow.com/2009/06/attribution-required/\" rel=\"license\">attribution required</a>\r\n            </div>\r\n            <div id=\"svnrev\">\r\n                rev 2015.2.26.2347\r\n            </div>\r\n            \r\n        </div>\r\n    </div>\r\n    <noscript>\r\n        <div id=\"noscript-warning\">Server Fault works best with JavaScript enabled<img src=\"http://pixel.quantserve.com/pixel/p-c1rF4kxgLUzNc.gif\" alt=\"\" class=\"dno\"></div>\r\n    </noscr"], "copyright__copyright__copyright": ["ly have two sets of write stripe translation going on, one at gluster level and one at the controller level. Then you have two parity calculations which slow things down and cause I/O blocking unless you have a large write cache and periods of low I/O activity.\n\nI'd recommend you switch to RAID 10, and back this with either fibre channel or multiple bonded GigE links.\n\nshare|improve this answer\n\nYour Answer\n\n\u00a0\ndiscard\n\nBy posting your answer, you agree to the privacy policy and terms of service."]}