Управление сетевыми заторами

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

У маршрутизатора или коммутатора имеются буферы на входящем и исходящем портах. На каждый такой буфер выделяется ограниченный объем памяти из общей емкости памяти. Кроме того, при отправке любого кадра возникает так называемая задержка при отправке (Serialization Delay), необходимая для того, чтобы преобразовать информацию в соответствующий сигнал (ток, свет, электромагнитную волну) и направить в физическую среду.

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

Чаще всего заторы возникают в месте подключения к Интернету, между коммутаторами уровня распределения/ядра и коммутаторами уровня доступа, между устройствами на уровне распределения/ядра и при доступе к серверам. В последнем случае заторы обусловлены принципами проектирования сети: невозможно обеспечить доступ к ресурсам сервера с пропускной способностью, величина которой была бы равна сумме скоростей соединений клиентов. Во-первых, такой подход чрезвычайно дорог, поскольку требует установки СКС, серверного и сетевого оборудования с очень высокой производительностью, а во-вторых, избыточен, так как крайне редко возникает ситуация, чтобы сразу все клиентские станции активно обращались к одному серверу.

О модернизации (увеличении пропускной способности) следует задуматься, если средняя загруженность канала передачи данных приближается к 70%. Для корпоративных сетей, где время от времени возникают пиковые всплески активности, заторы — нормальное явление. Кроме того, в их появлении могут быть виноваты сотрудники, которые задействуют ресурсы компании в своих целях, например, используют различные программы для скачивания. Эту причину возникновения заторов можно устранить, если отдел безопасности будет контролировать, что происходит в сети и как выполняются политики безопасности, а отдел ИТ настроит приоритеты для разных типов трафика и задаст для них необходимую пропускную способность и соответствующий класс обслуживания.

КУПИРОВАНИЕ ХВОСТА

Первым и самым простым методом управления заторами был Tail Drop. Его суть крайне проста: если буфер для пакетов переполнен и следующий пакет некуда записать, то устройство просто отбрасывает этот пакет. Если сеть не передает критичные или чувствительные данные, нагрузка на сеть небольшая, а заторы возникают редко, этих мер вполне достаточно.

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

Действительно, если удален пакет HTTP, то протокол TCP запросит недостающие сегменты для повторной передачи, а пользователь даже не заметит, что Web-страница открылась на несколько миллисекунд позже; то же самое и в отношении изъятия пакета FTP: не так уж и важно, сколько будет скачиваться файл, — две или три минуты…

Если был отброшен пакет VoIP, то последствия будут сразу заметны. Потеря пакетов приведет к перебоям в речи. По сути, новые алгоритмы управления заторами были созданы в целях обеспечения своевременной доставки видео- и голосового трафика, весьма чувствительного к задержкам и потере пакетов (транспорт посредством UDP).

Потеря пакета DNS или Syslog тоже не остается без последствий, так как большинство служебных протоколов функционируют с помощью UDP, который не гарантирует доставки, из-за чего могут возникнуть проблемы с сервисом имен или записи событий не попадут на сервер. Поэтому служебные протоколы не должны страдать из-за заторов, так как они, в свою очередь, являются опорой для служб и протоколов высших уровней.

СИНХРОНИЗАЦИЯ СЕТИ

При установлении соединения сетевые устройства сначала согласуют размер окна передачи данных (TCP Window), а затем начинают передавать данные. Это окно характеризуется количеством байт, которое одно устройство может отправить другому до получения подтверждения. Если после отправки данных отправитель своевременно получает подтверждение о доставке, то он увеличивает окно передачи, тогда как при поступлении запроса на повторную пересылку окно передачи сокращается наполовину. С подобным поведением связана проблема «синхронизации» сети.

Допустим, кому-то потребовалось передать достаточно большой объем данных. При наличии свободной пропускной способности окно передачи будет увеличиваться, и скоро этот поток займет весь канал. Сетевое устройство, обладающее наименьшей производительностью, перестанет справляться со своевременной отправкой данных, и пакеты будут помещаться в его буфер. В конце концов в буфере не останется места для прибывающих пакетов, и один из них будет отброшен. Об этом в скором времени узнает станция-отправитель и уменьшит окно передачи данных.

Казалось бы, в чем проблема? Дело в том, что мы рассмотрели ситуацию только для одного потока, но в один буфер поступают пакеты со всех потоков. И когда буфер окажется переполнен, то последствия будут одинаковы для всех потоков. А это значит, что каждый из них может потерять по пакету в одно и то же время, в ответ все отправители сразу же уменьшат окна передачи на одинаковую величину. Алгоритм TCP не предусматривает никаких механизмов случайных задержек для расширения окна, поэтому все отправители опять одновременно увеличат окно передачи данных после устранения затора — и все повторится заново (см. Рисунок 1).

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

RED И WRED

Для решения проблемы синхронизации сети был придуман алгоритм раннего случайного обнаружения (Random Early Detection, RED). RED полностью заменяет Tail Drop и немного смягчает ситуацию в сети. Суть технологии заключается в том, что пакеты удаляются прямо из буфера, не дожидаясь его переполнения. Алгоритм не дискриминирует пакеты по каким-либо признакам, будь то длина, тип или поток данных. Он опирается на теорию вероятности: объемные потоки данных присылают больше пакетов, поэтому и «страдают» больше, а единичные пакеты редко подвергаются экзекуции…

Работа алгоритма строится в соответствии с тремя параметрами:

• минимальный порог (minimum threshold) — количество пакетов в очереди, при превышении которого активируется RED. Другими словами, эта величина определяет степень заполнения очереди, при которой наступает необходимость от них избавляться;
• максимальный порог (maximum threshold) — число пакетов в очереди, когда RED уже не справляется с наплывом пакетов, поэтому приходится прибегать к помощи TailDrop и удалять все поступающие пакеты;
• вероятностный множитель (mark probability denominator) — доля пакетов, которые будут отбрасываться при достижении максимальной длины очереди. Именно от этого значения зависит, какой процент пакетов будет отбрасываться при заданной степени заполнения очереди.

В качестве примера рассмотрим график, представленный на Рисунке 2. Если в очереди находится до 30 пакетов, то нижняя граница еще не достигнута, и пакеты обслуживаются обычным образом. В случае превышения числа 30 к очереди применяется RED. Значение MPD равно пяти: при достижении максимально разрешенного числа пакетов в очереди отбрасывается каждый пятый, то есть 20% пакетов. Если и этого недостаточно, то применяется Tail Drop.

С изменением количества пакетов в очереди от минимального значения к максимальному активность RED возрастает по линейной зависимости. Так, если полная загрузка очереди составляет 40 пакетов, то RED удалит 20% из них, тогда как из очереди, где находятся 35 пакетов, будет удалено 10%.

При использовании RED пакеты удаляются случайным образом и в разное время, поэтому потоки данных будут рассинхронизированы и проблемы синхронизации TCP уже возникать не будут (по крайней мере, не в такой жесткой форме, как раньше).

Компания Cisco предложила собственную модификацию алгоритма RED, получившую название Weighted RED. Основное отличие версии Cisco — добавление к RED интеллектуального функционала для преднамеренного удаления пакетов. WRED отбрасывает пакеты на основе приоритетов QoS, таких как IP Precedence или DSCP. Кроме того, он позволяет настроить разные пороговые значения очередей для различных классов и предоставить приоритет необходимому трафику.

Но эти алгоритмы не позволяют устранить все возможные проблемы с заторами вследствие нескольких причин:

• станция, которая передавала пакет, узнаeт о заторе в сети только при условии «уничтожения» одного из своих пакетов;
• хоть трафик и «прореживается» с учетом приоритета, его необходимо пересылать еще раз, если он передается по протоколу TCP;
• трафик UDP оказывается потерян безвозвратно.

ЯВНОЕ ОПОВЕЩЕНИЕ О ЗАТОРЕ

Явное оповещение о заторах (Explicit Congestion Notification, ECN) представляет собой дополнение к RED и делает управление заторами в сети более щадящим по отношению к трафику. Технология появилась еще в 2001 году, но до сих пор ее мало кто использует. Алгоритмы работы, лежащие в основе ECN, позволяют уведомлять сетевые устройства о заторе в сети без необходимости отбрасывания пакетов.

Первое изменение, которое предполагает ECN, — использование последних двух битов в поле ToS в заголовке IP (см. Рисунок 3). Как видно из схемы, для ECN отводятся седьмой и восьмой биты. Два бита позволяют задать четыре значения (см. Таблицу 1).

Значение поля, равное «0», говорит о том, что устройство либо ничего не знает про ECN, либо не может работать с этой технологией по каким-то другим причинам. Значения «01» и «10» не различаются, и станции сами могут выбирать, какое из них использовать для сигнализации о поддержке ECN (как ожидается, разграничение значений будет произведено в будущем). Флаг затора в сети, или значение «11», устанавливается при помощи служебных сетевых устройств.

Кроме двух битов в поле ToS были внесены изменения в заголовок TCP — из зарезервированных ранее задействовано два бита для использования в качестве флагов ECN:

• Explicit Congestion Echo (ECE) — этот флаг используется принимающей станцией для уведомления передающей о возникновении затора в сети;
• Congestion Window Reduced (CWR) — этот флаг выставляется отправителем для уведомления получателя об уменьшении окна передачи данных.

Рассмотрим работу алгоритма в действии. Итак, у нас есть рабочая станция, два маршрутизатора, которые представляют сеть, и сервер (см. Рисунок 4). Все устройства поддерживают ECN. На втором (от клиента) маршрутизаторе возникает затор, в результате чего активируется RED с ECN.

При установлении соединения между рабочей станцией и сервером с поддержкой ECN станция должна переслать серверу модифицированный пакет TCP SYN, в котором оба флага (ECE и CWR) будут заданы равными «1». Если этому пакету удастся достичь сервера, то последний определит, что рабочая станция хочет создать соединение с поддержкой ECN. В ответ сервер отправит модифицированный TCP-пакет SYN-ACK с установленным битом ECE. Такой ответ свидетельствует о том, что сервер умеет работать с ECN и соединение с поддержкой этой технологии может быть создано.

Для согласования и установления соединения все флаги должны быть выставлены именно так, как указано выше, любая другая комбинация будет сигнализировать о том, что устройство не способно работать с ECN. После успешного обмена модифицированными служебными пакетами организуется соединение между рабочей станцией и сервером с поддержкой ECN. (Кстати, если служебные пакеты TCP не доходят до получателя, то при следующей попытке установить соединение оба флага обнуляются. Это сделано для того, чтобы устаревшие устройства, особенно системы обнаружения вторжений и межсетевые экраны, не заблокировали общение полностью, так как, не поддерживая данной модификации TCP, они могут воспринимать такие пакеты как подозрительные или испорченные.)

Обмен данными происходит следующим образом. При отправке данных на сервер рабочая станция в заголовке пакета IP задает биты ECN — «01» или «10». Получив пакет, первый маршрутизатор определит, что передаваемый поток данных поддерживает технологию ECN. Ввиду отсутствия затора маршрутизатор просто передаст пакет дальше. Из-за того что второй маршрутизатор не успевает обработать все пакеты, он применит к очереди ожидания RED. Если RED выберет пакет с ECN из данного потока, то не станет его отбрасывать. Вместо этого маршрутизатор установит значение ECN=11, т. е. оповещение о заторе в сети, и отправит пакет к серверу.

Получив пакет, сервер определит, что установлен флаг перегрузки (Congestion Experienced, CE), поэтому следует оповестить рабочую станцию о заторе. Когда сервер будет отправлять служебный пакет подтверждения доставки — TCP ACK, он установит флаг ECE. (Для того чтобы пакеты «пробились» через сеть, сервером будет выслано несколько подтверждений.) Рабочая станция, получив TCP ACK, по выставленному флагу установит, что в сети образовался затор, уменьшит окно передачи данных и выставит флаг CWR в своем следующем пакете. Для сервера этот флаг будет служить подтверждением того, что станция получила эхо-пакет и оповещена о наличии затора в сети. Таким образом, с помощью ECN можно бороться с заторами в сети, причем число отброшенных пакетов окажется очень малым, либо потерь удастся избежать вовсе.

Внедрение технологии ECN затруднено из-за отсутствия поддержки со стороны производителей программного обеспечения. Как уже упоминалось, сама технология появилась в 2001 году, и производители сетевого оборудования внедрили ее несколько лет назад (Cisco IOS версии 12.2(8)T). А вот операционные системы не предусматривали поддержки ECN вплоть до последнего поколения. Внедрять технологию без поддержки ОС, только в сетевых устройствах, нет никакого смысла — сами маршрутизаторы не могут остановить или замедлить скорость передачи пакетов в сети.

Если пакеты постоянно поступают на входной интерфейс, их маркировка вряд ли поможет решить проблему, ведь эту маркировку некому обрабатывать. Технология должна быть внедрена сразу по всей сети, включая сетевое оборудование, клиентские и серверные операционные системы. Последнее поколение операционных систем компании Microsoft — Windows Vista, Windows 7 и Windows Server 2008 — поддерживает технологию ECN.

НЕМНОГО О НАСТРОЙКЕ ECN

Настройка ECN занимает мало времени и очень проста. На устройствах Cisco ECN обычно настраивается в картах политик (Policy Мap) для различных классов трафика на выходе из интерфейса.

Команда для включения ECN:

Router(config-pmap-c)# random-detect ecn

Команда для проверки настроек:

Router# show policy-map

Для операционных систем Windows настройка выглядит следующим образом:

1. вызвать командную строку с правами администратора;
2. netsh int tcp set global ecncapability=enabled (включение поддержки ECN);
3. netsh int tcp set global congestionprovider=ctcp (дополнения к TCP);
4. netsh int tcp show global (проверка настроек).

При наборе команды мы должны получить результат, представленный на Рисунке 5. Параметры, обведенные красным маркером, показывают, что ECN включен.

Технология Explicit Congestion Notification является хорошим дополнением для RED и WRED, ее «гуманность» по отношению к трафику позволит повысить эффективность использования пропускной способности, так как отброшенные пакеты не придется передавать заново. Однако далеко не все проблемы, связанные с нехваткой пропускной способности, можно решить при помощи приоритизации трафика, конфигурирования алгоритмов работы с очередями и технологий управления заторами. Если для легального трафика пропускной способности канала недостаточно, все перечисленные выше методы лишь смягчат последствия инцидентов, возникающих вследствие чрезмерной загруженности канала.

RED, WRED и ECN — средства предотвращения заторов — являются только частью инструментария управления сетевыми заторами и предоставления QoS, который включает еще и алгоритмы управления очередями: Weighted Fair Queue, Custom Queue, Low Latency Queue, Priority Queue и др. Кроме того, оптимизация использования пропускной способности канала выполняется посредством технологии сжатия, чередования и фрагментации. Для конкретного типа трафика необходимого уровня обслуживания можно добиться только с помощью комбинации технологий QoS. Без применения механизмов очередей с приоритизацией критичного для компании трафика внедрение механизмов предотвращения заторов не даст желаемого результата.

Алексей Зайончковский — эксперт по обучению в области ИТ.