Методы борьбы с перегрузками в сети SIP

Причины возникновения перегрузок

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

Пропускная способность сервера определяется мощностью его центрального процессора (ЦП), объемом оперативной памяти, скоростью сетевых интерфейсов, объемом дисковой памяти и другими ресурсами. Как правило, в случае перегрузки быстрее всего расходуются ресурсы ЦП, так как остальные ресурсы обычно планируются таким образом, чтобы вероятность перегрузки в них была минимальной. Сразу оговоримся, что перегрузкой сервера SIP будем считать отсутствие ресурсов ЦП, необходимых для работы программной реализации протокола SIP на данном сервере.

Существующий метод борьбы с перегрузками

Изначально в спецификации стандарта SIP [1] был определен метод борьбы с перегрузками с помощью сообщений № 503 «Service Unavailable» (условно назовем его «метод 503»). Когда сервер не в состоянии обработать вызов, он может послать сообщение 503 Service Unavailable. Он также может включить в ответ заголовок Retry-After с указанием временного промежутка, сообщающего нижестоящему элементу о необходимости подождать указанное время. Однако в процессе эксплуатации у данного метода был выявлен целый ряд недостатков [2]:

• -    увеличение нагрузки: в случае перегрузки множества компонентов в сети SIP, данный метод может привести к еще большей перегрузке. «Метод 503» может быть приемлемым в случае перегрузки одного - единственного сетевого элемента, но в случае перегрузки множества элементов этот метод приводит к значительному увеличению количества передаваемых сообщений и, соответственно, к еще большей нагрузке на серверы;

• -    недоиспользование ресурсов: в большинстве реализаций протокола SIP получение сообщения 503 означает, что в состоянии перегрузки находится весь сервер, определяемый доменным именем. Хотя в действительности за одним доменным именем может находиться несколько серверов, и только один из них может быть перегружен;

• -    проблема неустойчивости трафика: использование таймера приостановки трафика в заголовке Retry-After приводит к резкому всплеску трафика по истечении данного таймера, что потенциально может привести к очередной перегрузке сервера.

Новый механизм управления перегрузками

Для устранения вышеуказанных недостатков был разработан новый механизм управления перегрузками (УП). Обобщенная модель реализации данного механизма изложена в [3]. Модель описывает два взаимодействующих сервера – сервер-отправитель и сервер-получатель. Механизм УП направлен на защиту от перегрузок сервера-получателя. Для этой цели между двумя серверами реализована обратная связь (ОС). В каждом из серверов выделены реализующие данную модель компоненты, представленные в виде выполняемых ими функций (см. рис. 1).

Рис. 1. Обобщенная модель УП

Основными компонентами обобщенной модели УП на рис. 1 являются:

• -    стек SIP – программная реализация протокола SIP. Функция, отвечающая за обработку вызовов. Объект защиты от перегрузок;

• -    монитор – функция, ответственная за измерение текущей загрузки стека SIP на приемной стороне. Результаты измерения (РИ) в виде отчетов передаются функции контроля;

• -    контроль – функция, реализующая алгоритм защиты от перегрузок. Используя полученные отчеты (РИ) как входную функцию, определяет наступление состояния перегрузки и необходимые изменения (НИ) нагрузки для оптимальной загрузки стека SIP сервера-получателя. На рис. 1 изображены две функции контроля, однако не обязательно присутствие обоих, так как необходимые изменения могут высчитываться и на сервере Б и передаваться напрямую исполнителю сервера А;

• -    исполнитель – функция, реализующая алгоритм действий, описанных в необходимых изменениях (НИ), путем передачи инструкций стеку SIP сервера А.

Измерение текущей загрузки сервера

Формула для расчета текущего числа обслуживаемых вызовов имеет вид

^общ (О ⁼ ^INVITE М + ”     Г" ’    (1)

^ВЫЗ где -^INVITE – число принятых сообщений INVITE (число новых сессий); N^oine – число других сообщений от уже установленных сессий; ^ВЫЗ – средняя длина вызова, определяемая средним количеством сообщений за один вызов.

Таким образом, параметр ^invite равен текущему числу пришедших на сервер сообщений о           ^NOINVV)

INVITE, а отношение          – число вызо-

L виз — вов, уже обслуживаемых сервером.

Трафик протокола SIP обладает определенными статистическими свой-ствами. В частности, агрегированный трафик от множества источников обладает свойством самоподобия. Эта его особенность делает возможным потенциальное прогнозирование интенсивности трафика на коротких промежутках времени [4]. Результаты прогноза могут использоваться для более точного определения нагрузки и корректировки выходных данных функции монитора. Обозначим прогнозированное число сообщений INVITE:

^пр V + ^0 — f{^INVITE W)’ то есть прогноз определяется как функция от текущего количества получаемых сообщений INVITE. Таким образом, с учетом прогноза (1) принимает вид:

Note] Q-'-^=N _INV1TE (?) + ^v^ + д^^ (/ + Д/). (2)

Реализация функции контроля

Результаты измерений нагрузки в дальнейшем используются функцией контроля для определения наступления состояния перегрузки и необходимых изменений (НИ) нагрузки для оптимальной загрузки стека SIP сервера-получателя. Существует несколько видов реализации контроля:

• -    по абсолютному значению скорости: основная идея данного механизма – ограничение скорости запросов от вышестоящего сервера. В случае перегрузки SIP-сервер сигнализирует об этом своего вышестоящего соседа, разрешая ему передавать максимум Х запросов в С;

• -    по относительному значению скорости: данный механизм подразумевает, что серверы-отправители ограничат интенсивность трафика на X процентов по просьбе сервера-получателя;

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

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

Реализация ограничений исполнителем

Когда серверу-отправителю станет известно, на какую величину следует изменить интенсивность нагрузки сервера-получателя, он может ограничивать свою интенсивность одним из следующих способов [7]:

• -    процентное регулирование: сервер-отправитель ограничивает свою интенсивность на Х процентов;

• -    Leaky bucket и Token bucket: два классических способа ограничения скорости, используемых в оборудовании передачи данных;

• -    автоматическое разряжение вызовов: данная технология очень часто используется в сетях телекоммуникации и является более консервативным механизмом ограничения скорости, чем техники Leaky (Token) bucket. По принятии первого вызова запускается таймер разряжения, до истечения которого все остальные поступившие вызовы сбрасываются. После истечения этого таймера принимается следующий вызов, сразу после его приема таймер перезапускается. Данный механизм не допускает всплесков нагрузки на выходе и генерирует нагрузку строго определенной интенсивности;

• -    оконное регулирование: в данном случае сервер-отправитель следит за размером окна, определенным сервером-получателем. Вызов будет отправлен только в случае, если окно еще не полностью заполнилось.

Вызов, отброшенный данными способами, может быть либо поставлен в очередь, либо сброшен моментально, либо переадресован.

Оценка эффективности методов УП

Сравним эффективность работы трех различных методов УП:

• -    метод 503 – существующий метод УП;

• -    win – метод УП, реализующий оконный алгоритм без учета прогнозируемой нагрузки (1);

• -    win+ – метод УП, реализующий оконный алгоритм с учетом прогноза нагрузки (2).

Для сравнения этих трех методов было проведено компьютерное моделирование. С помощью программной среды OPNET была построена модель сети SIP в соответствии с топологией, приведенной на рис. 2.

Рис. 2. Тестовая топология сети SIP

На рис. 2 П1-П5 – это пользователи сети SIP; СО1-СО3 – серверы-отправители; СП – сервер-получатель. Каждый из серверов может обслу- жить до 500 сообщений в С и может сбрасывать запросы со скоростью 3000 сообщений в С. В переводе на скорость обслуживания вызовов производительность сервера-получателя составляет 72 вызова в С. Основной измеряемый параметр – это полезная пропускная способность сервера, определяемая обслуживаемой нагрузкой. На протяжении всего эксперимента нагрузка на СП возрастала с 0 до 10 условных единиц (1 у.е. = 72 вызова в С).

Рис. 3. Результаты тестирования

На рис. 3 ось абсцисс соответствует поступающей на сервер нагрузке, нормированной таким образом, что единица шкалы равна нагрузке, создаваемой трафиком с интенсивностью 72 вызова в С. Ось ординат отражает полезную пропускную способность сервера, при том, что 1 – это максимальная загрузка сервера.

Из приведенного рисунка видно, что при использовании метода 503 полезная пропускная способность сервера при увеличении входящей нагрузки сначала растет, а потом при достижении максимального значения загрузки сервера резко падает. Это резкое падение и является коллапсом сервера, когда все его ресурсы уходят на отбой вновь поступающих вызовов. При этом у сервера нет возможности обслужить даже существующие вызовы. Его полезная пропускная способность почти равна нулю.

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

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

В результате эксперимента было выявлено, что при использовании метода win количество ретранслированных сообщений находится в основном пределах от 1 до 4 (см. рис. 4). В свою очередь, 4 ретранслированных сообщения означают, что задержка установления соединения 4

увеличится на ^2"⁴ -А/= 7,5 С ( n – число ретранслированных сообщений, А/ = 500 С – таймер, определенный в [1]), что при среднем времени установления соединения 7,5 С [8-9] приводит к суммарным 15 С установления соединения. К тому же в реальной сети в период максимальной загрузки этот порог может достигаться много раз на протяжении нескольких часов, что в итоге приведет к значительному ухудшению качества предоставляемых сетью услуг вследствие увеличения задержки установления соединения.

Рис. 4. Вероятность появления одного и более ретранслированных сообщений

На рис. 4 ось абсцисс соответствует количеству ретранслированных сообщений, ось ординат – соответствующей вероятности. Для наглядности вероятность отсутствия ретранслированных сообщений (в обоих случаях порядка 0,9) на рис. 4 не показана.

Метод win+ позволяет минимизировать количество ретранслированных сообщений таким образом, что большая их часть лежит в пределах от 1 до 2, что подразумевает максимальную дополнительную задержку до 1,5 С. Таким образом, использование метода win+ дает выигрыш 80% в уменьшении задержки установления соединений по сравнению с методом win.