Способ обеспечения надежной функции сервера в поддержке службы или набора служб

Способ обеспечения надежной функции сервера в поддержке службы или набора служб

Иллюстрации

Показать все

Реферат

Изобретение относится к способу обеспечения надежной функции сервера в поддержке службы или набора служб, таких как основанные на Интернет приложения.

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

Q. Xie и др.: «Rserpool Redundancy-model Policy» Internet Draft, [Online] 9 июня 2004 (2004-06-09), страницы 1-43, XP002308317 IETF, полученный из Интернет: URL-адрес: http://www.watersprings.org/pub/id/draft-ietf-rserpool-asap-09.txt> [найденный 30.11.2004], определяет параметр стратегии выбора участника модели Rserpool Redundancy и связанные процедуры. Эта стратегия предназначена быть гибкой и способной поддерживать широкий диапазон улучшенных моделей избыточности, найденных в некоторых системах высокой готовности. Проект использует возможность наращивания в стратегии распределения нагрузки опроса Rserpool.

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

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

Для того чтобы поддерживать высокую производительность, готовность и масштабируемость приложений, требуется поддерживать отслеживание тех серверов, которые находятся в пуле и способны принять запросы, и путь для клиента для того, чтобы связаться с желаемым сервером. Эти темы обсуждаются в документе рабочей группы IETF (инженерная группа по развитию Интернет) «Reliable Server Pooling», называемой рабочей группой RSerPool. Архитектура надежного объединения серверов в пул стандартизируется в рамках этой рабочей группы, см., например, определение отказоустойчивой платформы надежного объединения серверов в пул, описанное в Tuexen и др., "Architecture for Reliable Server Pooling", <draft-ietf-rserpool-arch-07.txt>, 12 октября 2003.

RserPool определяет три типа архитектурных элементов:

элементы (PE) пула: серверы, которые предоставляют одинаковую услугу в рамках пула;

пользователи (PU) пула: клиенты, обслуживаемые PE;

серверы (NS) имен: серверы, которые предоставляют услугу трансляции к PU и наблюдения за состоянием элементов PE.

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

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

RSerPool содержит два протокола, а именно обобщенный протокол (ASAP) доступа к серверу и протокол (ENRP) разрешения имени конечной точки. ASAP использует основанную на имени модель адресации, которая изолирует конечную точку логической связи от ее IP-адреса(ов). Серверы имен используют ENRP для связи друг с другом для того, чтобы обмениваться информацией и обновлениями относительно пулов серверов. Экземпляр ASAP (или ENRP), работающего в данном объекте, упоминается как конечная точка ASAP (или ENRP) этого объекта. Например, ASAP-экземпляр, работающий в PU, называется конечной точкой ASAP пользователя PU.

Каждый раз, когда PU отправляет сообщение пулу, который содержит более чем один PE, конечная точка ASAP пользователя PU должна выбрать один из PE в пуле в качестве приемника текущего сообщения. Выбор производится в PU согласно текущей стратегии (SSP) выбора сервера. В настоящее время обсуждаются четыре основных стратегии SSP с тем, чтобы использоваться с ASAP, а именно алгоритм циклического обслуживания ("карусель"), наименее используемый, наименее используемый с деградацией и взвешенный алгоритм циклического обслуживания, см. R.R. Stewart, Q. Xie: Aggregate Server Access Protocol (ASAP), <draft-ietf-rserpool-asap-08.txt>, 21 октября 2003.

Схема упрощенного примера последовательности на фиг.2 схематически иллюстрирует последовательность событий, когда конечная точка ASAP пользователя PU делает заполнение кэша [Stewart & Xie] для данного имени пула и выбирает PE согласно состоянию уровня техники.

Заполнение (обновление) кэша означает обновление локального кэша имен самыми последними данными соответствия имя-адрес как найденными сервером ENRP.

Этапы, показанные на фиг.2, объяснены как следующие:

S1: Конечная точка ASAP пользователя PU отправляет запрос NAME RESOLUTION (разрешение имени) серверу ENRP, запрашивающему всю информацию о данном имени пула.

S2: Сервер ENRP принимает запрос и находит элемент базы данных для конкретного имени пула. Сервер ENRP извлекает информацию о транспортных адресах из элемента базы данных.

S3: Сервер ENRP создает NAME RESOLUTION RESPONSE (ответ разрешения имени), в который вставлены транспортные адреса элементов PE. Сервер ENRP отправляет NAME RESOLUTION RESPONSE пользователю PU.

S4: Конечная точка ASAP пользователя PU заполняет (обновляет) свой локальный кэш имен информацией о транспортных адресах имени пула.

S5: PU выбирает один из элементов пула серверов на основе принятой адресной информации.

В конце концов, PU получает доступ к выбранному серверу для использования службы/служб.

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

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

- взвешенная "карусель" является простым расширением "карусели". Она назначает определенный вес каждому серверу. Вес указывает производительность обработки сервера.

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

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

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

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

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

Эта проблема решена способом с комбинацией признаков, как указано в п. 1, и посредством сервера имен и устройства пользователя пула, как указано в п. 12 или 15, соответственно.

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

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

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

Изобретение, описанное в данном документе, таким образом предлагает по существу расширение протокола RSerPool, где соответствующее расширение архитектуры RSerPool может легко быть осуществлено на сервере имен и пользователе пула.

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

Изобретение будет далее описано относительно отдельной стратегии выбора сервера, называемой SSP с максимальной готовностью (MA-SSP), которая является поводом отделить заявку заявителя. Изобретение однако не ограничено этой MA-SSP, а может быть основано на любой статической или динамической SSP, которая известна или должна быть разработана в будущем.

MA-SSP работает с так называемым вектором состояния. Согласно MA-SSP вектор состояния имеет размер N (т.е. равен числу элементов пула в данном пуле серверов) и определен следующим образом:

p = [p₁, p₂, • • •, p_N]

Определенный элемент в векторе состояния представляет последний известный момент состояния отдельного PE. Если последнее состояние PE было ON (включен), значение времени сохраняется в векторе состояния неизмененным. Если последнее состояние PE было OFF (выключен), значение времени сохраняется в векторе состояния с отрицательным знаком. Алгоритм MA всегда выбирает PE, который имеет максимальное значение в векторе состояния.

Конечная точка ASAP пользователя PU выполняет обновление своего вектора состояния. В будущем вектор состояния PU обозначается как p^(u). Согласно первоначальной спецификации RSerPool [Tuexen et al.; Stewart & Xie] сервер имен возвращает транспортные адреса серверов пула. Для того чтобы плавно объединить, например, MA-SSP в архитектуру RSerPool определено расширение RSerPool. Это расширение RSerPool, которое может быть использовано для других SSP до некоторой степени одинаковым способом, описано в последующем тексте.

Расширение в RSerPool влияет на связь между PU и NS, а именно конечными точками ASAP сервера NS и пользователя PU. В данном документе принято для иллюстративных целей, что как PU, так и сервер ENRP применяют алгоритм MA. Алгоритм MA в сервере ENRP создает вектор состояния для каждого пула серверов. Этот вектор состояния обновляется периодически посредством использования существующего механизма доступности протокола ASAP [Stewart & Xie]. Авторы будут далее обозначать вектор состояния сервера имен как p^(s). Вектор p^(s) для данного пула сохраняется в вышеупомянутом элементе данных базы данных в сервере имен, зарезервированном для этого пула. Авторы будут предполагать, что есть N элементов пула в пуле.

PU инициирует заполнение кэша в следующих двух случаях:

1) PU хочет выполнить заполнение (обновление) кэша для того, чтобы обновить свой вектор p^(u) новейшей информацией из сервера имен.

2) PU хочет разрешить имя пула.

В любом случае конечная точка ASAP пользователя PU отправляет запрос NAME RESOLUTION серверу ENRP через ASAP. Сервер ENRP принимает запрос и находит элемент базы данных для конкретного имени пула. Элемент данных базы данных содержит самую последнюю версию вектора p^(s). Сервер ENRP выполняет следующие действия:

1) Сервер ENRP извлекает информацию о транспортных адресах из элемента базы данных.

2) Сервер ENRP извлекает вектор p^(s) из элемента базы данных.

3) Сервер ENRP создает NAME RESOLUTION RESPONSE, в который вставлены транспортные адреса элементов PE. В дополнение к информации о транспортных адресах ответ об имени расширен дополнительным полем. В это дополнительное поле вставлен вектор p^(s).

4) Сервер ENRP отправляет NAME RESOLUTION RESPONSE пользователю PU.

Таким образом, NAME RESOLUTION RESPONSE содержит наиболее свежую версию вектора p^(s) сервера ENRP. После того как PU принимает NAME RESOLUTION RESPONSE, он обновляет локальный кэш имен (информацию о транспортных адресах) так же, как и свой вектор p^(u). Процедура обновления вектора p^(u) ASAP PU следующая:

(1)

где p_i ^(u) и p_i ^(s) являются i-ми элементами p^(u) и p^(s), соответственно.

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

Преимущественно расширение протокола RSerPool, требуемое для осуществления изобретения, довольно простое и легко вводимое в RSerPool. Более того, расширение протокола является прозрачным для уровня приложений в PU, т.е. клиенте. Вектор состояния обрабатывается на уровне ASAP стека протоколов PU. Таким образом, расширение протокола прозрачно к уровню приложений над уровнем ASAP. Каждый PU, поддерживающий это расширение протокола, выигрывает от улучшений в производительности, предоставленных изобретением.

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

фиг.1 (обсуждался выше) как упрощенную блок-схему общей архитектуры RSerPool согласно уровню техники;

фиг.2 (обсуждался выше) - упрощенная схема последовательности, иллюстрирующая обмен сообщениями между пользователем пула и сервером имен из фиг.1 согласно уровню техники;

фиг.3 схема последовательности как на фиг.2, иллюстрирующая обмен сообщениями между сервером имен и пользователем пула согласно варианту осуществления заявленного способа;

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

Схематический чертеж, резюмирующий основной принцип изобретения, показан на фиг.3. Этапы S1-S4 для заполнения кэша, как определено в этом изобретении, объясняются следующим образом:

1) Отправка запроса NAME RESOLUTION из конечной точки ASAP пользователя PU пула серверу NS имен или ENRP, запрашивающий всю информацию об имени данного пула.

2) Прием запроса и отыскание элемента базы данных для конкретного имени пула посредством сервера NS имен. Сервер NS имен извлекает из элемента базы данных информацию о транспортных адресах так же, как и вектор p^(s).

3) Создание NAME RESOLUTION RESPONSE, в который включают транспортные адреса PE и вектор p^(s), посредством сервера NS имен. Сервер NS имен отправляет NAME RESOLUTION RESPONSE пользователю PU пула.

4) Заполнение (обновление) локального кэша имен средствами конечной точки ASAP пользователя пула PU информацией о транспортных адресах по имени пула. Конечная точка ASAP пользователя пула применяет простую процедуру, описанную выше в уравнении (1), чтобы обновить вектор p^(u) состояния.

5) Выбор отдельного элемента пула или сервера для отправки ему запроса обслуживания.

Осуществление изобретенного способа может быть выполнено довольно просто. NAME RESOLUTION RESPONSE расширено с помощью отдельного поля, которое содержит вектор p^(s) состояния. Фиг.4 показывает принципиальные функциональные компоненты пользователя PU пула и сервера NS имен, последний иллюстрирован ассоциативно связанным с пулом SP серверов с двумя элементами PE пула.

Сервер NS имен содержит серверный модуль 10 разрешения пула, модуль 12 состояния элемента и память 14. Модуль 12 состояния элемента периодически компонует сообщения доступности конечной точки согласно протоколу IETF ASAP [Stewart & Xie] и отправляет эти сообщения каждому из серверов PE1, PE2.

Предполагая, что сервер PE1 находится в рабочем состоянии «включен» (сервер PE1 готов предоставить функцию сервера по запросу, например, клиента PU), сервер PE1 отвечает на сообщение о доступности от сервера NS, отправляя сообщение подтверждения доступности конечной точки назад серверу NS имен.

Принимая далее, что сервер PE2 находится в функциональном состоянии "выключен" (сервер PE2 не готов для обслуживания), сервер PE2 не отвечает на сообщение о доступности от сервера NS имен, посредством чего локальный таймер, инициированный для этого сообщения поддержки на сервере NS имен, истекает согласно протоколу IETF ASAP.

Модуль 12 состояния элемента удерживает вектор состояния, который сохранен в памяти 14. Вектор содержит для каждого элемента PE1, PE2 пула SP число, представляющее временную отметку, которая указывает время обработки ответа каждого из элементов на сообщение поддержки. Сообщение подтверждения доступности, принятое от PE1, таким образом заставляет модуль 12 записать временную отметку 'A8C0' (hex) в позицию вектора состояния, предоставленную для сервера PE1, предполагающую, что сообщение подтверждения приема обработалось в двенадцать часов, как измерено блоком синхронизации (не показан) в сервере имен, и временная отметка точна в единицах секунд. Сообщение о недоступности, принятое от PE1, заставляет модуль 12 записать временную отметку '-A8C1' (hex) в позицию вектора состояния, предоставленную для сервера PE2, предполагающую, что сообщение о недоступности было обработано в пределах одной секунды после двенадцати часов.

Функциональность серверного модуля 10 описана ниже более детально относительно запроса от пользователя PU пула. Пользователь PU пула содержит клиентский модуль 16 разрешения пула, модуль 18 выбора сервера, память 20 и модуль 22 готовности сервера.

Пользователь PU пула реализован в мобильном устройстве (не показано), допускающем передачу данных и голоса через UMTS-сеть, пул SP серверов и сервер NS имен являются ее частями. Приложение устройства хочет получить доступ к службе, предоставленной любым из серверов пула SP. В этом примере пул SP серверов является "фермой" или набором серверов, реализующими службы, связанные с IMS(IP мультимедиа подсистема)-доменом сети UMTS. Заявка является примером основанного на SIP приложения.

Чтобы запросить отдельную службу, приложению, работающему на мобильном устройстве (не показано), известно только имя пула. Приложение запускает часть пользователя пула (содержащего конечную точку ASAP) мобильного устройства посредством передачи имени пула. Клиентский модуль разрешения пула компонует сообщение разрешения имени согласно протоколу ASAP и отправляет его серверу NS имен (этап S1 на фиг.3).

Сообщение разрешения имени принимается в сервере NS имен посредством серверного модуля 10 разрешения пула. Имя пула извлекают, и серверный модуль 10 получает доступ в память 14, чтобы извлечь адресную информацию, которая сохранена ассоциативно связанной с именем пула. В данном примере из памяти 14 считываются IP-адреса элементов PE1, PE2 пула вместе с адресом порта, который должен быть использован для запроса отдельной службы, и, согласно изобретению, также временные отметки 'A8C0', '-A8C1', сохраненные в ассоциативной связи с серверами PE1, PE2, считывают из памяти 14. Этап S2 на фиг.3 на этом заканчивается.

Серверный модуль 10 компонует сообщение ответа разрешения имени согласно протоколу IETF ASAP, которое содержит список разрешения имен с транспортными адресами элементов PE1, PE2, как известно в области техники. Далее, вектор состояния присоединяется к части информации о транспортном адресе в сообщении-ответе. Вектор содержит в этом примере два основанных на временной отметке элемента состояния для серверов PE1, PE2 пула.

Сообщение-ответ отправляется отправителю запроса (этап S3 на фиг.3), т.е. клиентскому модулю 16 пользователя PU пула. После приема сообщения-ответа модуль 16 извлекает транспортные адреса и вектор состояния из сообщения-ответа и записывает данные в память 20. Далее модуль захватывает управление над модулем 18 выбора сервера.

Чтобы выбрать конкретный сервер для отправки ему запроса на обслуживание (т.е. выполняют этап S5 на фиг.3), модуль 18 выбора сначала загружает два вектора состояния в рабочую память, первый, который был определен модулем 22 готовности сервера, второй является вектором состояния, принятым от сервера имен, как описано выше.

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

Как упоминалось выше, модуль 18 выбора загружает оба вектора состояния. Затем модуль 18 определяет обновленный локальный вектор состояния, заменяя каждый элемент в локальном значении состояния соответствующим значением вектора состояния сервера имен в случае, когда это соответствующее значение в абсолютных выражениях (т.е. игнорируя знак '-') является наибольшим, что означает, что измерение состояния сервера имен более свежее, т.е. было выполнено более недавно, то измерение состояния выполняют локально модулем 22 готовности.

В качестве примера сохраненный локальный (первый) вектор состояния может представлять состояние PE1 в 11:50 (недоступен) и 11:55 (доступен), т.е. <-A668, A794>, затем локальный вектор обновляется в обоих позициях, имеющих результатом <A8C0, -A8C1>.

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

На следующем этапе (этап 5 на фиг.3) модуль 18 выбора сервера определяет сервер, который должен быть выбран посредством оценки наибольшего значения в обновленном векторе состояния. В этом примере наибольшее значение - это 'A8C0', сохраняемое в позиции, указывающей элемент PE1 пула. Таким образом, модуль 18 создает указатель, указывающий на позицию сохранения внутри памяти 20, содержащую транспортный адрес и дополнительные данные, такие как адрес порта, относящиеся к PE1, и возвращает этот указатель назад вызывающему приложению, чтобы разрешить ему запросить обслуживание от PE1.

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

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

1. Способ обеспечения надежной функции сервера в поддержке службы

или набора служб, таких как приложения, основанные на Интернет, способ содержит следующие этапы, на которых

формируют пул (SP) серверов с одним или более элементами (РЕ1, РЕ2) пула, причем каждый из элементов (РЕ1, РЕ2) пула может поддерживать службу(ы),

обеспечивают, по меньшей мере, один сервер (NS) имен для управления и сохранения пространства имен для пула (SP) серверов, причем пространство имен содержит имя пула, идентифицирующее пул (SP) серверов,

отправляют посредством пользователя (PU) пула, для использования службы/служб, запрос серверу (NS) имен, указывающий имя пула,

разрешают, посредством сервера (NS) имен по запросу, имя пула в список разрешения имен, причем список разрешения имен содержит адресную информацию, такую как IP-адрес, относящуюся к одному или более элементам (РЕ1, РЕ2) пула,

отправляют список разрешения имен посредством сервера (NS) имен пользователю (PU) пула,

получают доступ, посредством пользователя (PU) пула и на основе адресной информации из списка разрешения имен, к одному из элементов (РЕ1, РЕ2) пула (SP) серверов для использования службы/служб,

отличающийся тем, что

отправляют информацию о состоянии, относящуюся к операционному состоянию, по меньшей мере, одного из элементов (РЕ1, РЕ2) пула, из сервера (NS) имен к пользователю (PU) пула,

пользователь (PU) пула определяет вектор состояния, содержащий информацию о состоянии, относящуюся к готовности одного или более из элементов (РЕ1, РЕ2) пула, и вектор состояния, определенный пользователем (PU) пула, обновляется посредством вектора состояния, принятого от сервера (NS) имен, и

информация состояния, относящаяся к готовности, определяется по истечении или неистечении времени одного или более таймеров, относящегося к передаче сообщения между пользователем (PU) пула и одним или более из элементов (РЕ1, РЕ2) пула, на уровне приложения и/или транспортном уровне.

2. Способ по п.1, отличающийся тем, что информация о состоянии представляет временную отметку, указывающую момент времени, в который определяется состояние одного из элементов (РЕ1, РЕ2) пула.

3. Способ по п.2, отличающийся тем, что

состояние упомянутого одного из элементов (РЕ1, РЕ2) пула определяется на основе сообщения подтверждения доступности, принятого сервером (NS) имен от одного из элементов (РЕ1, РЕ2) пула в ответ на сообщение о доступности, отправленное сервером (NS) имен одному из элементов (РЕ1, РЕ2) пула, или извещение об истечении времени локального таймера на сервере (NS) имен из-за отсутствия сообщения подтверждения доступности от одного из элементов (РЕ1, РЕ2) пула,

сообщение подтверждения доступности и извещение об истечении времени локального таймера указывают состояние одного из элементов (РЕ1, РЕ2) пула, например, такое как включение и выключение, соответственно.

4. Способ по п.2 или 3, отличающийся тем, что

информация о состоянии содержит положительное число, например, представляющее временную отметку, если упомянутый один из элементов (РЕ1, РЕ2) пула находится в состоянии «включен», и

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

5. Способ по п.1, отличающийся тем, что этап, на котором отправляют запрос посредством пользователя (PU) пула к серверу (NS) имен, выполняется посредством отправления сообщения разрешения имени, причем отправка запускается пользователем (PU) пула для выполнения заполнения кэша.

6. Способ по п.5, отличающийся тем, что этап, на котором отправляют список разрешения имен сервером (NS) имен к пользователю (PU) пула, содержит передачу ответного сообщения разрешения имени, которое дополнительно содержит информацию о состоянии, при этом информация о состоянии предпочтительно вставляется в ответное сообщение разрешения имени в качестве вектора состояния.

7. Способ по п.1, отличающийся тем, что конкретный один из элементов (РЕ1, РЕ2) пула в пуле (SP) серверов выбирается для функции сервера на основе информации о состоянии в векторе состояния, принятом от сервера (NS) имен.

8. Способ по п.1, отличающийся тем, что вектор состояния, определенный пользователем (PU) пула, обновляется посредством замены информации состояния соответствующей информацией состояния вектора состояния, принятого от сервера (NS) имен, в случае, когда соответствующая информация о состоянии указана как более свежая, например, когда абсолютное значение временной отметки является более высоким.

9. Способ по любому из пп.5-8, отличающийся тем, что на этапе выбора конкретного одного из элементов (РЕ1, РЕ2) пула в пуле серверов, посредством пользователя (PU) пула, дополнительно применяется стратегия выбора сервера, в частности, SSP с максимальной готовностью или одно из ее расширений.

10. Сервер (NS) имен для управления и хранения пространства имен для пула (SP) серверов с одним или более элементами (РЕ1, РЕ2) пула для обеспечения надежной функции сервера при поддержке службы или набора служб, таких как приложения, основанные на Интернет, причем сервер имен содержит

серверный модуль (10) разрешения пула для приема запроса, предпочтительно сообщения разрешения имени, согласно протоколу IETF ASAP, указывающее имя пула, и

память (14) для хранения адресной информации, такой как IP-адрес, относящейся к элементам (РЕ1, РЕ2) пула, связанным с именем пула, идентифицирующим пул (SP) серверов,

причем серверный модуль (10) разрешения пула предназначен для разрешения, в ответ на запрос, имени пула в список разрешения имен посредством получения доступа к памяти (14) и извлечения адресной информации, связанной с его именем пула, и для компоновки сообщения, содержащего список разрешения имен, такого как ответное сообщение разрешения имени согласно протоколу IETF ASAP, и для отправки сообщения отправителю (16) запроса,

отличающийся тем, что

память (14) дополнительно предназначена для хранения информации о состоянии, связанной с одним или более элементами (РЕ1, РЕ2) пула, и

серверный модуль (10) разрешения пула дополнительно предназначен для получения доступа, в ответ на запрос, к памяти (14) для извлечения информации о состоянии и отправки информации о состоянии назад к отправителю (16) запроса, предпочтительно путем вставки информации о состоянии в сообщение в качестве вектора состояния.

11. Сервер имен по п.10, отличающийся модулем (12) состояния элемента, предназначенным для компоновки сообщения о доступности, предпочтительно сообщения о доступности конечной точки согласно протоколу IETF ASAP, и для отправки сообщения о доступности одному из элементов (РЕ1, РЕ2) пула и для приема сообщения подтверждения доступности или приема уведомления об истечении времени локального таймера, предпочтительно сообщения подтверждения доступности конечной точки или истечения времени локального таймера согласно протоколу IETF ASAP от одного из элементов (РЕ1, РЕ2) пула и, в ответ на этот прием, для получения доступа к памяти (14) для записи информации о состоянии, указывающей состояние упомянутого одного из элементов (РЕ1, РЕ2) пула, предпочтительно как нахождение во включенном или выключенном состоянии, соответственно.

12. Сервер имен по п.11, отличающийся тем, что модуль (12) состояния элемента предназначен для записи в качестве информации о состоянии числа, представляющего временную отметку.

13. Устройство (PU) пользователя пула для использования функции сервера в поддержке службы или набора служб, например, приложений, основанных на Интернет, которая может быть предоставлена каждым из одного или более элементов (РЕ1, РЕ2) пула (SP) серверов, при этом устройство пользователя пула содержит

клиентский модуль (16) разрешения пула для компоновки запроса, предпочтительно сообщения разрешения имени согласно протоколу IETF ASAP, указывающий имя пула, идентифицирующее пул (SP) серверов, для отправки запроса серверу (NS) имен и приема сообщения, содержащего список разрешения имен, предпочтительно ответное сообщение разрешения имени согласно протоколу IETF ASAP от сервера (NS) имен,

модуль (18) выбора сервера для получения доступа на основе адресной информации из списка разрешения имен к конкретному одному из элементов (РЕ1, РЕ2) пула (SP) серверов для использования службы/служб, отличающийся тем, что

клиентский модуль (16) разрешения пула дополнительно предназначен для приема сообщения, содержащего вектор состояния, и модуль (18) выбора сервера дополнительно предназначен для получения доступа к конкретному одному из элементов (РЕ1, РЕ2) пула в ответ на информацию о состоянии, включенную в вектор состояния, причем клиентский модуль (16) разрешения также предназначен для определения вектора состояния, содержащего информацию о состоянии, относящуюся к готовности одного или более элементов (РЕ1, РЕ2) пула, и обновления вектора состояния, определенного пользователем (PU) пула, посредством вектора состояния, принятого от сервера (NS) имен, и

клиентский модуль (16) разрешения пула предназначен для определения информации о состоянии, относящейся к готовности, по истечении или неистечении времени одного или более таймеров, относящихся к передаче сообщения между пользователем (PU) пула и одним или более элементами (РЕ1, РЕ2) пула на уровн