Мы анимационная студия, и у нас есть интрасеть, которая постоянно должна перемещать большие файлы (2 ГБ +) по сети. У нас есть такой конфиг:
Три неуправляемых коммутатора Netgear на 24 порта. Коммутатор 1 подключен к коммутатору 2, подключенному к коммутатору 3, и коммутатор 3, подключенному к маршрутизатору. К Switch 2 подключен NAS.
50 ПК подключены к различным переключателям. 20 рабочих станций и 30 узлов рендеринга.
Все идет гладко, пока мы не пришлем рендер. Когда мы это делаем, около 30 машин пытаются одновременно скопировать один и тот же файл с NAS, и сеть замедляется до обхода.
Управляемые коммутаторы выходят за рамки бюджета. Возможно обновление до двух 48-портовых неуправляемых коммутаторов в стеке.
У меня есть следующие вопросы:
Спасибо за помощь. Эти сетевые штуки действительно сбивают с толку ...
Сожалею, но НЕКОТОРЫЕ из того, что вы говорите, не имеет никакого смысла. В самом деле. Вы в значительной степени должны быть северокорейской рендеринговой компанией, чтобы это имело смысл.
50 ПК подключены к различным переключателям. 20 рабочих станций и 30 узлов рендеринга.
И:
Управляемые коммутаторы выходят за рамки бюджета
В самом деле. Вы можете заплатить 20 работающим людям плюс все лицензии, и у вас не будет денег на управляемый коммутатор, который составляет около… 100 долларов США за каждую вашу рабочую станцию. Поздравления. Как я уже сказал, это имеет смысл, когда вы работаете в северокорейской компании, где ваши сотрудники зарабатывают около 1,5 долларов в час. Управляемые коммутаторы не так уж дороги. Особенно если они вам нужны.
Хорошо, поехали.
Нет денег? Плохие новости - не повезло.
Также убедитесь, что вы действительно можете передать 1 Гбайт данных из хранилища, что является еще одной проблемой бюджета. Зависит от оборудования и компоновки диска, какая производительность вы действительно можете получить от дисков.
Во всяком случае, у вас двоякая проблема. Во-первых, 1 ГБ - это примерно 100 МБ в секунду. Это звучит неплохо (20 секунд для файла размером 2 ГБ), но если 30 узлов тянут, это умножается на 30, потому что у вас ТАКЖЕ есть только 1 ГБ в хранилище. Узкое место, вот и мы. Во-вторых, все, от Switch 1 до Switch 2, также проходит через узкое место в 1 Гбит.
Когда вы перемещаете такое количество вещей, вам просто НУЖНО намного больше пропускной способности на хранилище, чем на рабочих станциях. 10 Гбит здесь позволяют вам в основном иметь сокращение только в 3 раза, когда узлы работают, а не в 30 раз.
Это в значительной степени элемент повторных требований, не соответствующих реальности - с 1-гигабитной сетью, копирование 2gbx30 = 60gb данных вокруг IS займет много времени, и вы в основном туннелируете все это через соединение 1gbit, поэтому переключение не дает вам дополнительных пропускная способность. Итак, получите бюджет, обновитесь до оборудования, которое подходит для того, что вы хотите делать, и тогда проблемы исчезнут. Однако это ЯВЛЯЕТСЯ одной из самых больших проблем - кто-то должен был заложить бюджет при планировании 30 узлов рендеринга.
Возможно, вы можете переключиться на что-то вроде огнемет, программа многоадресной рассылки файлов, чтобы вам не приходилось отправлять 60 ГБ (от 2 ГБ до 30 машин) и вместо этого отправлять 2 ГБ по сети ...
Если это не вариант, вам, вероятно, придется обновить узкие места в вашей сети. Судя по вашему описанию, NAS является основным узким местом, поэтому вам в первую очередь нужно будет посмотреть, можете ли вы связать несколько интерфейсов. Это зависит от NAS. Коммутатор на 48 портов будет иметь очень высокую пропускную способность объединительной платы, но это не имеет значения, если это 40 Гбит / с, если ваш NAS является узким местом на 1 Гбит / с.
Если у вас есть 2 коммутатора, подключенные к другому коммутатору через каналы со скоростью 1 Гбит / с, это будет узким местом. Таким образом, переход на 48-портовый коммутатор и установка как можно большего количества вещей поможет устранить эти узкие места.
Помимо этого, возможно, вы можете использовать распределенная, параллельная файловая система как PVFS? Думайте об этом как о файловой системе bittorrent, в которой многие машины разделяют нагрузку по распространению файла, а не один центральный NAS. Таким образом, NAS не становится узким местом.
Я считаю, что NAS является основным узким местом. 30 узлов, извлекающих один и тот же (предположительно большой) файл, - отличный способ полностью заполнить сетевое соединение NAS всем, что попадает в него. Я предполагаю, что по мере завершения узлов рендеринга они загружают свою завершенную работу в NAS, что, вероятно, также вызывает его собственные замедления. Дополнительное узкое место, вероятно, находится в конфигурации вашего коммутатора.
Switch 1 -> Switch 2 (NAS) -> Switch 3 -> [Router] -> Internet
Если ваш маршрутизатор не является чем-то большим, чем обычный маршрутизатор SOHO, вы сможете сделать это бесплатно:
Switch 1 -> [ ]
switch 2 -> [ router ] -> Internet
Switch 3 -> [ ]
Это само по себе может помочь в решении вашей проблемы, и, что самое приятное, это ничего не стоит, кроме небольшого простоя.
Вы действительно хотите, чтобы ваши узлы рендеринга и NAS были на одном коммутаторе, если это возможно. Поскольку у вас 30 узлов рендеринга, вы не можете разместить их все и NAS на одном коммутаторе с вашей текущей конфигурацией, поэтому потребуется новое оборудование. Вы можете помочь снизить нагрузку на свои восходящие каналы, используя стекируемые коммутаторы, как вы сказали. Это должно обеспечить лучшую пропускную способность между коммутаторами. Оба шага должны оставить ваш порт (ы) восходящего канала менее насыщенным, хотя это не влияет на нагрузку на NAS.
30 узлов, загружающих файлы с высокой скоростью, могут полностью заполнить 1GbE, поэтому для исправления этого требуется один из нескольких шагов:
Определенно имеет смысл заняться этим как с точки зрения программного обеспечения, так и с точки зрения оборудования. Я уверен, что вы можете найти там программное обеспечение, которое будет выполнять многоадресную рассылку файла на машины для рендеринга.
Отличные ответы от других здесь. У вас должно быть достаточно информации, чтобы дать вам все необходимые идеи. Однако вот пара нестандартных мыслей:
Настройте локальный трекер бит-торрентов в вашей сети (видимый ТОЛЬКО в вашей сети) и делитесь своими большими файлами между своими рабочими станциями через BitTorrent.
Каждой ли станции рендеринга нужен весь файл? Если нет, то поделитесь частями файлов. Либо разбейте большие файлы на более мелкие куски, либо обслуживайте файлы с помощью HTTP-сервера, который понимает запросы диапазона, и пусть ваши клиенты загружают только те диапазоны байтов, которые им нужны.
Одноранговое решение, такое как Aerofs может помочь вам. Каждый файловый сервер! :-)
Вот что бы я сделал.
1 - Выполните базовое измерение производительности.
2 - Исправьте текущую конфигурацию (см. Ниже), добавив новый переключатель.
PC’s-->[ SW1 ]-->[ ]
[ ]
[ ]
PC’s-->[ SW2 ]-->[ SW New ]-------------->[ Router ]
[ ]
[ ]
PC’s-->[ SW3 ]-->[ ]--->NAS
3 - Сделайте новое измерение.
4 - Установите программное обеспечение, которое пересылает (многоадресно) файл с NAS на ПК. (см. сообщение Шона)
5 - Сделайте новое измерение.
В каждой точке измерения выполните один и тот же тест несколько раз.
Кроме того, если вы сообщите нам модель / производитель NAS, мы сможем предоставить другие ответы.