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

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.

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.

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.