DRBD terrible rendimiento de sincronización en 10GigE


15

He configurado un par de servidores idénticos con matrices RAID (8 núcleos, 16 GB de RAM, 12x2 TB RAID6), 3 interfaces 10GigE, para alojar algunos servicios altamente disponibles.

Actualmente, los sistemas ejecutan Debian 7.9 Wheezy oldstable (porque corosync / pacemaker no está disponible en 8.x estable ni prueba).

  • El rendimiento del disco local es de aproximadamente 900 MB / s de escritura, 1600 MB / s de lectura.
  • El rendimiento de la red entre las máquinas supera los 700 MB / s.
  • A través de iSCSI, cada máquina puede escribir en el almacenamiento de la otra a más de 700 MB / s.

Sin embargo, no importa la forma en que configuro DRBD, el rendimiento está limitado a 100 MB / s. Realmente parece un límite codificado. Puedo reducir el rendimiento de manera confiable ajustando la configuración, pero nunca supera 1 Gbit (se alcanzan 122 MB / s durante un par de segundos a la vez). Realmente estoy tirando de mi pelo en este caso.

  • grano de vainilla simple 3.18.24 amd64
  • drbd 8.9.2 ~ rc1-1 ~ bpo70 + 1

La configuración se divide en dos archivos 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;
        }
}

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

Salida del cat /proc/drbdesclavo:

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

Salida desde vmstat 2el maestro (ambas máquinas están casi completamente inactivas):

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

Salida de iperfentre los dos 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, se supone que la sincronización inicial es algo lenta, pero no tan lenta ... Además, en realidad no reacciona a ningún intento de acelerar la velocidad de sincronización como drbdadm disk-options --resync-rate=800M all.


1
¿Has intentado construirlo asíncrono, luego lo detuviste y lo volviste a sincronizar?
Xavier Nicollet

Respuestas:


11

En las versiones más recientes de DRBD (8.3.9 y más recientes) hay un controlador de resincronización dinámica que necesita ajuste. En versiones anteriores de DRBD, la configuración syncer {rate;}era suficiente; ahora se usa más como un punto de partida ligeramente sugerido para la velocidad de resincronización dinámica.

El controlador de sincronización dinámica está sintonizado con la "configuración c" en la sección del disco de la configuración de DRBD (consulte los $ man drbd.confdetalles sobre cada una de estas configuraciones).

Con 10Gbe entre estos nodos, y suponiendo baja latencia desde que se usa el protocolo C, la siguiente configuración debería hacer que las cosas se muevan más rápido:

recurso rd0 {
        protocolo C;
        disco {
                c-fill-target 10M;
                c-max-rate 700M;
                c-plan-ahead 7;
                c-min-rate 4M;
        }
        en cl1 {
                dispositivo / dev / drbd0;
                disco / dev / sda4;
                dirección 192.168.42.1:7788;
                meta-disco interno;
        }

        en cl2 {
                dispositivo / dev / drbd0;
                disco / dev / sda4;
                dirección 192.168.42.2:7788;
                meta-disco interno;
        }
}

Si todavía no estás contento, intenta max-bufferssubir a 12k. Si todavía no estás contento, puedes intentar subir c-fill-targeten incrementos de 2M.


En realidad, con esta configuración, el rendimiento cae a 3 MB / s. Estoy tratando de jugar con estos ajustes, pero las perspectivas son sombrías.
wazoox

Hasta ahora, deshabilitar c-plan-ahead al establecerlo en cero y aumentar max-epoch-size y max-buffers parece ser el truco.
wazoox

2
¿Qué sucede si aumenta el máximo de amortiguadores a 20k y el objetivo de relleno c a 20M? Creo que aumentar lentamente estos dos valores eventualmente le dará los resultados que está buscando.
Matt Kereczman

¡Eso está mucho mejor! No satura el enlace (que es dedicado y aunque está bien llenarlo), pero ya estoy a 400 MB / s. Estoy jugando un poco con esta configuración ...
wazoox

1
El aumento de los buffers máximos de 250 a 2500 marcó una diferencia de día y noche para mí (en mi configuración de rendimiento no crítica)
davidgo

7

Alguien en otro lugar me sugirió que usara esta configuración:

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

Y el rendimiento es excelente.

Editar: según @Matt Kereczman y otras sugerencias, finalmente he cambiado a esto:

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

La velocidad de resincronización es 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

La velocidad de escritura es excelente durante la resincronización con estos ajustes (80% de la velocidad de escritura local, velocidad de cable completa):

# 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

La velocidad de lectura está bien:

# 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

Edición posterior:

Después de una resincronización completa, el rendimiento es muy bueno (escritura a velocidad de cable, lectura de velocidad local). La resincronización es rápida (5/6 horas) y no perjudica demasiado el rendimiento (lectura de velocidad de cable, escritura de velocidad de cable). Definitivamente me quedaré con c-plan-ahead en cero. Con valores distintos de cero, la resincronización es demasiado larga.


Aumentar los buffers máximos a 131K no es el enfoque más elegante para resolver su problema. Básicamente, está proporcionando DRBD 512MiB de búferes de sistema para su resincronización, que es mucho espacio de búfer. He visto que suceden cosas con buffers máximos mayores de 80k. Recomiendo encarecidamente ajustar la configuración del controlador de resincronización, al tiempo que aumenta el máximo de búferes en pequeños incrementos hasta que esté satisfecho.
Matt Kereczman

@MattKereczman Cambiaré la configuración, pero me gustaría tener un clúster óptimo (sincronizado) lo más rápido posible antes de jugar con la configuración de producción ... La configuración predeterminada significa que la sincronización tarda al menos varios días y más a varias semanas, esto simplemente no es aceptable. El rendimiento de producción requerido es de 500 MB / s.
wazoox

4

c-plan-ahead tiene que establecer un valor positivo para habilitar el controlador de velocidad de sincronización 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;

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.