Хотя я понимаю, что SSH сам по себе является протоколом, использующим очень низкую пропускную способность, он иногда забивает пропускную способность в часы пик в нашей офисной среде. Я хочу знать, можно ли вообще уменьшить / оптимизировать трафик SSH (rsync) через WAN?
Я понял, что русло этого не может. Какие еще проекты (прокси) я могу придумать, игнорируя проблемы безопасности, такие как MiTM, DPI и т. Д. Могут ли здесь быть полезны TrafficSqueezer, WANProxy или OpenNOP?
Также, пожалуйста, предложите, есть ли какие-либо другие идеи для резервного копирования данных (если они есть), кроме rsync. Возможно ли, что я думаю о расшифровке SSH с помощью прокси-сервера до того, как достигнет Riverbed и переместит его через WAN на другой конец.
Sender (RSYNC) Server --> Proxy (Decrypt SSH) --> Sending Riverbed --> Receiving Riverbed --> Receiver Server
Текущая топология:
100's of Users (rsync) --> Source Riverbed --> (passed through traffic/unoptimized) --> Destination Riverbed --> Remote Machine
Обязательно посмотрите ответы на: Почему мой rsync такой медленный?
Я много лет полагался на решения на основе rsync для репликации и резервного копирования. Мне никогда не нужно было использовать какую-либо форму ускорения WAN (с помощью устройства).
С годами мои подходы к rsync эволюционировали; от базового сжатия до использования "-e ssh -c arcfour" в качестве более легкого шифра, до использования HPN-SSH чтобы иметь возможность управлять окнами TCP и отключать шифрование по каналам на большие расстояния, а в последнее время упаковка rsync в UDR / UDT для передачи rsync на основе UDP. Я должен добавить это UDT это ядро некоторые продукты для ускорения WAN на рынке.
Это довольно эзотерические решения, но я бы действительно начал с понимания того, что вы делаете сегодня. Давайте посмотрим на ваши текущие командные строки rsync и попробуем их оптимизировать.
Редактировать:
Вы говорите о двоичных данных, передаваемых на большие расстояния с пропускной способностью 400 Мбит / с. И это похоже несколько потоков двунаправленного трафика срабатывает в случайное время дня.
Если вас беспокоит насыщение полосы пропускания, не могли бы вы просто ограничить скорость передачи rsync с помощью:
--bwlimit=KBPS limit I/O bandwidth; KBytes per second
Или, если ваши сетевые устройства способны, это может стать формированием трафика или качество обслуживания упражнение. Но, в конце концов, похоже, что это проблема людей / политики.
Редактировать:
Мое предложение для UDR отправляет rsync в незашифрованном виде по умолчанию через порты UDP 9000-9100. Это не требует значительных изменений в командной строке по сравнению с запуском rsync в режиме демона. Который является возможно, в области чего-то, что может быть решено вашими подразделениями Riverbed. Из вашего первоначального вопроса не было ясно, каковы масштабы, количество пользователей и есть ли у вас даже ускорители WAN.
Изначально я собирался скептически относиться к идее попытки «оптимизировать WAN» rsync-трафик, но чем больше я думал об этом, тем больше я решал, что это возможно.
Компрессор словаря на основе TCP (который, как я полагаю, могут выполнять устройства Riverbed Steelhead), вероятно, принесет пользу незашифрованному потоку rsync. Предположительно устройства Riverbed могут выполнять шифрование «оптимизированного» трафика, поэтому запуск незашифрованного rsync не должен нарушать целостность или конфиденциальность трафика в глобальной сети. (Между исходным сервером и устройством Riverbed может быть другая история.)
Вам не нужно запускать rsync через SSH. Он отлично работает через TCP или любой другой надежный потоковый транспорт.
Похоже, что хорошая архитектура ускорения WAN будет несколько противоречить хорошей архитектуре безопасности, поскольку зашифрованный трафик будет иметь высокую энтропию и низкую избыточность и совсем не способствует сжатию. Я думаю, вам нужно уравновесить эти опасения. Я не следил за Riverbed в течение ряда лет, но на самом деле это похоже на место, где расшифровка шифрованных протоколов посредником может иметь смысл (хотя и превращает ускоритель WAN в огромный цель для атак).
Редактировать:
Я возвращаюсь к этому ответу через несколько часов, потому что, честно говоря, он не дает мне уснуть по ночам.
Я хочу прояснить некоторые предположения, которые я делаю. Я предполагаю:
Вы работаете с соединениями WAN, которые значительно медленнее, чем LAN - 100 Мбит / с или меньше.
Вы выполняете резервное копирование по этим каналам глобальной сети, которое вы хотели бы ускорить с точки зрения времени настенного времени.
Серверы, на которых размещены исходный и целевой файлы, имеют достаточные возможности ЦП и подключения к сети, чтобы полностью заполнить канал WAN, и WAN действительно является узким местом.
Вы используете операционные системы с реализациями TCP, которые могут разумно масштабировать окно приема, чтобы приспособиться к произведению задержки пропускной способности вашего канала WAN.
Если серверы не могут заполнить сетевое соединение, значит, ваше узкое место где-то еще. В принципе, я предполагаю, что у вас есть небольшой канал, который ваши серверы могут насыщать при выполнении резервного копирования. Если у вас есть узкие места в процессоре или вводе-выводе на серверах, никакая "магия", связанная с сетью, вам не поможет.
Говоря откровенно, я чувствую себя немного глупо, говоря положительно об устройствах ускорения WAN. Раньше они меня мало впечатляли (в основном с точки зрения рентабельности инвестиций и стоимости), и я опасался их после того, как услышал многочисленные ужасающие истории о «странностях» приложений и операционных систем, которые исчезли бы, если бы ускорители WAN были отключены. Я с подозрением относился к ним как к «технологии» и вообще считал, что они являются симптомом использования плохо спроектированных протоколов, неправильных решений по размещению серверов или плохой сетевой архитектуры.
Я потратил большую часть двух часов на чтение основанных на словарях протокольных компрессоров и экспериментирование с rsync. Я думаю, что в зависимости от степени избыточности изменений, которые вы синхронизируете с rsync, на самом деле есть потенциал для небольшого улучшения производительности с использованием ускорителя WAN на основе словаря. Это будет во многом зависеть от того, как выглядят ваши данные.
У меня нет никаких цифр, использующих настоящий ускоритель WAN, чтобы подтвердить это. У меня также нет личного опыта использования ускорителей WAN в производственной среде, не говоря уже об «ускорении» протокола rsync. Я бы определенно не пошел и не купил что-то, основываясь на том, что я здесь говорю, но если у вас уже есть что-то, я бы подумал о том, чтобы пропустить через него некоторый незашифрованный трафик rsync, чтобы посмотреть, что он делает.