Gluster users - Jan 2009 - HA scalabile cluster - help make vol pls

Hello!

There is a challenge to build a robust network-based storage glusterfs. All of
course good, but there is a problem - there is no scalability (the number of
units will vary with time) and not very good speed afr (need to work as a
database for storage of about gigabytes and temporaly (no more than 2 seconds,
then delete) small files). Can you help with a sketch configuration?

P.S. Tire tried scheme afr ha has not yet been particularly pleased with ... By
the way, but as a work ha?

// sorry about my bad english

here are my quick thoughts.

First, to solve your AFR performance problem, use only 2 bricks per AFR
use unify (or DHT) to combine your multiple AFR bricks into a single 
representation.

for your loads of small files use the Berkeley DB translator, as it''s 
apparently much faster for small files.  ( you may need to use the 
switch scheduler within unify to make sure the right files get to the 
right bricks.)

Beyond that, hopefully someone with a deeper understanding of all the 
translators can help


At 05:18 PM 1/4/2009, aka_Red=5FLion wrote:
>Hello!
>
>There is a challenge to build a robust network-based storage 
>glusterfs. All of course good, but there is a problem - there is no 
>scalability (the number of units will vary with time) and not very 
>good speed afr (need to work as a database for storage of about 
>gigabytes and temporaly (no more than 2 seconds, then delete) small 
>files). Can you help with a sketch configuration?
>
>P.S. Tire tried scheme afr ha has not yet been particularly pleased 
>with ... By the way, but as a work ha?
>
>// sorry about my bad english
>
>_______________________________________________
>Gluster-users mailing list
>Gluster-users at gluster.org
>http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users

here are my quick thoughts.

First, to solve your AFR performance problem, use only 2 bricks per AFR
use unify (or DHT) to combine your multiple AFR bricks into a single 
representation.

for your loads of small files use the Berkeley DB translator, as it's 
apparently much faster for small files.  ( you may need to use the 
switch scheduler within unify to make sure the right files get to the 
right bricks.)

Beyond that, hopefully someone with a deeper understanding of all the 
translators can help


At 05:18 PM 1/4/2009, aka_Red=5FLion wrote:
>Hello!
>
>There is a challenge to build a robust network-based storage 
>glusterfs. All of course good, but there is a problem - there is no 
>scalability (the number of units will vary with time) and not very 
>good speed afr (need to work as a database for storage of about 
>gigabytes and temporaly (no more than 2 seconds, then delete) small 
>files). Can you help with a sketch configuration?
>
>P.S. Tire tried scheme afr ha has not yet been particularly pleased 
>with ... By the way, but as a work ha?
>
>// sorry about my bad english
>
>_______________________________________________
>Gluster-users mailing list
>Gluster-users at gluster.org
>http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users