[Gluster-users] Using gluster for a CDN

Harald Stürzebecher haralds at cs.tu-berlin.de
Tue May 5 16:29:29 UTC 2009


Hello!

2009/5/4 Ugo PARSI <ugo.parsi at gmail.com>:
> Hello,
>
> I'm totally new to this project, but it seems really great !
> I have tried a lot of clustered and network file systems, and most of
> them were unreliable due to their complex mechanisms, I really like
> this simpler design.

IIRC, a lot of the 2.0 release candidates had data corruption problems
with the replicate translator. I'd suggest checking the mailing list
archive to see if these issues are fixed.

> I'm currently building a CDN in order to serve static files all over
> the world for my services.
> The DNS and load-balancing part is complete, but I'm currently stuck
> at the point of synchronizing and spreading the files.

rsync+cron? If the files don't change to often, that might be enough.
drbd ( http://www.drbd.org/ )? Might be suitable if used as backup
only (each set of disks is read/written at one location and replicated
to off site backup).

> Gluster would seem to do the job perfectly, right ?
> But my question is more about the network latency.... is there any way
> to specify some geographical or routing informations with it ?

AFAIK, not directly.

> For example I would like to achieve the following configuration :
>
> Datacenter A - Paris, FR
> Datacenter B - Chicago, US
> Datacenter C - Auckland, NZ
>
> Storage Servers A, B, C are synchronized (mirror) with each others .
> But clients of Datacenter A, only use Storage A, clients of B, use
> Storage B, etc.... in order to get a good latency to access the files.
>
> Is this possible and suitable ?

AFAIK, 'replicate' is - by design - sensitive to network latency: it
talks to all mirrors to find out which one has the latest version of a
file.
IMHO, that would not work well in your case if every access takes
500ms round trip time (rough estimate for "half around the world", not
based on any tests) before even opening the file.
http://www.gluster.org/docs/index.php/Understanding_AFR_Translator

Using it as a "staging area" for updates might work:
1. write changes to replicated gluster volume (from any location)
2. sync from gluster volume to local disk (the one that feeds the web servers)


Harald Stürzebecher




More information about the Gluster-users mailing list