Объединение ресурсов в сервере центра коммутации с кластером с электронными платами
Настоящее изобретение относится к серверу центра коммутации, содержащему: кластер блэйдов с множеством блэйдов, множество объединенных ресурсов, доступных упомянутому множеству блэйдов для обработки вызова, и мастер, обеспечиваемый на одном из блэйдов, централизованно координирующий использование объединенных ресурсов, причем мастер как центральная инстанция ответственен за размещение, перераспределение и обслуживание объединенных ресурсов. При выходе из строя одного или более блэйдов изобретение обеспечивает механизмы сохранения минимального влияния на текущие вызовы и сохранения объединенных ресурсов доступными для остальных блэйдов, что является техническим результатом. 2 н. и 19 з.п. ф-лы, 19 ил., 1 табл.
Область техники, к которой относится изобретение
Настоящее изобретение относится к серверу центра коммутации, обрабатывающему вызовы. В частности, но не исключительно, изобретение относится к серверу центра коммутации мобильной связи (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. На том же самом блэйде контроллер вызовов имеет запись "R-A; CIC-12", что означает, что один и тот же CIC маршрута A предоставлен в пользование. Так как мастер 112a и контроллер 111 вызовов постоянно находится на одном и том же блэйде, маршрут А партнера 113a на блэйде 2 также имеет запись: "B-1; CIC- 12", указывая, что CIC-12 был предоставлен в пользование контроллеру вызовов на блэйде 1.
В примере, показанном на фиг.4, контроллер 111-1 вызовов на блэйде 1 дополнительно имеет полученную в пользование схему 25 для маршрута A. Поскольку мастер 112a маршрута, содержащий информацию о занятой схеме 25, также содержится на блэйде 1 для маршрута A, партнер 113a дополнительно имеет запись о занятой схеме CIC-25, используемой блэйдом 1. Партнер 113c маршрута С имеет запись, что на блэйде 3 схема 34 занята, поскольку контроллер вызовов для схемы 34 и мастер 112c маршрута С оба обеспечиваются на одном и том же блэйде, а именно, на блэйде 3. То же самое действительно для партнера 113b маршрута В, содержащего информацию, что на блэйде 2 схема 18 занята для маршрута В, информация, которая в противном случае предоставляется на блэйде 2 в контроллере 111-2 вызовов и мастере 112b маршрута В. В других показанных примерах информация о предоставленных в пользование схемах и занятых схемах обеспечивается на двух различных блэйдах, так что в дополнительной информации у партнера нет необходимости.
Восстановление при отказе блэйда
Как только блэйд выходит из активного состояния, любые роли мастера и партнера, которые они имели, теряются. Для ролей мастера и партнера должны быть организованы замены.
Обработка ресурсов, полученных в пользование отказавшим блэйдом, различается в зависимости от того, выполняет ли он процедуру восстановления с сохранением вызова или без сохранения вызова. Другим блэйдам сообщается, если вызов, который управляется отказавшим блэйдом, может быть сохранен.
Действия, выполняемые другими блэйдами при одиночном отказе блэйда
Установка в исходное состояние устройств и терминалов
Восстановление блэйда с потерей текущих вызовов:
Мастер маршрута знает, какой CIC, а мастер PRA знает, какие каналы используются отказавшим блэйдом. Как только известно, что блэйд отказал и что он не выполняет восстановление с сохранением вызова, CIC/каналы и подключенные терминалы TDM, которые использовались отказавшим блэйдом, устанавливаются в исходное состояние (новым) мастером маршрута/PRA. Временные терминалы удаляются мастером MGw, используя механизм группового символа, идентифицирующий терминалы, используемые восстанавливаемым блэйдом.
Восстановление блэйда, позволяющее сохранение вызова:
Мастер принимает от восстанавливаемого блэйда информацию о том, какие CIC/каналы все еще используются и какие CIC/каналы больше не используются, причем от того блэйда, который выполнил процедуру восстановления с сохранением вызова. Затем мастер устанавливает в исходное состояние те CIC/каналы, которые больше не используются, и посылает на MGw команды удаления GCP в отношении соответствующих терминалов TDM и временных терминалов. Здесь для удаления временных терминалов механизм группового символа не может использоваться.
Мастер медиашлюза находился на отказавшем блэйде
Роль мастера MGw назначается другому блэйду. Текущие вызовы не затрагиваются.
Мастер маршрута/PRA находился на отказавшем блэйде, партнер работает
Каждый блэйд принимает уведомление об изменении состояния других блэйдов в кластере. Роли мастера и партнера, которые были назначены на отказавшем блэйде, теперь назначены другим блэйдам. Каждый блэйд посылает новому мастеру первый список CIC/каналов, которые предоставлены в пользование. Блэйды, которые пока возложили роль партнера на мастера на отказавшем блэйде, дополнительно посылают второй список CIC/каналов, которые были предоставлены в пользование мастерам на отказавшем блэйде, чтобы управлять вызовами, размещенными на собственном блэйде. Новый партнер должен быть создан для каждого из новых мастеров и должны быть обновлены данные занятости CIC/каналов, которые в настоящее время предоставлены в пользование пользователями на блэйде, на котором постоянно находится новый мастер, а также данные, принятые от предыдущего партнера. Новый мастер и мастер MGw затем выполняют установку в исходное состояние устройств и терминалов, как описано выше.
Партнер находился на отказавшем блэйде, мастер исправен
Создается новый партнер и текущий мастер посылает копию списка CIC/каналов, которые управляются его собственным блэйдом новому партнеру. Какое-либо воздействие на обработку трафика или эксплуатационную деятельность отсутствует.
Действия, выполняемые другими блэйдами при отказе нескольких блэйдов
Никакой блэйд не выполняет восстановление блэйда с сохранением вызова
Роли мастера и партнера, которые стали свободными из-за отказа блэйда, переназначаются другим блэйдам.
Если два блэйда выходят из строя одновременно, то некоторые устройства будут терять контроллер вызовов и мастера. Если никакой блэйд не выполняет процедуру восстановления блэйда с сохранением вызова, то новый мастер может идентифицировать, какие схемы/каналы не используются никаким блэйдом. При создании нового мастера все блэйды посылают список схем, которые они предоставили в пользование новому мастеру. Схемы, которые не указаны как предоставленные в пользование никаким блэйдом, являются либо простаивающими, либо предоставленными в пользование любым из перезапущенных блэйдов, они находятся в неизвестном состоянии.
Из-за двойного отказа блэйдов новый мастер не может определить, какие из этих схем являются простаивающими и какие из них предоставлены в пользование для вызовов, которые, как предполагается, разорваны. Он должен установить в исходное состояние все эти схемы/каналы и удалить соответствующие терминалы.
Для промежутка времени, в котором устройства находятся в неизвестном состоянии, мастер маршрута/PRA не может предоставлять их в пользование для новых вызовов. Устройства, которые какой-либо блэйд вернул после предоставления в пользование, находятся в известном состоянии и могут быть немедленно назначены новым вызовам.
Любые запросы о занятии, которые не могут быть обслужены таким образом, помещаются в буфер (FIFO) и обрабатываются, пока не будут доступны устройства, известные как простаивающие (IDLE). При переполнении буфера самые старые запросы о занятии удаляются.
Новый партнер назначается для каждого мастера маршрута/PRA, у которого партнер находился на отказавшем блэйде. Новый партнер будет загружен с состоянием занятости CIC/каналов, которые предоставлены в пользование для вызовов, управляемых блэйдом, на котором постоянно находится (новый) мастер.
Один или более блэйдов выполняют восстановление блэйда с сохранением вызова
Если какой-либо блэйд выполняет процедуру восстановления, которая может в результате привести к тому, что вызовы будут сохранены, то активными блэйдами не может быть сделано никакое предположение о том, какие схемы/каналы, полученные ими в пользование, могут быть установлены в исходное состояние. До восстановления блэйда следует решить, какие вызовы сохраняются. В конце процедуры восстановления мастер принимает информацию о том, какие схемы/каналы должны быть установлены в исходное состояние из-за разрыва вызовов.
Когда блэйд, выступающий в роли мастера, отказывает в то же самое время, что и другой блэйд, он один или они оба выполняют процедуру восстановления с сохранением вызовов и тогда вновь назначенный мастер не в состоянии сказать, какие из схем, о которых не сообщается остальными блэйдами, простаивают и какие заняты блэйдом(-ами), выполняющим такую процедуру восстановления. Он не может поэтому установить в исходное состояние никакие из тех схем, состояние которых неизвестно, пока не станет известно, что больше никакая процедура восстановления с сохранением вызова не будет продолжаться.
Для промежутка времени, когда устройства находятся в неизвестном состоянии, мастер маршрута/PRA не может прекращать предоставление их в пользование для новых вызовов. Устройства, которые любой блэйд возвращает при прекращении предоставления в пользование, находятся в известном состоянии и могут быть назначены новым вызовам, если они не заблокированы.
Любые запросы о занятии, которые не могут быть обслужены таким образом, помещаются в буфер (FIFO) и обрабатываются, пока не будут доступны устройства, которые известны как простаивающие. При переполнении буфера самые старые запросы занятия удаляются.
Новый партнер будет определен для тех мастеров маршрута/PRA, которые имеют партнера на любом отказавшем блэйде. Новый партнер будет загружен с состоянием занятости CIC/каналов, которые предоставлены в пользование для вызовов, управляемых блэйдом, на котором постоянно находится (новый) мастер.
Партнеры потерянных мастеров на блэйдах, которые выполняют восстановление без сохранения вызова, посылают новым мастерам списки схем, которые потерянные мастера предоставили в пользование для управления размещенными вызовами. Новые мастера могут немедленно установить эти каналы в исходное состояние, удалить подключенные терминалы и использовать их повторно.
Действия, выполняемые блэйдом, выполняющим восстановление с сохранением вызова
Распределение ролей
Действия по восстановлению блэйда, которые позволяют сохранить вызовы, немедленно освобождают мастера или партнера от любых ролей, которые они имели до того, как произошло восстановление. Во время восстановления не существует никакой информации, передаваемой от восстанавливаемого блэйда новому мастеру или партнеру (или любому другому блэйду).
CIC/каналы, имеющие мастера на другом, но восстанавливаемом блэйде
Любое предоставление в пользование CIC/каналов мастерами в направлении восстанавливаемого блэйда остается действительным. То есть, он сам определяет, какие вызовы сохранить и какие разорвать. В конце процедуры восстановления восстанавливаемый блэйд посылает мастеру маршрута/PRA информацию о том, какие схемы/каналы должны быть установлены в исходное состояние из-за разрыва вызовов.
Восстанавливаемый блэйд не может сообщить состояние CIC/каналов, для которых запрос о занятости был послан на блэйд, где постоянно находится мастер, но никакое подтверждение не было получено. Могло случиться так, что запрос о занятости был потерян во время процедуры восстановления, но могло также случиться и так, что подтверждение было потеряно. Связанные с этим вызовы должны быть разорваны и запрашиваемый CIC/канал также требуется освободить. Мастер будет принимать освобождение CIC/канала, только если он был принят от того же самого блэйда, который занял ресурс. Эта предосторожность необходима, так как CIC/channel может быть занят другим блэйдом, если заподозренная занятость никогда не была осуществлена мастером.
Восстанавливаемый блэйд не может сообщить состояние CIC/каналов, для которых был послан запрос освобождения, но никакое подтверждение не было получено. Могло случиться так, что запрос освобождения был потерян во время восстановления, но могло также случиться так, что подтверждение было потеряно. Сопутствующие вызовы должны быть разорваны и восстанавливаемый блэйд снова запрашивает CIC/канал, который должен быть освобожден. Мастер будет принимать запрос освобождения CIC/канала, только если он был принят от того же самого блэйда, который занял ресурс. Эта предосторожность необходима, так как CIC/канал может быть занят другим блэйдом, если заподозренное освобождение было выполнено мастером. Мастер допускает попытку освобождения CIC/канала, который не находится в занятом состоянии.
Действия, производимые блэйдом, выполняющим восстановление без сохранения вызова
Любое предоставление в пользование ресурсов этим блэйдом становится недействительным. Восстанавливаемый блэйд не сообщает мастеру ни о каких CIC/каналах. Восстанавливаемый блэйд удаляет все вызовы, но не посылает сообщений установки в исходное состояние и команд на удаление.
Пример восстановления блэйда с сохранением вызова
На последующих чертежах показана обработка маршрутов; обработка PRA выполняется в соответствии с теми же самыми принципами.
На фиг.5 представлен кластер с четырьмя блэйдами. Блэйд 2 выходит из активного состояния, чтобы выполнить действие восстановления. Во время восстановления никакая связь с другими блэйдами невозможна. Тип восстановления не позволяет сохранять никакие вызовы, управляемые этим блэйдом.
Мастер 112a маршрута А постоянно находится на блэйде 1. Он устанавливает в исходное состояние все схемы, которые были предоставлены в пользование блэйду 2. В данном примере это только CIC-50. Мастер маршрута А посылает на MGw команду удаления для терминала, подключенного к CIC-50 маршрута А.
Мастер 112c маршрута C постоянно находится на блэйде 3. Он устанавливает в исходное состояние все схемы, которые были предоставлены блэйду 2. В данном примере это только CIC-98. Мастер маршрута С посылает на MGw команду удаления для терминала, подключенного к CIC-98 маршрута С.
Роль мастера для маршрута В должна быть переназначена, потому что ранее она была назначена блэйду 2. Теперь она назначается блэйду 3. Всякий раз, когда роль мастера переназначается, роль партнера переназначается тоже. Роль партнера для маршрута В теперь назначается блэйду 1.
Роль партнера для маршрута А необходимо переназначить, потому что ранее она была назначена блэйду 2. Теперь она назначается блэйду 4.
На фиг.6 показано, как новый мастер 112b маршрута В теперь принимает состояния CIC от контроллеров вызовов всех блэйдов, находящихся в активном состоянии. CIC-36 предоставляется в пользование управлением 111-3 вызовами на том же самом блэйде, и CIC-08 предоставляется в пользование управлением 111-1 вызовами на блэйде 1. Прежний партнер 113b маршрута В сообщает новому мастеру 112b маршрута В, что CIC-18 был предоставлен в пользование блэйду 2. Чтобы поддерживать эту информацию избыточной на двух блэйдах в любое время, новый мастер передает эти данные новому партнеру, как показано на фиг.7. Прежний партнер сохраняет данные до тех пор, пока вся последовательность перемещения роли не будет успешно завершена. Новый мастер устанавливает в исходное состояние все каналы, которые были предоставлены в пользование блэйду 2. В данном примере это только CIC-18. Новый мастер посылает на MGw команду удаления для терминала, подключенного к CIC-18 маршрута А.
Новый мастер 112b маршрута В сообщает обо всех схемах, предоставленных в пользование контроллерам вызовов на собственном блэйде, новому партнеру 113b маршрута В. В примере, показанном на фиг.7, это - CIC-36.
На фиг.7 показано, как мастер 112a маршрута А подает данные, связанные с вызовами, управляемыми собственным блэйдом, своему новому партнеру 113a. В данном примере, это - CIC-12.
Пример восстановления блэйда с сохранением вызова
Этот пример показывает обработку маршрутов; обработка PRA делается в соответствии с теми же принципами.
На фиг.15 показан кластер с четырьмя блэйдами. Блэйд 2 выходит из активного состояния, чтобы выполнить действие восстановления. Во время восстановления никакая связь с другими блэйдами невозможна. Тип восстановления позволяет сохранять вызовы, управляемые этим блэйдом. Некоторые вызовы, не считающиеся стабильными, будут разорваны. Другие блэйды не могут сообщить, какие вызовы будут сохранены, пока не закончится восстановление блэйда.
Мастер 112a маршрута А постоянно находится на блэйде 1. Ему известны все каналы, которые были предоставлены в пользование блэйду 2. В данном примере это только CIC-50. Предоставление в пользование продолжается. Мастер 112c маршрута C постоянно находится на блэйде 3. Ему известны все схемы, которые были предоставлены в пользование блэйду 2. В данном примере это только CIC-98. Предоставление в пользование продолжается.
Роль мастера 112b для маршрута В должна быть переназначена, потому что ранее она была назначена блэйду 2. Теперь она назначена блэйду 3. Всякий раз, когда роль мастера переназначается, роль партнера переназначается тоже. Роль партнера для маршрута В теперь назначена блэйду 1.
На фиг.16 показано, как новый мастер маршрута В теперь принимает состояния CIC от контроллеров вызовов всех блэйдов, находящихся в активном состоянии. CIC-36 предоставлен в пользование управлением вызовами на том же самом блэйде и CIC-08 предоставлен в пользование управлением вызовами на блэйде 1.
Прежний партнер 113b маршрута В сообщает новому мастеру 112b, что CIC-18 был предоставлен в пользование блэйду 2. Предоставление в пользование продолжается.
Чтобы поддерживать эту информацию избыточной на двух блэйдах в любое время, новый мастер передает эти данные новому партнеру, как показано на фиг.17. Прежний партнер сохраняет данные до тех пор, пока вся последовательность перемещения роли не будет успешно завершена.
Роль партнера для маршрута А необходимо переназначить, потому что ранее она была назначена блэйду 2. Теперь она назначена блэйду 4. На фиг.17 показано, как мастер 112a маршрута А подает данные, связанные с вызовами, управляемые его собственным блэйдом, своему новому партнеру 113a. В данном примере, это - CIC-12.
В конце процедуры восстановления контроллер вызовов на блэйде 2 сообщает мастерам маршрута о схемах, которые должны быть установлены в исходное состояние, потому что вызов, который их использовал, был разорван из-за процедуры восстановления, смотрите фиг.18. Соответствующий мастер должен установить в исходное состояние такие схемы и удалить соответствующий терминал.
Создание мастера и партнера
Точка запуска создания
Когда пригодный для распространения объект определен на всех активных блэйдах, координатор выбирает, какому блэйду назначить роли мастера и партнера. Все блэйды, находящиеся в активном состоянии, информируются посредством широковещательного сообщения. Если только один блэйд в кластере находится в активном состоянии, то никакой партнер не может быть создан. В такой ситуации партнер будет создан координатором позже, как только будет доступен второй блэйд.
Другой запуск создания мастера и партнера происходит, когда блэйд, который выступает в роли мастера, выходит из активного состояния без предшествующего успешного перемещения.
Создание мастера и партнера также запускается, когда координатор решает, что текущее создание потерпело неудачу из-за истечения времени ожидания.
Алгоритм распределения ролей
Алгоритм распределения ролей мастера и партнера должен удовлетворять следующим критериям:
Данные обмена для объекта должны быть определены на целевом блэйде.
Мастер и партнер одного и того же распределенного объекта никогда не должны распределяться на одном и том же блэйде.
Загрузка обработки должна быть распределена по всем блэйдам, так чтобы все блэйды были загружены с одним и тем же процентом от их индивидуальной емкости.
Создание мастера и партнера
Координатор решает, какие блэйды должны выступать в роли мастера и партнера. Последовательность показана на фиг.8. Для MGw не существует никакой передачи данных от мастера к партнеру. Этапы, которые не применяются к объектам MGW, указывают в приведенном ниже поэтапном описании.
Когда мастер и партнер созданы, нет никакого способа узнать, существовал ли мастер и партнер прежде. Вызовы могут продолжаться, и вызовы, возможно, были разорваны в отсутствии мастера и партнера. Запросы освобождения предоставленных в пользование ресурсов, помещенные в буфер на блэйде, управляющим вызовом, могут быть потеряны из-за процедур восстановления этого блэйда. Поэтому вероятность, что схемы и терминалы предоставлены в пользование отказавшим блэйдом и способны зависать, не может быть исключена. Как средство восстановления, любой ресурс, который не имеет известного потребителя, должен быть установлен в исходное состояние, если действие восстановления с сохранением вызова не проводится на блэйде, не ведущим обработку трафика.
Этап 1: Активный блэйд с наименьшим возрастным рангом всегда имеет роль координатора. Это определяет блэйды, которые должны играть роли нового мастера и нового партнера.
Затем координатор запускает процедуру создания с помощью передачи группового сообщения NEW_MASTER всем активным блэйдам. Роли, таким образом, назначаются без последующего сообщения подтверждения.
Этап 2: Этот этап не применяется к MGw. Новый мастер теперь подготовлен для приема данных от других блэйдов. Мастер компилирует данные, принятые от других блэйдов, чтобы построить полную таблицу занятости/незанятости для всех ресурсов, за которые он ответственен.
Этап 3: Этот этап не применяется к MGw. С помощью сообщения TRANSFER все блэйды, находящиеся в активном состоянии, за исключением того, который играет роль мастера, предоставляют свои данные, необходимые новому мастеру для выполнения роли мастера.
Этап 4: Этот этап не применяется к MGw. Мастер обеспечивает партнеру копию данных, относящихся к управлению вызовами на его собственном блэйде, посылая сообщение UPDATE BUDDY.
Этап 5: С помощью сообщения BUDDY_READY партнер указывает мастеру, что он принял и сохранил данные от мастера и что он готов взять на себя роль партнера.
Этап 6: Новый мастер рассылает групповое сообщение CHANGE_MASTER всем активным блэйдам. Теперь новый мастер должен установить в исходное состояние все ресурсы, которые, возможно, были предоставлены в пользование его предшественником (и, возможно, другие блэйды, которые вышли из активного состояния во время отсутствия мастера). Новый мастер должен ждать до тех пор, пока все блэйды перестанут выполнять восстановление с сохранением вызова, и затем, в зависимости от типа ресурсов, за которые он ответственен, установить в исходное состояние все схемы, В-каналы или удалить все терминалы, которые в настоящее время не предоставляются в пользование никакими блэйдами, в том числе, его собственным. Механизм работы с окнами должен быть осуществлен, чтобы регулировать поток массива субтрактовых сообщений для предотвращения перегрузки MGw.
Перемещение мастера и партнера
Общие положения
Чтобы сбалансировать нагрузку на процессор и нагрузку, создаваемую сигнализацией между блэйдами, может оказаться необходимым переместить роль мастера для индивидуального маршрута, PRA или MGw на другой блэйд.
Другим поводом для перемещения роли мастера является то, что координатор обнаруживает, что блэйд выходит из активного состояния. Координатор затем запускает перемещение ролей любого мастера или партнера, которые играют блэйды, на другие блэйды. Если не существует никакого активного блэйда, на который мастер может быть перемещен, то прежний мастер, в конечном счете, прекращает существовать и роль мастера становится свободной.
Любая последовательность перемещения мастера на другой блэйд должна быть устойчивой против неработоспособности любого блэйда в любой момент времени. Протокол, несущий соответствующие сообщения, обеспечивает средство получения позитивного подтверждения, что все намеченные блэйды получателя приняли определенное сообщение. Блэйд, возвращаемый после отказа, должен получить самый последний статус от любого другого блэйда. Если восстанавливаемый блэйд не играет жизненно важную роль в процессе перемещения, такой случай не должен нарушать перемещение. Носитель протокола должен гарантировать глобальный порядок кластеров, то есть, сообщения, посланные через этот носитель, всегда принимаются в одном и том же порядке на всех блэйдах.
Чтобы сократить количество потенциально ошибочных сценариев, количество сообщений, посылаемых между блэйдами, поддерживается на минимуме.
В течение продолжительности перемещения мастера маршрута/PRA для соответствующего маршрута/PRA новые вызовы не могут быть установлены. Перемещение мастера MGw не приводит ни к какому нарушению трафика.
Перемещение инициируется с блэйда координатора посредством групповой передачи сообщения MOVE_MASTER. Оно заканчивается либо передачей группового сообщения CHANGE_MASTER или NOT-MOVED, либо когда один из блэйдов, назначенных для роли мастера или партнера, выходит из активного состояния. Подробности описаны в последующих главах.
Если один или более блэйдов недоступны или если существует ситуация разбиения центрального процессора в кластере, никакая широковещательная или групповая передача невозможна. Размещение мастеров и партнеров будет зафиксировано, потому что перемещения не могут быть ни начаты, ни закончены. Как следствие, если и мастер и партнер испытывают отказ одновременно или последовательно, то роль будет освобождаться и соответствующий объект не может более использоваться системой. Как только связь снова возможна, координатор запустит создание мастера и партнера.
Успешное перемещение роли мастера
Последовательность связи между блэйдами является той же самой, что для создания мастера и партнера, показанной на фиг.8. После приема сообщения NEW_MASTER текущий мастер приостанавливает свою роль до тех пор, пока последовательность либо успешно заканчивается, либо прерывается.
Во время последовательности перемещения не существует никаких данных, передаваемых между прежним и новым партнером. Новый партнер будет хранить совершенно другой набор данных, чем прежний партнер, потому что мастер размещается на другом блэйде. Прежний партнер будет хранить данные до тех пор, пока не закончится последовательность перемещения; если последовательность прерывается, то распределение ролей возвращается к тому назначению, которое было действительным до перемещения.
Обработка запросов обслуживания во время перемещения мастера
Обработка вызовов продолжается во время перемещения мастера. В течение времени, когда данные передаются между прежним и новым мастером, контроллер вызовов может захотеть получить в пользование схему/канал или освободить их. Процедура перемещения должна быть разработана с особым вниманием, чтобы избежать несогласованностей, которые могут быть вызваны модификацией данных, перемещаемых на новый блэйд. Перемещение заканчивается только когда адресат взял на себя роль мастера. До этого момента оно может прерваться в любое время из-за действий восстановления или выхода из строя блэйда адресата. Данные должны оставаться непротиворечивыми также и в таком сценарии.
Чтобы избежать несогласованностей, запросы обслуживания, которые связаны с перемещенным объектом и влияют на переданные данные, помещаются в буфер на все время перемещения.
На фиг.9 показана обработка запросов обслуживания во время перемещения роли мастера. Помещение в буфер выполняется блэйдом, управляющим вызовом, между приемом сообщений NEW_MASTER и CHANGE_MASTER на блэйде мастера.
Этап 1: Занятость может быть опробована для вызовов, управляемых блэйдом прежнего мастера. Блэйд ждет до тех пор, пока не будет принято сообщение CHANGE_MASTER, прежде чем обработать запрос.
Этап 2: Занятость может быть опробована для вызовов, управляемых другими блэйдами. Этот блэйд ждет, пока не будет принято сообщение CHANGE_MASTER.
Этап 3: При приеме сообщения CHANGE_MASTER блэйд, управляющий вызовом, который выполнял роль прежнего мастера, посылает помещенные в буфер сообщения SEIZURE_REQUEST на блэйд нового мастера.
Этап 4: При приеме сообщения CHANGE_MASTER любой блэйд, управляющий вызовом, посылает помещенные в буфер сообщения SEIZURE_REQUEST на блэйд нового мастера.
Особые сценарии во время явного перемещения роли мастера
Принцип состоит в том, что в любое время все блэйды обладают достаточной информацией, чтобы определить, продолжается ли еще перемещение или, если оно закончилось, то успешно или нет. На фиг.10 показан конечный автомат, связанный с перемещением, который поддерживается на каждом активном блэйде для всех мастеров. Переходы запускаются посылкой или приемом упомянутых сообщений.
В дальнейшем последствия выходов из строя блэйда и проблемы связи описываются со ссылкой на фиг.11.
Если мастер или партнер имеют отказ на временном отрезке, который заштрихован на фиг.11, то перемещение прерывается.
Время ожидания операции перемещения
Все блэйды ведут контроль времени для каждой текущей операции перемещения. Во времени ожидания координатор будет пытаться создать нового мастера и партнера, повторяя процедуру, начинающуюся с MOVE_MASTER. Предпочтительно, он попытается разместить роли на других блэйдах, отличных от прежних.
Перемещения роли координатора
Роль координатора перемещается, только если блэйд, выступающий в роли текущего координатора, выходит из активного состояния. Если перемещение роли координатора произошло в любое время до приема сообщения CHANGE_MASTER, то оно не оказывает никакого воздействия на последовательность перемещения мастера. Все остальные блэйды в активном состоянии имеют достаточную информацию, чтобы принять на себя роль координатора в любое время. Остающийся блэйд с наименьшим возрастным рангом, то есть, тот, который был в активном состоянии в течение самого долгого времени, возобновит роль координатора. Он будет знать о текущем перемещении, так как он принял сообщение MOVE_MASTER таким же образом, как это сделали все другие. Он не должен запускать никакое дополнительное действие по повторному балансированию, прежде чем текущее перемещение успешно или неудачно закончится. Он будет использовать уже работающие контрольные таймеры на собственном блэйде для текущих последовательностей перемещения.
Новый блэйд становится активным во время перемещения
Блэйд, который хочет присоединиться к активному состоянию, должен принять текущее состояние и размещение мастеров и партнеров от блэйда с наименьшим возрастным рангом в сообщении ALLOCATION_TABLE. Он будет знать, ведется ли перемещение в настоящее время, и будет введен в список получателей сообщения CHANGE_MASTER, поскольку новому мастеру стало известно об изменении состояния нового пользователя через блок обслуживания групповой связи кластера.
Другой блэйд изменяет состояние во время перемещения
Тот факт, что блэйд, который не назначен ни в качестве мастера, ни в качестве партнера, изменил состояние блэйда, не влияет на последовательность перемещения.
Назначенный мастер или партнер выходят из активного состояния во время перемещения
Все блэйды, находящиеся в активном состоянии, информируются службой обработчика кластера, если любой из блэйдов, владеющий ролью нового мастера или нового партнера, выходит из активного состояния. Если это случается в течение отрезка времени, показанного заштрихованным на фиг.11, то есть, если остающиеся блэйды не приняли сообщение CHANGE_MASTER к этому времени, они будут прерывать перемещение и действовать, как если бы сообщение MOVE_MASTER никогда не было принято. Если информация поступает после приема сообщения CHANGE_MASTER, перемещение рассматривается как успешно законченное и предпринимаются обычные действия восстановления при выходе из строя мастера.
Широковещательная или групповая передача невозможна
Если сообщение MOVE_MASTER уже послано и широковещательная или передача групповых сообщений NOT_MOVED или CHANGE_MASTER невозможна, координатор будет обнаруживать время ожидания операции перемещения и применяется описанная выше обработка. Неспособность перемещения роли мастера может, в конечном счете, уменьшить емкость и/или связность узла. Система будет восстанавливаться из этого состояния, как только связь снова будет возможна.
Перемещение партнера
Общие положения
Чтобы сбалансировать нагрузку на процессор и нагрузку, создаваемую сигнализацией между блэйдами, может оказаться необходимым переместить роль партнера для индивидуального маршрута, PRA или MGw на другой блэйд. Перемещение партнера возможно, только если, по меньшей мере, три блэйда находятся в активном состоянии: один - для мастера, один - для роли текущего партнера и еще один - как цель для перемещения партнера.
На блэйде, выступающем в роли мастера, новые вызовы не могут быть установлены для соответствующего маршрута/PRA, пока продолжается перемещение партнера. Причина здесь состоит в том, что в противном случае состояние схемы/канала не может поддерживаться избыточным на двух разных блэйдах. Перемещение партнера MGw не приводит ни к какому нарушению трафика.
Координатор будет обнаруживать, что блэйд выходит из активного состояния, и запустит перемещение на другие блэйды любых ролей мастера или партнера, которые возложены на этот блэйд. Если не имеется никакого блэйда в активном состоянии, на который может быть перемещен партнер, то прежний партнер прекратит существовать и роль партнера будет становиться свободной.
Любая последовательность перемещения партнера на другой блэйд должна быть устойчивой против неработоспособности любого блэйда в любой момент времени. Групповое обслуживание связи обеспечивает средство получения положительного подтверждения, что все намеченные блэйды получателя приняли определенное сообщение. Блэйд, возвращающийся в активное состояние, должен будет принимать самую последнюю информацию о распределении от координатора с помощью сообщения ALLOCATION_TABLE.
Чтобы сократить количество потенциально ошибочных сценариев, количество сообщений, посылаемых между блэйдами, поддерживается на минимуме.
Успешное перемещение роли партнера
На фиг.12 показана последовательность сообщений без вмешательства запросов обслуживания или сценариев ошибки.
Этап 1: Блэйд, находившийся в активном состоянии в течение самого длительного времени, (координатор) определяет, какой партнер должен быть перемещен и в какое место назначения он должен быть перемещен. Затем он запускает процедуру передачи группового сообщения MOVE_BUDDY на все блэйды, находящиеся в активном состоянии.
Этап 2: Блэйд, на котором постоянно находится мастер, компилирует все данные, необходимые новому партнеру, и посылает их в сообщении UPDATE_BUDDY назначенному партнеру.
Этап 3: Мастер должен позаботиться, чтобы текущие процессы не повлияли на данные, которые должны быть переданы новому партнеру; в противном случае, новый партнер может пропустить соответствующую информацию. Такие запросы происходят только от контроллера вызовов, расположенных на том же самом блэйде. Блэйд, на котором постоянно находится мастер, помещает в буфер такие запросы на занятие или освобождение и между приемом MOVE_BUDDY и CHANGE_BUDDY не посылает никаких сопутствующих сообщений обновления партнеру на блэйд партнера.
Этап 4: Инстанция обслуживания на электронной плате нового партнера затем проводит передачи группового сообщения CHANGE_BUDDY на все блэйды, находящиеся в активном состоянии. Блэйд прежнего партнера принимает сообщение CHANGE_BUDDY как индикацию, что блэйд потерял роль партнера. Он удаляет все данные партнера, которые хранились на случай, если перемещение окажется неудачным.
Этап 5: Когда блэйд мастера принимает сообщение CHANGE_BUDDY, он запускает обработку запросов обслуживания от собственного контроллера вызовов. Он посылает сообщение UPDATE_BUDDY на блэйд нового партнера для любого измененного состояния CIC.
Сценарии отказа во время перемещения роли партнера
Принцип состоит в том, что в любое время все блэйды имеют достаточную информацию, чтобы определить, продолжается ли все еще перемещение или, если оно закончилось, то было ли оно успешным или нет. На фиг.13 показан связанный с перемещением конечный автомат, который поддерживается на каждом активном блэйде для всех партнеров. Переходы запускаются посылкой или приемом названных сообщений или изменениями состояния блэйда.
Все блэйды, находящиеся в активном состоянии, информируются службой обработчика кластера, если какой-либо из блэйдов, владеющий ролью нового мастера или нового партнера, выходит из активного состояния. Если это случается в течение отрезка времени, показанного штриховкой на фиг.14, то есть, если остающиеся блэйды не приняли сообщение CHANGE_BUDDY к этому времени, они будут прерывать перемещение и действовать, как если бы сообщение MOVE_BUDDY никогда не было принято. Если информация поступает после приема сообщения CHANGE_BUDDY, перемещение рассматривается как успешно законченное и предпринимаются обычные действия восстановления при выходе из строя.
Далее обсуждаются возможности для каждой роли, которой может владеть блэйд.
Время ожидания операции перемещения
Все блэйды ведут контроль времени для каждой текущей операции перемещения. Во время ожидания координатор будет пытаться создать нового партнера, повторяя процедуру, начинающуюся с сообщения MOVE_BUDDY. Мастер будет знать, что текущее перемещение прошло неудачно, когда он принимает сообщение BUDDY_NOT_MOVED или когда он принимает сообщение MOVE_BUDDY, не получив перед этим сообщение BUDDY_NOT_MOVED или CHANGE_BUDDY. Нет никакой необходимости разрывать какие-либо вызовы, поскольку информация, которая должна быть послана партнеру, все еще находится в буфере, помещенная туда мастером и прежним партнером.
Потеря координатора
Если в любое время до приема сообщения CHANGE_BUDDY координатор перемещается (при условиях, описанных выше), это не должно оказывать никакого воздействия на последовательность перемещения. Все блэйды в активном состоянии имеют достаточную информацию, чтобы в любое время принять на себя роль координатора. Остающийся блэйд, который в течение самого долгого времени находился в активном состоянии, возобновит роль координатора. Он будет знать о продолжающемся перемещении, так как принял сообщение MOVE_BUDDY таким же образом, как это сделали все другие. Он будет использовать уже запущенные таймеры контроля на собственном блэйде для продолжающихся операций перемещения.
Новый блэйд переходит в активное состояние во время перемещения
Блэйд, который хочет перейти в активное состояние, должен получить информацию о состоянии и размещении мастеров и партнеров от блэйда координатора с помощью сообщения ALLOCATION_TABLE. Он будет знать, продолжается ли перемещение и будет внесена в список получателей сообщения CHANGE_BUDDY, потому что новый партнер становится знающим об изменении состояния.
Другой блэйд изменяет состояние во время перемещения
Тот факт, что блэйд, который не выступает ни в роли мастера, ни в роли назначенного партнера, изменил состояние блэйда, не влияет на перемещение.
Прежний партнер недоступен в начале перемещения
Последовательность является той же самой, как если бы партнер был доступен.
Прежний партнер потерян во время перемещения
Если прежний партнер выходит из активного состояния, то перемещение продолжится оставаться незатронутым. При отказе во время перемещения роль партнера станет свободной. Координатор затем попытается назначить нового партнера.
Назначенный партнер потерян во время перемещения
Всем блэйдам сообщается, если блэйд, взявший на себя роль назначенного партнера, выходит из активного состояния. Если к тому времени они не приняли сообщение CHANGE_BUDDY, они будут действовать, как если бы никакое перемещение никогда не предпринималось. Если информация поступает после приема сообщения CHANGE_BUDDY, предпринимаются обычные действия восстановления, выполняемые при выходе из строя партнера, то есть, координатором будет создан новый партнер.
Мастер потерян во время перемещения
Всем блэйдам сообщается, если блэйд, выступающий в роли мастера, выходит из активного состояния. Если мастер становится недоступным в любое время до того, как послано сообщение CHANGE_BUDDY, то перемещение партнера прерывается и блэйды будут действовать так, как если бы никакое перемещение никогда не предпринималось.
Широковещательная или групповая передача невозможна
Если сообщение MOVE_BUDDY уже послано и широковещательная или групповая передача сообщений NOT_MOVED или CHANGE_BUDDY невозможна, координатор будет обнаруживать время ожидания операции перемещения и применяется описанная выше обработка. Система будет восстанавливаться из этого состояния, как только связь снова будет возможна.
Подводя итоги, изобретение позволяет масштабируемой системе блэйдов распределять инстанции объектов, которые координируют распределение общих ресурсов по индивидуальным блэйдам. Распределение делается динамическим способом, который адаптируется к изменению состояний блэйда и к изменению количества блэйдов. В любое время гарантируется избыточность информации.
1. Сервер центра коммутации, содержащий:
- кластер с блэйдами со множеством блэйдов (110),
- множество пулов ресурсов, доступных упомянутому множеству блэйдов (110), и
- мастер для каждого пула (112) ресурсов, обеспечиваемого на одном из блэйдов, централизованно координирующего использование объединенных в пул ресурсов, отличающийся тем, что дополнительно содержит контроллер (111) вызовов, обеспечиваемый на одном из блэйдов, управляющий ресурсами в течение длительности упомянутого вызова.
2. Сервер центра коммутации по п.1, в котором кластер с блэйдами сконфигурирован таким образом, что информация об используемых ресурсах для вызова обеспечивается на двух разных блэйдах (110).
3. Сервер центра коммутации по п.1, дополнительно содержащий партнера (113) мастера (112) на одном из блэйдов, на котором мастер не обеспечивается, причем партнер (113) содержит информацию о ресурсах, управляемых контроллером вызовов, находящимся на том же самом блэйде, что и мастер.
4. Сервер центра коммутации по любому из пп.1 или 2, в котором каждый блэйд дополнительно содержит блок (114) информации о состоянии блэйда, определяющий состояние блэйда (110), при этом блок (114) информации о состоянии блэйда сообщает другим блэйдам о любом изменении состояния блэйда.
5. Сервер центра коммутации по п.4, в котором в случае, если координатор назначает нового мастера на одном из блэйдов, другие блэйды передают новому мастеру (112) список используемых ресурсов.
6. Сервер центра коммутации по п.1 или 2, в котором каждый блэйд (110) содержит блок восстановления блэйда, выполняющий процедуру восстановления блэйда в случае отказа блэйда, при этом блок восстановления блэйда решает, какой из вызовов, обрабатываемых отказавшим блэйдом, сохранить, и передает информацию о ресурсах, которые все еще выделены, и о ресурсах, управление которыми передается обратно мастеру (112).
7. Сервер центра коммутации по п.5, в котором координатор (115) обнаруживает нагрузку сигнализации блэйдов (110) и перемещает мастеров (112) и партнеров (113) для различных пулов ресурсов на различные блэйды в зависимости от нагрузки сигнализации этих различных блэйдов (110).
8. Сервер центра коммутации по п.1 или 2, в котором мастер маршрута обеспечивается для каждого маршрута магистральной линии связи, тогда как мастер доступа обеспечивается для каждого доступа ISDN.
9. Сервер центра коммутации по п.1 или 2, дополнительно содержащий мастера медиашлюза, управляющего обработкой сообщений поддержки медиашлюза (200).
10. Сервер центра коммутации по п.8, в котором контроллер вызовов запрашивает управление над ресурсами от мастера маршрута или мастера доступа и возвращает управление, если ресурсы более не требуются.
11. Способ управления сервером центра коммутации, причем сервер имеет кластер блэйдов с множеством блэйдов (110), содержащий следующие этапы, на которых:
- обеспечивают пулы ресурсов, доступные упомянутому множеству блэйдов (110), и
- координируют использование объединенных в пул ресурсов для упомянутого вызова упомянутым множеством блэйдов с помощью мастера (112), назначенного каждому пулу, при этом по меньшей мере один из следующих этапов выполняется контроллером (111) вызовов для обработки вызовов, причем контроллер вызовов обеспечен на одном из блэйдов для управления ресурсами в течение длительности упомянутого вызова: установление вызова, наблюдение за вызовом и разрыв вызова, запрашивание управления над ресурсами от мастера маршрута или мастера доступа и возвращение управления, если ресурсы более не требуются.
12. Способ по п.11, в котором информацией об используемых ресурсах для вызова управляют таким образом, что информация об используемых ресурсах, присутствующих на блэйде контроллера вызовов упомянутого вызова, дополнительно предоставляется на еще одном блэйде.
13. Способ по любому из пп.11 и 12, дополнительно содержащий этап обнаружения изменения состояния по меньшей мере одного из блэйдов сервера, при этом в случае изменения состояния другим блэйдам сообщают об изменении состояния упомянутого одного блэйда.
14. Способ по любому из пп.11 и 12, дополнительно содержащий этапы, на которых:
- обнаруживают отказ блэйда,
- обнаруживают, выполнена ли процедура восстановления для упомянутого блэйда,
при этом вызовы могут быть сохранены, и ресурсы, управляемые упомянутым отказавшим блэйдом для таких вызовов, продолжают использоваться после окончания процедуры восстановления.
15. Способ по любому из пп.11 и 12, дополнительно содержащий этапы, на которых:
- обнаруживают отказ блэйда,
- обнаруживают, выполнена ли процедура восстановления для упомянутого блэйда,
при этом, когда процедура восстановления выполнена, мастеру сообщается о ресурсах, которые были использованы для несохраненных вызовов после процедуры восстановления, причем мастер устанавливает эти ресурсы в исходное состояние.
16. Способ по п.14, в котором в случае обнаружения отказа блэйда, на котором присутствует мастер (112), создается новый мастер и первый список ресурсов, используемых каждым блэйдом, передается новому мастеру от каждого другого блэйда к другому.
17. Способ по любому из пп.11 и 12, в котором этап создания нового мастера содержит по меньшей мере один из следующих этапов:
- определение координатором (115), на каком блэйде создан новый мастер,
- информирование с помощью координатора (115) других блэйдов о создании нового мастера,
- создание с помощью нового мастера таблицы состояний ресурсов, используемых каждым блэйдом,
- передачу с помощью других блэйдов новому мастеру информации, необходимой новому мастеру для координации использования объединенных в пул ресурсов множеством блэйдов,
- копирование партнеру (113) с помощью нового мастера данных, касающихся вызовов, управляемых на том же самом блэйде,
- информирование мастера (112) с помощью партнера (113), что данные были успешно сохранены,
- информирование с помощью нового мастера других блэйдов о завершении создания мастера.
18. Способ по п.17, в котором запросы о занятости для ресурсов, принятые во время перемещения мастера (112), буферизуются и после завершения передачи передаются новому мастеру.
19. Способ по п.18, в котором в случае, если до завершения передачи обнаруживается отказ для нового мастера, перемещение прерывается.
20. Способ по любому из пп.11, 12, 18, 19, в котором перемещение координатора (115), управляющего перемещением или созданием нового мастера или партнера, не влияет на перемещение или создание мастера или партнера.
21. Способ по любому из пп.11, 12, 18, 19, дополнительно содержащий этапы, на которых:
- обнаруживают, становится ли новый блэйд активным,
- передают текущее состояние и распределение мастеров и партнеров от другого блэйда на новый активный блэйд.
