Добрый день,
Извините за мой английский, это не мой родной язык, и в последнее время у меня меньше, чем следовало бы, аналитического письма.
У меня установлен ESXi 6.0.0 с обновлением 2 на голом железе сервера HP Proliant. Он достаточно хорошо работает с двумя внешними корпусами для жестких дисков, подключенными через 2 RAID-контроллера P411. Кроме того, некоторые из внутренних 2,5-дюймовых разъемов сервера заняты твердотельными накопителями (лишь небольшая часть из них), обслуживаемыми встроенным RAID-контроллером HP P410 (да, я знаю, что это плохо). Все жесткие и твердотельные диски разделены на несколько хранилищ данных в зависимости от их размера и скорости вращения, и все хранилища данных настроены как RAID10.
Естественно, существует несколько виртуальных машин, ежедневно поступает много производственных данных, и внезапно появляется решение для резервного копирования, использующее выделенную виртуальную машину с установленным надлежащим программным обеспечением, а также выделенное хранилище данных, работающее на 8 дешевых дисках SATA 5400 об / мин по 3 ТБ каждый, что в сумме составляет 12 ТБ. резервного копирования первого уровня на месте.
Существует / был второй уровень резервного копирования на месте, а именно резервная копия наиболее важных виртуальных машин, сделанная на 4 ТБ ST4000NM0055, расположенном в корпусе с внешним питанием, подключенном к резервной виртуальной машине через сквозную карту PCI-USB3.1.
Недавно вышла из строя карта PCI-USB3.1 (она не была одобрена VMWare, но проработала около года), и я решил переместить резервную копию, чтобы подключить ее по более стабильному и безопасному пути. Это было сделано путем использования существующего незанятого порта SATA, расположенного непосредственно на материнской плате этого сервера HP Proliant. Порт SATA запитан, он задокументирован как SSD SATA, похоже, работает через другой контроллер, не связанный с вышеупомянутыми P410 и P411.
Поэтому я купил подходящий кабель и подключил Seagate ST8000NM0055 к порту SATA. Сразу после подключения нового диска к резервной виртуальной машине через хранилище данных с тонким выделением ресурсов объемом 7 ТБ я заметил, что производительность перемещения файлов оставляет желать лучшего: перемещение резервного копирования со старого диска USB 3.0 начинается со скоростью 70-80 МБ / с (мегабайт в секунду), но в пределах От 10 до 15 минут упал до 10 Мбит / с и остановился на этом уровне на несколько часов. Ожидалось, что операция по перемещению файла размером 3 ТБ завершится через 80–90 часов с момента начала.
Я предположил, что крупномасштабное перемещение файлов и выделение базового дискового пространства для VMDK с тонким выделением ресурсов - это в основном две тяжелые операции для одного и того же объема данных, поэтому, вероятно, это было причиной такой неожиданно низкой скорости передачи данных. Чтобы ускорить процесс, я решил раздуть VMDK с тонким предоставлением с того момента 300 ГБ до целевых 7 ТБ. Я выключил резервную виртуальную машину и щелкнул правой кнопкой мыши надуть в веб-интерфейсе операций VMWare vCenter.
Это произошло 6 дней назад, и диск все еще накачивается ... Сервер не испытывает большой нагрузки на ЦП или диск, его загрузка составляет от 15 до 25% от всех видов емкости. Так что я думаю, что это время выходит за рамки обычного, однако у меня нет другого выбора, кроме как ждать, как будто отменить я потеряю уже переданные 300 ГБ некритичных, но сентиментальных данных.
Ежедневно проверяя, как идут дела, я заметил, что не только IOPS записи довольно низки, но и через 3-4 дня работы они внезапно увеличились почти вдвое. Единственная операция, выполняемая с этим носителем, - это надувание диска.
Запись IOPS внезапно увеличилась вдвое
Общая производительность записи ужасная
Было найдено и опробовано несколько настроек, таких как включение и выключение аппаратного ускорения хранилища данных в настройках хоста ESXi, а именно следующие параметры - DataMover.HardwareAcceleratedInit от 1 до 0 - DataMover.HardwareAcceleratedMove от 1 до 0 - VMFS3.HardwareAcceleratedLocking от 1 до 0 они дали не влияет ни на SATA, ни на хранилища данных SAS.
Что мне не хватает для хорошей производительности этого диска? Исходя из опыта домашнего ПК, я ожидаю, что он будет легко выполнять операции со скоростью не менее 100 Мбит / с, поэтому полная инфляция должна занять 20 часов вместо 180 часов, на которые мы нацелены в настоящее время.
TL; DR: ESXI 6.0, похоже, я застрял на скорости записи 10 МБ / с для напрямую подключенного жесткого диска SATA. Иногда он подскакивает до кричащих 20 Мбит / с. Пожалуйста, пришлите помощь, чтобы объяснить
Причина такой ужасной производительности заключалась в том, что HP BIOS Drive Write Cache по умолчанию отключил.
После изменения на «Включено» (очевидно, что здесь требуется цикл включения питания) производительность вернулась к норме, как и ожидалось от этой модели Enterprise HDD.
