Когда я выполняю тяжелые операции с диском, такие как удаление 10k файлов за раз, общий сетевой ресурс перестает отвечать на запросы и не будет обслуживать файлы в течение короткого времени.
Вот моя конфигурация. У меня есть отказоустойчивый кластер файлового сервера, состоящий из двух серверов Windows 2008 R2 Enterprise. Каждый сервер представляет собой виртуальную машину, работающую поверх двух независимых серверов Dell Poweredge под управлением Windows Hyper-V. Оба сервера Dell имеют выделенные сетевые адаптеры для сети SAN Dell MD3000i. Каждая виртуальная машина файлового сервера направляет свои подключения iSCSI через этот выделенный сетевой адаптер для подключения к тому в сети SAN, где находятся файлы.
Если я запускаю командный файл, который выполняет 10 тыс. Удалений с удаленного компьютера, который ссылается на файл по имени общего ресурса (т.е. \\ fileserver \ sharename \ folder \ filename.jpg), он может выполнить 1000 или 8000 удалений до того, как общий ресурс будет выдан. Каждый раз случайный. По иронии судьбы, пакетный файл продолжит удаление файлов, но другие серверы, обращающиеся к файлам на том же общем ресурсе, будут задержаны. Файлы, которые я удаляю, не будут доступны другим серверам, поэтому блокировка этих конкретных файлов не является проблемой.
Если я запускаю тот же командный файл на главном сервере кластера файлов и ссылаюсь на файлы по их локальному пути (например, x: \ folder \ filename.jpg), общий ресурс немедленно отключается, и другие серверы сидят и ждут. Доступ к этому общему ресурсу возобновится, когда я завершу запуск командного файла.
У кого-нибудь есть идея относительно причины отключения доли или что я могу сделать для дальнейшей диагностики этой проблемы? Любые предложения приветствуются.
Обновленное примечание: я выделил эту проблему, чтобы она возникала только в пределах поля хоста. Ни один сетевой трафик, задействованный для репликации этой проблемы с виртуальными машинами, не достигает физического коммутатора, к которому подключается блок хоста, кроме подключения iSCSI к SAN. Соединение iSCSI имеет собственный выделенный коммутатор и частную подсеть для SAN за пределами стандартного сетевого трафика.
Это кричит о каком-то истощении ресурсов. Если бы это был хост Linux, я бы подумал: «Это похоже на загрузку IO-Wait». Проверьте мониторы производительности на уровне ОС, как указал mfinni. У вас есть две области, которые могут стать узкими местами, а именно производительность логического / физического диска и производительность сети при сетевом подключении iSCSI. PerfMon может вам это предоставить. Я вообще не знаю HyperV, но если это что-то вроде VMWare, тогда у вас есть некоторые показатели производительности на стороне гипервизора, которые вы также можете изучить. Сделай так.
Как теорияя предполагаю, что очень высокий уровень обновлений метаданных, который вы делаете, вызывает некоторую внутреннюю задержку в вашем стеке iSCSI для увеличения. Это, в свою очередь, вытесняет другие запросы ввода-вывода или метаданных, что приводит к симптомам, которые вы описываете, другие процессы могут получить слово в сторону, поскольку блоки MFT забиваются этим другим процессом. Это может быть вызвано самим iSCSI, но уровень виртуальной машины, вероятно, добавляет свои собственные внутренние задержки. Если это действительно проблема, вы можете подумать о том, чтобы вместо этого представить iSCSI LUN гипервизору, а затем представить полученный диск виртуальной машине; таким образом вы не полагаетесь на виртуализированный сетевой адаптер для iSCSI, вы полагаетесь на физический.
Редактировать: Похоже, у вас наверняка такая вина на руках. Я бы обратил внимание на счетчики PerfMon: «Отправлено байт / сек» и «Отправлено пакетов / сек» для интерфейса, на котором выполняется соединение iSCSI. Комбинация этих двух параметров должна дать вам средний размер пакета. (в качестве альтернативы, если у вас есть возможность, включите сниффер в цикл и посмотрите, как выглядят пакеты на сетевом коммутаторе. Это более надежный метод, если вы можете это сделать) Если размер этого пакета довольно мал (скажем, ниже 800 байт), то вы ничего не можете с этим поделать, кроме как перейти к уровню TCP и посмотреть, какие оптимизации могут быть сделаны между узлами кластера и целью iSCSI. Server 2008 придирчив к настройкам TCP, так что здесь можно получить выгоду.
О Боже. Есть ли что-нибудь в средстве просмотра событий, указывающее на то, что в ОС наблюдается какое-то истощение ресурсов? Можете ли вы проверить с помощью perfmon?