ОБЪЕДИНЕНИЕ РЕСУРСОВ В СЕРВЕРЕ ЦЕНТРА КОММУТАЦИИ С КЛАСТЕРОМ С ЭЛЕКТРОННЫМИ ПЛАТАМИ

1. Сервер центра коммутации, содержащий:
- кластер с блэйдами со множеством блэйдов (110),
- множество пулов ресурсов, доступных упомянутому множеству блэйдов (110), и
- мастера для каждого пула (112) ресурсов, обеспечиваемого на одном из блэйдов, централизованного координирующего использование объединенных ресурсов.
2. Сервер центра коммутации по п.1, в котором кластер с блэйдами сконфигурирован таким образом, что информация об используемых ресурсах для вызова обеспечивается на двух разных блэйдах (110).
3. Сервер центра коммутации по п.1 или 2, отличающийся тем, что дополнительно содержит контроллер (111) вызовов, обеспечиваемый на одном из блэйдов, управляющих ресурсами для упомянутого вызова.
4. Сервер центра коммутации по п.3, дополнительно содержащий партнера (113) мастера (112) на одном из блэйдов, на котором мастер не обеспечивается, причем партнер (113) содержит информацию о ресурсах, управляемых контроллером вызовов, находящимся на том же самом блэйде, что и мастер.
5. Сервер центра коммутации по п.1 или 2, в котором каждый блэйд дополнительно содержит блок (114) информации о состоянии блэйда, определяющий состояние блэйда (110), в котором блок (114) информации о состоянии блэйда сообщает другим блэйдам о любом изменении состояния блэйда.
6. Сервер центра коммутации по п.1 или 2, дополнительно содержащий координатор (115), создающий нового мастера для мастера, присутствующего на отказавшем блэйде, и создающий нового партнера для партнера, присутствующего на отказавшем блэйде, причем координатор (115) принимает решение, какой блэйд назначить новому мастеру и/или новому партнеру.
7. Сервер центра коммутации по п.5, в котором, в случае, если координатор назначает нового мастера на одном из блэйдов, другие блэйды передают новому мастеру (112) список используемых ресурсов.
8. Сервер центра коммутации по п.1 или 2, в котором каждый блэйд (110) содержит блок восстановления блэйда, выполняющий процедуру восстановления блэйда в случае отказа блэйда, в котором блок восстановления блэйда решает, какой из вызовов, обрабатываемых отказавшим блэйдом, сохранить, и передает информацию о ресурсах, которые все еще выделены и о ресурсах, управление которыми передается обратно мастеру (112).
9. Сервер центра коммутации по п.6, в котором координатор (115) обнаруживает нагрузку сигнализации блэйдов (110) и перемещает мастеров (112) и партнеров (113) для различных пулов ресурсов на различные блэйды в зависимости от нагрузки сигнализации различных блэйдов (110).
10. Сервер центра коммутации по п.1 или 2, в котором каждый блэйд содержит блок (116) обслуживания групповой связи, управляющий доставкой сообщений другим блэйдам таким образом, что сообщения доставляются в одном и том же порядке множеству блэйдов (110).
11. Сервер центра коммутации по п.1 или 2, в котором мастер маршрута обеспечивается для каждого маршрута магистральной линии связи, тогда как мастер доступа обеспечивается для каждого доступа ISDN.
12. Сервер центра коммутации по п.1 или 2, дополнительно содержащий мастера медиашлюза, управляющего обработкой сообщений поддержки медиашлюза (200).
13. Сервер центра коммутации по п.11, в котором контроллер вызовов запрашивает управление над ресурсами от мастера маршрута или мастера доступа по п.11 и возвращает управление, если ресурсы более не требуются.
14. Способ управления сервером центра коммутации, причем сервер имеет кластер блэйдов с множеством блэйдов (110), содержащий следующие этапы, на которых:
- обеспечивают пулы ресурсов, доступных упомянутому множеству блэйдов (110), и
- координируют использование объединенных ресурсов для упомянутого вызова упомянутым множеством блэйдов с помощью мастера (112), назначенного каждому пулу.
15. Способ по п.14, в котором контроллером (111) вызовов для обработки вызовов выполняется, по меньшей мере, один из следующих этапов: установление вызова, наблюдение за вызовом и разрыв вызова, запрашивая управление над ресурсами от мастера маршрута или мастера доступа и возвращая управление, если ресурсы более не требуются.
16. Способ по п.14 или 15, в котором информацией об используемых ресурсах для вызова управляют таким образом, что информация об используемых ресурсах, присутствующих на блэйде контроллера вызовов упомянутого вызова, дополнительно предоставляется на еще одном блэйде.
17. Способ по любому из пп.14-15, дополнительно содержащий этап обнаружения изменения состояния, по меньшей мере, одного из блэйдов сервера, в котором, в случае изменения состояния, другим блэйдам сообщают об изменении состояния упомянутого одного блэйда.
18. Способ по любому из пп.14-15, дополнительно содержащий этапы, на которых:
- обнаруживают отказ блэйда,
- обнаруживают, выполнена ли процедура восстановления для упомянутого блэйда,
в котором вызовы могут быть сохранены и ресурсы, управляемые упомянутым отказавшим блэйдом для таких вызовов, продолжают использоваться после окончания процедуры восстановления.
19. Способ по любому из пп.14-15, дополнительно содержащий этапы, на которых:
- обнаруживают отказ блэйда,
- обнаруживают, выполнена ли процедура восстановления для упомянутого блэйда,
в котором, когда процедура восстановления выполнена, мастеру сообщается о ресурсах, которые были использованы для несохраненных вызовов после процедуры восстановления, причем мастер устанавливает эти ресурсы в исходное состояние.
20. Способ по п.17, в котором, в случае обнаружения отказа блэйда, на котором присутствует мастер (112), создается новый мастер и первый список ресурсов, используемых каждым блэйдом, передается новому мастеру от каждого другого блэйда к другому.
21. Способ по п.17, в котором блэйд, на котором обеспечивается партнер (113) мастера, который находится на отказавшем блэйде, передает новому мастеру второй список ресурсов, используемых мастером (112), который находится на отказавшем блэйде, на котором также находился контроллер (111) вызовов.
22. Способ по п.18, в котором все ресурсы, которые не присутствовали в первом или втором списках используемых ресурсов, устанавливаются в исходное состояние в ситуации многочисленных отказов блэйдов.
23. Способ по п.20 или 21, в котором ресурсы, которые не присутствовали в списках, устанавливаются в исходное состояние только тогда, когда не выполняется никакая процедура восстановления блэйда, что может привести к непрерывному использованию ресурсов после окончания процедуры восстановления.
24. Способ по любому из пп.14-15, 20-22, дополнительно содержащий этап обнаружения, находится ли более, чем один блэйд в активном состоянии, в котором в случае утвердительного ответа и если не был назначен партнер, партнер (113) мастера (112) создается на блэйде (110), на котором не обеспечивается мастер.
25. Способ по любому из пп.20-22, в котором для нового мастера, выступающего в роли прежнего мастера, создается новый партнер (113).
26. Способ по любому из пп.14-15, 20-22, дополнительно содержащий этап обнаружения, присутствует ли партнер (113) на отказавшем блэйде, в котором новый партнер создается, заменяя партнера, присутствующего на отказавшем блэйде.
27. Способ по любому из пп.14-15, 20-22, в котором этап создания нового мастера содержит, по меньшей мере, один из следующих этапов:
- определение координатором (115), на каком блэйде создан новый мастер,
- информирование с помощью координатора (115) других блэйдов о создании нового мастера,
- создание с помощью нового мастера таблицы состояний ресурсов, используемых каждым блэйдом,
- передачу с помощью других блэйдов новому мастеру информацию, необходимую новому мастеру для координации использования объединенных ресурсов множеством блэйдов,
- копирование партнеру (113) с помощью нового мастера данных, касающихся вызовов, управляемых на том же самом блэйде,
- информирование мастера (112) с помощью партнера (113), что данные были успешно сохранены,
- информирование с помощью нового мастера других блэйдов о завершении создания мастера.
28. Способ по п.27, в котором запросы о занятости для ресурсов, принятые во время перемещения мастера (112), буферизуются и после завершения передачи передаются новому мастеру.
29. Способ по п.28, в котором, в случае, если до завершения передачи обнаруживается отказ для нового мастера, перемещение прерывается.
30. Способ по любому из пп.14-15, 20-22, 28-29, в котором перемещение партнера (113) содержит, по меньшей мере, один из следующих этапов, на которых:
- определяют с помощью координатора (115), какой партнер должен быть перемещен и на какой блэйд партнер должен быть перемещен,
- передают новому партнеру с помощью мастера (112) все данные, необходимые новому партнеру,
- информируют с помощью партнера (113) другие блэйды (110) о перемещении партнера, в котором мастер (112) посылает информацию об измененных состояниях занятости новому партнеру после того, как он информирован об изменении.
31. Способ по любому из пп.14-15, 20-22, 28-29, в котором перемещение координатора (115), управляющего перемещением или созданием нового мастера или партнера, не влияет на перемещение или создание мастера или партнера.
32. Способ по любому из пп.14-15, 20-22, 28-29, дополнительно содержащий этапы, на которых:
- обнаруживают, становится ли новый блэйд активным,
- передают текущее состояние и размещение мастеров и партнеров от другого блэйда на новый активный блэйд.