У нас есть следующая договоренность: Dev Site <--vpn--> Prod Site. Брандмауэр Prod Site, работающий под управлением pfSense 2, принимает трафик VPN TCP / UDP на SMB-порты 135-139 и 445. Наши разработчики могут подключаться к административным общим ресурсам. \\Computer\C$ без инцидентов, и на самом деле загрузка отдельных файлов в общую папку довольно проста - около 200–300 килобайт в секунду. Однако при попытке удалить папку с множеством вложенных папок / файлов, загрузить много отдельных файлов или изменить множество отдельных файлов, проводник останавливается, обычно работая со скоростью 2-4 ФАЙЛА в секунду (даже если они <1 КБ). Это оказывается очень болезненным при выполнении заданий синхронизации и т. Д. Это отсутствие скорости было подтверждено для клиентов Windows XP, 2k3 Server и Windows 7. Рассматриваемый сервер работает под управлением Win2k3.
Некоторые вопросы:
Добро пожаловать в чудесный мир SMB через любое соединение с задержкой выше, чем в локальной сети. Все, что вы описываете, совершенно нормально для таких сценариев, как только вы превысите 20 мс, все станет значительно медленнее, более 50 мс, и это очень больно. Протокол очень плохо разработан для соединений с задержками выше, чем в локальной сети. Особенно при работе с общими ресурсами с большим количеством файлов и / или каталогов.
В SMBv2 это в какой-то степени исправлено. Если у вас строго Server 2008 с Vista или более новыми клиентами, все будет не так плохо.
См. «Проблемы с производительностью» здесь для получения более подробной информации: http://en.wikipedia.org/wiki/Server_Message_Block
Вы обязательно должны проверить пропускную способность вашего офисного интернет-провайдера, чтобы убедиться, что она не превышена, и вы можете использовать ping для проверки задержки между удаленными разработчиками и вашим сервером. Я предполагаю, что это не так, поскольку вы обнаружили, что производительность SMB через VPN, как правило, воняет.
Ваше решение - найти для этих удаленных пользователей другой способ манипулировать файлами. Вы можете попробовать FTP, но это вводит другой протокол, а FTP сам по себе не особенно безопасен (лучше по VPN). Но лучше всего предоставить пользователям удаленный рабочий стол на сервере и заставить их выполнять удаление там. Для массовой загрузки они могли загрузить ZIP-файл и распаковать его на сервере через удаленный рабочий стол.
Вопрос о синхронизирующих заданиях сложен, потому что вы, скорее всего, делать надо смотреть каждый файл. Если задание синхронизации может выполняться по другим протоколам (psexec, FTP, SFTP, SCP и т. Д.), Это, вероятно, будет быстрее.
Также может быть проблема с фрагментацией пакетов - в этом случае вы можете попытаться настроить MTU между ссылками (хотя это может быть невозможно при подключении по VPN). Например, на моем рабочем столе - я не могу отправить пинг больше 1472 без разделения на несколько пакетов (Win7 -> Win2008R2):
ping -f -l 1472 10.1.10.3
В -f аргумент - флаг запрета фрагментации, а -l это размер. Я бы посоветовал начать с 1500 и постепенно снижаться.