Okropna wydajność synchronizacji DRBD na 10GigE

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.

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.

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.

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;