Я ищу варианты увеличения скорости между зданиями, в идеале без замены существующего волокна.
Текущая ситуация:
Чтобы снизить риск возникновения проблем со зданием / спринклерной системой / пожаром, вызывающих потерю данных, мы хотим переместить сервер резервного копирования в другое здание в нашем кампусе. Тем не менее, сервер резервного копирования имеет (2) объединенные сетевые адаптеры GbE, чтобы резервное копирование могло выполняться в ночное время.
Я не думаю, что основной коммутатор HP может поддерживать любые порты выше 1GbE. Моя первоначальная мысль - установить соответствующий HP на другом конце, объединить два оптоволоконных порта Gb, а затем объединить два порта Gb для резервного сервера на другом конце.
Но меня интересуют другие варианты, которые могут быть более быстрыми, устойчивыми или менее дорогими.
Если ваши коммутаторы поддерживают это (звучит так, как будто это сомнительно), вы можете просто перейти на оптику 10G, и все будет готово. Если это не вариант, вы могли бы подумать о том, чтобы получить пару блоков мультиплексирования / демультиплексирования CWDM, чтобы установить их на любом конце волоконно-оптической линии. Таким образом, вы можете разделить два или более потока 1G, каждый на свою длину волны.
У тебя здесь серьезная проблема. Я подозреваю, что единственным решением будет обновление ядра для поддержки портов 10 Гбит / с, потому что единственный другой вариант, который приходит на ум (и который вы упомянули в своем вопросе) - агрегация ссылок - не работает очень хорошо, когда у вас только одна конечная точка. Реализация таких вещей в каждом коммутаторе, которую я видел, имеет досадно ограниченные возможности для балансировки трафика между несколькими ссылками - обычно ограниченные MAC-адресами источника / назначения. Это меня раздражает, потому что драйвер связывания каналов Linux может выполнять прямой циклический перебор, который будет достаточно хорошо работать в подобной ситуации.
Если вы обнаружите, что все ваши коммутаторы будут работать в этом режиме (я не играл с коммутаторами Netgear, только с Cisco Catalyst и HP Procurve), то определенно стоит попробовать. Поскольку устройство на дальнем конце является резервным сервером, и, следовательно, трафик должен быть (по моим оценкам) довольно асимметричным, поэтому балансировка по каналу источник MAC-адрес тоже может работать, поскольку (я полагаю) трафик исходит из самых разных источников. Я бы не стал сразу переходить к этому как к решению, потому что весь ваш обратный трафик обязательно попадет на одну ссылку (один исходный MAC-адрес для всего этого), и если вы работаете почти со скоростью 2 Гбит / с, вы закончите с одним забитым звеном).
Другой возможный вариант, если вы открыты для необычных решений, - это разделение резервных копий на несколько машин. Это будет (иметь тенденцию) балансировать трафик за счет различных MAC-адресов (хотя алгоритм хеширования может вызвать проблемы из-за «случайного» хеширования всех MAC-адресов в одну и ту же ссылку, что никогда не бывает забавным).
Если все это не сработает, я думаю, вам нужно обновить базовую сеть. Коммутаторы, способные работать с оптикой 10G, не который дорогие в наши дни (во всяком случае, намного лучше, чем 48-портовые медные коммутаторы 10G ...)