Построение бессерверных филиалов (часть 3). Что если расширить WAN-каналы или применить QoS?

08.04.2014 | Кацубо Сергей
Want create site? Find Free WordPress Themes and plugins.

Как мы выяснили в предыдущей части, чтобы уменьшить время отклика (ART – Application Response Time), нужно для трафика соответствующих приложений:
— сократить время ожидания в буфере;
— свести к минимуму потери пакетов.

   Увеличение пропускной способности каналов
Что если просто увеличить пропускную способность WAN-каналов – расширить «трубу»? Очевиден выигрыш: во-первых, сокращается время ожидания, поскольку буфер освобождается быстрее; во-вторых, становится менее острой конкуренция за пропускную способность и реже происходит сброс пакетов. Впрочем, на таком интуитивно понятном и простом пути нас ожидают ловушки.

Передаваемый трафик занимает весь предоставленный ему канал. (С учетом Window Scaling одна TCP-сессия способна занять даже очень широкий WAN-канал). Пусть ранее на скорости 1 Мбит/с загрузка файла занимала 1 минуту; соответственно интерактивные приложения (например, терминалы RDP/Citrix) «тормозили» и «залипали» в течение 1 минуты. Что получим при удвоении пропускной способности в подразделениях и центре? Да, на канале 2 Мбит/с будет быстрее загружаться файл, пусть в 2 раза. Значит, в течение меньшего времени будут «тормозить» интерактивные сессии. Если раньше перерыв в работе составлял 1 минуту, то теперь это время уменьшится до 30 секунд. Рост производительности сотрудников налицо : )

Увеличение пропускной способности само по себе не решает вопрос потерь пакетов. При заполнении буфера будут сбрасываться все приходящие пакеты, что приведёт к росту ART для всех приложений. Вспомним также о сети оператора: гарантируется ли указанная в договоре пропускная способность? Или же эпизодически скорость может падать, что эквивалентно сбросу трафика оператором? Повсеместно распространенная практика – это просто выделение полосы, ограниченной «сверху» и без гарантий «снизу».

Расширение каналов «вслепую» не устраняет автоматически все точки конкуренции за ресурсы, остаются подводные камни:
— разница скоростей LAN-to-WAN на каждой площадке – отчасти смягчается расширением канала, в предельном случае при наличии достаточных финансовых средств можно уравнять скорости в LAN и WAN и убрать эту точку;
— агрегация в центре – суммарный трафик удаленных подразделений может превысить ширину канала в центре, а значит, ширина канала в центре должна быть достаточной для парирования такой ситуации (снова финансы);
— разница скоростей в центре и регионах – поскольку в центре канал заведомо шире, чем в подразделении, то будут возникать моменты, когда центр выдаёт больше трафика, чем способен принять канал подразделения и получим сброс пакетов на оборудовании оператора и ухудшение ART.

И еще момент: имеют ли региональные сотрудники доступ в Интернет? Если да, то непроизводственный трафик будет «съедать» WAN-канал независимо от его ширины.

   Network QoS
Если наращивание пропускной способности не выход, то воспользуемся механизмами QoS. Под QoS понимаем встроенные в маршрутизаторы механизмы Congestion Management и Congestion Avoidance.
Congestion Management позволяет различным образом обслуживать трафик разных типов приложений: вместо стандартной FIFO-очереди формируются несколько очередей со своими параметрами (размер буфера, доступная пропускная способность, приоритет), и трафик назначается в ту или иную очередь в зависимости от требований приложения.
Congestion Avoidance направлен на своевременное уведомление получателя и/или источника о возникающих проблемах, прежде чем полное заполнение буфера приведёт к коллапсу: применяются механизмы RED или ECN.

Действительно, настройка QoS на пограничных маршрутизаторах в некоторой степени улучшает ситуацию с ART, но упирается в ограничения QoS: проблемы с распознаванием ряда приложений и отсутствие обратной связи.

QoS классифицирует трафик на основе параметров L3 и L4. Но совсем не редкость, когда различные приложения используют один номер порта, например, порт 80. Значит, нужно добавить классификатор по IP-адресу. Но и IP-адрес в условиях динамического ЦОД может меняться после перезапуска машины (сохраняется закрепленный за ней FQDN и только обновляются DNS-записи). Как быть?
Более того, при работе с одним приложением по одному порту клиент может открывать несколько сессий с разными требованиями к уровню обслуживания. Пример: терминалы Citrix используют различные сессии для различных действий, и признаком интерактивного трафика служит поле в L7-заголовке. Стандартный QoS, не имея возможности анализировать Citrix-заголовки, не сможет отделить интерактивные сессии (прорисовка рабочего стола, перемещении мыши) от фоновой печати или передачи файлов и назначить им различные приоритеты. Как следствие, даже при наличии QoS-политик один сотрудник, отсылающий в Citrix-сессии файл на печать, «подвесит» терминальный доступ для остальных сотрудников удаленного подразделения.
Другой пример: портал совместной работы. Тонкий клиент – браузер – открывает параллельные соединения под различные задачи: чат, видеотрансляция, обмен документами. Для распознавания интерактивного трафика нужно анализировать HTTP-заголовки – поле URL в запросе, поле Content-Type в ответе. Стандартный QoS, не имея возможности анализировать HTTP-заголовки, не сможет отделить интерактивные сессии от фоновых.
Проблема не нова и в некоторых реализациях QoS производители добавляют расширения для сигнатурного анализа пакетов, что в теории позволяет «заглянуть» на L7.

Далее, QoS работает с потоками в каждом направлении независимо. Например, соединение между клиентом и сервером – это с точки зрения QoS два независимых потока, и для каждого потока независимо выполняется распознавание типа приложения, классификация и обработка в очереди. Иначе говоря, невозможно на основе содержания запроса назначить политику обслуживания ответа.

Механизмы Network QoS работают на каждом устройстве автономно, независимо от других устройств, не сохраняют информацию о состоянии, не получают информацию из сети и не выдают её в сеть или администратору. Это значит, что механизмы QoS:
— не способны замерить время отклика (ART) и выдать какую-либо статистику о функционировании приложений через WAN. Для администратора WAN оказывается слепым пятном;
— не способны отреагировать на изменения условий в WAN, например, рост потерь пакетов или рост задержки. А ведь при наличии двух WAN-каналов появляется принципиальная возможность в любой момент автоматически переключить чувствительный трафик на путь с лучшим уровнем обслуживания.

Кроме того, задавать политики обслуживания QoS приходится в терминах размера буфера, относительного приоритета и веса, пропускной способности. Невозможно средствами QoS указать явно желаемое время отклика или проконтролировать этот параметр в работающей сети. (Отметим, что с дополнительными инструментами замерить ART для реального трафика возможно: например, захватив снифером копию трафика с промежуточного коммутатора).

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

Did you find apk for android? You can find new Free Android Games and apps.
Комментариев пока нет
Добавить комментарий