DRBD страшна продуктивність синхронізації на 10GigE


15

Я створив пару однакових серверів з масивами RAID (8 ядер, 16 ГБ оперативної пам’яті, 12x2 ТБ RAID6), 3 інтерфейсами 10GigE, щоб розмістити деякі високодоступні сервіси.

Наразі в системах працює Debian 7.9 Wheezy oldstable (оскільки коросинхронізація / кардіостимулятор недоступні на стаціонарному режимі 8.x, ні на тестуванні).

  • Продуктивність на локальному диску становить близько 900 Мб / с запису, 1600 Мб / с прочитаного.
  • пропускна здатність мережі між машинами перевищує 700 Мб / с.
  • через iSCSI кожна машина може записувати на інший накопичувач понад 700 Мб / с.

Однак, незалежно від способу налаштування DRBD, пропускна здатність обмежена 100 Мб / с. Це дійсно схоже на деякий жорсткий код. Я можу надійно знизити продуктивність, налаштувавши налаштування, але він ніколи не перевищує 1 Гбіт (122 МБ / с досягається за пару секунд одночасно). Я справді зачісую волосся на цьому.

  • ядра ванілі 3.18.24 amd64
  • drbd 8.9.2 ~ rc1-1 ~ bpo70 + 1

Конфігурація розділена на два файли 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;
        }
}

і 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;
        }
}

Вихід з cat /proc/drbdпідлеглого:

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

Вихід з vmstat 2головного (обидва машини майже повністю простоюють):

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

Вихід iperfміж двома серверами:

------------------------------------------------------------
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

Мабуть, початкова синхронізація повинна бути дещо повільною, але не такою повільною ... Крім того, вона насправді не реагує на будь-яку спробу прискорити швидкість синхронізації drbdadm disk-options --resync-rate=800M all.


1
Ви намагалися створити його як асинхронізацію, а потім зупинити її та відновити її синхронізовано знову?
Ксав'є Ніколет

Відповіді:


11

У новіших версіях DRBD (8.3.9 і новіших) є динамічний контролер пересинхронізації, який потребує настройки. У старих версіях налаштування DRBD syncer {rate;}було достатньо; тепер він використовується більше як легке запропоноване місце старту для динамічної швидкості пересинхронізації.

Контролер динамічної синхронізації налаштовується на "c-налаштуваннях" в розділі диска конфігурації DRBD (див. $ man drbd.confПодробиці щодо кожного з цих параметрів).

З 10Gbe між цими вузлами та припускаючи низьку затримку, оскільки використовується протокол C, наступна конфігурація повинна рухатися швидше:

ресурс rd0 {
        протокол С;
        диск {
                c-fill-target 10M;
                c-max швидкість 700M;
                c-план-вперед 7;
                c-хв швидкість 4М;
        }
        на cl1 {
                пристрій / dev / drbd0;
                диск / dev / sda4;
                адреса 192.168.42.1:7788;
                метадиск внутрішній;
        }

        на cl2 {
                пристрій / dev / drbd0;
                диск / dev / sda4;
                адреса 192.168.42.2:7788;
                метадиск внутрішній;
        }
}

Якщо ви все ще не задоволені, спробуйте max-buffersдовести до 12 к. Якщо ви все ще не задоволені, можете спробувати піднятися c-fill-targetз кроком 2М.


Насправді при такій конфігурації продуктивність падає до 3 Мб / с. Я намагаюся грати з цими налаштуваннями, але перспективи похмурі.
wazoox

Поки що вимкнення програми c-plan заздалегідь, встановивши його на нуль та збільшивши розмір max-epoch та max-буферів, схоже, робить свою справу.
wazoox

2
Що станеться, якщо збільшити max-буфери до 20k, а c-fill-target до 20M? Я вірю, що повільне збільшення цих двох значень зрештою дасть вам результати, які ви шукаєте.
Метт Керечман

Це набагато краще! Це не насичує посилання (яке присвячене, і хоча це нормально заповнювати), але я вже на 400 Мб / с. Я трохи граю з цими налаштуваннями ...
wazoox

1
Підвищення максимальних буферів від 250 до 2500
змінило

7

Хтось ще запропонував мені використовувати ці налаштування:

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

І продуктивність відмінна.

Редагувати: Відповідно до пропозицій @Matt Kereczman та інших, я остаточно змінив це:

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;
}

Швидкість повторної синхронізації висока:

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

Швидкість запису є відмінною під час повторної синхронізації з цими налаштуваннями (80% локальної швидкості запису, повна швидкість проводу):

# 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

Швидкість читання нормальна:

# 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

Пізніше редагуйте:

Після повної ресинхронізації продуктивність дуже хороша (запис швидкості проводів, зчитування локальної швидкості). Ресинхронізація швидка (5/6 годин) і не заважає продуктивності (читання швидкості дроту, запис швидкості проводів). Я обов'язково залишатимусь з нульовим планом вперед на нулі. При ненульових значеннях пересинхронізація занадто довга.


Підвищення максимальних буферів до 131K - це не найвишуканіший підхід до вирішення вашої проблеми. Ви по суті даєте DRBD 512MiB системних буферів використовувати для його пересинхронізації, що є багато буферного простору. Я бачив, як це відбувається з максимальними буферами більше 80 кк. Я настійно рекомендую налаштувати настройки контролера ресинхронізації, збільшуючи при цьому макс-буфери з невеликими кроками, поки ви не будете задоволені.
Метт Керечман

@MattKereczman Я зміню налаштування, але я хотів би мати оптимальний (синхронізований) кластер якомога швидше, перш ніж грати з налаштуваннями виробництва .... Налаштування за замовчуванням означають, що синхронізація займає щонайменше кілька днів і більше до декількох тижнів, це просто не прийнятно. Необхідна виробнича пропускна здатність - 500 МБ / с.
wazoox

4

c-план заздалегідь повинен встановити позитивне значення для включення динамічного регулятора швидкості синхронізації. диск c-plan-ahead 15; // 5 * RTT / 0.1s unit,in my case is 15 c-fill-target 24; c-max-rate 720M;

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.