Диссертация (1154395), страница 24

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 24)

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

К преимуществаммеханизма можно отнести отсутствие необходимости передавать управляющие- 131 -сообщения между узлами, находящимися на расстоянии более одногопереприема, и собирать статистику о статусах перегрузок серверов, с которымиузел не связан напрямую.Сквозное управление (end-to-end) предусматривает наличие управляющегоконтура, объединяющего все узлы сети по маршруту следования сообщений отUAc в направлении UAs. Механизм должен собирать информацию по маршрутуо состоянии всех узлов, включая серверы и UA-клиенты, и ограничитьпоступающую по маршруту нагрузку как можно ближе к источнику. Сборинформации должен проводиться регулярно, по всем потенциально возможныммаршрутам следования сообщений и результат должен отправляться источникув управляющих сообщениях. UAс или серверу следует уменьшать числозапросовтольковнаправленииконкретногоперегруженногосервера.Предположим, что сквозное управление реализовано, как показано на рис.

4.7,по контурам С2-С5-С3 и С2-С5-С4. Пусть только С3 находится в состоянииперегрузки, тогда С2 должен сократить число запросов только в направленииС3. Во многих случаях задача определения узла, которому будет доставлено витоге сообщение, представляется сложной и трудно предсказуемой, т.к. зависитот применяемых политик маршрутизации вызовов, балансировки нагрузки,запрашиваемых услуг и пр. Так, если предыдущее сообщение, относящееся кпроцедуре установления сессии, было направлено на перегруженный сервер, тоне обязательно следующее сообщение будет направлено на этот же сервер.Существеннаяпроблемасквозногомеханизмаконтроляперегрузокзаключается в необходимости мониторинга всех потенциально возможныхмаршрутов и определения, какие сообщения-запросы следует ограничить, акакие могут быть отправлены.

Даже в случае наличия этой информации крайнесложно четко определить, по какому маршруту будет следовать запрос.Заметим, что в зависимости от метода, на основании которого серверотправитель определяет состояние сервера-получателя и управляет нагрузкой,механизмы контроля перегрузок делятся на явные (explicit) и неявные (implicit).Основные идеи пяти явных механизмов управления, которые работают наоснове уведомления, сформулированы на основании RFC 6357 и приведеныниже.- 132 - Механизм снижения скорости передачи (rate-based overload control)36предоставляет серверу-получателю возможность регулировать ограниченияна скорости передачи соседних серверов-отправителей, исходя из текущегозначения своей производительности.

В управляющем сообщении вышележащему серверу указывается верхнее значение допустимой скоростипередачи. Механизм просеивания потока сообщений (loss-based overload control)37предусматриваетдлясервера-получателявозможностьзапроситьотправителей снизить нагрузку, при этом в управляющем сообщении вышележащему серверу указывается значение доли нагрузки (в процентах отисходной), которую необходимо перенаправить, вычисленное получателем сучетом его текущей загрузки. Механизм управления размером окна (window-based overload control)определяется счетчиком числа отправленных сообщений, на которые еще неполучены положительные подтверждения.

При отправке сообщения значениесчетчика увеличивается, при получении подтверждения - уменьшается.Сервер приостанавливает отправку сообщений, если значение счетчикастанет равным размеру окна перегрузки (overload window). Механизм снижения нагрузки по сигналу (signal-based overload control)заключается в использовании сообщения 503 Service Unavailable в качествеответа, который сигнализирует обнаружение перегрузки сервера-получателя.Получив это сообщение, сервер-отправитель снижает нагрузку на серверполучатель, чтобы избежать дальнейшего получения сообщений с кодом 503.Сервер-отправитель сохраняет передачу с текущим сниженным значениеминтенсивности нагрузки до тех пор, пока он продолжает получать сообщенияс кодом 503.

После того, как такие сообщения перестанут поступать, северотправитель может постепенно увеличивать нагрузку на сервер-получатель. Механизмвременногозапретапередачи(on/offoverloadcontrol)осуществляет запрет по команде от сервера-получателя. В качествеуправляющегосообщенияпредлагаетсяиспользоватьсообщение503 Service Unavailable с заголовком Retry-After. Поскольку рассмотренные36IETF RFC 7415 (2015/02). Noel E., Williams P. Session Initiation Protocol (SIP) Rate Control. –IETF, February 2015.37IETF RFC 7339 (2014/09). Gurbani V. Ed., Hilt V., Schulzrinne H.

Session Initiation Protocol (SIP)Overload Control. – IETF, September 2014.- 133 -выше механизмы позволяют как полностью запрещать передачу, так иосуществлять ее без ограничений, то, в сущности, механизм временногозапрета передачи является их частным случаем.В отличие от явных механизмов неявные механизмы управленияперегрузкойгарантируют,чтопроцесспередачисообщенийявляетсясамоограничивающимся (self-limiting) и снижает скорость передачи сообщенийна сервере-отправителе, когда появляются признаки перегрузки сервераполучателя.

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

отправительне сможет продолжить отправку сообщений в случае размера окна, равногонулю, до тех пор, пока не получит соответствующего уведомления. Остальныемеханизмы не обладают таким свойством и должны применяться совместно снеявным механизмом для того, чтобы ограничить передачу сообщений в случае,когда получатель не имеет достаточных ресурсов для отправки уведомления,сигнализирующего о перегрузке.В следующем разделе диссертации на основании исследования механизмовуправления перегрузкой и принципов гистерезисного управления нагрузкойпостроена базовая модель СМО с гистерезисным управлением перегрузкамиSIP-сервера.4.3.Базовая модель гистерезисного управления нагрузкойТакимобразом,вразделе 4.1иcследованыособенностимоделигистерезисного управления в сетях сигнализации, а в разделе 4.2 проведендетальный анализ особенностей контроля перегрузками в сети серверовпротокола установления сеcсий.

Эти исследования позволили построить модель,получившую название базовой модели управления нагрузкой в сети северовпротокола SIP, и основанную на принципах гистерезисного направления- 134 -нагрузкой. В данном разделе модель построена в простейших предположениях охарактере обслуживаемой нагрузки.Уточним введенные выше формулировки и упростим, не снижая при этомуровень общности изложения, разработанный метод управления сигнальнойнагрузкой в мультисервисных сетях, схематично изображенный на рис. 4.5.Базовая модель при гистерезисном управлении нагрузкой предполагаетиспользование порогов трех типов – порог H обнаружения перегрузки, порог Lснижения перегрузки и порог B сброса нагрузки. При достижении очередьюпорога обнаружения перегрузки производится снижениевходящего потока, при этом при продолженииинтенсивностиперегрузки и достиженииочередью порога сброса нагрузки производится сброс поступающих сообщений.Во избежание осцилляции при падении длины очереди возврат к нормальномуфункционированию происходит не сразу после снижения очереди нижезначения порога обнаружения перегрузки, а лишь после пересечения очередьюпорога снижения перегрузки.

На рис. 4.8 показана качественная зависимостьинтенсивности   s, n  входящего потока сигнальных сообщений от длины nочереди при гистерезисном управлении. Здесь sстатус перегрузки: s=0 - нормальная нагрузка, s =1 – перегрузка, s =2 – сброс нагрузки.Интенсивностьвх. потока  s, n Рост перегрузкиs0s0s 1s 1Снижение перегрузки0Длинаочередиs2L 1LПорог сниженияперегрузкиH 1HH 1Порог обнаруженияперегрузкиB 1BnПорог сбросанагрузкиРис. 4.8.

Принцип гистерезисного управления нагрузкой в базовой модели- 135 -В режиме нормальной нагрузки при интенсивности входящего потока при росте очереди перегрузка обнаруживается, когда длина очереди достигаетзначения очереди n = H . Это служит сигналом для перехода системы в режимперегрузки, в котором интенсивность входящей нагрузки снижена до величины    . Если очередь продолжает расти, и ее длина достигает значения n = B ,система переходит в режим сброса нагрузки, интенсивность входящей нагрузкив котором равна нулю:   s, n  =0 для n  B .

В режиме сброса нагрузки, вкотором длина очереди падает за счет обсуживания заявок, система остается домомента, когда убывающая очередь пересечет порог H , после чего системавозвращается в режим перегрузки, а величина интенсивности входящейнагрузки восстановится до значения   . При дальнейшем падении длиныочереди система перейдет в режим нормальной нагрузки с исходнойинтенсивностью интенсивности входящего потока после уменьшенияочереди до значения n = L .

Характеристики

Список файлов диссертации