スタックサイトのDRBDディスクdrbd10でI / Oが高い
次のOS /パッケージを備えた4つのRedhatボックスDellPowerEdge R630（たとえば、a、b、c、d）があります。
RedHat EL 6.5 MySql Enterprise 5.6 DRBD 8.4 Corosync 1.4.7
以下のように、4ウェイスタックdrbdリソースをセットアップしました。
クラスタークラスター-1：サーバーaとbが互いに接続されているローカルLANクラスタークラスター-2：サーバーcとd
Cluster Cluster-1とCluster-2は、仮想IPを介してスタックされたdrbdを介して接続され、異なるデータセンターの一部です。
Drbd0ディスクは各サーバー1GBでローカルに作成され、さらにdrbd10に接続されています。
全体的なセットアップは4つのレイヤーで構成されています：Tomcatフロントエンドアプリケーション-> rabbitmq-> memcache-> mysql/drbd
非常に高いディスクIOが発生していますが、現時点ではアクティビティが必須ではありません。ただし、トラフィック/アクティビティは数週間で増加するため、パフォーマンスに非常に悪い影響を与えることが懸念されます。 I/O使用率は、スタックサイトでのみ高くなっています（90％以上になることもあります）。セカンダリサイトではこの問題は発生していません。アプリケーションが理想的な場合は、使用率が高くなることがあります。
そのため、問題の解決に役立つアドバイス/調整ガイドラインを共有してください。
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;
}
}
スタック構成：-
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;
}
}
要求されたデータ：-
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
コメントに従って質問に更新します：-
実際にはローカルとスタックを比較すると高いです。
ローカルサーバー間
[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
2つのスタックサーバー間
[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]#
高い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
プロパティファイルを編集しましたが、まだ運がありません
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;
}
構成にスタックされたリソースが表示されません。バージョン番号についても言及していませんが、al-extentsが非常に低く設定されているのを見ると、古いもの（8.3.x）を実行しているか、非常に古い指示に従っているように思われます。
とにかく、スタックデバイスのレプリケーション（非同期）にプロトコルAを使用していると仮定すると、TCP送信バッファーは、IOスパイク時に、すぐにいっぱいになります。その結果、ヒットIOバッファがフラッシュするまで待機します。DRBDはレプリケートされた書き込みをどこかに配置する必要があり、確認されていないレプリケートされた書き込みを大量に実行することしかできません。
IO待機はシステム負荷に寄与します。スタックされたリソースを一時的に切断すると、システムの負荷は安定しますか？これが問題であることを確認する1つの方法です。また、netstatやssなどのTCPバッファーを調べて、負荷が高いときにそれらがどれだけいっぱいになっているかを確認することもできます。
サイト間の接続の遅延とスループットが驚くべきもの（ダークファイバーなど）でない限り、おそらくLINBITのDRBDプロキシの使用を検討する必要があります。システムメモリを使用して書き込みをバッファリングできます。