Диссертация (1154395), страница 23
Текст из файла (страница 23)
одним из условий эффективностигистерезисного управления является выполнение соотношения- 125 -P X0 P X1 P X2 .С другой стороны, вероятность сброса всего трафика определяетсяформулой P r 2минимизирована.Еслииясно,известнычтоэтавероятностьограничениянадолжнапараметрыбытькачествафункционирования системы, например,P Xi Pi* , * ,то из этой системы неравенств могут быть найдены конкретные значенияпорогов перегрузки Li и H i и сброса нагрузки Ri , i 1, 2 .Итак,вразделе 4.1предложеныобщиепринципыгистерезисногоуправления и введены все необходимые определения, которые использованыниже в разделе 4.2, посвященном исследованию методов контроля перегрузоксерверов проокола установления сессий.4.2.Исследование механизма контроля перегрузок сервера протоколаустановления сессийПротокол SIP является основным протоколом установления сесии вмультисервисных сетях.
Протокол разработан группой MMUSIC (MultipartyMultimedia Session Control) комитета IETF, а спецификации протоколапредставлены в документе RFC 326133. Фрагмент сети протокола установлениясессий на рис. 4.6 состоит из агентов пользователя (User Agents, UA) и двухпрокси-серверов, функционирующих по протоколу SIP. Перед установлениемсессии между вызывающей стороной и вызываемой стороной агентыпользователейUAc(UAclient)иUAs(UAserver)должныбытьзарегистрированы на своих прокси-серверах с помощью запросов Register. Какпоказано на рис. 4.6, установление соединения по протоколу SIP состоит изследующих шагов: UAc инициирует соединение отправкой запроса INVITE прокси-серверу 1; запрос INVITE передается через прокси-сервер 2 агенту пользователя UAs; прокси-сервер 2 и прокси-сервер 1 отвечают UAc сообщением 100 Trying, чтозапрос INVITE принят к обработке;33IETF RFC 3261 (2002/06).
Hilt V., Rosenberg J., Schulzrinne H. et al. SIP: Session InitiationProtocol. – IETF, June 2002.- 126 - UAs уведомляет прокси-серверы и UAc сообщением 180 Ringing оготовности к установлению соединения; после ответа вызываемого абонента UAs сообщением 200 OK уведомляетпрокси-серверы и UAc о том, что запрос на установление соединенияуспешно выполнен; UAc сообщением ACK подтверждает прием ответа 200 ОК на запрос INVITEи между UAc и UAs устанавливается сессия для обмена медиа потоками; после окончания сессии UAc посылает UAs через прокси-серверы запросBYE на завершение сеанса связи; UAs прекращает передачу медиа потока и подтверждает свои действияотправкой UAc сообщения 200 OK.Прокси-сервер 1UAcINVITEПрокси-сервер 2100 TryingINVITE100 Trying180 Ringing180 Ringing200 O K200 O KACKACKUAsINVITE180 Ringing200 O KACKсессияBYE200 OKBYE200 OKBYE200 O KРис.
4.6. Диаграмма установления и завершения сессииС ростом числа пользователей услуг, предоставляемых на базе протоколаSIP, возникают различного рода перегрузки SIP-серверов из-за отсутствиядостаточных ресурсов для установления и завершения сессий между агентамипользователей. Различают два типа перегрузок – перегрузки типа «клиентсервер» и типа «сервер-сервер» [1]. Перегрузки «клиент-сервер» возникают всерверах-отправителях из-за избыточной нагрузки, создаваемой группами SIPтерминалов. Примером перегрузки «клиент-сервер» служит так называемый- 127 -лавинный перезапуск, который происходит, когда большое число UAcпытаются зарегистрироваться на серверах-отправителях. Еще одним примеромявляется сценарий «Манхэттенского перезапуска», когда в результате авариипроизошло отключение электричества в этом крупнейшем районе города, ипосле восстановления электроснабжения все SIP-терминалы одновременнопытались зарегистрироваться на серверах, создав тем самым поток сообщенийRegister высокой интенсивности.Отметим, что проблема перегрузки «клиент-сервер» может быть решенаоператором сети связи простым увеличением числа SIP-серверов, но кроме того,в 2009 году в протокол SIP были внесены изменения в части механизмапредотвращения лавинных подключений UAc к серверу, которые во многомрешили проблему.
Поэтому далее мы рассматриваем только перегрузки типа«сервер-сервер», которые могут возникать в ситуации, когда большое числовызовов начинает одновременно поступать на один номер (UAs). Примеромтакой ситуации является участие пользователей в телеголосовании или ихреакция на рекламный ролик, сообщающий о том, что первые дозвонившиесяпользователи получат ценный подарок.В протоколе SIP в части механизма контроля перегрузок до сих поримеютсясущественныенедоработки.Далееприведемописаниеэтогомеханизма, после чего в соответствии с RFC 539034 кратко сформулируемпроблемы, которые этот механизм не позволяет разрешить.Базовый механизм контроля перегрузок.
определенный в RFC 3261(далее - механизм 503),предусматриваетвслучаеотправкуперегрузкипрокси-получателяпрокси-отправителюсообщения503 Service Unavailable. В случае, когда сервер не может обработать запрос из-завременной перегрузки, ему следует отклонить этот запрос с кодом ошибки 503.Отправителю, получившему сообщение 503, следует действовать так, как вслучаеполучениясообщения500 Server Internal Error,инеследуетперенаправлять сообщение с кодом 503 далее вверх по цепочке SIP-серверов,уведомляя их о перегрузке на одном из ниже лежащих серверов, до тех пор,покапрокси-отправительнеопределит,чтопрокси-получательимеетвозможность отвечать на каждое его сообщение сообщением с кодом 503.34IETF RFC 5390 (2008/12).
Rosenberg J. Requirements for Management of Overload in the SessionInitiation Protocol. – IETF, December 2008.- 128 -Прокси-отправительдолженповторитьисходноесообщениепрокси-получателю или направить его на другой сервер. Перегруженный проксиполучатель также может добавить заголовок Retry-After в сообщение с кодом503, указав время в секундах, в течение которого он не будет реагировать налюбые сообщения от отправителя. Отправитель на этот период временипрекращает направлять сообщения получателю, вместо этого сообщениянаправляются на альтернативные сервера. Отправка сообщений на сервер,сообщивший о перегрузке, возобновляется по истечении интервала времени,указанного в заголовке Retry-After сообщения 503. Отметим, что RFC 3261предусматривает в случае перегрузки возможность получателю сбрасыватьпоступающие сообщения без уведомления отправителя.Перчислим также проблемы, возникающие в результате применениямеханизма 503 контроля перегрузок SIP-серверов согласно c RFC 5390.Заметим, что в документах IETF эти проблемы до сих пор не решеныполностью. Проблема усугубления перегрузки (load amplification); Проблема неполного использования кластера SIP-серверов (underutilization); Проблема использования сообщения 503 с заголовком Retry-After (RetryAfter problem); Проблема неоднозначного использования сообщения 503 (ambiguous usages);Эти и некоторые другие проблемы достаточно подробно исследованы вобзоре [1] с участием автора.
Перечислим теперь согласно с RFC 5390 основныетребования к механизмам, отвечающие сформулированным выше проблемам. Механизмы контроля перегрузок должны поддерживать производительностьсерверов на приемлемом уровне с учетом требований к заданномупоказателюкачестваобслуживания.Минимальноезначениепроизводительности сервера является критическим значением для оценкиэффективности механизма контроля перегрузок. Существенно, что в случаеретрансляции сообщений по причине перегрузки получателя серверотправитель должен направлять сообщения только на серверы, работающие внормальном режиме. В случае сбоя, приводящего к перегрузке сервера, механизм долженсглаживать негативное влияние на работу смежных серверов. Это поможет- 129 -избежать полного или частичного простоя участка сети и восстановитьнормальную работу. Сообщения, уведомляющие о перегрузке сервера, должны позволять четкоопределить причину отправки сообщения, например, перегрузка сервера,перегрузка смежного сервера или сбой, произошедший не по причинеперегрузки. Механизм должен обеспечивать возможность ограничения поступающей насервер нагрузки, сброс нагрузки должен производиться не сразу, а внесколько приемов. Механизм должен обеспечивать возможность взаимодействия серверов,находящихся в различных доменах. Механизм не должен определять приоритеты на обработку сообщенийсоседних серверов, а должен назначать их в соответствии с локальнойполитикой в зависимости от типов поступающих сообщений, например,экстренные вызовы. Механизм должен однозначно идентифицировать ситуации, в которыхотправителибудутпроводитьретрансляциюсообщений,количествоуправляющих сообщений должно быть минимально. Механизм должен обеспечивать возможность однозначно определятьотправителя сообщения о перегрузке. Механизм должен обеспечивать возможность работы сети SIP-серверов ссервером балансировки нагрузки.Различают35 три типа управления, схематично изображенные на рис.
4.7.Локальное управление (local). Механизм локального контроля перегрузокпредполагает,чтосервернаосновемониторингатекущегоуровняиспользования своих ресурсов принимает решение о сбросе части нагрузки.Идея этого механизма заключается в том, что серверу требуется меньшересурсов на сброс сообщения, чем на его обработку. Однако сброс сообщенийприведет к их ретрансляции, и, следовательно, сервер, продолжая сбрасыватьсообщения, будет затрачивать ресурсы на обработку повторных сообщений и нерешит проблему перегрузки. Поэтому локальное управление не можетсамостоятельно справиться с возрастающей нагрузкой, а, следовательно, не35IETF RFC 6357 (2011/08).
Hilt V., Noel E., Shen C., Abdelal A. Design Considerations for SessionInitiation Protocol (SIP) Overload Control. – IETF, August 2011.- 130 -может использоваться в качестве единственного механизма управления.Рекомендуется применять для контроля поступающей нагрузки другиемеханизмыуправления,амеханизмлокальногоуправлениядолжениспользоваться как мера последней необходимости.Домен 2Домен 1UAsUAс......Сервер 3Сервер 2Сервер 4Сервер 1кСервер3,СервДомен 3ер4локальноемежузловоесквозноеСервер 5Рис. 4.7.
Межузловое, сквозное и локальное управление перегрузкамиМежузловое управление (hop-by-hop). Идея состоит в создании отдельногоконтура управления для каждой пары смежных серверов, причем контурыуправления каждой пары независимы друг от друга. На рис. 4.7 показаны дваконтура Сервер 1 – Сервер 5 (С1–С5), С4–С5, причем каждый контур управляетодним транзитным участком (hop). Управляющие сообщения, полученные отсервера-получателя, не передаются вверх по всей цепочке серверов. Вместоэтого сервер выполняет управляющее действие на основе полученногосообщения, например, полностью или частично сбрасывает нагрузку.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
