СПОСОБ ВЫБОРА СЕРВЕРА ИЗ НАБОРА СЕРВЕРОВ Российский патент 2009 года по МПК H04L29/06 

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

В публикации R.Stewart et al.: "Aggregate Server Access Protocol", Internet Draft, [Online] 9 June 2004 (2004-06-09), pages 1-43, XP002308317 IETF, доступной из Интернет: URL: http://www.watersprings.org/pub/id/draft-ietf-rserpool-asap-09.txt> [получена 2004-11-30], описано, что Протокол агрегатного доступа к серверам (ASAP) во взаимосвязи с Протоколом разрешения имени конечного пункта (ENRP) обеспечивает механизм передачи данных высокой доступности в IP-сети. Протокол ASAP использует модель адресации на основе имени, которая выделяет логический конечный пункт передач из его логического(их) адреса(ов), тем самым эффективно исключая связывание между конечным пунктом передачи и его физическим(и) IP-адресом(ами), что обычно образует один пункт сбоя.

В публикации Hofmann R. et al.,: "Distributed Performance Monitoring: Methods, Tools, and Applications", IEEE Transactions on Parallel and Distributed Systems, IEEE Inc., New York, US, vol. 5, no.6, 1 June 1994 (1994-06-01), pages 585-598, XP000450482, ISSN: 1045-9219 описывается способ анализа функционального поведения и характеристик программ в распределенных системах. В документе описываются гибридный мониторинг и метод, который объединяет преимущества мониторинга на основе программного обеспечения и мониторинга аппаратными средствами. Статья содержит описание аппаратного блока мониторинга и пакета программ, чтобы сделать эти принципы доступными для программистов и помочь им в отладке и настройке их кодов. Краткий обзор связанных с этим систем мониторинга выявляет характерные признаки реализации. В качестве применения системы мониторинга и оценивания описан анализ программы параллельной трассировки лучей, исполняемой на мультипроцессоре Suprenum.

Документ D3 (US 2003/0101258 A1) описывает способ мониторинга серверов-реплик в сетевой компьютерной системе, в которой каждый сервер в системе имеет таблицу векторов партнеров-реплик, включающую в себя информацию состояний для других серверов в системе. Таблица векторов серверов-реплик включает в себя поля данных для хранения номера последовательности обновления (USN) и информацию временной метки, которая идентифицирует время последнего обновления и/или время последней успешной попытки реплицирования для каждого сервера-реплики в системе. После успешного реплицирования сервер обновляет записи в векторе партнеров-реплик для отображения обновленного USN и информации временной метки. Способ мониторинга оценивает записи USN и временной метки в таблице векторов партнеров-реплик для определения того, являются ли какие-либо серверы в системе латентными. Если способ мониторинга обнаруживает, что сервер в системе является латентным, то генерируется предупредительная сигнализация, посредством чего пользователи и/или сетевой администратор информируются о проблеме.

Управление сеансом приобретает все большую важность по мере быстрого роста числа и популярности Интернет-услуг, основанных на уведомлении о сеансе. Основанные на сеансе услуги включают в себя мультимедийные конференции, вызовы Интернет-телефонии и подобные приложения, состоящие из одного или более типов мультимедийных данных, таких как аудио, видео и т.д. Примеры использования включают в себя услуги управления сеансом как часть IP мультимедийной подсистемы (IMS) в мобильных сетях 3-го поколения. В подсистеме IMS серверы функции управления сеансом вызова (CSCF) выполняют управление сеансом на основе Протокола инициирования сеанса (SIP). Протоколы управления сеансом, такие как SIP, являются транзакционными протоколами. В принципе транзакция состоит в одном запросе и ответе на этот запрос.

Устойчивость к отказам, например, в системах управления сеансом обеспечивается за счет введения избыточности. А именно серверы управления сеансами объединяются в наборы серверов. Набор серверов состоит из N серверов, обеспечивающих одну и ту же функциональность. Такая устойчивая к отказам реплицированная система управления сеансами показана на фиг. 1.

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

Пунктирные линии 2 обозначают на фиг. 1 распространение обновления состояния от центрального сервера к двум серверам в левом и правом положениях. Пересекающиеся сплошные линии 3 иллюстрируют состояние отказа центрального сервера. Кроме того, клиенты будут определять, что центральный сервер не отвечает на запросы, и будут повторять свои запросы путем направления их на левый и правый серверы. Это показано сплошными линиями 4, иллюстрирующими отказоустойчивые резервированные передачи на другие работоспособные серверы.

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

Существующие статические стратегии выбора серверов используют предварительно определенные схемы для выбора серверов. Примерами статических SSP являются следующие:

- Алгоритм кольцевого списка представляет собой циклическую стратегию, при которой серверы выбираются в последовательном порядке до тех пор, пока первоначально выбранный сервер не будет выбран снова.

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

Неосведомленность о состояниях динамической системы приводит к низкой сложности, однако ценой снижения эффективности и доступности услуг. Адаптивные (динамические) стратегии SSP принимают решения на основе изменений в состоянии системы и динамической оценки наилучшего сервера. Примерами динамических стратегий SSP являются следующие:

- Интеллектуальный алгоритм кольцевого списка (SRR).

В этой стратегии SSP новый запрос посылается на сервер путем применения кольцевого списка для текущего поднабора серверов, которые были известны как активные последними. Если ни для одного сервера не получено уведомление, что он активен, то кольцевой список применяется ко всему набору серверов. Этот алгоритм использует двоичную информацию о состоянии активности сервера, то есть работает ли сервер или он неисправен.

- Интеллектуальный алгоритм кольцевого списка на сеанс (SRR-S).

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

- Последняя использованная SSP (см. R.R. Stewart, Q. Xie: "Aggregate Server Access Protocol (ASAP), <draft-ietf-rserpool-asap-08.txt>, October 21, 2003, от рабочей группы IETF (Internet Engineering Task Force) "Relative Server Pooling"). В этой стратегии SSP нагрузка каждого сервера контролируется центральным контролирующим объектом или самим клиентом. На основе контроля нагрузок серверов каждому серверу присваивается так называемое значение стратегии, которое пропорционально нагрузке сервера. Согласно стратегии последней использованной SSP сервер с самым низким значением стратегии будет выбран в качестве приемника текущего сообщения. Важно отметить, что эта стратегия SSP означает, что тот же самый сервер выбирается всегда до тех пор, пока значения стратегии серверов не будут обновлены и изменены.

- Последняя использованная SSP с ухудшением [Stewart & Xie] представляет тот же самый алгоритм, что и алгоритм последней использованной SSP, с одним исключением. В частности, каждый раз, когда из набора серверов выбирается сервер с самым низким значением стратегии, его значение стратегии получает приращение. Таким образом, этот сервер может уже не иметь самого низкого значения стратегии в наборе серверов. Это сдвигает алгоритм последней использованной с ухудшением SSP с течением времени к SSP кольцевого списка. Каждое обновление значений стратегии серверов сдвигает SSP к последней использованной SSP с ухудшением.

Эффективность динамической SSP зависит от метрики, которая используется для оценки наилучшего сервера. Исследования SSP главным образом фокусировались на системах реплицированных Web-серверов. В таких системах типовые метрики основаны на близости серверов, включая географическое расстояние, число участков ретрансляции до каждого сервера, время двустороннего распространения (RTT) и времена отклика НТТР (см. Robert L. Carter, Mark E. Crovella, "Dynamic Server Selection using Bandwidth Probing in Wide Area Networks", Proceedings of Infocom'97, the Sixteenth Annual Joint Conference of the Computer and Communication Societies, April 1997; Mark E. Crovella, Robert L. Carter, "Dynamic server selection in the Internet", Proceedings of the third IEEE Workshop on the Architecture and Implementation of High Performance Communication Subsystems (HPCS'95), August 1995; M. Sayal, Y. Breitbart, P. Scheuermann, R. Vingralek, "Selection Algorithms for Replicated Web Servers", Workshop on Internet Server Performance, Madison, Wisconsin, 1998; K. Obraczka, F. Silvia, "Network Latency Metrics for Server Proximity", Proceedings of the IEEE Globecom, November 2000.

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

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

Эта задача решается способом согласно пункту 1 формулы изобретения и клиентским устройством согласно пункту 12 формулы изобретения.

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

Изобретение основано на максимизации мгновенной вероятности успешной транзакции с n-й повторной передачей запроса, при условии, что (n-1) попыток были безуспешными. Следовательно, изобретение может определяться как SSP максимальной доступности (МА).

Согласно заявленному алгоритму МА клиент или каждый клиент поддерживает вектор состояний, обозначенный как р. Размер вектора состояний равен N (т.е. равен числу серверов в наборе):

p=[p₁, p₂,..., p_n]

Определенный элемент в векторе состояний представляет момент последнего известного состояния для конкретного сервера. Если последнее состояние сервера соответствовало включенному (активному), то соответствующее значение временной отметки сохраняется в векторе состояний. Если последнее состояние сервера соответствовало выключенному (неактивному), то соответствующее значение временной отметки сохраняется в векторе состояний с отрицательным знаком. Базовый алгоритм выбирает сервер, который имеет максимальное значение временной отметки в векторе состояний. В соответствии с модифицированным вариантом выполнения изобретения выбирается сервер, имеющий значение временной отметки в пределах некоторого диапазона от максимального значения временной отметки.

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

1) Если переданная транзакция, посланная на конкретный сервер, успешно завершена или была безуспешной.

2) Если периодическое контрольное сообщение, посланное на сервер, успешно завешено или было безуспешным.

Механизм периодически посылаемого контрольного сообщения обеспечивает периодический или любым иным образом регулярно повторяемый опрос, чтобы проактивным образом (с упреждением) контролировать состояние заданного сервера. Опрос может основываться, например, на механизме эхо-запроса и эхо-ответа по протоколу управляющих сообщений в сети Интернет (ICMP), хорошо известный как эхо-тестирование или тестирование по методу «запрос-ответ», или на сообщениях, предназначенных для этой цели, например, Heartbeat-Message и Heartbeat-Ack-Message согласно публикации R.Stewart, et al.,: Stream Control Transmission Protocol, RFC 2960, October 2000, IETF Working Group "Signaling Transport", или на сообщениях Keep-Alive-message или Keep-Alive-Ack-message согласно протоколу ASAP [Stewart & Xie].

Транзакция (или периодическое контрольное сообщение) является безуспешной, если клиент не принял ответа на запрос (или на запрос в периодическом контрольном сообщении) в течение интервала времени, определяемого таймаутом. Всякий раз, когда получают новый момент состояния или момент времени t_i, связанный с сервером S_i (когда транзакция или периодическое контрольное сообщение, посланные на конкретный сервер, успешно завершены или оказались безуспешными), элемент, связанный с сервером S_i в векторе р_i, обновляется следующим образом:

3) Путем контактирования с третьей стороной, например, специальным сервером или другим клиентом, который поддерживает и обновляет собственный вектор состояний для данного набора серверов. В процессе информационного обмена с третьей стороной, например, с использованием специализированного протокола клиент получает вектор текущих или обновленных состояний третьей стороны. С использованием данных состояний, полученных от третьей стороны, клиент обновляет свой локальный вектор состояний. Клиент не обновляет запись в своем локальном векторе состояний, если такая запись является более новой (более обновленной), чем соответствующая запись в данных состояний, полученных от третьей стороны. Тактовые сигналы у клиента и третьей стороны, используемые для измерения временных отметок, должны быть синхронизированы, например, путем использования прокола сетевого времени (NTP) для обозначения одного и того же момента времени одной и той же временной отметкой (синхронизация может быть также реализована путем коррекции временной отметки, полученной от третьей стороны, например, в предположении постоянного временного сдвига или дрейфа по отношению к третьей стороне, что требует использования соответствующего алгоритма).

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

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

В рамках другого разработанного варианта осуществления изобретения можно дополнительно сократить время управления транзакцией. Это МА-расширение основано на минимизации времени отклика приложения для выбранного в текущий момент сервера. Время отклика приложения представляет собой временную длительность между моментом посылки запроса к конкретному серверу и моментом приема окончательного ответа на клиенте. С этой целью клиент поддерживает дополнительные данные состояния, так называемый вектор задержек, обозначенный как d. Размер вектора задержек также равен N:

d=[d₁, d₂,..., d_N]

Некоторый элемент в векторе задержек представляет время отклика приложения, которое транзакция испытывает в данном сервере. Если транзакция безуспешна, то время отклика приложения для данного сервера рассматривается как бесконечное.

Заметим, что два вектора р и d эквивалентны и могут быть представлены одним вектором s состояний, элементы которого состоят из данных временных отметок и задержек:

s=[(p₁, d₁), (p₂, d₂),..., (p_n, d_N)]

Поскольку МА-расширение вводит дополнительные данные состояния, помимо временной отметки доступности может применяться другой критерий решения о выборе сервера на основе двух векторов.

Может быть выведено несколько возможных критериев. Два предпочтительных варианта осуществления изобретения, использующих конкретные критерии, представлены ниже:

1) Критерий с предварительно определенным порогом для элементов вектора задержек

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

- Идентифицировать поднабор серверов, для которых элементы вектора задержек ниже порогового значения задержки;

- Если такой поднабор существует, то применять базовый МА-алгоритм по данному поднабору, то есть выбирать сервер с наибольшим элементом вектора состояний,

- Если такой поднабор не существует, то применять базовый МА-алгоритм по полному набору серверов.

2) Критерий с предварительно определенным диапазоном временных отметок

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

- Идентифицировать поднабор серверов, для которых элементы вектора состояний положительны и попадают в набор, определенный диапазоном временных отметок;

- Если такой поднабор существует, то выбирать сервер с наименьшим элементом вектора задержек,

- Если такой поднабор не существует, то применять базовый МА-алгоритм по полному набору серверов.

Преимущества изобретения заключаются в следующем:

- Значительное повышение эффективности в противоположность классическим стратегиям SSP таким, как алгоритм кольцевого списка.

- МА представляет эффективную стратегию выбора сервера.

- МА характеризуется невысокой сложностью реализации. Клиенту необходимо только поддерживать вектор состояний с количеством элементов, равным числу серверов в наборе серверов.

- МА SSP не требует высокой вычислительной мощности.

- Алгоритм МА может быть реализован как динамический и как адаптивный алгоритм, который имеет возможность естественным образом и с высоким быстродействием обнаруживать самый быстродействующий сервер в наборе, даже если нагрузки трафика относительно велики.

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

Фиг. 1 - схематичная иллюстрация отказоустойчивой реплицированной системы управления сеансом (описана выше);

Фиг. 2 - схематичное представление примера процесса выбора сервера согласно варианту осуществления изобретения;

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

На фиг. 2 схематично представлен пример процесса выбора сервера согласно варианту осуществления изобретения. Клиент принимает решение относительно того, какой сервер должен быть выбран. В качестве примера набор серверов состоит из 4 серверов от S1 до S4. В момент принятия решения о выборе вектор состояний содержит элементы для каждого из серверов от S1 до S4, а именно значения временных отметок, обозначенных как t1, t2, t3 и t4, представляющих моменты, когда серверы от S1 до S4 были доступны в последний раз. В памяти клиента значения временных отметок от t1 до t4 сохранены как числа, представленные битовыми последовательностями. В примере, показанном на фиг. 2, сервер S2 предполагается имеющим максимальную (положительную) временную отметку, а сервер S4 - минимальную (отрицательную) временную отметку.

Сохраненный вектор состояний просматривается на клиенте. В соответствии с правилом выбора в варианте осуществления, реализованном на клиенте, максимальное значение временной отметки в векторе состояний определяется, и выбирается соответствующий сервер. Таким образом, сервер S2 выбирается для обслуживания текущей транзакции. Отметим, что для транзакции выполняется повторная попытка с другим сервером, выбранным согласно тому же правилу, если сервер S2 не сможет выполнить обработку транзакции. Затем следующая попытка может быть направлена на сервер S3, поскольку сервер S3 имеет второе по величине (положительное) значение временной отметки после сервера S2.

В качестве примера соответствующего изобретению способа выбора сервера с использованием вектора состояний с временной отметкой доступности во взаимосвязи со значением задержки на каждый элемент рассмотрим вновь четыре сервера от S1 до S4 в наборе серверов. В заданный момент времени пусть значения временной отметки, включающие в себя информацию доступности (знак '-' обозначает случай неактивного сервера), и значения задержки будут равны p=[-8,3 c, 11,2 c, 14,1 c 13,5 c] и d=[∞,08 с, 0,55 с, 0,15 с], соответственно, для серверов S1-S4 и пусть пороговое значение задержки установлено на 0,2 с.

В соответствии с критерием, охарактеризованным выше, сначала должны быть идентифицированы серверы, у которых элементы вектора задержек ниже порогового значения задержки. Это серверы S2 и S4. Далее, поскольку существует поднабор серверов со значениями задержки ниже порогового значения, то должен применяться базовый алгоритм МА, т.е. должен выбираться сервер с наибольшим элементом вектора состояний. Таким образом, поскольку сервер S4 имеет наибольший элемент вектора состояний из набора, удовлетворяющего условию задержки, то сервер S4 выбирается для обслуживания текущей транзакции.

В качестве примера соответствующего изобретению способа выбора сервера с использованием предварительно определенного значения диапазона временных отметок рассмотрим вновь четыре сервера от S1 до S4. Пусть значения временной отметки, включающие в себя информацию доступности и значения задержки для серверов от S1 до S4, будут равны p=[-8,3 c, 11,2 c, 14,1 c, 13,5 c] и d=[∞,08 с, 0,55 с, 0,15 с] и пусть диапазон временных отметок установлен на 3 с.

В соответствии с критерием, охарактеризованным выше, сначала должен быть идентифицирован поднабор серверов, у которых элементы вектора состояний положительны и попадают в интервал, определенный диапазоном временных отметок. Поднабор включает в себя серверы S2, S3 и S4. Далее, поскольку существует поднабор серверов (не требуется возврат к базовому алгоритму МА), то должен выбираться сервер с наименьшим элементом вектора задержек. Таким образом, поскольку сервер S2 имеет наименьший элемент вектора задержек, то сервер S2 выбирается для обслуживания текущей транзакции.

На фиг. 3 представлена упрощенная блок-схема, показывающая существенные функциональные блоки клиентского устройства 10, намеревающегося послать запрос на предоставление услуги от набора 12 серверов. Клиентское устройство 10 может представлять собой аппаратные средства или программно-аппаратные средства, но может предпочтительно быть реализовано как блок клиентского программного обеспечения на пользовательском устройстве (не показано), например, на мобильном устройстве. Набор 12 серверов предполагается обеспечивающим приложения на основе протокола SIP в контексте мультимедийной IP-платформы (IMS) сети UMTS, с которой связано мобильное устройство. Для обеспечения приложений или услуг отказоустойчивым способом набор 12 серверов содержит четыре сервера от S1 до S4, каждый из которых полностью адаптирован для обеспечения любой из услуг, которые могут быть запрошены мобильным устройством, на котором находится клиентское устройство 10.

Клиентское устройство 10 содержит модуль 13 управления, модуль 14 управления вектором состояний, модуль 16 выбора серверов, память 18 и клиентский модуль 20. Память предполагается частью или секцией более крупной памяти устройства, в котором находится клиентское устройство 10, но может быть и частью аппаратных средств памяти, выделенной для клиентского устройства 10.

Со ссылкой на фиг. 3 ниже описан процесс выбора сервера в соответствии с изобретением более детально, на основе вектора состояний с временной отметкой доступности во взаимосвязи со значением задержки на элемент (2-й пример, описанный выше).

Первоначально модуль 13 управления запускается некоторым блоком, внешним по отношению к клиентскому устройству 10, чтобы запросить услугу от набора 12 серверов, т.е. инициировать установку сеанса под управлением одного из CSCF-серверов S1-S4. Блок запуска может быть связан с мультимедийным приложением на мобильном устройстве.

Предполагается, что транспортные (IP) адреса и порты каждого из серверов S1-S4 известны в клиентском устройстве 10. Это может быть реализовано модулем 13 управления путем запроса списка разрешения имен в отношении имени из набора 12 серверов у сервера имен (не показан) или некоторым иным способом.

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

Вектор состояний содержит четыре элемента, по одному элементу для каждого из серверов от S1 до S4. Каждый элемент может содержать некоторую информацию, относящуюся к серверу (например, транспортный адрес, упомянутый выше), но, в частности, включает в себя информацию состояния, относящуюся к соответствующему серверу. Относительно информации состояния, вектор s состояний может быть представлен как вектор пар: s=[(-8,3, ∞ (11,2, 0,08), (14,1, 0,55), (13,5, 0,15)], где числа сохранены в памяти 18 в виде битовых последовательностей и представляют значения времени в секундах.

Любой знак «минус» в информации доступности, т.е. значение временной отметки как отрицательное числовое значение, может быть представлен в памяти в соответствии с процедурой, известной специалистам в данной области техники, включая, например, представление отрицательного значения временной отметки как дополняющего значения к 2 путем инвертирования всех битов и суммирования с 1.

Примерные значения взяты из 2-го примера, рассмотренного выше. Первое значение каждой пары (,) является значением временной отметки, а второе значение каждой пары является значением задержки.

Считав вектор состояний, модуль 16 выбора сервера выполняет первую операцию над всеми вторыми значениями пар информации состояния элементов вектора состояний, т.е. значений задержки. Каждое из значений задержки сравнивается с постоянной, а именно с пороговым значением задержки, которое в этом примере установлено один раз во время реализации клиентского устройства 10. Также возможно, что пороговое значение задержки изменяется, например, посредством модуля 13 управления, но не в течение описываемой процедуры выбора сервера.

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

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

Ввиду базового алгоритма МА первое значение каждой пары информации состояния в векторе поднабора анализируется, и выявляется пара информации состояния, которая имеет максимальное значение для этих первых значений. Иными словами, идентифицируется сервер, который имеет максимальное значение временной отметки, по результатам оценки, включая информацию доступности (знак '-'), если она имеется. В рассматриваемом примере первый элемент вектора поднабора имеет значение временной отметки 11,2 с, второй элемент имеет значение 13,5 с (в обоих элементах отсутствует явно выраженная информация доступности). Таким образом, указывается второй элемент вектора поднабора.

Поскольку этот элемент соответствует серверу S4, модуль выбора сервера идентифицирует транспортный адрес (и любую другую информацию, связанную с этим элементом) и возвращает транспортный адрес к модулю управления 13 в качестве ответа. Модуль управления использует возвращенную информацию для инициирования компоновки и посылки запроса на услугу на идентифицированный сервер (S4) через клиентский модуль 20. Запрос иллюстрируется сплошной линией на фиг. 3.

Предполагается, что сервер S4 отвечает на запрос, и транзакция, связанная с услугой, успешно завершается в момент времени, обозначенный как 15,3 с, как измерено в устройстве-хосте. Задержка в ответе на запрос составляла 0,37 с. Согласно варианту осуществления заявленного способа, как описано выше, вектор состояний, сохраненный в памяти 18, должен обновляться путем увязывания новой временной отметки и значений задержки с транспортным адресом сервера S4.

Для достижения этого модуль управления запускает модуль 14 управления вектором состояний после посылки запроса через клиентский модуль 20 на сервер S4. После запуска модуль 14 управления сначала определяет текущее время путем запроса модуля времени в устройстве-хосте (не показано), модуль времени возвращает последовательность, представляющую (в данном примере) значение 14,93 с. Затем модуль 14 запускает таймер, назначенный данному конкретному запросу. Таймер отсчитывает предварительно определенное время 10 с.

Модуль 13 управления посылает другой сигнал запуска на модуль 14 управления после приема окончательного ответа от сервера S4. Ввиду второго запуска модуль 14 управления сначала определяет текущее время путем запроса модуля времени, который возвращает последовательность, представляющую (в данном примере) значение 15,3 с. Затем модуль 14 управления останавливает таймер.

Далее модуль управления подготавливает новую пару информации состояния ((факультативно, информацию доступности), значение временной отметки, значение задержки). Когда второй сигнал запуска принят перед остановкой таймера, никакая информация доступности не связана с временной отметкой. Значение временной отметки принимается в виде второй последовательности времени от модуля времени. Значение задержки вычисляется путем вычитания первой последовательности времени из второй последовательности времени, в результате чего получается значение 0,37 с.

Если сервер S4 не ответил, то никакой второй сигнал запуска не поступит на модуль 14 управления состояниями. Затем таймер останавливается спустя 10 с. В этот момент времени модуль 14 также посылает свой второй запрос на модуль времени, что приводит к получению второй последовательности времени, представляющей момент времени, когда таймер остановился. Кроме того, модуль 14 подготавливает элемент вектора состояний для сервера S4 с информацией доступности '-', временной отметкой, как задано второй последовательностью времени, возвращенной от модуля времени, и значением задержки, конкретно заданным для устройства представлением числового значения «бесконечность» или '∞' Второй сигнал запуска, поступивший после остановки таймера, не обрабатывается модулем 14 управления, а игнорируется.

В конечном счете модуль 14 управления сохраняет скомпонованную пару информации состояния в векторе состояний, сохраненном в памяти 18 в четвертой позиции, т.е. в позиции, связанной с транспортным адресом сервера S4. Относительно информации состояний, в предположении, что транзакция, связанная с услугой, успешно завершена, обновленный вектор состояний теперь считывает s=[(-8,3, ∞ (11,2, 0,08), (14,1, 0,55), (15,3 0,37)].

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

Например, модуль управления вектором состояний (ссылочная позиция 14 на фиг. 3) и модуль (16) выбора сервера описаны как отдельные объекты в клиентском устройстве (10). Специалисту в данной области техники должно быть понятно, что эти модули могут быть также реализованы как единый модуль.

Список ссылочных позиций

S1-S4серверы набора серверовt1-t4значения временных отметок в векторе состояний10клиентское устройство12набор серверов13модуль управления14модуль управления вектором состояний16модуль выбора сервера18память20клиентский модуль

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

1. Способ выбора одного сервера (S1-S4) из набора (12) серверов для запроса одной или более услуг, например, связанных, по меньшей мере, с одним основанным на сеансе Интернет-приложением, при этом каждый из серверов (S1-S4) из набора (12) серверов имеет возможность поддерживать упомянутые услуги, причем способ содержит следующие этапы:

поддерживают вектор состояний, при этом присваивают, по меньшей мере, двум элементам вектора состояний информацию состояний, причем каждая информация состояния представляет состояние одного из серверов (S1-S4) набора (12) серверов,

выбирают сервер (S1-S4) путем применения предварительно определенного правила выбора к информации состояния элементов вектора состояний и

запрашивают услугу(и) от выбранного сервера (S1-S4), отличающийся тем, что, по меньшей мере, один тип информации состояния содержит значение временной отметки (t1-t4), указывающее момент времени, в который определяется состояние соответствующего сервера (S1-S4), правило выбора содержит этап определения максимального значения временной отметки (t1-t4) в векторе состояний и выбора соответствующего сервера (S1-S4).

модуль (13) управления для управления другими модулями (10, 16, 20) клиентского устройства (10),

память (18) для хранения вектора состояний, при этом, по меньшей мере, двум элементам вектора состояний присваивается информация состояний, причем каждая информация состояния представляет состояние одного из серверов (S1-S4) набора (12) серверов,

модуль (14) управления вектором состояний для поддержания вектора состояний путем записи информации состояний в память (18),

модуль (16) выбора сервера для считывания вектора состояний из памяти (18), применения предварительно определенного правила выбора к элементам вектора состояний и определения при этом выбираемого сервера (S1-S4),

клиентский модуль (20) для запроса услуги от выбранного сервера (S4), отличающееся тем, что память (18) предназначена для хранения, по меньшей мере, одного типа информации состояния, которая содержит значение (t1-t4) временной отметки, указывающее момент времени, в который определяется состояние соответствующего сервера (S1-S4), модуль (14) управления вектором состояний предназначен для записи такой информации состояния в память (18) и модуль (16) выбора сервера предназначен для определения максимального значения временной отметки в векторе состояний и соответствующего сервера (S1-S4).