То, что Вы описали, будет решением частной задачи ускорения работы и сжатия HTTP/HTTPS. Если требуется сконцентрироваться на одном приложении, тогда коробочное решение вряд ли подойдет, и можно обойтись малыми силами. Обычно задача стоит более комплексно, приложений в канале много, а канал расширить нельзя. Помимо HTTP всегда есть CIFS/SMB (signed), MAPI (чаще всего Encrypted или через HTTPS), FTP, различный трафик БД, терминальные сессии (RDP/Citrix). Даже если будет возможность тюнинговать настройки серверов для лучшей работы, то такое решение будет тяжело масштабируемым, особенно если удаленных точек/филиалов больше 10, к примеру. Прелесть Riverbed SteelHead еще в том, что им без разницы, через какое приложение передаются повторяющиеся/избыточные данные. Пример: скачиваем с файловой шары по SMB презентацию PowerPoint размером 20 МБ, локально на машине удаляем один слайд, сохраняем файл, заливаем обратно, но уже по FTP. В обычном сценарии обратно будет передано все те же 20 МБ, а в случае если на канале стоит Riverbed SteelHead, сжатие будет около 80-90%, в канал уйдет 2-4 МБ. Приведу пример со скриншотами с одного из наших последних пилотов. Первый показывает процент сжатия по приложениям, второй – увеличение пропускной способности канала. Итог тестирования – канал виртуально расширен в 3.2 раза. Таких результатов связкой из прокси и шейпера не добиться.
Riverbed использует 3 механизма – дедупликация (data streamlining), оптимизация транспорта (transport streamlining), оптимизация приложений (application streamlining). Т.е. максимально хорошо решение работает, когда все 3 механизма работают одновременно. Можно вручную крутить определенные настройки и использовать сторонние решения, но прирост будет незначительным.
Или вы что-то другое имели в виду?
По поводу каналов 50 Мбит/c – это не совсем так. Конечно, чем хуже условия, тем более ощутим будет эффект от оптимизации трафика. Многое зависит от расстояния между офисами и, соответственно, сетевой задержки на канале связи, плюс от качества этого канала связи или от процента потерь пакетов. Так, например, при сетевой задержке в 100 мс и определенном количестве потерь на канале связи в 50 Мбит/c — реальная скорость TCP соединения будет порядка 3-5 Мбит/c и выше подняться не сможет. Возможно, это и будет причиной, что канал связи не загружен полностью. Оптимизатор в этом случае поможет и позволит максимально утилизировать канал связи и, соответственно, быстрее доставлять контент до удаленного офиса.
По поводу второго утверждения – в случае, если оптимизированного трафика (на выходе из оптимизатора) будет больше чем его лицензионное ограничение, то оптимизатор будет действительно выполнять шейпинг. Поэтому важно правильно подойти к выбору оборудования и устанавливать его на соответствующие каналы связи.
Оптимизация – это симметричная технология, поэтому нельзя забывать, что с другой стороны канала связи должен быть установлен второй оптимизатор. Поэтому для Вашего примера – оптимизаторы (или хотя бы мобильные их версии на рабочих станциях) должны быть в Индии и на площадках по миру для успешной работы оптимизации трафика. Если это так, то для Ривербед не принципиально между какими площадками выполнять оптимизацию трафика. Оптимизатор видит в пакетах tcp флажки, указывающие на наличие Ривербеда на другой стороне, и в случае попадания трафика под правила оптимизации (ACL), начинает оптимизировать трафик.
У Riverbed механизм дедупликации избыточных данных в канале связи называется SDR (Scalable Data Referencing), который основан на методе словаря — файлы разбиваются на сегменты, присваиваются получившимся сегментам ссылки, далее в канал связи передаются эти короткие ссылки. Причем этот механизм работает без привязки к используемому протоколу — передаете Вы файл по FTP или CIFS, механизм будет работать.
Кеширование файлов в обычном понимании не используется.
В основном используются два метода.
Во-первых, дедупликация повторяющихся данных в канале связи протокола SQL. Соответственно при этом в разы ускоряется работа SQL и доступ к данных, плюс разгружается WAN канал связи.
Во-вторых, выполняется оптимизация взаимодействия клиента и сервера, а именно избыточное и неэффективное взаимодействие между клиентом и сервером переносится в Локальную сеть (осуществляется общение между Оптимизатором и Клиентом/Сервером), а в WAN канал связи отправляется только полезные данные.
Конечно еще можно выполнить полноценный QoS и еще кое-что, все зависит от задачи.
Дело в том, что в Infosim все эти модули тесно связаны между собой и это очень помогает в работе.
К примеру – выполнили дискаверинг устройств, соответственно, имеем инвентарную базу установленного оборудования (с разделением по производителям, моделям, группам, можем автоматически присваивать ярлыки провайдеров, сервисных контрактов – в общем имеем актуальную информацию по текущему оборудованию в сети), для этого же оборудования выполняем проверку доступности и снимаем операционные метрики типа – CPU, память, блоки питания и т.д. И далее для сбора конфигов используем туже самую, актуальную базу оборудования.
Причем дискаверинг выполняется по расписанию, что позволяет автоматически добавлять/удалять (если нужно) новые устройства из базы инвентаризации и соответственно проверки доступности и сбора конфигов.
Так же Infosim может наполнять базу специализированной системы для инвентаризации всего чего захочешь. Специализированные системы инвентаризации – это как правило ручное ведение базы.
Или вы что-то другое имели в виду?
По поводу второго утверждения – в случае, если оптимизированного трафика (на выходе из оптимизатора) будет больше чем его лицензионное ограничение, то оптимизатор будет действительно выполнять шейпинг. Поэтому важно правильно подойти к выбору оборудования и устанавливать его на соответствующие каналы связи.
Оптимизация – это симметричная технология, поэтому нельзя забывать, что с другой стороны канала связи должен быть установлен второй оптимизатор. Поэтому для Вашего примера – оптимизаторы (или хотя бы мобильные их версии на рабочих станциях) должны быть в Индии и на площадках по миру для успешной работы оптимизации трафика. Если это так, то для Ривербед не принципиально между какими площадками выполнять оптимизацию трафика. Оптимизатор видит в пакетах tcp флажки, указывающие на наличие Ривербеда на другой стороне, и в случае попадания трафика под правила оптимизации (ACL), начинает оптимизировать трафик.
Кеширование файлов в обычном понимании не используется.
Во-первых, дедупликация повторяющихся данных в канале связи протокола SQL. Соответственно при этом в разы ускоряется работа SQL и доступ к данных, плюс разгружается WAN канал связи.
Во-вторых, выполняется оптимизация взаимодействия клиента и сервера, а именно избыточное и неэффективное взаимодействие между клиентом и сервером переносится в Локальную сеть (осуществляется общение между Оптимизатором и Клиентом/Сервером), а в WAN канал связи отправляется только полезные данные.
Конечно еще можно выполнить полноценный QoS и еще кое-что, все зависит от задачи.
К примеру – выполнили дискаверинг устройств, соответственно, имеем инвентарную базу установленного оборудования (с разделением по производителям, моделям, группам, можем автоматически присваивать ярлыки провайдеров, сервисных контрактов – в общем имеем актуальную информацию по текущему оборудованию в сети), для этого же оборудования выполняем проверку доступности и снимаем операционные метрики типа – CPU, память, блоки питания и т.д. И далее для сбора конфигов используем туже самую, актуальную базу оборудования.
Причем дискаверинг выполняется по расписанию, что позволяет автоматически добавлять/удалять (если нужно) новые устройства из базы инвентаризации и соответственно проверки доступности и сбора конфигов.
Так же Infosim может наполнять базу специализированной системы для инвентаризации всего чего захочешь. Специализированные системы инвентаризации – это как правило ручное ведение базы.