«КПД» стандартного WAN – всего около 10%
Если заглянуть в практически любой канал связи между филиалом компании и дата-центром, то можно увидеть достаточно неоптимальную картину:
- Во-первых, передается очень много (до 60–70% канала) избыточной информации, которая так или иначе уже запрашивалась.
- Во-вторых, канал загружен «болтливыми» приложениями, рассчитанными на работу в локальной сети, — они обмениваются короткими сообщениями, что негативно сказывается на их производительности в канале связи.
- В-третьих, сам протокол TCP изначально создавался для локальных сетей и отлично подходит для малых задержек RTT и при отсутствии потерь пакетов в сети. В реальных каналах при потерях пакетов скорость сильно деградирует и медленно восстанавливается за счет больших RTT.
Я работаю руководителем инженерной команды департамента телекоммуникаций КРОК и регулярно оптимизирую каналы связи дата-центров как наших, так и энергетических компаний, банков и других организаций. Ниже расскажу основы и приведу наиболее интересное, на мой взгляд, решение.
Сжатие и дедупликация
Первая проблема уже описана: в канале передается очень много избыточных дублирующихся данных. Самый яркий пример — это Citrix-ферма, в которой работают филиалы какого-нибудь банка: в отдельно взятом офисе одни и те же данные могут запрашивать 20–30 разных машин. Соответственно, канал можно было бы спокойно разгрузить на 60–70% за счет дедупликации.
На самом Citrix, конечно, можно включить сжатие данных, но эффективность (сжатие) в разы ниже, чем на специализированных оптимизаторах трафика. Главным образом за счет того, что оптимизаторы не только сжимают данные, но и дедуплицируют. Через оптимизатор проходит трафик всего филиала. И чем больше пользователей в филиале, тем больше повторяющихся запросов пользователей и тем больше эффект от дедупликации. Для одного пользователя стандартное сжатие, например Limpel-Ziv, может быть даже выше, чем дедупликация, но при наличии большего количества устройств на первое место выйдет именно дедупликация.
Как правило, оптимизаторы — это ПАК, но можно внедрить и в виде виртуальных машин. Для оптимизации трафика на канале связи оптимизаторы должны быть установлены на обеих площадках. Оптимизаторы ставятся до VPN-шлюзов, поскольку дедупликация шифрованного трафика — дело бесполезное.
Алгоритм работы дедупликации следующий:
- Филиал делает запрос в ЦОД;
- Сервер отправляет данные в офис;
- До того, как попасть в канал связи, данные проходят через оптимизатор на стороне ЦОДа;
- Оптимизатор сегментирует данные и дедуплицирует их. Данные разбиваются на блоки, каждый из которых получает короткое название — ссылка на блок;
- Ссылки и блоки данных сохраняются в локальном хранилище — так называемом словаре;
- Ссылки и блоки данных передаются на оптимизатор в филиале. Но перед отправкой оптимизатор ЦОДа сжимает данные по алгоритму. В итоге данных не становится больше даже при первой (холодной) передаче данных;
- Оптимизатор филиала восстанавливает сжатые по алгоритму данные, полученные из ЦОДа, строит свой локальный симметричный словарь соответствий (блок данных — ссылка), убирает из данных ссылки и отправляет исходные данные клиенту;
- Теперь любые данные, проходящие через оптимизаторы филиала или ЦОДа, будут проверяться на наличие дуплицированных данных. Если будет обнаружено соответствие с блоком, находящимся в словаре, то этот блок сырых данных будет заменен короткой ссылкой. Известный (уже переданный) блок не передается.
Остается добавить, что словарь постоянно обновляется и, благодаря специальному алгоритму, в словаре остаются самые востребованные блоки данных.
Мы видим принципиальное отличие от традиционных кеширующих устройств. Кеширующие устройства работают на уровне файлов. Если файл претерпел какие-либо, пусть даже незначительные, изменения, то он должен быть передан заново. Оптимизаторы работают на уровне блоков данных, и при изменении ранее переданного файла в канал связи отправятся только изменения, а остальное будет заменено ссылками.
Еще одна проблема заключается в том, что скорость TCP ограничена размером окна (TCP Windows Size). Размер окна — объем данных, передаваемых отправителем до получения подтверждения от получателя. При этом для передачи уплотненного трафика требуется меньше раз передавать TCP Windows Size, что ведет к увеличению скорости передачи.
Итак, еще раз, это работает так:
- Устройство А дедуплицирует трафик.
- Устройство Б собирает «полную картину» из своего локального хранилища.
- Оба этих устройства работают симметрично.
- Оба этих устройства никак не влияют на инфраструктуру и конфигурирование всего того, что лежит за ними, то есть просто включаются в разрыв канала, например, на выходе из дата-центра и входе в региональный офис компании.
- Устройства никак не ограничивают связь с узлами, где таких устройств нет.
Дедупликация для шифрованных каналов
Шифрованный канал явно хуже подходит для сжатия и дедупликации, то есть практической пользы от работы с уже шифрованным трафиком почти нет. Поэтому оптимизаторы включаются в разрыв до устройства шифрования: ЦОД отдает данные оптимизатору, оптимизатор отдает на шифровку (например, в защищенный VPN-канал), на той стороне трафик расшифровывается и отдается оптимизатору на месте, а тот уже отдает их в сеть. Это штатная функция «коробочек-оптимизаторов», и все это происходит без снижения рисков компрометации трафика.
Дедупликация для мобильных сотрудников
В последние годы достаточно часто с ЦОДами напрямую работают люди с ноутбуками и планшетами, которым тоже нужно достаточно много данных (те же образы виртуальных машин или выборки из БД). Для них используются не «коробочки-оптимизаторы», а специальный софт, который просто расходует часть ресурсов процессора и часть жесткого диска для тех же целей. По факту мы меняем некоторое снижение производительности ноутбука и место в кеше на жестком диске на более быстрый канал. Пользователи обычно не замечают ничего, кроме ускорения работы сетевых сервисов.
Кто делает эти оптимизаторы?
Мы используем решения компании Riverbed. Эта компания была основана в 2002 году, а в 2004 году представила свою первую модель оптимизаторов для каналов связи. Продукты и решения Riverbed, включая оптимизацию WAN-сетей, управление производительностью, доставку приложений и ускорение работы хранилищ данных, дают возможность ИТ-специалистам увеличивать производительность и управлять ею. Оптимизаторы очень просто интегрировать в сеть. Самый простой способ — установка «в разрыв» со стороны LAN до маршрутизатора или VPN-шлюза.
Конкурентные решения. Компания Riverbed в 2013 году заняла 50% рынка сегмента WAN-оптимизации.
С точки зрения коммерческого директора заказчика, это несколько коробок, которые после простого включения в сеть ускоряют медленные каналы в 2–3 раза и снижают загрузку каналов от 2 раз. За это их любят почти все!
Подключение оптимизатора
Самый простой и надежный способ — «в разрыв» между граничным маршрутизатором и коммутатором ЛВС. Если оптимизатор выходит из строя, он замыкает контакты интерфейсов LAN и WAN — и трафик просто проходит через него, как через обычный кросс-кабель. Соответственно, видя неоптимизированный трафик, оптимизатор на той стороне также просто пропускает его через себя без обработки.
Соответственно:
- Связь филиала с оптимизатором и ЦОДа с оптимизатором – трафик оптимизируется.
- Связь филиала без оптимизатора и ЦОДа с оптимизатором – оптимизатор ЦОДа просто прозрачно пропускает трафик без изменений.
- Связь филиала с оптимизатором и ЦОДа с оптимизатором при выходе любого из оптимизаторов из строя – трафик просто не сжимается и ходит «как есть».
Естественно, в ЦОДах оптимизаторы кластеризуются для отказоустойчивости или наращивания мощности плюс снабжаются балансировщиками Interceptor. Но про это чуть ниже, когда дойдем до конкретного оборудования.
Ускорение TCP
Скорость работы TCP ограничена размером окна. Окно — это количество информации, которое сервер может отправить клиенту до получения подтверждения о получения.
Стандартное поведение TCP выглядит так:
- медленный разгон соединений, размер TCP-окна увеличивается;
- при потерях пакетов — резкое падение в скорости (уменьшение окна в 2 раза);
- и снова медленное ее увеличение (увеличение окна);
- снова потери пакетов и проседание полосы и так далее.
Оранжевая «пила» на графике – стандартное поведение TCP
На каналах связи с большой полосой пропускания, но наличием какого-либо уровня потерь и большими задержками RTT доступная полоса пропускания используется неэффективно, то есть канал никогда не загружается полностью.
В компании Riverbed думали примерно в том же направлении. И поскольку у нас уже есть коробки-оптимизаторы на входе и выходе, то глупо не использовать их для модификации TCP-протокола, чтобы избежать стандартных проблем. Поэтому оптимизаторы умеют не только оптимизировать трафик на уровне данных (дедупликация/сжатие), но и ускорять транспортный уровень.
Вот ряд режимов, доступных для ускорения TCP:
- режим HighSpeed TCP — здесь скорость достигает максимума куда быстрее, чем при обычной работе с TCP. При потерях он не так низко и не так сильно проседает, как стандартный TCP;
- режим MaxTCP — использует 100% полосы без замедлений. Пакет теряется — замедление не происходит. Однако этот режим требует настройки правил качества обслуживания QoS для определения ограничений доступной полосы пропускания, которую может занимать MX-TCP трафик;
- режим SCPS — разработан специально для спутниковых каналов связи. Здесь полосы не ограничиваются, как в MaxTCP. SCPS отлично адаптируется к плавающим характеристикам спутниковых каналов.
Оптимизация приложений
Многие приложения «болтливы», то есть могут отправить до 50 пакетов тогда, когда достаточно одного. Как я уже говорил, это следствие проектирования под локальные сети, а не под работу через каналы «дальней» связи. С использованием оптимизаторов число проходов туда-обратно уменьшается более чем в 50 раз.
Вот как это выглядит:
Оптимизаторы выступают в роли прозрачных прокси на седьмом уровне для ряда самых распространенных прикладных протоколов.
Оптимизатор ЦОДа выступает в роли клиента по отношению к серверу. Оптимизатор филиала выступает в роли сервера по отношению к клиентам. Таким образом, неэффективное, «болтливое» общение приложений остается в локальной сети. Между оптимизаторами обмен сообщениями приложения происходит в более подходящем для каналов связи виде — уменьшается количество сообщений.
Устройства оптимизации Riverbed умеют ускорять на седьмом уровне следующие прикладные протоколы:
Что интересно, тут есть и шифрованные приложения, включая зашифрованный Citrix и MAPI. При оптимизации шифрованного трафика не происходит снижение уровня безопасности.
Примеры ускорения работы приложений. В реальной сети ускорение будет зависеть от канала связи. Чем хуже канал связи, тем больших показателей ускорения можно добиться.
Типовая схема подключения
Оптимизаторы Steelhead ставятся перед каналом передачи данных, но до устройств шифрования. Для ЦОДов с особыми требованиями также используется кластеризация для повышения надежности плюс балансировщики нагрузок Interceptor.
Результат (пример)
Зеленый – WAN-трафик. Синий – LAN-трафик. Без оптимизатора Riverbed они были бы одинаковыми.
Выделенная колонка показывает процент сжатия по TCP-портам.
Линейки железа
Мощность может быть расширена лицензией. Для повышения производительности в ряде случаев требуется аппаратный upgrade. Возможности апргейда в пределах платформы показаны зелеными стрелочками.
Младшая модель подходит даже для маленького интернет-магазина: она от 1 мегабита в секунду и 20 каналов. А флагман поддерживает до 150 000 одновременных открытых соединений на каналах 1,5 гигабита в секунду. Если этого недостаточно, используется балансировщик Inteceptor. Кластеры из балансировщиков и оптимизаторов позволяют работать с каналом до 40 гигабит в секунду с открытым одновременно 1 миллионом соединений.
Сколько стоит по прайсу?
Младшая модель — примерно от 100 тысяч рублей, устройство для средних ЦОД — 1,1 млн рублей, для крупных ЦОДов — от 5,5 млн рублей. При этом цена достаточно сильно меняется в зависимости от конкретных схем использования, плюс могут быть скидки, поэтому названные числа сугубо примерные, лучше уточняйте по почте (она есть в конце топика). Окупаемость таких решений для среднего и крупного бизнеса просчитать достаточно легко, просто прикинув, что у вас освободится от 30 до 60% канала (опять же, конкретный показатель с точностью до 10% я смогу назвать по почте в зависимости от типа утилизации канала), а пользователи не будут жаловаться на тормоза приложений.
Еще элементы Riverbed:
После того как канал оптимизирован описанным способом, мы чаще всего делаем мониторинг и решение проблем с конкретными сервисами и оборудованием. На практике — это целые детективы. О них я расскажу чуть позже. Если интересно — подписывайтесь на корпоративный блог КРОК на Хабре.
Для кого внедрял конкретно я:
Я не имею права называть всех заказчиков, но могу сказать, что решение Riverbed для оптимизации трафика использовалось для:
- пяти крупнейших представителей банковского сектора;
- крупной золотодобывающей компании;
- крупной логистической компании;
- ряда компаний меньше размером.
Вопросы
Если интересно что-то конкретное, спрашивайте в комментариях или по почте AVrublevsky@croc.ru. По этой же почте могу отправить расчет цен, схемы внедрения и оценку оптимизации канала после обсуждения конкретно вашей ситуации. Понятно, что точная оценка возможна только после теста, но в среднем погрешность после обсуждения — около 10%.
Автор: AVrublev
