4 votes

d99kris avatar

E/S élevée sur le disque DRBD drbd10 sur le site empilé

Demandé el 7 de Octobre, 2016
Quand la question a-t-elle été
842 affichage
Nombre de visites la question a
1 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Nous avons 4 boîtes Redhat Dell PowerEdge R630 (disons a,b,c,d) ayant les OS/packages suivants.

RedHat EL 6.5 MySql Enterprise 5.6 DRBD 8.4 Corosync 1.4.7

Nous avons configuré des ressources drbd empilées à 4 voies comme ci-dessous :

Cluster-1 : serveurs a et b connectés l'un à l'autre par un réseau local Cluster-2 : serveurs c et d

Les clusters Cluster-1 et Cluster-2 sont attachés par drbd empilé via des IP virtuelles et font partie de différents centres de données.

Les disques drbd0 ont été créés localement sur chaque serveur 1GB, et sont ensuite attachés à drbd10.

La configuration globale comprend 4 couches : Application frontale Tomcat -> rabbitmq -> memcache -> mysql/drbd

Nous avons un très haut niveau de Disk IO, même l'activité n'est pas indispensable pour le moment. Mais le trafic/activité va augmenter dans quelques semaines, et nous craignons que cela n'ait un très mauvais impact sur les performances. L'utilisation des entrées/sorties est élevée uniquement sur les sites superposés (90% et plus parfois). Les sites secondaires n'ont pas ce problème et l'utilisation est parfois élevée lorsque l'application est idéale.

Veuillez donc nous donner quelques conseils ou directives de réglage qui nous aideront à résoudre ce problème ;

resource clusterdb {
protocol C;
handlers {
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notifyemergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notifyemergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergencyshutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
}
startup {
degr-wfc-timeout 120; # 2 minutes.
outdated-wfc-timeout 2; # 2 seconds.
}
disk {
on-io-error detach;
no-disk-barrier;
no-md-flushes;
}

net {
cram-hmac-alg "sha1";
shared-secret "clusterdb";
after-sb-0pri disconnect;
after-sb-1pri disconnect;
after-sb-2pri disconnect;
rr-conflict disconnect;
}

syncer {
rate 10M;
al-extents 257;
 on-no-data-accessible io-error;
 }

 on sever-1 {
 device /dev/drbd0;
 disk /dev/sda2;
 address 10.170.26.28:7788;
 meta-disk internal;
 }
 on ever-2 {
 device /dev/drbd0;
 disk /dev/sda2;
 address 10.170.26.27:7788;
 meta-disk internal;
 }
}

La configuration empilée : -

    resource clusterdb_stacked {
  protocol A;
handlers {
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notifyemergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notifyemergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergencyshutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
}
startup {
degr-wfc-timeout 120; # 2 minutes.
outdated-wfc-timeout 2; # 2 seconds.
}
disk {
on-io-error detach;
no-disk-barrier;
no-md-flushes;
}

net {
cram-hmac-alg "sha1";
shared-secret "clusterdb";
after-sb-0pri disconnect;
after-sb-1pri disconnect;
after-sb-2pri disconnect;
rr-conflict disconnect;
}

syncer {
rate 10M;
al-extents 257;
 on-no-data-accessible io-error;
 }

  stacked-on-top-of clusterdb {
    device     /dev/drbd10;
    address   10.170.26.28:7788;
  }
 stacked-on-top-of clusterdb_DR {
    device     /dev/drbd10;
    address    10.170.26.60:7788; 
  }
}

Les données demandées:-

Date || svctm(w_wait)|| %util
10:32:01 3.07 55.23 94.11
10:33:01 3.29 50.75 96.27
10:34:01 2.82 41.44 96.15
10:35:01 3.01 72.30 96.86
10:36:01 4.52 40.41 94.24
10:37:01 3.80 50.42 83.86
10:38:01 3.03 72.54 97.17
10:39:01 4.96 37.08 89.45
10:41:01 3.55 66.48 70.19
10:45:01 2.91 53.70 89.57
10:46:01 2.98 49.49 94.73
10:55:01 3.01 48.38 93.70
10:56:01 2.98 43.47 97.26
11:05:01 2.80 61.84 86.93
11:06:01 2.67 43.35 96.89
11:07:01 2.68 37.67 95.41

Mise à jour de la question selon les commentaires :-

C'est élevé en fait de comparer le local avec le superposé.

Entre serveurs locaux

[root@pri-site-valsql-a]#ping pri-site-valsql-b
PING pri-site-valsql-b.csn.infra.sm (10.170.24.23) 56(84) bytes of data.
64 bytes from pri-site-valsql-b.csn.infra.sm (10.170.24.23): icmp_seq=1 ttl=64 time=0.143 ms
64 bytes from pri-site-valsql-b.csn.infra.sm (10.170.24.23): icmp_seq=2 ttl=64 time=0.145 ms
64 bytes from pri-site-valsql-b.csn.infra.sm (10.170.24.23): icmp_seq=3 ttl=64 time=0.132 ms
64 bytes from pri-site-valsql-b.csn.infra.sm (10.170.24.23): icmp_seq=4 ttl=64 time=0.145 ms
64 bytes from pri-site-valsql-b.csn.infra.sm (10.170.24.23): icmp_seq=5 ttl=64 time=0.150 ms
64 bytes from pri-site-valsql-b.csn.infra.sm (10.170.24.23): icmp_seq=6 ttl=64 time=0.145 ms
64 bytes from pri-site-valsql-b.csn.infra.sm (10.170.24.23): icmp_seq=7 ttl=64 time=0.132 ms
64 bytes from pri-site-valsql-b.csn.infra.sm (10.170.24.23): icmp_seq=8 ttl=64 time=0.127 ms
64 bytes from pri-site-valsql-b.csn.infra.sm (10.170.24.23): icmp_seq=9 ttl=64 time=0.134 ms
64 bytes from pri-site-valsql-b.csn.infra.sm (10.170.24.23): icmp_seq=10 ttl=64 time=0.149 ms
64 bytes from pri-site-valsql-b.csn.infra.sm (10.170.24.23): icmp_seq=11 ttl=64 time=0.147 ms
^C
--- pri-site-valsql-b.csn.infra.sm ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 10323ms
rtt min/avg/max/mdev = 0.127/0.140/0.150/0.016 ms

Entre deux serveurs empilés

[root@pri-site-valsql-a]#ping dr-site-valsql-b
PING dr-site-valsql-b.csn.infra.sm (10.170.24.48) 56(84) bytes of data.
64 bytes from dr-site-valsql-b.csn.infra.sm (10.170.24.48): icmp_seq=1 ttl=64 time=9.68 ms
64 bytes from dr-site-valsql-b.csn.infra.sm (10.170.24.48): icmp_seq=2 ttl=64 time=4.51 ms
64 bytes from dr-site-valsql-b.csn.infra.sm (10.170.24.48): icmp_seq=3 ttl=64 time=4.53 ms
64 bytes from dr-site-valsql-b.csn.infra.sm (10.170.24.48): icmp_seq=4 ttl=64 time=4.51 ms
64 bytes from dr-site-valsql-b.csn.infra.sm (10.170.24.48): icmp_seq=5 ttl=64 time=4.51 ms
64 bytes from dr-site-valsql-b.csn.infra.sm (10.170.24.48): icmp_seq=6 ttl=64 time=4.52 ms
64 bytes from dr-site-valsql-b.csn.infra.sm (10.170.24.48): icmp_seq=7 ttl=64 time=4.52 ms
^C
--- dr-site-valsql-b.csn.infra.sm ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6654ms
rtt min/avg/max/mdev = 4.510/5.258/9.686/1.808 ms
[root@pri-site-valsql-a]#

La sortie montrant un haut I/O:-

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
drbd0             0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.06    0.00    0.00   99.94

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
drbd0             0.00     0.00    0.00    2.00     0.00    16.00     8.00     0.90    1.50 452.25  90.45

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.25    0.00    0.13    0.50    0.00   99.12

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
drbd0             0.00     0.00    1.00   44.00     8.00   352.00     8.00     1.07    2.90  18.48  83.15

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.13    0.00    0.06    0.25    0.00   99.56

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
drbd0             0.00     0.00    0.00   31.00     0.00   248.00     8.00     1.01    2.42  27.00  83.70

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.19    0.00    0.06    0.00    0.00   99.75

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
drbd0             0.00     0.00    0.00    2.00     0.00    16.00     8.00     0.32    1.50 162.25  32.45

J'ai modifié le fichier des propriétés, mais je n'ai toujours pas de chance.

disk {
on-io-error detach;
no-disk-barrier;
no-disk-flushes;
no-md-flushes;
c-plan-ahead 0;
c-fill-target 24M;
c-min-rate 80M;
c-max-rate 300M;
al-extents 3833;
}

net {
cram-hmac-alg "sha1";
shared-secret "clusterdb";
after-sb-0pri disconnect;
after-sb-1pri disconnect;
after-sb-2pri disconnect;
rr-conflict disconnect;
max-epoch-size 20000;
max-buffers 20000;
unplug-watermark 16;
}

syncer {
rate 100M;
 on-no-data-accessible io-error;
 }
Demandé el 7 de Octobre, 2016 par d99kris

0 votes

Avatar de d99kris

Tout pointeur ????

Commenté el 18 de Octobre, 2016 par d99kris

0 votes

Avatar de d99kris

@Matt Kereczman J'ai essayé de déconcerter temporellement la pile. L'attente diminue alors, mais l'E/S reste élevée. J'ai aussi essayé avec quelques paramètres d'ajustement, mais cela n'a pas aidé. Je les ai ajoutés à la question. Toute aide/commentaire est fortement appréciée.

Commenté el 18 de Octobre, 2016 par d99kris

Réponse

Trop de publicités?

2voto

dnwjn avatar
dnwjn Points 3

Je ne vois pas la ressource empilée dans votre configuration. Vous n'avez pas non plus mentionné de numéro de version, mais le fait de voir al-extents défini si bas me fait penser que vous utilisez quelque chose d'ancien (8.3.x) ou que vous avez suivi des instructions très anciennes.

Quoi qu'il en soit, en supposant que vous utilisiez le protocole A pour la réplication de votre dispositif empilé (asynchrone), vous allez toujours remplir rapidement vos tampons d'envoi TCP lors des pics d'E/S et, par conséquent, subir une attente d'E/S pendant que le tampon se vide ; DRBD doit placer ses écritures répliquées quelque part et ne peut avoir qu'un nombre limité d'écritures répliquées non reconnues en cours de vol.

L'attente des E/S contribue à la charge du système. Si vous déconnectez temporairement la ressource empilée, la charge du système se stabilise-t-elle ? Ce serait un moyen de vérifier que c'est bien le problème. Vous pouvez également examiner vos tampons TCP avec quelque chose comme netstat ou ss pour voir s'ils sont pleins lorsque la charge est élevée.

À moins que la latence et le débit de la connexion entre vos sites ne soient incroyables (fibre noire, ou autre), vous devez/voulez probablement envisager d'utiliser DRBD Proxy de LINBIT ; il vous permet d'utiliser la mémoire système pour mettre en mémoire tampon les écritures.

Répondu el 9 de Octobre, 2016 par dnwjn (3 Points )

0 votes

Avatar de d99kris

La version est 8.4.0 Et je vais mettre à jour la question avec la configuration empilée

Commenté el 10 de Octobre, 2016 par d99kris

0 votes

Avatar de d99kris

Les entrées/sorties ne sont élevées que sur les serveurs empilés. Sur les serveurs secondaires internes, le pourcentage d'utilisation des E/S est correct. Il n'y a pratiquement aucun ajout de données (aucune opération de lecture ou d'écriture sur MYSQL), lorsque l'utilisation est élevée.

Commenté el 10 de Octobre, 2016 par d99kris

0 votes

Avatar de dnwjn

@Manu avez-vous essayé de déconnecter la ressource empilée ? Les serveurs secondaires ne sont pas capables d'effectuer des entrées-sorties parce qu'ils sont, eh bien, des serveurs secondaires. Vous pouvez également utiliser 'iostat' pour consulter les statistiques du disque, en particulier 'w_await'.

Commenté el 10 de Octobre, 2016 par dnwjn
Afficher 7 autres commentaires

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X