rozproszony system plików Opcje

[michalkjp]

Witam,

Szukam rozproszonego systemu plików z replikacją, który by robił coś takiego jak opisze poniżej.

Mamy 3 serwery - na każdym jest cherokee. Serwer 1 robi load balancing pomiędzy te trzy serwery. Na każdym serwerze działa aplikacja, która zapisuje pliki do powiedzmy /data/uploads. Chodzi mi o taki system plików, który po zapisie jakiegoś pliku na jednym z węzłów od razu zapisywał ten plik na innych węzłach.

Jednak ten system powinien działać niezależnie od aplikacji tzn. nie chcę wprowadzać w niej zmian jeśli nie będę musiał - czyli na razie mogilefs odpada. Zna ktoś rozwiązanie, które by się sprawdziło?

Jak zwykle dzięki za wyczerpującą pomoc - problem rozwiązany (IMG:style_emoticons/default/biggrin.gif)

[erix]

Ale mógłbyś napisać jak, też mnie ciekawi rozwiązanie. (IMG:style_emoticons/default/winksmiley.jpg)

[michalkjp]

Przy pomocy glusterfs http://www.gluster.org/

Komputery A, B, C są jednocześnie serwerem jak i klientem.

volume posix
type storage/posix
option directory /data/server
end-volume

volume locks
type features/locks
subvolumes posix
end-volume

volume brick
type performance/io-threads
option thread-count 8
subvolumes locks
end-volume

volume server
type protocol/server
option transport-type tcp
option auth.addr.brick.allow 192.168.101.*
subvolumes brick
end-volume

Teraz na każdym kompie jest montowany gluserfs w /data/client

volume remote1
type protocol/client
option transport-type tcp
option remote-host A
option remote-subvolume brick
end-volume

volume remote2
type protocol/client
option transport-type tcp
option remote-host B
option remote-subvolume brick
end-volume

volume remote3
type protocol/client
option transport-type tcp
option remote-host C
option remote-subvolume brick
end-volume

volume replicate
type cluster/replicate
subvolumes remote1 remote2 remote3
end-volume

volume writebehind
type performance/write-behind
option window-size 1MB
subvolumes replicate
end-volume

volume cache
type performance/io-cache
option cache-size 512MB
subvolumes writebehind
end-volume

Cały projekt symfony trzeba wrzucić gdzieś do /data/client - bez tego są ciekawe efekty. Trzeba też wrzucić tam katalog, gdzie są trzymane informacje o sesjach php (chyba to miałem w /var/lib/php/session).

No i trzeba jeszcze odblokować port na firewallu - chyba 6996 jeśli dobrze pamiętam.

To w zasadzie tyle jeśli chodzi o replikacje na poziomie systemu plików.

Rozwiązanie w testach w stylu "time dd if of" wydaje się wolne, ale można puścić równolegle kilka procesów i każdy będzie działał - jest jakieś kolejkowanie i coś pilnuje, żeby żaden proces nie monopolizował dostępu do zasobu. Przy sprawdzeniu za pomocą iozone, taka replikacja jest nieznacznie wolniejsza niż dostęp do lokalnego zasobu (w niektórych testach była nieznacznie szybsza).

Gluster jest o tyle fajny, że nie jest potrzebna integracja z aplikacją tak jak w przypadku mogilefs. Z mogilefs miałbym taki problem, że o ile zrobienie uploadu plików nie przedstawiałoby problemu, to współdzielenie indeksu dla lucene pomiędzy serwerami wymagałoby przerabiania na poziomie biblioteki zend/lucene, co prawdopodobnie nie byłoby ani przyjemne ani łatwe ani dobre rozwiązanie.

Więcej o konfiguracji glustra można znaleźć w
http://howtoforge.com/high-availability-st...storage-servers

Jest też trochę artykułów o tuningu, ale na razie ocierają się one za bardzo o czarną magię - przynajmniej ja nie widziałem różnicy w zwykłych testach.

Powodzenia w konfiguracji.