Построение бессерверных филиалов (часть 2). Проблемные точки при работе через WAN

Рассмотрим взаимодействие между центральной площадкой и региональным подразделением. И если сотрудники подразделения сообщают «Всё тормозит!», то разберёмся: как и где возникают проблемы.

На этом пути существуют проблемные точки, обусловленные конкуренцией за ресурсы:
— разницей скоростей LAN и WAN в центре;
— разницей скоростей LAN и WAN в подразделении;
— разницей скоростей WAN в центре и в подразделении;
— ограничением полосы на граничном устройстве оператора;
— перегрузками внутри сети оператора (для начала допустим, что их нет и «облако» оператора не оказывает влияния на трафик).

Естественно, что на входе в сеть оператора и на выходе из сети оператора настроен контроль пропускной способности в соответствии с договором. Такой контроль обычно применяется ко всему трафику, независимо от его типа (и критичности для организации) и заключается в ограничении полосы (Rate Limiting). При превышении порога пакеты сбрасываются, что, конечно, не очень дружественно к всплескам трафика.
Вследствие этого лучшим выходом будет перенести точку контроля на оборудование организации, под собственный контроль, например, на пограничный маршрутизатор. В этой точке включить шейпер трафика (Shaping) до уровня скорости WAN, чтобы сглаживать разницу скоростей LAN и WAN. Также подразумеваем, что формируется буфер, чтобы не терять пакеты при всплесках трафика. В каком именно порядке освобождать буфер по окончании всплеска? В простейшем случае передача пакетов из буфера в WAN-канал может выполняться по методу FIFO (First Input – First Output). При заполнении буфера происходит сброс приходящих пакетов, для которых «нет мест» (принцип Taildrop).

В ситуации длительных всплесков трафика в проблемных точках (congestion points) происходит:
—      буферизация и рост задержки ввиду ожидания в очереди (именно ожидание в очереди даёт основной вклад в сетевую задержку, см. подробнее ЦОД. Часть 3);
— сброс пакетов, таймауты ожидания и повторная передача потерянных пакетов.
С одной стороны, пропускная способность канала остаётся прежней, с другой стороны, она расходуется на обмен служебной информацией и повторные передачи. Фактически «полезная» пропускная способность падает. Как в шутке «Я могу набирать текст со скоростью 1000 знаков в минуту, правда, такая чушь выходит».
Рост задержек и снижение полезной пропускной способности приводит к росту времени отклика приложений (Application Response Time, ART) и синдрому «всё тормозит!»

Стоит отметить, что проблемы с Congestion Points можно встретить и в локальных сетях, например, в ЦОД. Даже если сеть ЦОД как таковая построена без переподписки, возникает феномен, называемый «incast» (см. пример в исследовании Efficient Packet Transport for the Commoditized Data Center), что в итоге приводит к задержкам в работе приложения. Насколько существенными могут быть задержки? Порядок – десятки миллисекунд. Кажется, что 10 мс – это немного. Но в результате, например, когда пользователь в поисковом портале набирает запрос, то портал оказывается неспособен своевременно выдавать подсказки.

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

Рассмотрим на реальном примере влияние избыточного буфера (т.н. эффект Bufferbloat).
Время от времени пользователи жаловались на «медленный Интернет», при это входящий канал был загружен незначительно; проблема усугублялась, если был загружен исходящий канал. На доступ в Интернет установлен ADSL-маршрутизатор и проверка показала наличие буфера достаточно большого размера. Замеры с применением ICSI Netalyzr показали время отклика порядка 1.7 сек при заполнении выходного буфера.

Происходит следующее: пакеты накапливаются в буфере, растёт задержка. С точки зрения транспортных протоколов (TCP, UDP) ничего плохого не происходит – пакеты не теряются, они просто больше времени проводят «в пути», растёт RTT (Round Trip Time). Интерактивные приложении уже начинают подвисать и «дёргаться». Тем временем, алгоритм TCP Congestion Avoidance, ответственный за детектирование перегрузки в сети, не замечает проблем, поскольку он реагирует на потери пакетов, но потерь пока ещё нет. В итоге все участники продолжают передавать данные с прежней или даже возрастающей скоростью. Буфер заполняется до предела (задержка достигает максимального значения), начинается сброс трафика. Стандартный метод Taildrop отправляет «под нож» без разбору все пакеты, приходящие в хвост очереди. Как следствие для всех приложений сразу начинаются потери пакетов (более жадные к пропускной способности теряют в большей степени) и повторные передачи (для TCP) или дальнейшее ухудшение качества связи (для приложений с UDP-транспортом – ВКС, VoIP). Только после этого всеобщего коллапса срабатывает TCP Congestion Avoidance и существенно снижает скорость передачи у всех участников.
С учетом того, что размер буфера ADSL-маршрутизатора фиксирован, было принято решение настроить шейпер на выходном интерфейсе устройства перед ним. Был настроен шейпер на скорости 1.6 Мбит/с (скорость DSL-канала за вычетом служебных заголовков) и буфер на 40 пакетов. 

Итак, в сценарии «буфер + FIFO + Taildrop» нужно тщательно подходить к выбору длины очереди:
— уменьшение буфера – это риск сброса пакетов при всплесках;
— увеличение буфера – это рост задержек.
Кроме того, сама по себе FIFO-очередь, пусть и оптимального размера, обслуживает трафик в порядке поступления и не позволяет приоритетно обработать и уберечь от сбросов трафик интерактивных приложений.

Чтобы уменьшить время отклика (ART) для чувствительных (интерактивных) приложений, недостаточно просто сократить размер общего буфера. Для трафика интерактивных приложений нужно:
— сократить время ожидания в буфере;
— свести к минимуму потери пакетов.
Как этого достичь? Может быть увеличить пропускную способность каналов? Настроить QoS с различными очередями для разных типов приложений? Задействовать механизмы WRED (Weighted Random Early Detection)? Или ECN (Explicit Congestion Notification – интересный и полезный механизм, к сожалению не получивший широкого распространения)?
Варианты решений подробнее рассмотрим в следующих статьях.