Возможность WAN-оптимизации для SSH-трафика.

Определенно смотрите ответы на: Почему мой rsync такой медленный?

Я много лет полагался на решения на основе rsync для репликации и резервного копирования. Мне никогда не нужно было использовать какую-либо форму ускорения глобальной сети (с помощью устройства).

С годами мои подходы к 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. Из вашего первоначального вопроса не было ясно, каков охват, количество пользователей или были ли у вас на месте ускорители глобальной сети.

I was initially going to be a naysayer to the idea of trying to "WAN optimize" rsync traffic, but the more I thought about it the more I decided that it was possible.

Компрессор словаря на основе TCP (который, как я считаю, могут использовать устройства Riverbed Steelhead), вероятно, будет полезен для незашифрованного потока rsync. Предположительно устройства Riverbed могут выполнять шифрование на "оптимизированном" трафике, поэтому запуск незашифрованного rsync не должен нарушать целостность или конфиденциальность трафика в глобальной сети. (Между исходным сервером и устройством Riverbed может быть другая история.)

Вам не нужно запускать rsync через SSH. Он будет отлично работать по TCP или любому другому надежному потоковому транспорту.

Кажется, что хорошая архитектура ускорения глобальной сети несколько противоречила бы хорошей архитектуре безопасности, поскольку зашифрованный трафик имел бы высокую энтропию и низкую избыточность и совсем не способствовал сжатию. Я думаю, что это проблемы, которые вы должны сбалансировать. Я не поспевал за Riverbed уже несколько лет, но на самом деле это похоже на то место, где расшифровка зашифрованных протоколов может оказаться разумной (хотя и превращает ускоритель WAN в огромную цель для атак).).

Редактировать:

Я вернусь к этому ответу несколько часов спустя, потому что, честно говоря, он не дает мне спать по ночам.

Я хочу уточнить некоторые предположения, которые я делаю. Я предполагаю:

• Вы работаете с каналами WAN, которые значительно медленнее, чем LAN- 100 Мбит / с или менее.

• Вы выполняете резервное копирование по этим каналам глобальной сети, которое вы хотели бы ускорить, с точки зрения времени нахождения на стене.

• Серверы, на которых размещены исходные и целевые файлы, имеют достаточное количество ресурсов ЦП и сети для полного насыщения канала WAN, и WAN действительно является узким местом.

• Вы используете операционные системы с реализациями TCP, которые могут разумно масштабировать окно приема, чтобы приспособить продукт задержки полосы пропускания вашего канала WAN.

Если серверы не могут насытить сетевой канал, то ваше узкое место находится где-то еще. По сути, я предполагаю, что у вас есть небольшой канал, который могут насыщать ваши серверы при выполнении резервного копирования. Если у вас узкие места в ЦП или в / в на серверах, никакое количество "магии", связанной с сетью, вам не поможет.

Говоря довольно прямо, я чувствую себя немного глупо, положительно говоря об устройствах ускорения глобальной сети. Я был менее впечатлен ими в прошлом (в основном с точки зрения рентабельности инвестиций и затрат) и настороженно относился к ним после того, как услышал множество страшных историй о странностях приложений и операционной системы, которые исчезнут, когда ускорители WAN будут отключены. Я с подозрением относился к ним как к "технологии" и в целом чувствовал, что они являются симптомом использования плохо спроектированных протоколов, плохих решений по размещению серверов или плохой сетевой архитектуры.

Большую часть двух часов я потратил на чтение на базе словарных компрессоров протоколов и поигрался с rsync. Я думаю, что в зависимости от степени избыточности в изменениях, которые вы синхронизируете с rsync, на самом деле существует вероятность незначительного улучшения производительности при использовании ускорителя WAN на основе словаря. Это будет зависеть от того, как будут выглядеть ваши данные.

У меня нет цифр, использующих настоящий WAN-ускоритель, чтобы подтвердить это. Также у меня нет личного опыта использования ускорителей глобальной сети в производственных условиях, не говоря уже о "ускорении" протокола rsync. Я бы, конечно, не пошел и не купил что-нибудь, основываясь на том, что я здесь говорю, но если у вас уже есть что-то на месте, я бы подумал пропустить через него некоторый незашифрованный rsync-трафик, чтобы посмотреть, что он делает.