У нас есть узел dell, на котором запущено несколько виртуальных машин, расположенных в хранилище питания dell. Пользователи жаловались на периодическое замедление работы (например, долгое время на поиск папки или более длительное время ответа после входа в систему). Они ВСЕГДА виновата сеть, но эти VMS подключены через кабели SAS к хостам и через сеть 10 ГБ к основному коммутатору. Я сам видел замедление, но не курил, не знал, как начать отслеживать это. Я знаю, что мог бы сделать то, что я сделал однажды, когда жаловались на замедление, и увидел 4 разных RSYNCS, работающих на подключенном диске данных с другой виртуальной машины. Они сказали, что это не должно странно замедлять что-либо, когда эти процессы rsync были убиты, все двигалось быстрее.
Я установил для них эти виртуальные машины и пулы/тома powervault, и, хотя я новичок в VMWare, VCenter, Powervaults и т. д., у меня отключены две такие установки, а вторичная отлично работает для другой группы.
Итак немного информации:
Медленная виртуальная машина данных монтирует свой большой диск с помощью этой команды (команда монтирования):
/dev/sdb1 on /data type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
в фстабе:
/dev/sdb1 /data ntfs defaults 0 0
У нас есть виртуальная машина-концентратор, которая монтирует диск данных виртуальной машины данных для больших объемов пространства для записи: команда mount:
10.25.x.xxx:/data on /data type nfs4 (rw,noatime,nodiratime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.25.y.yyy,local_lock=none,addr=10.25.x.xxx)
фстаб:
10.25.x.xxx:/data /data nfs4 rw,nodiratime,noatime,rs
На виртуальной машине данных, на которой диск напрямую смонтирован iotop:
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
735 be/4 root 0.00 B/s 308.45 K/s 0.00 % 0.21 % mount.ntfs /dev/sdb1 /data -o rw
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd --switched-root --system --deserialize 22
Понятия не имею, что такое mount.ntfs, но похоже, что он занимает много ресурсов.
Я попытался выполнить ioping из концентратора, который обращается к данным vm (таким образом, к диску данных) и dd, чтобы получить дополнительную информацию:
(system) [root@hubVM ioping-1.0]# ./ioping -c 10 /data
4 KiB <<< /data (nfs4 10.25.x.xxx:/data): request=1 time=177.5 us (warmup)
4 KiB <<< /data (nfs4 10.25.x.xxx:/data): request=2 time=214.0 us
4 KiB <<< /data (nfs4 10.25.x.xxx:/data): request=3 time=140.7 us
4 KiB <<< /data (nfs4 10.25.x.xxx:/data): request=4 time=3.39 ms
4 KiB <<< /data (nfs4 10.25.x.xxx:/data): request=5 time=140.7 us
4 KiB <<< /data (nfs4 10.25.x.xxx:/data): request=6 time=187.5 us
4 KiB <<< /data (nfs4 10.25.x.xxx:/data): request=7 time=184.0 us (fast)
4 KiB <<< /data (nfs4 10.25.x.xxx:/data): request=8 time=154.6 us (fast)
4 KiB <<< /data (nfs4 10.25.x.xxx:/data): request=9 time=111.8 us (fast)
4 KiB <<< /data (nfs4 10.25.x.xxx:/data): request=10 time=288.4 us
--- /data (nfs4 10.25.x.xxx:/data) ioping statistics ---
9 requests completed in 4.81 ms, 36 KiB read, 1.87 k iops, 7.31 MiB/s
generated 10 requests in 9.00 s, 40 KiB, 1 iops, 4.44 KiB/s
min/avg/max/mdev = 111.8 us / 534.2 us / 3.39 ms / 1.01 ms
Также некоторые данные dd из hub vm в datavm
time dd if=/dev/zero of=/data/testfile2 bs=16k count=128k
131072+0 records in
131072+0 records out
2147483648 bytes (2.1 GB) copied, 35.3667 s, 60.7 MB/s
real 0m35.538s
user 0m0.015s
sys 0m1.139s
pyenv: no such command `sh-activate'
Я не уверен, что все это говорит мне.
У меня есть еще один хост vm в своей собственной другой сети, который делает свое дело для другой группы, настроенной таким же образом, и это цифры из того, что я вижу (нет жалоб на скорость со стороны пользователей в этом)
Во-первых, как монтируется большой диск из этой второй группы hubvm
10.50.x.xxx:/data/archive /archive nfs4 rw,nodiratime,noatime,rsize=8192,wsize=8192,bg,intr,tcp 0 0
Затем данные ioping из второй группы hubvm в data vm:
[root@hubvm ioping-1.0]# ./ioping -c 10 /archive
4 KiB <<< /archive (nfs4 10.50.x.xxx:/data/archive): request=1 time=277.9 us (warmup)
4 KiB <<< /archive (nfs4 10.50.x.xxx:/data/archive): request=2 time=359.7 us
4 KiB <<< /archive (nfs4 10.50.x.xxx:/data/archive): request=3 time=269.3 us
4 KiB <<< /archive (nfs4 10.50.x.xxx:/data/archive): request=4 time=349.6 us
4 KiB <<< /archive (nfs4 10.50.x.xxx:/data/archive): request=5 time=327.5 us
4 KiB <<< /archive (nfs4 10.50.x.xxx:/data/archive): request=6 time=301.6 us
4 KiB <<< /archive (nfs4 10.50.x.xxx:/data/archive): request=7 time=263.7 us (fast)
4 KiB <<< /archive (nfs4 10.50.x.xxx:/data/archive): request=8 time=267.9 us (fast)
4 KiB <<< /archive (nfs4 10.50.x.xxx:/data/archive): request=9 time=259.9 us (fast)
4 KiB <<< /archive (nfs4 10.50.x.xxx:/data/archive): request=10 time=408.5 us (slow)
--- /archive (nfs4 10.50.x.xxx:/data/archive) ioping statistics ---
9 requests completed in 2.81 ms, 36 KiB read, 3.21 k iops, 12.5 MiB/s
generated 10 requests in 9.00 s, 40 KiB, 1 iops, 4.44 KiB/s
min/avg/max/mdev = 259.9 us / 312.0 us / 408.5 us / 49.6 us
дд данные
time dd if=/dev/zero of=/archive/testfile2 bs=16k count=128k
131072+0 records in
131072+0 records out
2147483648 bytes (2.1 GB) copied, 4.79677 s, 448 MB/s
real 0m4.798s
user 0m0.012s
sys 0m1.120s
С самого начала он говорит 448 МБ/с для одного хоста с виртуальными машинами, который работает быстро, а затем 60,7 МБ/с для хоста, который медленный и отстает, и время записи на него истекает. Так что не уверен, как это отследить, например, в чем причина 60 МБ/с против 448 МБ/с.
Не знаете, где искать дальше? Конфигурация сети? (должно быть одинаковым на обоих vCenter, сеть 10 ГБ, подключенная к каждому хосту, имеющему на них определенные внутренние подсети, которые у нас есть.
Какая-то конфигурация, которую я пропустил в нашем vCenter? или основной коммутатор cisco? внутри вм?
Кодджой