Построение бессерверных филиалов (часть 4). Гарантии уровня обслуживания в WAN

На границе WAN – в точке конкуренции за ресурсы – нужен инструмент, который позволит, во-первых, задать требования к уровню обслуживания в терминах приложений, их значимости для деятельности организации, времени отклика; во-вторых,  применить эти требования к трафику в данной проблемной точке. Например, реализовать такую политику: обеспечить для голосового трафика и ВКС время отклика до 100 мс; для терминальных сессий и сетевых служб (AAA, DNS) – до 200 мс; для транзакционных корпоративных приложений (веб-портал, «толстый» клиент БД) – до 400 мс; для фоновых корпоративных приложений (электронная почта, файловый обмен) – просто гарантировать доставку сообщений или файлов, выделив для них определенную полосу; остальной трафик обслуживать по принципу «Best effort».
Чтобы достичь такой цели потребуется:
— идентифицировать приложения в сети, чтобы чётко распознавать принадлежность пакета или потока к тому или иному сетевому приложению;
— замерять параметры функционирования приложений, чтобы понимать насколько комфортно в настоящий момент чувствует себя каждое приложение и его пользователи;
— формировать очереди и автоматически подстраивать их параметры (размер буфера, приоритет, задержка, полоса пропускания), чтобы достичь заданных целевых значений для каждого приложения.

Для определенности назовем такой функциональный компонент WAN Optimization Controller. WOC распознает трафик приложений, замеряет текущие параметры функционирования приложений через WAN и назначает трафик в ту или иную очередь для обеспечения требуемого уровня обслуживания.

  Идентификация сетевых приложений
Для распознавания приложений требуется анализ трафика на L3-L7 – это как минимум DPI (Deep Packet Inspection), а ещё лучше DSI (Deep Session Inspection). Ведь чтобы принять решение о том, к какому приложению относится данная сессия, необходимо прочесть и верно интерпретировать поток байтов из пакета или последовательности пакетов – IP-адрес сервера и клиента, идентификатор протокола, номера портов TCP или UDP, заголовки прикладного уровня.
Что если обмен с удаленными подразделениями идёт в туннеле IPsec? В таком случае WOC должен применяться до функции IPsec, чтобы «видеть» и обрабатывать исходный трафик, не подвергнутый шифрованию. А если применяется шифрование end-to-end, например, клиент работает с сервером по протоколу HTTPS? Есть варианты: либо читать прикладной уровень, применяя механизм инспекции SSL-соединений (фактически Man-in-the-middle на уровне сети), либо ограничиться классификацией на уровнях OSI L3-L5 (IP-адрес сервера, TCP-порт, идентификатор Hostname в SSL-заголовке).

  Понимание характеристик функционирования приложений
О каких характеристиках идёт речь? Для простого пользователя важен только один параметр – время отклика, ART. Если время отклика ниже определенного порога, пользователь работает в комфортных условиях, не вспоминая о сети и не задумываясь о том, где находится сервер – рядом в здании (LAN) или на удаленной площадке (WAN).
Но ART – это интегральная величина, определяемая множеством факторов. Поэтому требуется регистрировать и другие метрики, влияющие на ART: задержка и вариация задержки, RTT (Round trip time), потребляемая сессией полоса пропускания, процент потерянных пакетов. Знание этих характеристик и их изменения с течением времени позволит определить причину, источник проблем в работе прикладных сервисов через WAN.
Кроме того, на ART влияют и не зависящие от сети аспекты, такие как загрузка CPU сервера или задержки в системе хранения данных. В общем случае стоит контролировать и такие метрики: ведь нередки ситуации, когда за эксплуатацию различных систем – серверов, приложений, СХД, сети – отвечают различные группы, и диагностика проблем функционирования переходит в режим «перевода стрелок» на другой отдел.

  Применение политик обслуживания
Выше были рассмотрены две функции: распознавание приложений и замер характеристик их функционирования. Эти функции позволяют построить картину происходящего в сети. И если картина не устраивает, то в дело вступает третий, активный компонент WOC. От него требуется:
— на вход принимать политики, задаваемые в терминах приложений и  их требований (время отклика, пропускная способность, допустимые потери), и сведения о WAN, такие как «ширина канала»;
— на основе политик и сведений о WAN формировать необходимые очереди и шейперы для приоритетной обработки трафика и управления полосой пропускания, чтобы для каждой сессии, каждого приложения гарантировать требуемые характеристики функционирования.

Итак, пусть в точке конкуренции за ресурсы мы распознаем сетевые приложения, контролируем метрики их функционирования, применяем к трафику заданные политики обслуживания.
Что если таких точек конкуренции несколько: одна точка в центре и N точек в удаленных подразделениях. Естественным выглядит применить WOC в каждой такой точке. Такая симметричная схема – вполне рабочее решение. Более того, в этом случае получаем дополнительные плюсы, о которых поговорим в следующей части блога.
Но рассмотрим экстремальную задачу: возможно ли обойтись применением WOC только на центральной площадке?

Итак, в центре решена проблема, связанная с разницей скоростей LAN и WAN. Какие ещё сложности остаются? Это:
— разница скоростей LAN->WAN на удаленных площадках;
— агрегация в центре – суммарный трафик удаленных подразделений может превышать ширину канала в центре;
— разница скоростей в центре и подразделениях – центр может выдать больше трафика, чем способен принять канал подразделения;
— проблемные точки в сети оператора.
В рассматриваемом экстремальном сценарии отсутствуют рычаги для прямого управления трафиком на удаленных площадках. Значит, придется использовать косвенные методы.
Пусть с удаленной площадки в центр передается одновременно фоновый трафик (файловый обмен, электронная почта) и интерактивный трафик (терминалы, телефония, ВКС) – канал удаленного подразделения «занят» на 100%. Пакеты сверх этих 100% будут либо сбрасываться на входе в сеть оператора, либо буферизоваться шейпером (если он есть) удаленного подразделения и в конечном счете тоже сбрасываться. Причём «под нож» пойдёт и фоновый, и чувствительный к задержкам или потерям трафик. Пострадают интерактивные приложения. Что можно с этим сделать, имея точку контроля только на центральной площадке?
Способ первый: избирательно «резать» этот с таким трудом переданный трафик. Ключевой пункт здесь – избирательно. Сбрасывая часть трафика фоновых приложений, центральный WOC неявно – через механизмы TCP Congestion Avoidance – просигнализирует этим приложениям о необходимости притормозить обмен трафиком. При этом более важные приложения такого сигнала не получат и смогут воспользоваться высвобожденными ресурсами канала.
Способ второй: управление окном TCP. Снова WOC в центре сигнализирует участникам притормозить обмен фоновым трафиком, но используется другой механизм –модификация значения TCP Window в проходящих пакетах. Стек TCP/IP оконечных узлов реагирует на изменение окна и сбавляет темп отправки данных в сеть.
Оба способа помогают решить первые две проблемы (разница скоростей LAN-to-WAN на удаленных площадках, агрегация в центре).
Третья проблема, когда центр выдаёт больше трафика, чем способен принять канал удаленной площадки, решается тривиально: WOC не должен допускать отсылки в каждое подразделение трафика больше, чем способен обработать канал подразделения. Как можно определить принадлежность трафика тому или иному подразделению? По IP-адресу назначения: например, за подразделением «Бобруйск» закреплен диапазон 10.20.30.0/24. Значит, трафик на сеть 10.20.30.0/24 не должен превышать ширины канала подразделения «Бобруйск».
Четвертый вопрос – это потенциальное наличие проблемных точек внутри сети оператора. По этому пункту схема с WOC в центре уступает симметричной схеме (WOC в центре и подразделениях). В последнем случае организация обладает «сенсорами» в каждой точке включения в WAN. Анализируя информацию от сенсоров можно сделать однозначные заключения. Вот пакет X был отправлен в момент T0 и был принят на другой стороне в момент T1, значит, сеть оператора внесла задержку (T1 — T0). Или пакет Y был отправлен в WAN, но не принят другой стороной (пропуск в TCP Sequence Number), значит, присутствуют потери в сети оператора, процент потерь такой-то.

Резюмируя. Джентльменский набор для обеспечения гарантированного уровня обслуживания в WAN:
— распознавание приложений, включая анализ L7-заголовков;
— мониторинг функционирования приложений;
— применение политик обслуживания трафика (формирование очередей и адаптивная подстройка их параметров для достижения заданных целевых показателей).
Вопрос дизайна: использовать WOC либо только на центральной площадке (асимметричная схема), либо в центре и в удаленных подразделениях (симметричная схема).

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