150 TB i rośnie, ale jak rosnąć?


18

Moja grupa ma obecnie dwa duże serwery pamięci, oba na NAS z systemem Debian Linux. Pierwszy to kilkuletni serwer All-in-One 24-dyskowy (SATA). Mamy na nich dwa sprzętowe RAIDS z LVM. Drugi serwer to 64 dyski podzielone na 4 obudowy, każda sprzętowa RAID 6, połączona za pomocą zewnętrznego SAS. Używamy XFS z LVM, aby stworzyć użyteczną pamięć o pojemności 100 TB. Wszystko to działa całkiem dobrze, ale przerastamy te systemy. Po zbudowaniu dwóch takich serwerów i wciąż rozwijaniu się, chcemy zbudować coś, co zapewni nam większą elastyczność w zakresie przyszłego wzrostu, opcji tworzenia kopii zapasowych, które będą się lepiej zachowywać w przypadku awarii dysku (sprawdzanie, czy większy system plików może zająć dzień lub dłużej) i może wytrzymać w mocno współbieżnym środowisku (pomyśl o małym klastrze komputerowym). Nie mamy wsparcia administracyjnego systemu,

Tak więc szukamy stosunkowo niedrogiego, akceptowalnego rozwiązania pamięci masowej, które pozwoli na przyszły rozwój i elastyczną konfigurację (pomyśl o ZFS z różnymi pulami o różnych właściwościach operacyjnych). Prawdopodobnie jesteśmy poza sferą jednego serwera NAS. Myśleliśmy o kombinacji ZFS (na przykład na openindiana) lub btrfs na serwer z glusterfs działającymi nad tym, jeśli sami to zrobimy. W porównaniu z tym po prostu gryziemy kulę i inwestujemy w rozwiązania magazynowe Isilon lub 3Par.

Wszelkie sugestie lub doświadczenia są mile widziane.

Odpowiedzi:


16

Mam nadzieję, że to trochę pomoże. Starałem się, aby nie zmieniła się w pełną ścianę tekstu. :)

3Par / Isilon

Jeśli możesz i poświęcisz stałą ilość roboczogodzin dla kogoś, kto przejmuje rolę administratora SAN i chce cieszyć się bezbolesnym życiem z nocnym snem zamiast pracy nocnej, to właśnie tak pójdę.

Sieć SAN pozwala ci wykonywać wszystkie czynności, w których ograniczałaby Cię pojedyncza „pamięć” (tj. Podłączać macierz flash purestorage i dużego potwora 3par sata do tego samego serwera), ale musisz też za to zapłacić i utrzymywać wszystko w dobrym stanie czas, jeśli chcesz skorzystać z elastyczności.

Alternatywy

Amplidata

Plusy: skalowalne, tanie, zaprojektowane z ładną koncepcją i dedykowanymi warstwami pamięci podręcznej odczytu / zapisu. To może być najlepsza rzecz dla Ciebie.

RisingTideOS

Ich docelowe oprogramowanie jest obecnie używane w prawie wszystkich systemach Linux i pozwala na nieco lepsze zarządzanie niż zwykłe rzeczy z Linuksem / Glusterem. (Imho) Wersja komercyjna może być warta obejrzenia.

Gluster / btrfs

PRO: Skaluje się, a „Cegły” dają warstwę abstrakcji, która jest bardzo dobra do zarządzania.

CON: Pierwszy to dla mnie całkowita PITA. Nie był solidny, a awarie mogły być lokalne w stosunku do jednej cegły lub usunąć wszystko. Teraz, gdy RedHat ma kontrolę, może faktycznie zmienić się w coś działającego, a nawet spotkałem ludzi, którzy potrafią go oswoić, aby działał przez lata. A drugi jest wciąż w połowie eksperymentalny. Zwykle FS potrzebuje 3-4 lat po „wykonaniu”, aż będzie sprawdzony i solidny. Jeśli zależy Ci na danych, dlaczego miałbyś to rozważyć? Mówiąc o eksperymentalnym, komercyjne wsparcie Ceph jest już prawie gotowe, ale musisz trzymać się warstwy „RBD”, FS po prostu nie jest jeszcze wystarczająco przetestowany. Chcę jednak jasno powiedzieć, że Ceph jest znacznie bardziej atrakcyjny na dłuższą metę. :)

ZFS

Pro: Funkcje, które zdecydowanie wbijają gwóźdź do trumny innych rzeczy. Te funkcje są dobrze zaprojektowane (pomyśl L2ARC), a kompresja / dedupcja jest fajna. Mają więcej „klastrów pamięci”, co oznacza, że ​​mają tylko małe awarie zamiast jednego dużego skonsolidowanego boomu

Wada: utrzymanie wielu małych pudełek z oprogramowaniem zamiast prawdziwej pamięci. Musisz je zintegrować i poświęcić $$$ godziny na solidną konfigurację.


3
+1. Mam nadzieję, że nie masz nic przeciwko, że zrobiłem to trochę mniej.
Kyle Smith,

@ florian-heigl Czy możemy podać kilka linków, aby śledzić, ponieważ nie mam szczęścia znaleźć niektórych z wymienionych przez Ciebie rozwiązań (np. 3Par, Isilon, RisingTideOS) TIA
ossandcad

7

Trasa XFS + LVM jest rzeczywiście jedną z najlepszych opcji skalowanego rozwiązania pamięci masowej opartego wyłącznie na systemie Linux w ciągu ostatnich kilku lat. Jestem zachęcony, że już tam jesteś. Teraz, gdy musisz się więcej rozwijać, masz jeszcze kilka dostępnych opcji.

Jak wiecie, wielcy dostawcy sprzętu mają głowy NAS do przechowywania. To rzeczywiście dałoby ci jednego dostawcę do współpracy, aby wszystko się stało, i działałoby całkiem nieźle. Są łatwym rozwiązaniem (w porównaniu do majsterkowania), a ich łatwość konserwacji jest niższa. Ale kosztują całkiem sporo. Z jednej strony będziesz mieć więcej zasobów inżynieryjnych do rozwiązywania głównych problemów niż problemów z infrastrukturą; z drugiej strony, jeśli jesteś podobny do większości wydziałów uniwersyteckich, wiedziałem, że siła robocza jest naprawdę tania w stosunku do płacenia gotówką za rzeczy.

Idąc drogą DIY możesz już docenić dostępne opcje DIY. ZFS / BTRFS są oczywistą ścieżką aktualizacji XFS + LVM dla skalowanej pamięci masowej. Unikałbym BTRFS, dopóki nie zostanie zadeklarowany jako „stabilny” w jądrze Linuksa, co powinno być niedługo teraz, gdy kilka głównych wolnych dystrybucji używa go jako domyślnego systemu plików. W przypadku ZFS zalecałbym użycie bazy BSD zamiast OpenIndiana po prostu dlatego, że jest już dłużej i ma załamania (więcej).

Gluster został zaprojektowany do opisanego tutaj przypadku użycia. Może wykonywać replikację, a także prezentować pojedynczy serwer wirtualny z dużą ilością pamięci. Ich woluminy rozproszone brzmią dokładnie tak, jak tego szukasz, ponieważ rozprzestrzeniają pliki na wszystkich serwerach pamięci w zadeklarowanym woluminie. Możesz nadal dodawać dyskretne serwery pamięci, aby nadal powiększać widoczny wolumin. Jedna przestrzeń nazw!

Gotcha z Glusterem polega na tym, że działa najlepiej, gdy klienci mogą korzystać z klienta Gluster, aby uzyskać dostęp do systemu, zamiast opcji CIFS lub NFS. Ponieważ prowadzisz mały klaster obliczeniowy klastra, możesz po prostu móc korzystać z klienta GlusterFS.

Jesteś na dobrej drodze tutaj.


Rozwiązanie „zrób to sam” oznacza, że ​​jeśli sam je złamiesz, musisz to naprawić samodzielnie. Staje się to drogie, gdy przekroczysz granice kilku serwerów. Jeśli istnieje jakakolwiek presja biznesowa na zwiększenie dostępności tego miejsca, wydasz mniej pieniędzy na zakup koła niż samodzielne jego wynalezienie. Oprogramowanie pamięci masowej działające na serwerach może być wykonane tak, aby zrobić wszystko, co może zrobić rzeczywista pamięć masowa, ale nie taniej.
Basil

1

O ile rozumiem, możesz użyć rozwiązania SAN opartego na Linux SCST + FibreChannel lub infiniband, co właśnie buduję. Jako bazę dla jednostek LUN można użyć LVM na sprzętowych macierzach RAID i zająć się migawkami / replikacją (na przykład DRBD) poniżej poziomu systemu plików. Jako system plików nie znam żadnego dobrego rozwiązania zapewniającego spójność, ponieważ umieszczam ESXi na wierzchu węzłów, więc magazynami danych zarządza współbieżny FS ESX. Myślę, że GFS2 może współpracować z tym środowiskiem, ale nie jestem w 100% pewien, ponieważ powinieneś sprawdzić swoje dokładne wymagania. W każdym razie, gdy masz solidną sieć SAN pod swoimi węzłami, łatwo jest załatwić sprawę.

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.