-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hm... DRBD is: a) not scalable at all b) not really a parallel filesystem IBM GPFS perhaps, but GPL Linux kernel module versions have quite limited functionality compared to their closed modules. Alternatively unsupported Sun Lustre setup with DRBD/heartbeat driven hybrid MGS/MDT. Lustre itself is pretty whimsical though, from my personal experience, and failover isn't smooth in the above setup. To make the story short, GlusterFS is the most reliable parallel FS (and probably the slowest one) I ever used. As Marcus said, caching frontend of any nature has absolutely nothing in common with storage subsystem. Caching itself has very limited usage indeed, it's basically suitable for archaic sites with mostly static content, and, sometimes, for media-rich sites (lol, why don't you use Akamai then?). Caching frontends are next to useless for modern WEB-2.0 style stuff (well, what is webapp in our case?), which obviously heavily relies on small files on storage backend. Speaking of GlusterFS performance, don't forget its underlying filesystem and physical storage performance. I had semi-production GlusterFS setup while back (2.0.7) based on ReiserFS backend, which was showing noticeably better performance on small files (PHP session cache - - sic!) than previous ext3-based deployment, I'd say +20% to +30% on low-to-mid data throughput. RAID-0 or RAID-10 gives even bigger performance boost. Side note, any type of control sum RAID (5 or 6) is a never-do for small files (circa stripe size), XOR is a poor man's RAID. :) Further, as Gluster has userspace implementation, consider optimizing kernel process scheduler. Linux CFS is a very bad idea on client side where live services are running. I/O scheduler, other than CFQ, is a very bad idea on server side. Renicing Gluster processes is actually the must, -20 is enough. ;) Further, what's the interconnect? Jenn, I'm guessing you're not running Gluster over 100Mbit ethernet shared with public webapp traffic, right? These VLAN thingy don't count of course. ;) Anything less than 1Gbit makes no sense. I'd suggest Infiniband DDR4x and above if you're really concerned about Gluster performance. 05.05.2010 3:14, David Simas ?????: > On Tue, May 04, 2010 at 09:43:01PM +0200, Marcus Bointon wrote: >> On 4 May 2010, at 21:27, Larry Bates wrote: >> >>> Seems to me that this problem should more likely be solved with Squid. Nginx, or >>> some caching software. >> >> The speed problem could be fixed with them, but it's not a replacement for what glusterfs is doing. I'm in the same boat: users upload images to a synchronously replicated gluster content area available to multiple web servers. Caching on individual servers is likely to run into coherency problems. With no server stickiness, we need to be able to guarantee that an uploaded file is immediately available to all front-ends without introducing a SPOF. >> >> While gluster might not be ideal for this, it is the *only* solution I've found that does it all. Do you have any better suggestions? > > A suggestion, not necessarily better: DRBD in dual-primary mode with > OCFS2 or GFS2. See > > http://www.drbd.org/docs/applications/ > > David Simas > >> >> Marcus >> -- >> Marcus Bointon >> Synchromedia Limited: Creators of http://www.smartmessages.net/ >> UK resellers of info at hand CRM solutions >> marcus at synchromedia.co.uk | http://www.synchromedia.co.uk/ >> >> >> _______________________________________________ >> Gluster-users mailing list >> Gluster-users at gluster.org > A >> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users - -- Regards, Dennis Arkhangelski Technical Manager WHB Networks LLC. http://www.webhostingbuzz.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAkvg1GAACgkQH77FUyBB2YWJawCcDj6982NZxwFDG/dHOydeN77/ pUsAl1u/GY9tuELkhrhtGUTesTVsGZY= =oigW -----END PGP SIGNATURE-----
