Мы передаем большие медиафайлы на несколько рабочих станций и файловых серверов и с них (аудио / видео файлы, размером до 20 ГБ каждый в некоторых случаях), и иногда у меня возникает ощущение, что в результате сеть зависает (списки каталогов могут занять 5- 10 секунд до появления, папки «вычисляют размер», а не показывают их общий размер и т. Д.)
Большинство рабочих станций и оба сервера имеют второй неиспользуемый порт Gigabit Ethernet. Я слышал, что подключение их к другому коммутатору и настройка их в качестве дополнительных маршрутов в другой подсети может быть полезным, но я не видел достаточно недавней статьи по этой теме, чтобы убедить меня, что это того стоит. (У меня есть запасной 8-портовый неуправляемый гигабитный коммутатор Ethernet, много cat5e и очень мало времени)
Кто-нибудь делает что-нибудь подобное или знает, стоит ли это усилий?
Если ваша проблема заключается в конфликте сетевых устройств, то поможет перенос передач в другую подсеть. Вы должны быть осторожны, чтобы убедиться, что переводы перемещаются по второй сети, а не по первой.
Однако, если вы пытаетесь сделать списки каталогов на серверах, участвующих в передаче этих больших файлов, ваши проблемы могут быть связаны с тем, что диски на задействованных компьютерах слишком заняты, чтобы быстро выполнять ваши запросы. В этом случае дополнительная сетевая емкость на сервере не поможет.
Использование отдельной параллельной сети - определенно не лучший способ решить эту проблему. Это довольно много работы и обслуживания, и вряд ли решит вашу проблему. Имейте в виду, что он не будет автоматически балансировать трафик в обеих ваших сетях. Так, например, если все клиенты используют вторую сеть для совместного использования файлов, она будет перегружена, а списки каталогов все равно будут медленными. Ваша первая сеть может быть быстрой, но никто не будет использовать ее для обмена файлами.
Вот что я бы попробовал:
Если ваш коммутатор поддерживает SNMP, я бы потратил время на настройку Зенос или что-то подобное. Он отобразит график использования каждого порта, что значительно улучшит вашу способность определять узкое место. Он также может отображать жизненно важную статистику ваших клиентских и серверных машин.
Вам необходимо измерить текущую загрузку сети и сервера. Без фактических данных об использовании имеющихся у вас ресурсов невозможно однозначно сказать, существует ли проблема с производительностью и было бы полезно использовать вторые сетевые адаптеры.
Другой вариант - сегментировать сеть. Подключите половину клиентов и один сервер к одному коммутатору и подключите коммутаторы вместе. Транкинговые порты между наиболее часто используемыми клиентами / серверами также могут быть возможны (хотя и не в том случае, если оба коммутатора неуправляемые).
Доступ к диску на самих файловых серверах может быть узким местом. Если файлы копируются / на них, то добавление дополнительной пропускной способности сети вряд ли поможет списку каталогов и т. Д. С тех же серверов.
Много лет назад (до того, как коммутаторы GigE были дешевыми), я использовал две отдельные подсети. На каждой машине было два сетевых адаптера: один для общего доступа, а другой - для обмена файлами. Это похоже на то, что вы предполагаете.
Так как у вас есть запасной переключатель, попробуйте. Возможно, ваш текущий коммутатор просто не может передавать данные достаточно быстро, когда некоторые порты работают на максимальной скорости.
Другая идея: вы упомянули, что выполняете переход между несколькими рабочими станциями / серверами. В зависимости от их физического расположения и доступных портов, вы можете проложить между ними кабели Firewire и таким образом передавать файлы (насколько я помню, вы можете сделать это похожим на сетевой интерфейс на машинах). Тогда ваши диски все еще могут быть узким местом, но, по крайней мере, вы решили проблемы со скоростью сети.
Сообщите о том, что вы нашли.
Одна вещь, которую вы можете сделать с отдельной подсетью (при условии, что она вся гигабитная), - это использовать jumbo-кадры для дополнительной пропускной способности. Чтобы это работало, все устройства (включая коммутатор) должны поддерживать jumbo-кадры.
У меня так настроена "внутренняя" сеть; каждый сервер и блок NAS имеют интерфейс в этой сети (установленный для jumbo-фреймов), серверы и блок NAS взаимодействуют друг с другом по этой сети, освобождая "внешние" интерфейсы для клиентов.
Если возможно, вы всегда можете настроить VLAN, если ваша текущая инфраструктура поддерживает это, и вам не нужно будет прокладывать дополнительный сетевой кабель к каждой машине. Но, как сказал Дэвид выше, если это не проблема сети, это ничего не решит.