Desempenho terrível de sincronização DRBD no 10GigE


15

Configurei um par de servidores idênticos com matrizes RAID (8 núcleos, 16 GB de RAM, 12x2 TB RAID6), 3 interfaces 10GigE, para hospedar alguns serviços altamente disponíveis.

Os sistemas estão atualmente executando o Debian 7.9 Wheezy oldstable (porque o corosync / pacemaker não está disponível no 8.x estável nem nos testes).

  • O desempenho do disco local é de cerca de 900 MB / s de gravação e 1600 MB / s de leitura.
  • a taxa de transferência de rede entre as máquinas é superior a 700 MB / s.
  • através do iSCSI, cada máquina pode gravar no armazenamento da outra a mais de 700 MB / s.

No entanto, independentemente da maneira como eu configuro o DRBD, o rendimento é limitado a 100 MB / s. Realmente parece algum limite codificado. Posso diminuir o desempenho de maneira confiável, ajustando as configurações, mas nunca ultrapassa 1 Gbit (122 MB / s são alcançados por alguns segundos por vez). Estou realmente puxando meu cabelo neste.

  • kernel simples de baunilha 3.18.24 amd64
  • drbd 8.9.2 ~ rc1-1 ~ bpo70 + 1

A configuração é dividida em dois arquivos 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;
        }
}

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

Saída do cat /proc/drbdescravo:

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

Saída do vmstat 2mestre (ambas as máquinas estão quase completamente inativas):

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

Saída iperfentre os dois servidores:

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

Aparentemente, a sincronização inicial deve ser um pouco lenta, mas não tão lenta ... Além disso, ela realmente não reage a nenhuma tentativa de acelerar a taxa de sincronização drbdadm disk-options --resync-rate=800M all.


1
Você tentou compilá-lo de forma assíncrona, depois pará-lo e reconstruí-lo sincronizado novamente?
Xavier Nicollet

Respostas:


11

Nas versões mais recentes do DRBD (8.3.9 e mais recente), há um controlador de ressincronização dinâmica que precisa de ajuste. Nas versões mais antigas do DRBD, a configuração syncer {rate;}era suficiente; agora é usado mais como um ponto de partida sugerido para a velocidade de ressincronização dinâmica.

O controlador de sincronização dinâmica é ajustado com as "configurações-c" na seção de disco da configuração do DRBD (consulte $ man drbd.confpara obter detalhes sobre cada uma dessas configurações).

Com 10Gbe entre esses nós, e assumindo baixa latência desde que o protocolo C é usado, a seguinte configuração deve acelerar o processo:

recurso rd0 {
        protocolo C;
        disco {
                alvo de preenchimento c 10M;
                taxa c-max 700M;
                c-planejar antecipadamente 7;
                taxa c-min 4M;
        }
        no cl1 {
                dispositivo / dev / drbd0;
                disco / dev / sda4;
                endereço 192.168.42.1:7788;
                meta-disco interno;
        }

        no cl2 {
                dispositivo / dev / drbd0;
                disco / dev / sda4;
                endereço 192.168.42.2:7788;
                meta-disco interno;
        }
}

Se você ainda não está feliz, tente max-buffersaumentar para 12k. Se você ainda não estiver feliz, tente aumentar c-fill-targetem 2 milhões.


Na verdade, com essa configuração, o desempenho cai para 3 MB / s. Estou tentando brincar com essas configurações, mas as perspectivas são sombrias.
wazoox

Até agora, desabilitar o c-plan-ahead, definindo-o como zero e aumentando o tamanho máximo de época e os buffers máximos parece fazer o truque.
wazoox

2
O que acontece se você aumentar o máximo de buffers para 20k e c-fill-target para 20M? Acredito que aumentar lentamente esses dois valores acabará fornecendo os resultados que você está procurando.
precisa saber é o seguinte

Isso é muito melhor! Ele não satura o link (que é dedicado e apesar de ser bom preencher), mas eu já estou em 400MB / s. Eu estou jogando um pouco com essas configurações ...
wazoox

1
Levantando max-buffers de 250-2500 fez a diferença noite e dia para mim (na minha configuração não crítica performance)
davidgo

7

Alguém sugeriu que eu use essas configurações:

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

E o desempenho é excelente.

Edit: Conforme @Matt Kereczman e outras sugestões, eu finalmente mudei para isso:

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

A velocidade de ressincronização é alta:

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

A velocidade de gravação é excelente durante a ressincronização com essas configurações (80% da velocidade de gravação local, velocidade total do fio):

# 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

A velocidade de leitura está 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

Edição posterior:

Após uma ressincronização completa, o desempenho é muito bom (gravação da velocidade do fio, leitura da velocidade local). A ressincronização é rápida (5/6 horas) e não prejudica muito o desempenho (leitura da velocidade do fio, gravação da velocidade do fio). Definitivamente vou ficar com c-plan-ahead em zero. Com valores diferentes de zero, a ressincronização é muito longa.


Aumentar o número máximo de buffers para 131K não é a abordagem mais elegante para resolver seu problema. Você está basicamente dando ao DRBD 512MiB de buffers do sistema para usar na ressincronização, que é muito espaço no buffer. Vi coisas acontecerem com buffers máximos maiores que 80k. Eu recomendo ajustar as configurações do controlador de ressincronização, enquanto aumenta o máximo de buffers em pequenos incrementos até que você esteja feliz.
Matt Kereczman

@MattKereczman Vou alterar as configurações, mas gostaria de ter um cluster (sincronizado) ideal o mais rápido possível antes de jogar com as configurações de produção .... As configurações padrão significam que a sincronização leva pelo menos vários dias e até a várias semanas, isso simplesmente não é aceitável. A taxa de transferência de produção necessária é de 500 MB / s.
wazoox

4

O c-plan-ahead precisa definir um valor positivo para ativar o controlador de taxa de sincronização dinâmica. disco c-plan-ahead 15; // 5 * RTT / 0.1s unit,in my case is 15 c-fill-target 24; c-max-rate 720M;

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.