Storage High Availability - Jaki mechanizm replikacji wybrac do sprzętu.

[ox1de 0]

A więc, te 2 dni dały mi jeszcze troszkę więcej wiedzy, znowu poczytałem.

Stworzyłem GlusterFs-a sprawdziłem jak to funkcjonuje, nie robiłem żadnych testów wydajnościowych póki co, bo prawda jest taka że to będzie pierwsze takie wdrożenie dlatego na razie obeznałem się z mechanizmami.

 

Doszedłem do punktu w którym zapadł decyzja co do podłączenia zasobów replikowanych do proxmoxa, i pozostanie to nadal NFS tylko w wersji HA z heartbeat lub Pacemaker + Gluster lub DRBD. Co do mechanizmu replikacji będę musiał zrobić testy wydajnościowe, ale to w przyszły tydzien jak dostane kolejne dwie półki dyskowe i serwery.

Pozostała mi jeszcze kwestia tych "split brain" o którym była wcześniej mowa, domyślam się że to też można jakoś zautomatyzować, ale to będzie problem do rozwiazania gdy go wygeneruje już na pełnoprawnym środowisku podczas testów oraz rodzaju replikacji active:active lub active:passive.

A no i OS na to muszę jakiś wybrać Albo debian albo CentOS, nie mogę się zdecydować

Edytowano Styczeń 11, 2016 przez ox1de (zobacz historię edycji)

[mcbarlo 61]

Split-brain to jest raczej sytuacja kiedy Ty musisz ręcznie zdecydować na którym storage znajdują się aktualne dane i ten właśnie stanie się źródłem do synchronizacji.

[ox1de 0]

A widzisz, dzięki za naprostowanie.

[Gość Adam Szendzielorz]

A widzisz, dzięki za naprostowanie.

Uzywam od ~kilku lat DRBD na klastrze HA zrobionym na pacemakerze - dziala bardzo przyzwoicie, mam tam trzy replikowane (master-slave) zasoby - nie sa bardzo duze (w sumie ok 1TB) ale calosc dziala bardzo dobrze. Od strony sieciowej - dwa switche, dwie sieciowki, dwa niezalezne porty do internetu i zrobiony zwykly bonding - dziala wysmienicie

 

Samemu DRBD raz na ruski rok zdarzy sie split-brain ale nigdy nie mialem problemu z przywroceniem go do poprawnego dzialania, oczywiscie bez przerw w dzialaniu zasobow.

pozdr.

Edytowano Styczeń 12, 2016 przez Adam Szendzielorz (zobacz historię edycji)

[ox1de 0]

Także buduje redundantnie z tym że do zastosowań produkcyjnych w firmie z półkami dyskowymi 24 - 48 TB A którą wersje DRBD męczysz? Ja będe testował ostatnią stabilną czyli chyba 8.x

Właśnie chłopaki jeszcze takie małe pytanie, co w momencie gdy będę chciał rozszerzyć pojemność półek wymieniając dyski z 2TB na 4TB, Lub jeśli będę chciał dołożyć kolejne zasoby do klastra (kolejną półkę? Jak taki proces wygląda?

[Gość Adam Szendzielorz]

Także buduje redundantnie z tym że do zastosowań produkcyjnych w firmie z półkami dyskowymi 24 - 48 TB A którą wersje DRBD męczysz? Ja będe testował ostatnią stabilną czyli chyba 8.x

8.4.2

 

Właśnie chłopaki jeszcze takie małe pytanie, co w momencie gdy będę chciał rozszerzyć pojemność półek wymieniając dyski z 2TB na 4TB, Lub jeśli będę chciał dołożyć kolejne zasoby do klastra (kolejną półkę? Jak taki proces wygląda?

DRBD to tylko "fizyczna" czesc, jezeli nie bedziesz uzywal zadnego sieciowego filesystemu to ja polecam ZFS - chyba najlepszy filesystem jaki znam - rozbudowa o kolejna polke to moze dwa proste polecenia

[ox1de 0]

Będę używał sieciowego systemu plików, NFS z opcja HA, muszę udostępnić te zasoby na inne serwery pod maszyny wirtualne.

[Gość Adam Szendzielorz]

Będę używał sieciowego systemu plików, NFS z opcja HA, muszę udostępnić te zasoby na inne serwery pod maszyny wirtualne.

NFS to tylko protokol udostepniania systemu plikow - mozesz udostepniac via NFS filesystem ext4, mozesz ZFS, mozesz wiele innych Polecam zainteresowac sie ZFSem - to IMHO najlepszy filesystem jaki istnieje na swiecie - port ZFS on Linux jest juz od jakiegos czasu stabilny i dziala swietnie :-)

 

Jeszcze tylko dodam, ze DRBD działa jak najbardziej poprawnie z pacemakerem - są moduły do obsługi DRBD, wiec zrobisz na tym bez problemu HA

 

Troche upierdliwy bywa NFS w rozwiązaniach HA, niby działa ale przy przełączaniu raz na ruski rok bywa, że coś się nie chce odmontować albo zamontować

Edytowano Styczeń 12, 2016 przez Adam Szendzielorz (zobacz historię edycji)

[mcbarlo 61]

Należy jednak dodać, że aby ZFS działał świetnie potrzebuje dużo ramu. Wydajne konfigi dla dużego storage to nie jest rzecz trywialna. Dla 1 TB to żaden stres, ale dla 48 TB uważam, że 64 GB RAM będzie niezbędne i może l2arc cache na SSD.

 

Elastyczność ZFS-a jest świetna, ale jednak nie jest do zbawienie dla świata. Mnie niestety przy partycji wielkości 21 TB przy zapełenieniu do połowy sypał błedami zapisu. Było to jakieś 3 lata temu, więc może się coś zmieniło. Dla storage do 6 TB działa u mnie bezawaryjnie i też sobie chwalę.

[ox1de 0]

aaaaa kumam już, faktycznie pomyliłem tematy To nie ja mam półki na ext4 puki co, w tym wypadku tez zrobię rozeznanie jak to wygląda, dzieki za sugestie

 

Edit:

 

Czyli jak wszystko ma swoje wady i zalety, ja mam jedna partycje na ext4 22TB i działa do dobrze, ale jeśli faktycznie ZFS ciągnie tyle zasobów to troszkę nie fajnie bo musze mieć mega serwer żeby to obsłużyć a będę miał 3 takie półki i możliwe ze zwieksze ich zasoby do 46TB i co wtedy ?

Edytowano Styczeń 12, 2016 przez ox1de (zobacz historię edycji)

[Gość Adam Szendzielorz]

Należy jednak dodać, że aby ZFS działał świetnie potrzebuje dużo ramu. Wydajne konfigi dla dużego storage to nie jest rzecz trywialna. Dla 1 TB to żaden stres, ale dla 48 TB uważam, że 64 GB RAM będzie niezbędne i może l2arc cache na SSD.

Prawda Ale jak kogoś stać na 48TB storagu to 64GB RAM to już pan pikuś :-)

[ox1de 0]

Owszem nie był by to problem ale teraz trzeba sobie odpowiedzieć jakie korzyści przyniesie mi ZFS wzgledem innych mniej wymagających systemów plików przy takiej infrastrukturze jaką mam teraz w firmie, Tak naprawdę to nie jest jakiś kluster obliczeniowy, czy gigantyczny system bazodanowy, to będzie bardziej przechowalnia z wysoką dostępniością.

A tyle TB dlatego że przy RIPie plików do druków wielkoformatowych generują się spore pliki, a wszystkie projekty z zeszłych lat maja być przechowywane, taka polityka.

 

 

EDIT

 

Owszem jest ERP z bazą MSSQL ponad 50GB, serwery terminali na MS, VPN, i inne pierdoły, ale wydaje mi sie żę te "mniej wymagające" systemy plików bez problemu to uciągną i wcale nie będą się gorzej spisywać. Nie ma sęsnu wytaczać armaty na muche, tak mi się wydaje.

Edytowano Styczeń 12, 2016 przez ox1de (zobacz historię edycji)

[Gość Adam Szendzielorz]

Owszem nie był by to problem ale teraz trzeba sobie odpowiedzieć jakie korzyści przyniesie mi ZFS wzgledem innych mniej wymagających systemów plików przy takiej infrastrukturze jaką mam teraz w firmie, Tak naprawdę to nie jest jakiś kluster obliczeniowy, czy gigantyczny system bazodanowy, to będzie bardziej przechowalnia z wysoką dostępniością.

A tyle TB dlatego że przy RIPie plików do druków wielkoformatowych generują się spore pliki, a wszystkie projekty z zeszłych lat maja być przechowywane, taka polityka.

Największe zalety ZFS to właśnie wysoka dostępność. Już widzę jak odpalasz FSCK na takim ext4 48TB - dwa dni nie Twoje ZFS przede wszystkim gwarantuje integralność danych - obojętnie co by się nie działo (awarie prądu, dysków etc) - on zawsze działa i ew. sprawdzenie integralności danych dzieje się przy normalnie działającym filesystemie. Dodatkowo możesz tworzyć jednym poleceniem snapshoty danych (perfekt do robienia kopii zapasowych), przesyłać rożnice w snapshotach po sieci i wiele innych. Ja tam polecam - zainteresuj się

[ox1de 0]

Tak czy siak sprawdzę, pewnie że tak, ale czy będę wdrażał zobaczymy

[Kszysiu 136]

Największe zalety ZFS to właśnie wysoka dostępność.

Co w nim takiego wysokodostępnego? Przecież chyba nie będzie walił kolejnej warstwy redundancji, czyli raidz jak ma replikacje w drbd? Czy to ja po prostu czegoś nie kumam?

[ox1de 0]

ooo zaczyna się

Ale fakt, sam system plików to jeszcze nic wysokodostępnego

Btw. półki HDD są w raid5, na tą chwilę

[Gość Adam Szendzielorz]

Co w nim takiego wysokodostępnego? Przecież chyba nie będzie walił kolejnej warstwy redundancji, czyli raidz jak ma replikacje w drbd? Czy to ja po prostu czegoś nie kumam?

Już napisałem co - ten filesystem w praktyce nie wymaga żadnego sprawdzania, bo zawsze jest zdrowy. A jeżeli wymaga - to robi to w tle na działającym systemie

 

Replikacja w DRBD to będzie tylko replikacja sieciowa, lokalnie jasne, że i tak lepiej jest zrobić sensowny raidz. Olać w ogóle RAID5 z kontrolera, podpiąć wszystkie dyski jako pojedyncze volumeny i całość raida robić na ZFSie jak radzi manual. DRBD jest tutaj zupełnie niezależne, to tylko sieciowa replikacja danych na zewnątrz.

 

To zresztą kolejna zaleta jaką daje ZFS - ja mam np. 18 dysków i zrobione 6 stripów po 3 raidz1, wydajność jest świetna, a i redundancja niezła

Ale fakt, sam system plików to jeszcze nic wysokodostępnego

Już pisałem - jak Ci przyjdzie zrobić fsck na tym 20parę TB z kilkunastoma milionami plików to pazury poobgryzasz nawet w nogach z nerwów, nim to stanie się *dostępne* online, bo to przecież cecha "wysokiej *dostępności*"

Edytowano Styczeń 12, 2016 przez Adam Szendzielorz (zobacz historię edycji)

[Dentarg 46]

@Adam Szendzielorz: Jaki port pod CentOS/Redhat ZFSa jest stabilny? Co prawda testowałem jakiś rok temu, ale brakowało kilku ważny feature (np. direct I/O) a co jakiś czas potrafił się sypnąć z kernel panic. ZFS to mocarz (ale na Solku). Jakby był stabilny to sam bym przeszedł (nie śledziłem ostatnio rozwoju, jeśli już jest to miodzio).

 

BTW: Ja RAID5 bym nie używał na półkach, szczególnie jak "storage pool'e" są duże (dużo dysków w jednym secie RAID5). Co prawda masz redundancję na 2 półkach (przez DRBD), ale widziałem tyle padniętych RAID5, że głowa mała. Ale ważniejsza sprawa to write penality dla RAID5. Jeśli trzymasz tam tą 50GB bazę ERP to jakbyś prosił o problemy z wydajnością . Tylko nie wpadnij na pomysł pójścia w RAID6, żeby mieć więcej dysków "zapasowych" .

[mcbarlo 61]

RAID oparty na bitach parzystości jest dobry tylko pod kopie, bo jest tani. Każdy inny przypadek to zło. Ryzyko utraty danych przy dużym storage przez wystąpienie URE i kiepska wydajność w zapisie. Patenty typu RAID50 też bym nie polecał.

[ox1de 0]

Nie nie trzymam tam bazy, baza stoi na innym serwerze raid5 na 3hdd sas + log na osobnym raid5 z 3 hdd takze sas i tak pozostanie z tym ze tez wprowadze redundancje na kolejne serwery w takiej samej konfiguracji dyskow. Takze baze na polce raczej odpuszcze.

[Gość Adam Szendzielorz]

@Adam Szendzielorz: Jaki port pod CentOS/Redhat ZFSa jest stabilny?

http://zfsonlinux.org/

 

Używam pod Slackwarem kompilowane ze źrodeł.

 

To jest już stabilne od jakiegoś czasu. Chwalę, jest stabilne :-)

W tym momencie są jedynie jeszcze problemy z kernel panicami jak próbujesz się dostać do snapshotów przez ukryty katalog .zfs po NFSie (lokalnie nie ma z tym żadnych problemów Innych problemów nie stwierdziłem - a codziennie mielę tam kilka milionów plików.

 

BTW: Ja RAID5 bym nie używał na półkach, szczególnie jak "storage pool'e" są duże (dużo dysków w jednym secie RAID5). Co prawda masz redundancję na 2 półkach (przez DRBD), ale widziałem tyle padniętych RAID5, że głowa mała. Ale ważniejsza sprawa to write penality dla RAID5. Jeśli trzymasz tam tą 50GB bazę ERP to jakbyś prosił o problemy z wydajnością . Tylko nie wpadnij na pomysł pójścia w RAID6, żeby mieć więcej dysków "zapasowych" .

Popieram, nigdy nigdzie nie używam RAID5. Pozatym - jak w takim dużym zasobie dysk padnie to się będzie parę dni odbudowywać, a w tym czasie wydajność będzie mizerna

pozdr.

Nie nie trzymam tam bazy, baza stoi na innym serwerze raid5 na 3hdd sas + log na osobnym raid5 z 3 hdd takze sas i tak pozostanie z tym ze tez wprowadze redundancje na kolejne serwery w takiej samej konfiguracji dyskow. Takze baze na polce raczej odpuszcze.

Odpuść tego RAID5 i używaj RAID10 - znacznie większa wydajność

[ox1de 0]

Jak będzie przesiadka na nowy serwer jeśli chodzi o bazę ERP, to pomyślę o tym.

Półki będę miał jeszcze 2 czyli w sumie 3 łącznie, to dwóch nowych bede wkładał już dyski 12x4TB i zrobie raida10 w takim razie, dużo wydajniejszy jest ?

[Dentarg 46]

Polecam: http://theithollow.com/2012/03/21/understanding-raid-penalty/ - chociaż to tylko wierzchołek tematu .

[Kszysiu 136]

Odpuść tego RAID5 i używaj RAID10 - znacznie większa wydajność

4 repliki?

[Gość Adam Szendzielorz]

4 repliki?

Czemu 4?

Jak będzie przesiadka na nowy serwer jeśli chodzi o bazę ERP, to pomyślę o tym.

Półki będę miał jeszcze 2 czyli w sumie 3 łącznie, to dwóch nowych bede wkładał już dyski 12x4TB i zrobie raida10 w takim razie, dużo wydajniejszy jest ?

Przy zapisie - dużo. Przy odbudowywaniu - dużo szybszy.

Ja tam jednak polecam raidz z ZFSa. Przy standardowym RAID10 zostanie Ci uzyteczne 24TB, przy stripie 4 raidz1 bedziesz mial uzyteczne 32TB, przy podobnej (jak nie wiekszej!) wydajnosci. Wydajnosc RAID5 w normalnym zastosowaniu zależy tylko i wyłącznie od szybkości samego kontrolera.

 

A jeżeli nie zależy Ci aż tak na prędkości, to możesz sobie dodatkowo włączyć kompresję w locie na dowolnym poolu (w dowolnym momencie) - ZFS robi to z bardzo małym kosztem CPU - wtedy wyciągniesz z 40-50TB z tego w zależności od rodzaju przechowywanych danych

pozdr.