9.1.7. Отказоустойчивость

Системы CORBA длительное время почти не имели средств поддержания отка­зоустойчивости. В большинстве случаев о факте ошибки просто сообщалось кли­енту, никаких других действий система не предпринимала. Так, например, при невозможности добраться до объекта по ссылке из-за недоступности его сервера (временной) клиент просто ждал. В CORBA версии 3 отказоустойчивостью за­нялись серьезно. Спецификация отказоустойчивой системы CORBA содержится в [328].

Группы объектов

Базовый подход к обработке ошибок в CORBA состоит в репликации объектов и создании из них групп объектов (object groups). Такая группа содержит одну или несколько абсолютно идентичных копий одного и того же объекта. Адресация группы объектов производится так же, как и одного объекта. Группа имеет тот же самый интерфейс, что и каждая из ее реплик. Другими словами, для клиента реп­ликация прозрачна. Поддерживаются различные стратегии репликации, включая репликацию на основе первичной копии, активную репликацию и репликацию на основе кворума. Все эти стратегии мы обсуждали в главе 6. Существуют также и другие характеристики групп объектов, их детальное рассмотрение можно най­ти в [328].

Для того чтобы по возможности обеспечить прозрачность репликации и вос­становления после сбоев, группы объектов не должны отличаться от обычных объектов CORBA, если приложение не потребует обратного. В связи с этим важ­но понять, как ссылаться на группы объектов. Применяемая методика состоит в использовании особого типа ссылки IOR, именуемой межоперациоппой ссылкой па группу объектов (Interoperable Object Group Reference, IOGR). Основное ее от­личие от обычной ссылки IOR состоит в том, что каждая ссылка IOGR содержит несколько ссылок на разные объекты, а именно на реплики, входящие в одну группу объектов. В противоположность этому ссылка IOR также может содер­жать несколько ссылок, но все они будут относиться к одному и тому же объек­ту, различаясь, возможно, протоколами доступа.

Когда клиент передает своему брокеру ORB ссылку IOGR, этот брокер пыта­ется выполнить привязку к одной из указанных реплик. В случае протокола НОР брокер ORB может использовать дополнительную информацию, обнару­женную в одном из профилей ПОР в ссылке IOGR. Эта информация, как мы уже говорили, может храниться в поле компонентов. Например, как показано на рис. 9.13, конкретный профиль ПОР может ссылаться на первичный экземпляр или резервную копию группы объектов посредством разных тегов TAG_PRIMARY и TAG_BACKUP соответственно.

Если привязка к одной из реплик невозможна, ORB клиента может продол­жить работу, попытавшись связаться с другой репликой в соответствии с прави­лом выбора следующей реплики, до получения успешного результата. Для кли­ента процесс привязки абсолютно прозрачен, для него это выглядит так, как будто он связывается с обыкновенным объектом CORBA.

Пример архитектуры

Чтобы поддерживать группы объектов и производить дополнительную обработ­ку отказов, к CORBA необходимо добавить определенные компоненты. Одна из возможных архитектур отказоустойчивой версии CORBA приведена на рис. 9.14. Эта архитектура была применена в системе Eternal [305, 310], которая имеет от­казоустойчивую инфраструктуру, построенную поверх системы надежных груп­повых коммуникаций Totem [304].

В этой архитектуре имеется несколько важных элементов. Наиболее важен менеджер репликации (replication manager), который отвечает за создание и управ­ление группой реплицированных объектов. В принципе существует только один менеджер репликации, хотя для повышения отказоустойчивости его можно реп­лицировать.

Как мы установили, для клиента нет разницы между группой объектов и любым другим типом объекта CORBA. Для создания группы объектов клиент просто обращается к стандартной операции create_object, в данном случае менеджера репликации, указывая тип создаваемого объекта. Клиент пребывает в неведении о том, что на самом деле при этом создается группа объектов. Число реплик, соз­даваемых при запуске новой группы объектов, обычно задается системным зна­чением по умолчанию. Менеджер репликации, кроме того, отвечает за замену реплики в случае ее отказа, гарантируя, таким образом, что число реплик не опус­тится ниже определенного минимума.

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

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