Okropna wydajność synchronizacji DRBD na 10GigE

15

Skonfigurowałem parę identycznych serwerów z macierzami RAID (8 rdzeni, 16 GB pamięci RAM, 12 x 2 TB RAID6), 3 interfejsy 10GigE, aby obsługiwać niektóre wysoce dostępne usługi.

Systemy działają obecnie na starszej stabilnej wersji Debiana 7.9 Wheezy (ponieważ corosync / pacemaker nie jest dostępny na wersji 8.x stabilnej ani testowej).

  • Wydajność lokalnego dysku wynosi około 900 MB / s zapisu, 1600 MB / s odczytu.
  • przepustowość sieci między maszynami wynosi ponad 700 MB / s.
  • za pośrednictwem iSCSI każda maszyna może zapisywać w pamięci drugiej z prędkością większą niż 700 MB / s.

Jednak bez względu na sposób konfiguracji DRBD, przepustowość jest ograniczona do 100 MB / s. To naprawdę wygląda na określony limit. Mogę niezawodnie obniżyć wydajność, modyfikując ustawienia, ale nigdy nie przekracza ona 1 Gb (122 MB / s jest osiągane przez kilka sekund na raz). Naprawdę ciągnę za to włosy.

  • zwykłe jądro waniliowe 3.18.24 amd64
  • drbd 8.9.2 ~ rc1-1 ~ bpo70 + 1

Konfiguracja jest podzielona na dwa pliki global-common.conf:

global {
        usage-count no;
}

common {
        handlers {
        }

        startup {
        }

        disk {
                on-io-error             detach;
         #       no-disk-flushes ;
        }
        net {
                max-epoch-size          8192;
                max-buffers             8192;
                sndbuf-size             2097152;
        }
        syncer {
                rate                    4194304k;
                al-extents              6433;
        }
}

i cluster.res:

resource rd0 {
        protocol C;
        on cl1 {
                device /dev/drbd0;
                disk /dev/sda4;
                address 192.168.42.1:7788;
                meta-disk internal;
        }

        on cl2 {
                device /dev/drbd0;
                disk /dev/sda4;
                address 192.168.42.2:7788;
                meta-disk internal;
        }
}

Wyjście z cat /proc/drbdniewolnika:

version: 8.4.5 (api:1/proto:86-101)
srcversion: EDE19BAA3D4D4A0BEFD8CDE 
 0: cs:SyncTarget ro:Secondary/Secondary ds:Inconsistent/UpToDate C r-----
    ns:0 nr:4462592 dw:4462592 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:16489499884
        [>....................] sync'ed:  0.1% (16103024/16107384)M
        finish: 49:20:03 speed: 92,828 (92,968) want: 102,400 K/sec

Dane wyjściowe z vmstat 2mastera (obie maszyny są prawie całkowicie bezczynne):

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0 14952768 108712 446108    0    0   213   254   16    9  0  0 100  0
 0  0      0 14952484 108712 446136    0    0     0     4 10063 1361  0  0 99  0
 0  0      0 14952608 108712 446136    0    0     0     4 10057 1356  0  0 99  0
 0  0      0 14952608 108720 446128    0    0     0    10 10063 1352  0  1 99  0
 0  0      0 14951616 108720 446136    0    0     0     6 10175 1417  0  1 99  0
 0  0      0 14951748 108720 446136    0    0     0     4 10172 1426  0  1 99  0

Dane wyjściowe iperfmiędzy dwoma serwerami:

------------------------------------------------------------
Client connecting to cl2, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  3] local 192.168.42.1 port 47900 connected with 192.168.42.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  6.87 GBytes  5.90 Gbits/sec

Najwyraźniej początkowa synchronizacja powinna być nieco powolna, ale nie taka powolna ... Co więcej, tak naprawdę nie reaguje na żadną próbę zmniejszenia prędkości synchronizacji drbdadm disk-options --resync-rate=800M all.

wazoox
źródło
1
Czy próbowałeś zbudować go asynchronicznie, a następnie zatrzymać go i ponownie zsynchronizować?
Xavier Nicollet,

Odpowiedzi:

11

W nowszych wersjach DRBD (8.3.9 i nowszych) istnieje kontroler dynamicznej resynchronizacji, który wymaga strojenia. W starszych wersjach DRBD ustawienie syncer {rate;}wystarczyło; teraz jest używany raczej jako lekko sugerowane miejsce początkowe dla prędkości dynamicznej resynchronizacji.

Kontroler synchronizacji dynamicznej jest dostrojony za pomocą „ustawień c” w sekcji dysku konfiguracji DRBD ( $ man drbd.confszczegółowe informacje na temat każdego z tych ustawień).

Z 10Gbe między tymi węzłami i przy założeniu małego opóźnienia, ponieważ używany jest protokół C, następująca konfiguracja powinna przyspieszyć:

zasób rd0 {
        protokół C;
        dysk {
                c-wypełnić-cel 10M;
                stawka c-max 700 mln;
                c-plan na przyszłość 7;
                stawka c-min 4M;
        }
        na cl1 {
                device / dev / drbd0;
                disk / dev / sda4;
                adres 192.168.42.1:7788;
                wewnętrzny meta-dysk;
        }

        na cl2 {
                device / dev / drbd0;
                disk / dev / sda4;
                adres 192.168.42.2:7788;
                wewnętrzny meta-dysk;
        }
}

Jeśli nadal nie jesteś zadowolony, spróbuj max-bufferszwiększyć do 12 000. Jeśli nadal nie jesteś zadowolony, możesz spróbować pojawiać się c-fill-targetco 2M.

Matt Kereczman
źródło
W rzeczywistości przy tej konfiguracji wydajność spada do 3 MB / s. Próbuję bawić się tymi ustawieniami, ale perspektywy są ponure.
wazoox,
Jak dotąd wydaje się, że wyłączenie c-planu z wyprzedzeniem przez ustawienie go na zero i zwiększenie maksymalnego rozmiaru epoki i maksymalnych buforów wydaje się załatwić.
wazoox
2
Co się stanie, jeśli zwiększysz maks. Liczbę buforów do 20 tys., A cel c-fill do 20 mln? Wierzę, że powolne zwiększenie tych dwóch wartości w końcu da wyniki, których szukasz.
Matt Kereczman,
To jest o wiele lepsze! Nie nasyca linku (który jest dedykowany i chociaż można go wypełnić), ale już mam prędkość 400 MB / s. Gram trochę z tymi ustawieniami ...
wazoox
1
Zwiększenie maksymalnej liczby buforów z 250 do 2500 stanowiło dla mnie różnicę w dzień iw dzień (w mojej niekrytycznej konfiguracji wydajności)
davidgo,
7

Ktoś inny sugerował, żebym użył tych ustawień:

        disk {
                on-io-error             detach;
                c-plan-ahead 0;
        }
        net {
                max-epoch-size          20000;
                max-buffers             131072;
        }

A wydajność jest doskonała.

Edycja: Zgodnie z sugestiami @Matt Kereczman i innych, w końcu zmieniłem na:

disk {
        on-io-error             detach;
        no-disk-flushes ;
        no-disk-barrier;
        c-plan-ahead 0;
        c-fill-target 24M;
        c-min-rate 80M;
        c-max-rate 720M;
} 
net {
        # max-epoch-size          20000;
        max-buffers             36k;
        sndbuf-size            1024k ;
        rcvbuf-size            2048k;
}

Szybkość ponownej synchronizacji jest wysoka:

cat /proc/drbd
version: 8.4.5 (api:1/proto:86-101)
srcversion: EDE19BAA3D4D4A0BEFD8CDE
 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---n-
    ns:133246146 nr:0 dw:2087494 dr:131187797 al:530 bm:0 lo:0 pe:5 ua:106 ap:0 ep:1 wo:d oos:4602377004
        [>....................] sync'ed:  2.8% (4494508/4622592)M
        finish: 1:52:27 speed: 682,064 (646,096) K/sec

Szybkość zapisu jest doskonała podczas resynchronizacji z tymi ustawieniami (80% lokalnej prędkości zapisu, pełna prędkość drutu):

# dd if=/dev/zero of=./testdd bs=1M count=20k
20480+0 enregistrements lus
20480+0 enregistrements écrits
21474836480 octets (21 GB) copiés, 29,3731 s, 731 MB/s

Prędkość odczytu jest OK:

# dd if=testdd bs=1M count=20k of=/dev/null
20480+0 enregistrements lus
20480+0 enregistrements écrits
21474836480 octets (21 GB) copiés, 29,4538 s, 729 MB/s

Późniejsza edycja:

Po pełnej ponownej synchronizacji wydajność jest bardzo dobra (zapis prędkości drutu, odczyt prędkości lokalnej). Resynchronizacja jest szybka (5/6 godzin) i nie wpływa zbytnio na wydajność (odczyt prędkości drutu, zapis prędkości drutu). Na pewno pozostanę z c-planem z wyprzedzeniem na zero. W przypadku wartości niezerowych ponowna synchronizacja jest zbyt długa.

wazoox
źródło
Zwiększenie maksymalnej liczby buforów do 131 KB nie jest najbardziej wdzięcznym podejściem do rozwiązania problemu. Zasadniczo dajesz DRBD 512 MB buforów systemowych do użycia w celu jego ponownej synchronizacji, która jest dużą ilością bufora. Widziałem, że coś się dzieje z maksymalnymi buforami większymi niż 80k. Zdecydowanie zaleciłbym dostrajanie ustawień kontrolera resynchronizacji, jednocześnie zwiększając maksymalne bufory w małych przyrostach, aż będziesz zadowolony.
Matt Kereczman,
@MattKereczman Zmienię ustawienia, ale chciałbym mieć optymalny (zsynchronizowany) klaster tak szybko, jak to możliwe, zanim zaczniesz grać z ustawieniami produkcyjnymi .... Domyślne ustawienia oznaczają, że synchronizacja trwa co najmniej kilka dni i więcej do kilku tygodni jest to po prostu niedopuszczalne. Wymagana przepustowość produkcji wynosi 500 MB / s.
wazoox,
4

c-plan z wyprzedzeniem musi ustawić wartość dodatnią, aby włączyć kontroler dynamicznej szybkości synchronizacji. dysk c-plan-ahead 15; // 5 * RTT / 0.1s unit,in my case is 15 c-fill-target 24; c-max-rate 720M;

Keven
źródło