lustrzany system plików na kilku serwerach


13

Szukam rozwiązania do dublowania lub replikacji jednego katalogu (lub jednego systemu plików) na kilku serwerach Linux. Idealnym rozwiązaniem byłoby takie, które zezwala wszystkim serwerom na dostęp do odczytu i zapisu. Chcę też, aby był odporny, jeśli jeden z serwerów ulegnie awarii, reszta powinna nadal działać bez utraty jakichkolwiek danych.

Patrzyłem na niektóre rozwiązania:

  • DRBD : replikacje na poziomie bloku, wydają się nieco przesadne;
  • lsyncd : wygląda bardzo prosto, ale mam wątpliwości co do wydajności;
  • GlusterFS : wydaje się, że byłoby to dobre dopasowanie, jeszcze nie zorientowałem się, jak dokładnie działa tryb replikacji. Czy będzie miał wymagane cechy?

Wszelkie inne sugestie są mile widziane.


Czy szukasz konfiguracji typu „nic wspólnego”, czy połączysz wszystkie serwery z tą samą siecią SAN zaplecza?
HampusLi

logicznie nic się nie dzieliło (fizycznie jest to EC2 z EBS).
vartec

Odpowiedzi:


6

Pierwsze pytanie, które zadam, to czy chcesz to zreplikować na dwóch serwerach, czy na więcej niż dwóch serwerach? W przypadku dwóch serwerów wybrałbym DRDB, w przypadku trzech lub więcej wybrałbym gluster.

Jeśli opóźnienie we / wy nie jest krytycznym problemem, poszedłbym z niechęcią. Jest dość łatwy w konfiguracji i może wyraźnie zrobić to, czego potrzebujesz. Wszystko, co musisz zrobić, to zrobić serwer gluster obsługujący pliki na wszystkich trzech urządzeniach, a następnie sprawić, by każde urządzenie działało jak klient programu Gluster, montujący pliki.

DRDB będzie skomplikowane, aby rozpocząć pracę w trybie master <-> master z 3 lub więcej serwerami. Musisz skonfigurować konfigurację opartą na pierścieniu i nie polecałbym tego. Jednak dla dwóch serwerów DRDB jest fantastyczny. Tryb Master <-> Tryb Master nie jest skomplikowany w konfiguracji i nie musisz uczyć się żadnych rzeczy z systemu plików.

lsycd jest świetny do konfiguracji master / slave, ale wydaje się, że tego nie chcesz.

Ceph jest wciąż całkiem nowy, ostatnim razem, gdy sprawdziłem, nie ma jeszcze obsługi fsck. Wolę oprzeć swoją infrastrukturę na czymś bardziej stabilnym.

Luster to fantastyczny produkt do wdrożeń na dużą skalę, ale musisz skonfigurować bicie serca i przełączanie awaryjne dla serwera mds lub jego pojedynczego punktu awarii. Biorąc pod uwagę ograniczoną liczbę serwerów, o których on mówi, podejrzewam, że w tym przypadku jest to nadmiar.


Początkowo zacznę od zaledwie 2 serwerów na klaster, ale chcę mieć więcej niż 2 serwery do skalowania; Opisana przez ciebie konfiguracja gluster, czy poradzi sobie z awarią jednego z serwerów? czy łatwo byłoby dodać dodatkowy serwer?
vartec


2

Powinieneś przyjrzeć się OpenAFS - jest to w większości rozproszony system plików, który pozwala na istnienie wielu kopii danych rozproszonych w klastrze i każdy może jednocześnie czytać / zapisywać w FS.

Ma także wiele innych przydatnych funkcji (dobre uwierzytelnianie, szyfrowanie na kablu, wbudowane buforowanie lokalne na klientach, natywny klient Windows, przenośny na wiele wersji Uniksa itp.)

Jest jednak trochę ciężki do skonfigurowania.


to samo pytanie, co w przypadku NFS: „zezwala na wiele kopii”. OK, ale czy faktycznie zajmuje się synchronizacją tych kopii?
vartec

Tak. Możliwe jest, choć denerwujące, wyzdrowienie po utracie głównego mistrza. Ale trywialne jest posiadanie wielu autorów i wynikowych bloków przechowywanych na wielu hostach.
Chris

Kluczem do zrozumienia OpenAFS jest to, że jest to system zarządzania pamięcią podręczną - istnieje jedna przestrzeń nazw (IE istnieje tylko jeden „plik”), ale wszędzie są kopie pliku w pamięci podręcznej i protokół zapewniający spójność wszystkich kopii w pamięci podręcznej . Jeśli stracisz mistrza, możesz zamienić jedną z kopii z pamięci podręcznej w mistrza, ale nie jest idealnie w takiej sytuacji.
Chris

1

NFS może również działać dobrze, w zależności od potrzeb.


AFAIK, NFS nie zapewnia sposobu montowania replikowanych serwerów, ale nie sama replikacja. Ale od dawna nie korzystam z NFS, więc może to się zmieniło. Czy możesz podać link do dokumentacji NFS opisującej taką konfigurację?
vartec

Daleko od mojej głowy byłoby replikowanie katalogów na kilka serwerów nfs, z których jeden ma podstawowy plik vip, i migrowanie pliku vip między serwerami, jeśli jeden z nich ulegnie awarii. Lub może okrągłe robin dns. Sam NFS może nie robić wszystkiego, czego potrzebujesz, ale w połączeniu z usługami pulsu lub klastrów red hat może być tym, czego potrzebujesz. Nie jestem pewien, czy pierwotne pytanie zawierało wszystkie wymagania. Możesz nawet wykonać rsync na kilku serwerach, powiedzmy co godzinę, aby uzyskać naprawdę szybkie i łatwe rozwiązanie.
lsd

Pomiń część dotyczącą rsync. Wykonałby replikację, ale jest to przede wszystkim konfiguracje tylko do odczytu, co nie spełnia twoich wymagań. Chciałem edytować mój komentarz powyżej, ale nie pozwolił mi.
lsd

1

Doprowadzenie tego do pracy z DRBD będzie naprawdę trudne - problem nie polega na tym, że n8whnp wydaje się myśleć o problemie z replikacją wielostronną (po prostu tworzysz paski węzłów w zestawie lustrzanym), ale ma kontrolę współbieżności - ty ' d trzeba uruchomić system plików klastra na dublowaniu na DRBD.

lsyncd jest jeszcze gorszy, ponieważ nie ma praktycznego rozwiązania do kontroli współbieżności.

Poleciłbym rozwiązanie typu AFS (AFS, OpenAFS) jako dojrzałe, stabilne, otwarte rozwiązanie. Trzymam się z daleka od blasku, odkąd Oracle go zamknęła. Nie jestem zbyt zaznajomiony z glusterfs, ale ponieważ opiera się on na rozproszonej, a nie replikowanej pamięci, polecam przyjrzeć się, jak będzie się zachowywać w trybie podzielonego mózgu (AFS OTOH jest zaprojektowany do pracy w trybie odłączonym).

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.