Сеть нашей компании (я считаю, что это домен Windows, работающий на сервере 2008) очень медленный. Ярким примером этого является копирование файлов через SMB - списки занимают минуты, а копирование файлов даже небольшого размера занимает еще больше времени. Когда к нему обращаются по этому поводу, ИТ-менеджер (который, несмотря на любые другие достоинства, который у него может быть, очень упрямый и не очень технический человек) вскидывает руки, становится очень защищающимся и извиняется, вместо того чтобы слушать и пытаться выясните первопричину проблемы.
Теперь, осознавая, что для решения этой проблемы потребуется время и усилия, я не знаю, как технически опровергнуть его оправдания. В данном случае он утверждает, что проблема в SMB и что это «медленный» протокол. Есть ли доказательства этого утверждения (у меня есть только анекдотические встречные доказательства)? Как лучше всего развить этот аргумент?
SMB вполне может быть медленнее, чем некоторые другие протоколы обмена файлами, и вполне может быть быстрее, чем некоторые другие. Но это не главное.
Вместо того, чтобы делать этот вопрос / аргумент, можете ли вы найти способ отойти от этого и спросить, работает ли SMB так же быстро (или так медленно!), Как предполагаемый быть. Например, можете ли вы передать файл с помощью FTP между сервером и рабочей станцией, которая страдает от медлительности и увидит заметный скачок производительности?
Поставщик может посоветовать вам обзоры оборудования с установленной Windows, в которых говорится о производительности файлового сервера.
По моему опыту, SMB более чем «достаточно быстр» в моей сети. Мы используем сеть 10 ГБ между серверами, и мы очень довольны производительностью файлового сервера с использованием SMB, и мы измерили хорошие скачки производительности на одном и том же оборудовании в зависимости от того, используем ли мы сетевую карту 1 ГБ или 10 ГБ. SMB для нас не проблема.
Я бы, конечно, посмотрел на другие вещи в вашей сети - это устаревшая инфраструктура, оптимально ли она настроена (например, все сетевые карты сервера настроены правильно для последних драйверов, правильно работают на максимально возможной скорости), такие вещи, как DNS и т. на всех настроенных должным образом, есть ли много "нежелательного" трафика в сети, вызывающего замедление, настроен ли антивирус чрезмерно параноидальным образом (я видел, что это вызывает некоторые шокирующий замедления).
Многое может привести к снижению производительности файлового сервера, и очень мало из них - выбор протокола.
Хотя существуют более быстрые протоколы, чем SMB, это ни в коем случае не является медленным.
Однако он, возможно, немного более восприимчив к внешним воздействиям, чем другие протоколы, такие как насыщенные серверы, насыщенные сегменты и т. Д.
Если бы я был азартным игроком, я бы подозревал, что ваша сеть могла бы быть связана либо с редизайном, либо с некоторыми инвестициями, поскольку многие обычные офисные сети компании не были модернизированы с учетом огромного увеличения интернет- и интранет-трафика, наблюдаемого за последние годы. Также существует разумная вероятность того, что сервер / серверы могут нуждаться в замене или доработке, чтобы получить от них максимальную отдачу.
В любом случае я бы не стал уделять слишком много внимания тому, что SMB является прямым виновником, это более чем вероятно просто неудачник из-за плохой / старой сети и серверного комплекта.
У него больше накладных расходов (на передачу), чем у таких вещей, как NFS или FTP. Перечисление файлов в больших каталогах может занять некоторое время - частично это связано с SMB, некоторые с NTFS, некоторые из-за глупых вещей, которые различные версии Explorer и установленное программное обеспечение могут делать со стороны клиента. Некоторые вещи, такие как файловые базы данных (Access, PST-файлы), не следует открывать по медленным (WAN) каналам, потому что они плохо справляются с задержкой.
При этом операции, которые вы описываете, не должны занимать много времени. Может быть, файловый сервер (ы?) Недостаточно мощный. Возможно, у компании есть какое-то программное обеспечение как часть стандартной установки, которая замедляет работу. Может быть, это неправильно настроенный антивирусный сканер. Может есть вирус. Возможно, между вами и сервером есть WAN-соединение, о котором вы не знаете.
К сожалению, Нейт, мы не можем иметь дело напрямую с PHB. Ваша первая линия защиты здесь - это фактические показатели, например, сравнение между передачей SMB и NFS.
Если у вас есть реальные цифры или статистика, подтверждающие ваши аргументы, вам не придется так много заниматься человеческим фактором. Статистика говорит: «Вот в чем проблема, и вот доказательства». Это ваш аргумент.
Можете ли вы вообще сузить круг вопросов? Дает ли передача с сервера на сервер в той же подсети лучшие результаты? Как насчет перехода от одного клиента к другому (\\client\c$ → \\client\d$)?
Вы можете обнаружить такую простую вещь, как несоответствие дуплексного режима.
Я знаю, что это устарело, но очень важным фактором, который следует учитывать, является дисковый ввод-вывод. Если производительность записи на диск невероятно низка из-за программного обеспечения / RAID материнской платы, в отличие от аппаратной карты RAID с выделенной памятью.
Сетевая нагрузка является важным фактором, но лучше всего в качестве системного администратора взглянуть на Resource Monitor и выяснить, откуда могут происходить узкие места - проверка вкладки «Обзор», чтобы показать общий ЦП, сеть, дисковый ввод-вывод, память и т. Д. С этой точки зрения вы можете увидеть, есть ли процесс или набор процессов, разъедающих дисковый ввод-вывод, или утечка памяти (SQLServer.exe - экземпляр SBSMonitoring) и т. Д. Если есть сетевой процесс, использующий много пропускной способности, проверьте этот процесс и проверьте, сколько и какие узлы привязаны к этому процессу. Это могло быть много попыток взлома RDP на 3389. Я видел это раньше, и наше решение состояло в том, чтобы удалить прямой доступ RDP и переключить конечных удаленных пользователей на VPN.
Надеюсь это поможет!