Как стать автором
Обновить

Комментарии 15

А как Riverbed работает с SQL трафиком?
Кстати да, как вообще оцениваете Riverbed для профилирования?
В основном используются два метода.
Во-первых, дедупликация повторяющихся данных в канале связи протокола SQL. Соответственно при этом в разы ускоряется работа SQL и доступ к данных, плюс разгружается WAN канал связи.
Во-вторых, выполняется оптимизация взаимодействия клиента и сервера, а именно избыточное и неэффективное взаимодействие между клиентом и сервером переносится в Локальную сеть (осуществляется общение между Оптимизатором и Клиентом/Сервером), а в WAN канал связи отправляется только полезные данные.
Конечно еще можно выполнить полноценный QoS и еще кое-что, все зависит от задачи.
Я правильно понимаю, что сначала Riverbed по сути копирует в себя результат SQL запроса, и отдает только уникальные данные? Если результат одного запроса — гигов 40 данных, все проанализирует?
Оптимизаторы сети повесили систему слежения и телефонию в одном сегменте и всё упало? Я правильно понял?
В этот момент они как раз запускали новое приложение, которое хорошо показало себя в тестовом сегменте, но в промышленной сети под нагрузкой его ещё не видели. Внедрили, но из-за сложной структуры об этом знали не все ИТ-специалисты. Через 3-4 дня после включения сервиса начались проблемы с ip-телефонией.

Они — это заказчик, на сколько это понятно из текста.
спасибо, был невнимателен.
что такое оптимизатор трафика? Как оно работает?
В их блоге есть статья про оптимизаторы.
У автора хотелось бы спросить использовалось ли кэширование трафика на оптимизаторах Riverbed, например, как у Cisco WAAS?
У Riverbed механизм дедупликации избыточных данных в канале связи называется SDR (Scalable Data Referencing), который основан на методе словаря — файлы разбиваются на сегменты, присваиваются получившимся сегментам ссылки, далее в канал связи передаются эти короткие ссылки. Причем этот механизм работает без привязки к используемому протоколу — передаете Вы файл по FTP или CIFS, механизм будет работать.
Кеширование файлов в обычном понимании не используется.​
От себя добавлю (байка, которую слышал): банк, серверная, проверки языком витой пары, подсоединена ли или нет.
А я правильно понимаю что ривербенды не имеют особого смысла для соединения офисов, у которых хороший избыточный канал (50 мегабит, например) и не загружают его целиком?

И что происходит если трафик идет через двухмегабитный Ривербенд если поставить его в таком месте? Он оптимизирует 1/25 канала или попросту порежет его до 2 Мб/с. И отдельно, что если только часть WAN трафика идет на какую-нибудь Индию, а остальное — по миру? (Про то, что можно купить более дорогое решение, я понимаю. Интересна механика.)
По поводу каналов 50 Мбит/c – это не совсем так. Конечно, чем хуже условия, тем более ощутим будет эффект от оптимизации трафика. Многое зависит от расстояния между офисами и, соответственно, сетевой задержки на канале связи, плюс от качества этого канала связи или от процента потерь пакетов. Так, например, при сетевой задержке в 100 мс и определенном количестве потерь на канале связи в 50 Мбит/c — реальная скорость TCP соединения будет порядка 3-5 Мбит/c и выше подняться не сможет. Возможно, это и будет причиной, что канал связи не загружен полностью. Оптимизатор в этом случае поможет и позволит максимально утилизировать канал связи и, соответственно, быстрее доставлять контент до удаленного офиса.

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

Оптимизация – это симметричная технология, поэтому нельзя забывать, что с другой стороны канала связи должен быть установлен второй оптимизатор. Поэтому для Вашего примера – оптимизаторы (или хотя бы мобильные их версии на рабочих станциях) должны быть в Индии и на площадках по миру для успешной работы оптимизации трафика. Если это так, то для Ривербед не принципиально между какими площадками выполнять оптимизацию трафика. Оптимизатор видит в пакетах tcp флажки, указывающие на наличие Ривербеда на другой стороне, и в случае попадания трафика под правила оптимизации (ACL), начинает оптимизировать трафик.
Процент потерь у нас очень низкий (крайне близко к нулю), в основном виновата последняя миля с другой стороны (мобильного сотрудника). Идея была в том, чтобы купить лицензий тем кто постоянно в дальних командировках и они могли повысить качество своей работы.

Но вы сказали что оптимизатор порежет трафик, и это очень хреново. Выходит если у нас есть 2-3 мобильных сотрудника в Индии (с приложениями на их компьютерах), то нам все равно нужно купить очень дорогостоящее оборудование или резать хороший и широкий канал до пары мегабит ради них двоих.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.