Как разрешить ВМ использовать всю пропускную способность локального хранилища?
Дано: Хост VMware 6.7, на нем рейд-5 из 8 6-ТБ дисков, на хосте ВМка для бэкапов, которой это хранилище практически полностью отдано под данные. На ВМ WS2012R2, VeeamBackup 10.0. Проблема в том, что при попытке забэкапить ВМ с соседнего хоста sustained скорость записи на диск изнутри ВМ показывает 38-31МБ/с (зависит от фазы луны и неизвестных параметров, первые пару минут бывает и выше), при этом скорость чтения самого Veeam бывает равной, бывает 60+МБ, бывает и выше сотни, если диск, который бэкапится, частично забит нулями. Это было бы нормально, если бы массив не позволял работать быстрее и намного быстрее. Я подозреваю, что в районе VMware 6.5 разработчики ESXi где-то вместе с политиками, запрещающими насыщение сетевого хранилища запросами с одной ВМ, воткнули такие же или их самих в отношении локальных хранилищ (DAS в смысле). По крайней мере, когда соседняя ВМ начала принимать резервные копии из другого источника параллельно с бэкапом на этой на то же самое физическое хранилище, общая скорость записи, измеренная в esxtop, достигала 76МБ/с, по 38 на ВМ. Такая же проблема с самим хостом - скорость обмена данными с хранилищем также упирается в 38МБ/с, измерял путем запуска inflate на диск с хранилищем и отслеживал esxtop. То есть, картина маслом выглядит так: любой источник записи получает 38МБ/с гарантированной полосы и некоторый кредит на превышение, после чего включаются некие ограничения на уровне между рейдом и ядром ESXi, судя по счетчикам esxtop (DAVG~20ms/запрос, остальные 0-2ms), не дающие ему увеличить скорость выше обнаруженного предела. Остальные симптомы: при работе бэкапа виндовый perfmon показывает скорость в те же 38МБ/с, длина очереди на диск с хранилищем =1, esxtop показывает уменьшение длины очереди на диск вскоре после начала бэкапа со стартовых 64 до 4, не исправляется параметрами вроде `esxcli storage core device set -d eui.d260037300d00000 -s 0 -q 0` оно же отключение троттлинга на хранилище, или `esxcli storage core device set -d eui.d260037300d00000 -O 16 -m 16 -f`, оно же установка минимального значения длины очереди, вне зависимости от значений (не применяются, -m должен ограничивать очередь снизу, все равно в процессе работы очередь проваливается под 16). Драйвер контроллера aacraid 6.0.6.2.1.59002, модель железа Adaptec ASR8805. Куда копать? Доки VMware по оптимизации хранилища уже прошерстил, а больше ничего не находится.
Тип виртуальной машины какой? ок, какая ОС в госте? если к примеру винда то смотреть драйвера, дело в том что там по умолчанию могут стоять эмулированный сетевой контроллер, который будет грузить процессор и не очень эффективно работать, если же поставить vmware tools и повыбирать сетевые адапртеры в настройках виртулки... https://kb.vmware.com/s/article/1001805 (резюме, выбирайте paravirtual)
rPman Так... Хост 6.7U3, ВМ Windows Server 2019, тип ВМ - хм, это вы о чем? Hardware version 15 (6.7U2+). VMware tools стоят, сетевая VMXNET3 (т.е. paravirtual), контроллер SCSI стоит LSI Logic SAS, альтернатива Paravirtual по идее доступна. Поменяю, посмотрю на скорость. Но вопрос остается, почему сам хост так медленно работает с дисками - на нем-то уже нет никаких виртуализаций.
Странно я по тексту понял что тормоза у вас именно в гостевых машинах (или как написали между хостом и гостевой)
VMXNET3 это виртуально 10Гб сетевая карта, но требует драйвера в гостевой vmware tools, должна однозначно давать скорость максимальную
Нужно протестировать скорость передачи данных между гостевой и хостовой системой или ее локальной сети, каким-нибудь iperf (есть и под windows), он просто гонит сгенерированный трафик без использования диска. Этот тест исключит влияние проблем с диском, если это они
Я подозреваю, что в районе VMware 6.5 разработчики ESXi где-то вместе с политиками, запрещающими насыщение сетевого хранилища запросами с одной ВМ, воткнули такие же или их самих в отношении локальных хранилищ (DAS в смысле).
Простой
Простой
