Synchronizacja milionów plików między dwoma serwerami Linux


10

Mam serwer, który eksportuje katalog zawierający ~ 7 milionów plików (głównie obrazów) z dysku lokalnego do klientów sieciowych za pośrednictwem NFS .

Muszę dodać drugi ze względu na HA i utrzymać go w synchronizacji z pierwszym z jak najmniejszą różnicą między nimi.

Badania sugerują użycie do tego celu lsyncd lub innych rozwiązań opartych na inotify , ale biorąc pod uwagę liczbę plików tworzących zegarki inotify, trwa to wieczność. To samo dotyczy rsync .

Inne możliwe rozwiązania wydaje się być drdb lub klaster plików systemy takie jak Ceph lub glusterfs , ale nie mam żadnego doświadczenia z tym i nie wiem który z nich byłby bardziej odpowiedni i dobrze radzą sobie z tym wielu plików i wciąż zapewniają przyzwoitą wydajność.

Zauważ, że aktywność jest w większości odczytywana z niewielkim zapisem.


2
DRDB działa dobrze i jest łatwy do skonfigurowania i zrozumienia w konfiguracji z dwoma maszynami; jednak nie będzie skalować w najbliższej przyszłości. Mogą być również inne podejścia do tematu. highscalability.com/blog/2012/6/20/…
Rui F Ribeiro

Czy próbowałeś uruchomić rsyncw trybie demona? Przyspieszy to początkowe generowanie listy plików podczas uruchamiania rsyncpolecenia, ale zajmie dużo pamięci RAM w zależności od ilości plików.
Thomas

ile opóźnień możesz tolerować? jeśli możesz tolerować kilka minut (lub więcej), używając btrfslub zfsmoże być opcją, w połączeniu z zadaniem cron do tworzenia snapsnotów i / zfs sendlub btrfs sendich do serwera kopii zapasowej. znacznie szybsze i znacznie lżejsze (zarówno dla nadawcy, jak i odbiornika) niż rsync, ponieważ migawka + wysyłanie nie musi porównywać znaczników czasowych plików ani sum kontrolnych.
cas

BTW, dzięki ceph masz również opcję używania go jako magazynu obiektów (np. Jak Amazon Amazona s3 lub openstacks Swift) zamiast systemu plików. W rzeczywistości, cef's fs jest nałożony warstwami na swój obiekt-magazyn.
cas

@ Thomas: rsync -akorzystanie z demona (w źródle) zajmuje 200 minut, co jest więcej niż jest dopuszczalne. @cas: btrfs sendmoże warto spróbować, przyjrzę się temu. Nie mogę przejść do magazynu obiektów, ponieważ nie jestem programistą aplikacji korzystającej z plików.
user60039

Odpowiedzi:


1

Skłaniam się do sugerowania replikacji, która jest niezależna od danych, tak jak drbd. Duża liczba plików spowoduje, że wszystko, co działa na wyższym poziomie niż „blokowanie pamięci”, poświęci nadmierną ilość czasu na chodzenie po drzewie - tak jak odkryłeś, używając rsync lub tworzenia inotify zegarków.

Krótka wersja mojej osobistej historii popierająca to: Nie korzystałem z Ceph, ale jestem prawie pewien, że nie jest to ich główny cel rynkowy ze względu na podobieństwo do Glustera. Jednak od kilku lat próbuję wdrożyć tego rodzaju rozwiązanie z Glusterem. Działało przez większość tego czasu, chociaż kilka głównych aktualizacji wersji, ale nie miałem końca problemów. Jeśli Twoim celem jest większa redundancja niż wydajność, Gluster może nie być dobrym rozwiązaniem. Szczególnie, jeśli twój wzorzec użytkowania zawiera wiele wywołań stat (), Gluster nie radzi sobie dobrze z replikacją. Wynika to z tego, że wywołania statystyk do zreplikowanych woluminów trafiają do wszystkich replikowanych węzłów (w rzeczywistości „cegiełek”, ale prawdopodobnie będziesz mieć tylko jedną cegłę na hosta). Jeśli na przykład masz replikę dwukierunkową, każda stat () od klienta czeka na odpowiedź z obu cegieł, aby upewnić się, że korzysta z bieżących danych. Następnie masz również narzut FUSE i brak buforowania, jeśli używasz natywnego systemu plików gluster do nadmiarowości (zamiast Gluster jako backendu z NFS jako protokołem i automounterem do nadmiarowości, który wciąż jest do bani z powodu statystyki ()) . Gluster radzi sobie naprawdę dobrze z dużymi plikami, w których można przenosić dane na wiele serwerów; paski i dystrybucja danych działają dobrze, ponieważ tak naprawdę jest po to. Nowsza replikacja typu RAID10 działa lepiej niż starsze proste replikowane woluminy. Ale w oparciu o to, co przypuszczam, jest twoim modelem użytkowania, odradzałbym to. Następnie masz również narzut FUSE i brak buforowania, jeśli używasz natywnego systemu plików gluster do nadmiarowości (zamiast Gluster jako backendu z NFS jako protokołem i automounterem do nadmiarowości, który wciąż jest do bani z powodu statystyki ()) . Gluster radzi sobie naprawdę dobrze z dużymi plikami, w których można przenosić dane na wiele serwerów; paski i dystrybucja danych działają dobrze, ponieważ tak naprawdę jest po to. Nowsza replikacja typu RAID10 działa lepiej niż starsze proste replikowane woluminy. Ale w oparciu o to, co przypuszczam, jest twoim modelem użytkowania, odradzałbym to. Następnie masz również narzut FUSE i brak buforowania, jeśli używasz natywnego systemu plików gluster do nadmiarowości (zamiast Gluster jako backendu z NFS jako protokołem i automounterem do nadmiarowości, który wciąż jest do bani z powodu statystyki ()) . Gluster radzi sobie naprawdę dobrze z dużymi plikami, w których można przenosić dane na wiele serwerów; paski i dystrybucja danych działają dobrze, ponieważ tak naprawdę jest po to. Nowsza replikacja typu RAID10 działa lepiej niż starsze proste replikowane woluminy. Ale w oparciu o to, co przypuszczam, jest twoim modelem użytkowania, odradzałbym to. który wciąż jest do bani z powodu statystyki ()). Gluster radzi sobie naprawdę dobrze z dużymi plikami, w których można przenosić dane na wiele serwerów; paski i dystrybucja danych działają dobrze, ponieważ tak naprawdę jest po to. Nowsza replikacja typu RAID10 działa lepiej niż starsze proste replikowane woluminy. Ale w oparciu o to, co przypuszczam, jest twoim modelem użytkowania, odradzałbym to. który wciąż jest do bani z powodu statystyki ()). Gluster radzi sobie naprawdę dobrze z dużymi plikami, w których można przenosić dane na wiele serwerów; paski i dystrybucja danych działają dobrze, ponieważ tak naprawdę jest po to. Nowsza replikacja typu RAID10 działa lepiej niż starsze proste replikowane woluminy. Ale w oparciu o to, co przypuszczam, jest twoim modelem użytkowania, odradzałbym to.

Pamiętaj, że prawdopodobnie będziesz musiał znaleźć sposób na mistrzowskie wybory między maszynami lub wdrożyć blokowanie rozproszone. Rozwiązania urządzeń z blokami współdzielonymi wymagają systemu plików obsługującego wiele systemów głównych (np. GFS) lub wymagają, aby tylko jeden węzeł zamontował system plików w trybie odczytu-zapisu. Systemy plików na ogół nie lubią, gdy dane są zmieniane na poziomie urządzenia blokowego pod nimi. Oznacza to, że Twoi klienci będą musieli być w stanie stwierdzić, który jest nadrzędny i bezpośrednio tam pisać żądania. To może okazać się dużym utrapieniem. Jeśli GFS i cała jego wspierająca infrastruktura jest opcją, drbd w trybie multi-master (nazywają go „podwójnym podstawowym”) może działać dobrze. https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-mode, aby uzyskać więcej informacji na ten temat.

Niezależnie od kierunku, w którym się wybierasz, możesz przekonać się, że nadal jest to dość duży problem w czasie rzeczywistym, nie dając firmie SAN ogromnej ilości pieniędzy.


Jestem w początkowej fazie migracji z komend rsync w cron do korzystania z rozproszonego systemu plików. Jeśli Gluster uruchomi stat () na wszystkich cegłach, być może będę musiał ponownie rozważyć to jako rozwiązanie.
Jesusaur

1
Dotyczy to tylko replikowanego systemu plików; działa stat()na wszystkich cegłach, które mają repliki określonego bloku, na który patrzysz. Na przykład, jeśli masz replikę w paski 2x2, statbędzie działać na dwóch cegłach z replikowanym blokiem, ale nie na dwóch pozostałych. W mojej aplikacji z dużą ilością małych plików (rzędu miliona plików poniżej 4K danych każdy) ani NFS, ani FUSE nie zapewniały dobrej wydajności na zreplikowanych woluminach. A georeplikacja na ~ 20 maszynach była bardzo zawodna w kilku konfiguracjach.
dannysauer,

1
Twój przebieg może się różnić, ale przeniosłem się z Glustera wszędzie (którego używałem wyłącznie do replikacji, nie dla wszystkich innych naprawdę fajnych rzeczy, które Gluster naprawdę robi dobrze) na rsync na rodzimych systemach plików. :) Patrzę na przejście do lsyncd ( github.com/axkibe/lsyncd ) teraz zamiast crona, więc mogę zbliżyć się w czasie rzeczywistym bez narzuty Glustera.
dannysauer,

0

Zmieniłem rsync na ceph przy pomocy konfiguracji Proxmox VE.

Teraz zarządzam 14 TB w jednym klastrze z replikacją na żywo. Przez prawie 4 lata.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.