Объединение ресурсов в сервере центра коммутации с кластером с электронными платами

Объединение ресурсов в сервере центра коммутации с кластером с электронными платами

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Настоящее изобретение относится к серверу центра коммутации, обрабатывающему вызовы. В частности, но не исключительно, изобретение относится к серверу центра коммутации мобильной связи (MSC-S).

Уровень техники

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

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

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

При описанной выше технологии трудно совместно использовать терминалы TDM и CIC среди нескольких блэйдов. Диапазон доступных схем TDM, а для BICC - диапазон кодов инстанций вызова, должен быть разделен. В этом случае, каждая часть административно назначается конкретному блэйду сервера MSC.

Однако, разделение ресурсов обладает тем недостатком, что разделение исключает эффективное использование схем в плоскости пользователей. При отказе блэйда ресурсы, которые выделены отказавшему блэйду, недоступны для другого трафика. Дополнительно становится труднее конфигурировать сервер MSC по сравнению с системой, которая не нуждается в разделении схем TDM. В частности, когда блэйды добавляются в кластер или удаляются из кластера, переразделение ресурсов, назначенных другим блэйдам, должно быть выполнено. Число блэйдов, находящихся в активном состоянии, может изменяться, например, из-за выхода из строя отдельных блэйдов или в случае, когда производительность сервера увеличивается за счет добавления новых блэйдов. Если количество схем, которые должны быть разделены, лишь ненамного превышает количество блэйдов, равномерное распределение связности с блэйдами становится затруднительным. Если количество схем, которые должны быть разделены, меньше, чем количество блэйдов в кластере, связность для всех блэйдов не может быть обеспечена.

Сущность изобретения

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

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

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

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

Мастер доступа может быть обеспечен для каждого доступа к цифровой сети комплексного обслуживания (ISDN). Для доступа к ISDN терминалы TDM имеют административно установленные фиксированные отношения с каналом. Каждый доступ с базовой скоростью имеет мастера, координирующего выбор и освобождение подключенных каналов. Этот мастер, называемый "мастер доступа", рассматривает типы поиска, применимые для рассматриваемого доступа. Координация эксплуатационных процедур, содержащая обработку эксплуатационных сообщений, выполняется мастером доступа. Соответственно, для каждого маршрута или для каждого доступа может обеспечиваться инстанция мастера, причем каждая инстанция мастера управляет пулом ресурсов общего пользования.

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

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

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

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

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

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

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

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

На дополнительном этапе обнаруживается состояние блэйдов и в случае изменения состояния одного блэйда другие блэйды информируются об изменении состояния упомянутого одного блэйда. Обнаруживая изменение состояния блэйда, обнаруживается отказ блэйда. На дополнительном этапе может быть обнаружено, выполнена ли процедура восстановления для упомянутого блэйда. Если это не происходит, то все ресурсы, управляемые упомянутым отказавшим блэйдом, могут быть высвобождены, чтобы использоваться для других вызовов. Ресурсы отказавшего блэйда устанавливаются в исходное состояние. В случае неисправности одиночного блэйда, копия всей информации присутствует на другом блэйде. В случае, если на отказавшем блэйде выполняется процедура восстановления, мастеру сообщают о ресурсах, используемых для вызовов, которые не сохранены после процедуры восстановления, так чтобы мастер мог затем установить в исходное состояние ресурсы, использовавшиеся для несохраненных вызовов. Когда мастер принимает от блэйдов, которые выполнили восстановление блэйда, информацию, какие CIC/каналы более не используются, мастер затем устанавливает в исходное состояние те CIC/каналы, которые больше не используются, и может послать на медиашлюз команды GCP (межсетевого протокола управления шлюзом) отказа в предоставлении прав в отношении связанных с ним терминалов TDM и временных терминалов.

Когда на отказавшем блэйде никакие вызовы не сохраняются, CIC/каналы и подключенные терминалы TDM, которые использовались отказавшем блэйдом, устанавливаются мастером в исходное состояние, временные терминалы удаляются мастером медиашлюза, используя механизм группового символа.

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

Каждый блэйд принимает уведомление об изменениях состояния других блэйдов в кластере. Роли мастера и партнера, которые были назначены отказавшему блэйду, теперь назначаются другим блэйдам. Каждый блэйд посылает новому мастеру список CIC/каналов, которые она предоставила в пользование. Блэйд, который пока управляет партнером мастера на отказавшем блэйде, дополнительно посылает второй список CIC/каналов, которые мастер на отказавшем блэйде предоставил в пользование контроллеру вызовов, расположенному на том же самом блэйде. Новый партнер может быть создан для каждого из новых мастеров и обновляется данными занятости ресурсов, которые в настоящее время предоставлены в пользование пользователями на блэйде, на котором постоянно находится новый мастер, а также данными, принятыми от предыдущего партнера. Новый мастер и мастер медиашлюза могут затем установить в исходное состояние устройства и терминалы, как описано выше.

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

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

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

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

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

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

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

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

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

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

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

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

Краткое описание чертежей

Далее изобретение будет описано со ссылкой на сопроводительные чертежи, на которых

Фиг.1 - сервер центра коммутации со структурой кластера блэйдов, по существу, координирующего использование ресурсов мастером,

Фиг.2a и 2b - пример кластера блэйдов с тремя блэйдами и размещением управления вызовами и мастера,

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

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

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

Фиг.6 - структура блэйда с передачей данных новому мастеру для структуры, показанной на фиг.5,

Фиг.7 - структура с блэйдами, показанная на фиг.5, с передачей данных новым партнерам,

Фиг.8 - блок-схема последовательности выполнения операций для создания нового мастера,

Фиг.9 - блок-схема последовательности помещения в буфер запросов обслуживания, подаваемых пользователем во время перемещения мастера,

Фиг.10 - конечный автомат перемещения мастера,

Фиг.11 - блок-схема последовательности выполнения операций при изменении состояния блэйда во время перемещения мастера,

Фиг.12 - блок-схема последовательности выполнения операций при успешном перемещении партнера,

Фиг.13 - конечный автомат для партнера и

Фиг.14 - блок-схема последовательности выполнения операций во время перемещения партнера.

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

Фиг.16 - структура с блэйдами с передачей данных новому мастеру для структуры, показанной на фиг.15,

Фиг.17 - структура с блэйдами, показанная на фиг.15, с передачей данных новым партнерам,

Фиг.18 - структура с блэйдами, показанная на фиг.15, с передачей данных в конце восстановления блэйда.

Подробное описание

На фиг.1 показан пример варианта осуществления сервера 100 коммутации мобильной связи (сервер MSC), имеющего кластерную структуру с множеством блэйдов 110. Для обработки вызовов центр 100 коммутации мобильной связи подключен к медиашлюзам (MGw) 200. Каждый MGw содержит множество терминалов 210. Как известно в технике, MGw действует как блок трансляции между отдельными сетями связи, причем MGw позволяет осуществлять мультимедийные соединения по многочисленным транспортным протоколам. Такие ресурсы, как терминалы 210 в плоскости пользователя или набор схем или каналов, являются примерами объединенных ресурсов, которые должны быть доступны всем блэйдам 110. Координация использования объединенных ресурсов выполняется мастером 112, как показано в правой части фиг.1, где в качестве примера варианта осуществления показаны некоторые из модулей, обеспечиваемых на блэйде. Для магистральных линий связи мастер является мастером маршрута, координирующим выбор и освобождение CIC, связанных с маршрутом. Для каждого маршрута обеспечивается мастер маршрута, причем каждый мастер координирует пул объединенных ресурсов. Другими словами, каждый пул совместно используемых ресурсов управляется специально назначенным мастером. Для доступа к цифровой сети ISDN мастер является мастером доступа, координирующим выбор и освобождение каналов, подключенных для доступа. Дополнительно, обеспечивается контроллер 111 вызовов, управляющий индивидуальными ресурсами во время вызова, то есть, он устанавливает вызов, контролирует вызов и разрывает вызов. Дополнительно, блок определения состояния блэйда обеспечивается на каждом блэйде, осуществляющем связь с блоками определения состояния блэйда на других блэйдах, чтобы информировать другие блэйды об изменениях состояния, например, в случае отказа блэйда.

Дополнительно, на блэйде может быть обеспечен координатор 115, решающий, какие блэйды должны содержать функции мастера 112 или партнера 113. Как далее будет объяснено подробно, функция партнера 113 предоставляется в случае, если на одном и том же блэйде для определенного вызова обеспечиваются мастер 112 и контроллер 111 вызовов. Дополнительно обеспечивается блок 116 обслуживания групповой связи, управляющий доставкой сообщений между различными блэйдами таким образом, что сообщения доставляются в одном и том же порядке всем блэйдам. Дополнительно обеспечивается блок восстановления блэйда (не показан), инициирующий процедуру восстановления блэйда в случае отказа блэйда. Эксплуатационные процедуры на уровне медиашлюза координируются мастером медиашлюза, не показанным в варианте осуществления, представленном на фиг.1.

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

Изменение конфигурации блэйда и восстановление после отказа

Подготовка к восстановлению

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

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

На фиг.2a посредством примера показано, какая информация хранится мастером 112b, партнером 113b и контроллером 111 вызовов. На блэйде 1 контроллер 111 вызовов имеет запись "R-B; CIC-08", что означает, что CIC 08 маршрута В был предоставлен в пользование. Первой записью в списке занятых схем мастера 112b маршрута является "B-I; CIC-08". Это означает, что CIC с номером 08 был предоставлен в пользование контроллеру 111 вызова на блэйде 1. Так как мастер 112b и контроллер 111 вызовов не постоянно присутствуют на одном и том же блэйде, на блэйде 3 нет никакой соответствующей записи в маршруте 113b партнера.

На фиг.2b представлен пример случая, в котором мастер 112a и контроллер 111 вызовов постоянно присутствуют на одном и том же блэйде. На блэйде 1 контроллер 111 вызовов имеет запись "R-A; CIC-12", что означает, что CIC 12 маршрута A был предоставлен в пользование. Первой записью в списке занятых схем мастера А 112a маршрута является "B-1; CIC-12". Это означает, что CIC с номером 12 был предоставлен в пользование контроллеру вызовов на блэйде 1. Так как мастер 112a и контроллер 111 вызовов постоянно присутствуют на одном и том же блэйде, информация, что CIC 12 был использован в контроллере вызовов на блэйде 1, также хранится партнером 113a, который постоянно присутствует на блэйде 2.

На фиг.3 показано обобщение знания различными блэйдами о схемах, принадлежащих одному маршруту. На фиг.3 для каждого блэйда обведены области, указывающие наборы схем, для которых блэйд знает их состояние. Большая область 130 представляет общее количество схем, доступных для упомянутого маршрута. Меньшие области 131 представляют схемы, предоставленные в пользование каждым блэйдом. Область 132, представляющая разность областей 130 и 131, представляет неактивные схемы для упомянутого маршрута. В показанном варианте осуществления обеспечиваются четыре различные блэйда. Блэйд 1 знает, какие схемы предоставлены в пользование блэйдом 1, тогда как блэйд 2 знает схемы, предоставленные в пользование блэйдом 2. В показанном варианте осуществления блэйд 3 содержит мастера маршрута, знающего, какие схемы используются различными блэйдами для этого заданного маршрута. Мастер, обеспечиваемый на блэйде 3, имеет информацию о схемах, предоставленных в пользование блэйдом 1, блэйдом 2, блэйдом 3, блэйдом 4 и неактивных схемах, не предоставленных в пользование никакому контроллеру вызовов. Как можно видеть, мастер также знает состояние неиспользуемых схем. В показанном варианте осуществления партнер содержится на блэйде 4. Как следствие, блэйд партнера не только знает, какие схемы предоставлены в пользование блэйдом 4. Блэйд 4 в его роли партнера дополнительно обладает знанием о схемах, предоставленных в пользование блэйдом 3 в случае, если контроллер вызовов для вызова обеспечивается на блэйде 3, также как и мастер. Для каждого вызова обеспечивается контроллер вызовов и эти контроллеры вызовов распределены по блэйдам. В случае, когда контроллер вызовов для вызова, использующего определенный маршрут, обеспечивается на том же самом блэйде, что и мастер для упомянутого маршрута, партнер дополнительно содержит информацию о том, какие схемы предоставлены в пользование блэйдом, на котором обеспечивается мастер.

Мастера MGw не имеют партнера. Информация о состоянии MGw копируется на все блэйды. В приведенной ниже таблице указывается, как распределяется связанная с вызовом информация.

Информация	Первичное	Вторичное	Альтернатива
Состояние занятости устройства маршрутизации	Мастер маршрута	Контроллер вызовов	Партнер маршрута
Состояние занятости устройства PRA	Мастер PRA	Контроллер вызовов	Партнер PRA
Состояние блокировки линии устройства маршрутизации	Мастер маршрута	Каждый блэйд
Состояние другой блокировки устройства маршрутизации	Мастер маршрута	Каждый блэйд
Деятельность по эксплуатационным сообщениям и тревоги	Мастер	Каждый блэйд
Состояние MGw	Мастер MGw	Каждый блэйд
Деятельность по проверке терминалов	Мастер MGw	Каждый блэйд

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

На фиг.4 показаны примеры, когда информация хранится мастером, партнером и контроллером вызовов. Первой записью в списке занятых схем мастера 112a маршрута является "B-1; CIC-12". Это означает, что CIC с номером 12 был предоставлен в пользование контроллеру вызовов на блэйде 1.