[Gluster-users] (no subject)

[Dennis Arkhangelski]

-----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-----