[MEGOLDVA] DRBD lassú (WAN-on)

Hálózatok általános

Sziasztok!

Milyen paramétert kell a DRBD-nél állítani, hogy akkor is kihasználja a sávszélességet, ha 70 ms a ping a két node között?
Most így néz ki:


resource backup {
options {
}
net {
protocol A;
sndbuf-size 10485760; # bytes
rcvbuf-size 10485760; # bytes
cram-hmac-alg "sha1";
shared-secret "sharedsecret";
on-congestion pull-ahead;
}
_remote_host {
address ipv4 192.x.y.z1:7789;
}
_this_host {
address ipv4 192.x.y.z2:7789;
volume 0 {
device minor 1;
disk "/dev/drbdvg/drbdlv";
meta-disk internal;
disk {
resync-rate 112640k; # bytes/second
c-plan-ahead 0; # 1/10 seconds
c-delay-target 0; # 1/10 seconds
}
}
}
}

Iperf legalább 30Mbps -t mért a két node között, viszont a szinkornizálás lassú:


1: cs:SyncTarget ro:Secondary/Secondary ds:Inconsistent/UpToDate A r-----
ns:0 nr:1435648 dw:1435648 dr:0 al:0 bm:0 lo:1 pe:4 ua:0 ap:0 ep:1 wo:f oos:271185756
[>....................] sync'ed: 0.6% (264828/266228)M
finish: 258:56:40 speed: 276 (284) want: 112,640 K/sec

Mind a két node Debian Jessie.
Milyen paramétert nem vettem észre a doksiban ami segíthet?

  • 1834 megtekintés

( andrej_ v | 2016. 09. 08., cs – 22:17 )

Ha esetleg teljes szinkront vársz el a tuloldalon, akkor a 70ms már a visszaigazolások válaszideje miatt is lassíthat akár.

( kallaics | 2016. 09. 08., cs – 22:31 )

Talán a félkövérrel kiemelt rész?

disk {
resync-rate 112640k; # bytes/second
c-plan-ahead 0; # 1/10 seconds
c-delay-target 0; # 1/10 seconds
}

mi történik, ha módosítod mondjuk 10M -re a 112640k-t?
Egyforma a mért sebesség ha elhagyod a k-t a resync rate-nél és elosztod ezerrel. Lehet hülyeség, lehet véletlen, csak egy tipp.


1: cs:SyncSource ro:Secondary/Secondary ds:UpToDate/Inconsistent A r-----
ns:29101992 nr:0 dw:0 dr:29105152 al:0 bm:1775 lo:0 pe:4 ua:0 ap:0 ep:1 wo:f oos:246930268
[>...................] sync'ed: 9.5% (241140/266228)Mfinish: 235:47:02 speed: 276 (320) K/sec

Sajnos semmi sem változott.

--
http://blog.htmm.hu/

Nem benéztem, tényleg erre akartam használni. Nem kell nagy sávszélesség (csak a backup távoli része megy ide), de azért 300 kBpsnél többre számítottam. Főleg úgy, hogy közben egyik magon sem látszott jelentős terhelés.
Ráadásul a VPN-t kikerülve, scp-vel megvolt az elvárt sávszélesség.

--
http://blog.htmm.hu/

( Cni | 2016. 09. 08., cs – 22:38 )

En amikor fel akarom huzni a syncet ezekkel operalok:
drbdadm disk-options --resync-rate=valami drbd[X]
drbdadm disk-options --c-min-rate=valami drbd[X]
a valami helyere valami jo nagy szamot sozktam beirni
amikor keszen van akkor meg egy adjust :)

( Elbandi v | 2016. 09. 08., cs – 23:01 )

bar ez nem pont valasz a kerdesedre, de a net reszhez add hozza ezt:
verify-alg sha1;
csums-alg sha1;

es ha meg nincs irva a diskre semmi, akkor kezd elorol a drdb-t ossze, de elotte a disket (nalad a /dev/drbdvg/drbdlv) ird teli 0-val mindket oldalon. ugyanis ha a csums-alg be van kapcsolva, akkor egy adatblockrol hasht csinal, es csak akkor kuldi at a teljes block adatot ha kulonbozo a hash a ket oldalon. (mivel te 0-val teliirtad elotte, igy valoszinu egyezni fognak a hashek => csak keves adatot kell atkuldeni a halon => gyors lesz a sync).

persze ez kesobb nem segit, ha nagy mennyisegu iras lesz a drbd-re.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( Fisher v | 2016. 09. 10., szo – 12:34 )

Csak ötletelek. Ha jól látom, VPN-en át megy. Az iperf is a VPN-en át ment? És kapcsolgasd a VPN-t is, mondjuk a tömörítést ide/oda :D

( vl v | 2016. 09. 10., szo – 13:10 )

tcpdump.

Elsőre olyanokat keresnék, hogy
- a TCP window size már az elején sem 10MB (ahogy a konfigodban van), hanem valami irreálisan kicsi szám
- valaki %-ban mérhető packet dropot okoz
- ha tunnelben nyomod (márpedig láthatóan abban), akkor vajon mennyi a tunnel MTU-ja? ez tükröződik-e a TCP MSS-ben? véletlenül sem fragmentált packetok mennek a gépből ki, ugye?
- valóban 70ms az RTT? jönnek is szépen az ACK-ok 70ms múlva vissza?