Wskazówki na temat efektywnego przechowywania ponad 25 TB wartych miliony plików w systemie plików

Załóżmy, że masz do czynienia z nieskompresowanymi plikami dziennika o wartości 25 TB i masz do dyspozycji szereg 20 skrzynek towarowych o łącznej pojemności 25 TB.

Jak je przechowujesz?

a) Jakiego rozproszonego systemu plików użyć?

b) Jaki format / algorytm kompresji / dekompresji?

c) Rozmiar pliku dziennika wynosi od 1 MB do maksymalnie 7 MB całego tekstu i dużej ilości spacji

d) Wykorzystanie to: a) ludzie chcą więcej plików dziennika więcej niż poprzednie, więc z jakiego systemu buforowania korzystać, b) ludzie będą czytać tylko pliki dziennika, a nie je usuwać c) ludzie chcą listy plików dziennika w odniesieniu do zakresu dat

e) System operacyjny działający na skrzynkach towarowych to Linux,

f) Jeśli chodzi o kopie zapasowe, mamy macierz pamięci, która się tym zajmuje. Istnieje więc możliwość przywracania danych z tablicy.

Nie chcę, żeby mieli bezpośredni dostęp do systemu plików. Co powinienem zrobić ? Jak mogę uzyskać do tego interfejs API oparty na REST?

Oszczędź 2 centy i co byś zrobił?

Ankur

Nie jestem ninja z rozproszonego systemu plików, ale po skonsolidowaniu jak największej liczby dysków na jak najmniejszej liczbie komputerów, spróbuję użyć iSCSI, aby połączyć większość komputerów z jedną maszyną główną. Tam mogłem skonsolidować rzeczy w pamięci, która może być odporna na uszkodzenia. Najlepiej, jeśli jest odporny na uszkodzenia w maszynie (w przypadku awarii napędu) i wśród maszyn (w przypadku braku zasilania całej maszyny).

Osobiście lubię ZFS. W takim przypadku pomocna byłaby kompresja kompresji, deduplikacja i odporność na awarie. Jednak jestem pewien, że istnieje wiele innych sposobów kompresji danych, jednocześnie czyniąc je odpornym na uszkodzenia.

Szkoda, że ​​nie mam poleconego rozwiązania plików rozproszonych pod klucz, wiem, że to naprawdę kludgey, ale mam nadzieję, że skieruje cię we właściwym kierunku.

Edycja: Nadal jestem nowy w ZFS i konfiguruję iSCSI, ale przypomniałem sobie wideo z firmy Sun w Niemczech, w którym pokazali odporność na błędy ZFS. Połączyli trzy koncentratory USB z komputerem i umieścili cztery dyski flash w każdym koncentratorze. Następnie, aby zapobiec wyłączeniu puli pamięci przez jeden koncentrator, utworzyli wolumin RAIDz składający się z jednego dysku flash z każdego koncentratora. Następnie łączą razem cztery woluminy ZFS RAIDz. W ten sposób do parzystości wykorzystano tylko cztery dyski flash. Następnie oczywiście odłączony jeden koncentrator i to pogorszyło każdy zpool, ale wszystkie dane były dostępne. W tej konfiguracji maksymalnie cztery dyski mogą zostać utracone, ale tylko wtedy, gdy jakieś dwa dyski nie będą w tej samej puli.

Jeśli ta konfiguracja zostanie użyta z nieprzetworzonym dyskiem każdego pudełka, to zachowa więcej dysków dla danych, a nie dla parzystości. Słyszałem, że FreeNAS może (lub miał być w stanie) udostępniać dyski w „surowy” sposób przez iSCSI, więc sądzę, że Linux może zrobić to samo. Jak powiedziałem, wciąż się uczę, ale ta alternatywna metoda byłaby mniej marnotrawna z punktu widzenia parzystości dysków niż moja poprzednia sugestia. Oczywiście polegałoby na użyciu ZFS, którego nie wiem, czy byłoby to dopuszczalne. Wiem, że najlepiej trzymać się tego, co wiesz, jeśli będziesz musiał coś zbudować / utrzymać / naprawić, chyba że jest to doświadczenie edukacyjne.

Mam nadzieję, że to jest lepsze.

Edycja: trochę kopałem i znalazłem wideo , o którym mówiłem. Część, w której wyjaśniają rozkładanie napędu flash USB na koncentratory, zaczyna się od 2m10s. Film wideo ma na celu pokazanie serwera pamięci „Thumper” (X4500) oraz sposobu rozmieszczania dysków na kontrolerach, aby w przypadku awarii kontrolera dysku twardego dane były nadal dobre. (Osobiście uważam, że to tylko film z geekami, którzy się bawią. Chciałbym sam mieć pudełko Thumpera, ale moja żona nie chciałaby, żebym poprowadził wózek paletowy przez dom.: D To jedno duże pudełko.)

Edycja: Pamiętam, jak przechodziłem przez rozproszony system plików o nazwie OpenAFS . Nie próbowałem tego, przeczytałem tylko trochę o tym. Być może inni wiedzą, jak sobie radzi w prawdziwym świecie.

Po pierwsze, pliki dziennika można kompresować w naprawdę wysokich proporcjach. Uważam, że moje pliki dziennika kompresują się w stosunku 10: 1. Jeśli kompresują nawet do proporcji 5: 1, to tylko 5 GB, czyli 20% pojemności pamięci.

Biorąc pod uwagę, że masz więcej niż wystarczającą ilość miejsca, konkretny algorytm kompresji nie jest zbyt ważny. Mógłbyś...

• Użyj plików zip, jeśli użytkownicy systemu Windows będą mieli bezpośredni dostęp do plików.
• Użyj gzip, jeśli będzie dostępny przez Linux, a szybka dekompresja jest ważna.
• Użyj bzip2, jeśli będą dostępne za pośrednictwem Linuksa i ważne jest, aby mieć możliwie najmniejsze pliki.

Większe pytanie brzmi: w jaki sposób zapewnisz swoim użytkownikom łatwy dostęp do tych plików? Częściowo zależy to od konfiguracji komputerów.

Jeśli umieścisz wystarczającą ilość miejsca na jednym komputerze, możesz zrobić coś niezwykle prostego, na przykład udział plików Windows tylko do odczytu. Po prostu uporządkuj pliki w podkatalogach i możesz zacząć.

Jeśli nie możesz utworzyć pojedynczego serwera plików dla tych plików, może się okazać, że potrzebujesz rozproszonego systemu plików. System Windows ma rozproszony system plików (DFS), który może odpowiadać Twoim potrzebom.

Jeśli Twoje potrzeby są bardziej zaawansowane, możesz chcieć, aby aplikacja internetowa była frontonem, w którym użytkownicy mogą przeglądać i pobierać pliki dziennika. W takim przypadku zalecam użycie MogileFS, który jest rozproszonym systemem plików zaprojektowanym do użytku z front-endowym serwerem aplikacji. Bardzo łatwo jest zintegrować go z większością języków programowania. Nie możesz zamontować go jako dysku współdzielonego na swoim komputerze, ale jest on najwyższej klasy jako magazyn danych dla aplikacji sieci web.

lessfs to deduplikujący, kompresujący system plików. Chociaż nie rozwiąże to całego problemu, warto spojrzeć na niego jako backend.

eksportuj te foldery przez NFS

zamontuj je na jednym komputerze z uruchomionym Apache (w katalogu głównym dokumentu) jako drzewo

użyj kompresji zip, aby je skompresować - dobry współczynnik kompresji, zip można otworzyć ze wszystkich systemów operacyjnych

wyświetl listę plików w Apache - więc dajesz użytkownikom dostęp tylko do odczytu (pliki dziennika nie powinny być edytowane, prawda)

Myślałeś kiedyś o kompresji plików dziennika? Następnie zrób coś na froncie, aby je zdekompresować przed podaniem ich użytkownikowi końcowemu. Może coś w rodzaju skryptu CGI.

@Ankur i @Porch. Zdecydowanie zgadzam się z koniecznością kompresji tych dzienników.

@jet Myślę, że prostszy schemat jest lepszy - dlatego httpd dla użytkownika końcowego jest bliski ideału. A backend może być dowolny.

Moja opinia - podziel dzienniki na 2 grupy - foldery „stary” i „nowy”.

Scal je w katalogu głównym httpd. Użyj silnej kompresji dla starych (archiwa xz lub 7z, popularne dla wszystkich systemów operacyjnych) z dużymi słownikami i rozmiarami bloków, mogą być nawet solidnymi archiwami.

Użyj kompresji fs dla nowych: lessfs (rw, deduplikacja + lekkie metody kompresji), fusecompress 0.9.x (rw, od lekkich do mocnych metod kompresji), btrfs / zfs, squashfs (ro, od lekkich do silnych metod kompresji, niektóre deduplikacje, użyj dla nowo obróconych dzienników).

Możesz nawet transparentnie zapisywać logi w skompresowanym pliku fs (fusecompress, lessfs, btrfs / zfs). Zapewnij dostęp R / O przez httpd do zapisywanych dzienników. Będą przejrzyste dla użytkowników i przejrzyste dla nich dekompresowane.

Ostrzeżenia przed bezpiecznikiem: 1) używaj tylko 0.9.x - jest stabilny. Sklonuj tutaj https://github.com/hexxellor/fusecompress

Późniejsze wersje albo nie obsługują dobrze LZMY, albo tracą dane.

2) używa tylko 1 rdzenia procesora do kompresji jednego pliku, dlatego może być powolny.

Ponownie skompresuj każdy dziennik w „nowym” folderze, starszym niż jakiś czas (kilka miesięcy) i przejdź do „starego”.