В центрах обработки данных бывает необходимо иметь более одного процессора. Такой подход оказывается весьма полезным для обеспечения большой мощности вычислительных ресурсов и емкости ресурсов данных, а также возможностей восстановления в случае сбоев. Однако независимое управление несколькими большими системами создает проблемы при разделении общих ресурсов и увеличивает стоимость эксплуатации. Архитектура zSeries позволяет соединить множество систем и рассматривать их как единую логическую единицу. Это достигается с помощью технологии, разработанной корпорацией IBM, и называемой кластерной технологией Parallel Sysplex (Sysplex - это аббревиатура слов System Complex) [4.3].
В рамках рассматриваемой технологии системы zSeries различные конфигурации могут взаимодействовать как между собой, так и с процессорами более ранних серий. В этой связи, помимо вышеуказанных преимуществ, Parallel Sysplex позволяет равномерно распределять загрузку между новейшими процессорами и процессорами более старых моделей.
Кроме того, Parallel Sysplex дает пользователям возможность выполнять динамическую реконфигурацию (добавление или удаление процессоров) системы без ее остановки и последующего рестарта. Следует также отметить обеспечение целостности разделяемых между несколькими процессорами данных при их постоянном изменении.
Впервые базовая среда Parallel Sysplex была введена корпорацией IBM в 1990 году. Она обеспечивала управление мультисистемами с помощью компонента системы MVS/ESA (известной теперь как OS/390), называемого межсистемными сервисами Coupling Facility (XCF). Компонент XCF дает возможность установленным в среде системы программам взаимодействовать с программами этой же системы, или других систем. В базовой среде Sysplex образы выполняющихся OS/390 взаимодействуют с использованием соединения <канал-к-каналу> и разделяемых данных. В случае нахождения выполняющихся образов на различных процессорах они синхронизируются с помощью Sysplex-таймера для обеспечения корректной совместной работы, что очень важно для обработки разделяемых данных.
Таким образом, кластер Parallel Sysplex zSeries содержит новейшую технологию мультисистемного разделения данных. Каждый узел кластера может одновременно обрабатывать разделяемые данные в памяти локального процессора под синхронным управлением, опирающимся на аппаратные средства. В результате этого текущие запросы, относящиеся к логически единому процессу, такому, как обработка транзакций или запросы к базе данных, могут динамически распределяться для параллельного выполнения на узлах кластера Sysplex с использованием доступных ресурсов процессоров. Расширение мощностей серверов в рамках рассматриваемой технологии достигается связыванием в единый кластер до 32-х процессоров. При этом каждый сервер в кластере Parallel Sysplex имеет доступ ко всем ресурсам и данным, а каждый образ может выполняться на любом сервере. Такое разделение данных и параллельное выполнение образов позволяют динамически балансировать нагрузку по всем серверам кластера Parallel Sysplex. Динамическое распределение нагрузки, в свою очередь, позволяет переназначать нагрузку на доступные серверы в случае выхода из строя программного обеспечения или аппаратных средств какого-либо из серверов кластера. Таким образом обеспечивается непрерывность вычислительного процесса в целом.
Еще одно важное достоинство технологии Parallel Sysplex заключается в возможности манипуляции программными и аппаратными средствами без нарушения работоспособности системы в целом. Благодаря разделению данных и динамическому управлению загрузкой, серверы могут быть удалены из кластера или добавлены к нему без остановки работы системы. Это свойство позволяет заказчикам конфигурировать кластер <по шагам>, в соответствии со своими текущими потребностями. Ниже рассматривается архитектура кластеров Parallel Sysplex и программные средства их поддержки.
Структура Parallel Sysplex
Технология Parallel Sysplex включает в себя программные, микропрограммные и аппаратные средства, которые тесно взаимодействуют между собой. Структура кластера Parallel Sysplex представлена на рис. 4.15 [4.3,4.5].
Ядром кластера являются два или более центральных обрабатывающих комплексов (Central Processing Complex, CPC), однако в отдельных случаях возможно построение кластера из одного CPC. Обычно это процессоры моделей ES/9000, S/390 или z900.
Для обеспечения взаимодействия между сервисами Parallel Sysplex необходимо наличие связей между участвующими в нем системами и подсистемами. Для реализации таких связей между CPC необходимо, по меньшей мере, две линии: входная и выходная. Эти линии могут быть реализованы как ESCON/FICON-каналы или как устройства Coupling Facility. Устройства ESCON/FICON представляют собой волоконно-оптические широкополосные каналы связи.
(рис 4.15) Структура кластера Parallel SysplexКак видно из рис. 4.15, CPC соединяются между собой устройствами Coupling Facility (CF). Эти устройства представляют собой процессоры, обеспечивающие среду для хранения разделяемых данных, откуда они могут быть считаны для обработки внутри Parallel Sysplex.
Процессор CF может быть реализован либо в виде логического раздела (LPAR) в рамках процессора S/390, но без каналов ввода/вывода и периферийных устройств, либо в виде автономного процессора. Поэтому принято различать автономные и внутренние CF. Автономный CF обычно реализуется на процессоре типа 9674 и является внешним по отношению к CPC, что показано в левой части рисунка. В последнее время большинство CPC снабжается внутренними CF, которые перед использованием нуждаются только в активации. Этот вариант показан в правой части рисунка. Блок z900, например, может поставляться с несколькими центральными процессорами общего назначения (CPU) вместе с дополнительными CPU, которые могут быть сконфигурированы и использованы только как LPAR CF. Кроме того, имеется возможность конфигурирования одного или более разделов LPAR системы S/390 в качестве CF. Следует отметить, что с точки зрения конечного пользователя никакой разницы между типами CF не существует. Связь CF-CPC функционально является эквивалентной каналам
CPC, к которым подключаются периферийные устройства. Она обеспечивает физический путь передачи данных из CF и приема данных в CF.
Код управления CF (CF Control Code, CFCC) является эквивалентом операционной системы этого устройства. Он реализуется только в виде микрокода внутри CF. Следует отметить, что на данном процессоре никакое программное обеспечение не выполняется.
В качестве оконечного устройства каждое CF имеет в своем составе адаптер связи. Такой адаптер обеспечивает прием и передачу данных между CF и CPC и реализован в виде специального микрокода. Адаптер имеет внутренние буферы, в которые помещаются данные. Буферы, подобно субканалам, характеризуются внутренним состоянием. Так, например, субканал может иметь состояние <субканал занят> в случае заполнения буфера. Состояние буферов контролируется соответствующими сервисами Parallel Sysplex.
Конфигурации последних версий Parallel Sysplex могут включать в свой состав еще один вид связей, называемый связью CF-к-CF. Этот вид связей используется некоторыми сервисами разделения данных для синхронизации изменений в данных. Примером такого сервиса может служить иерархическая база данных.
Для корректного функционирования кластера необходима информация о его конфигурации, текущем состоянии и т. п. Эта информация хранится в так называемых Coupling - наборах данных (Coupling Data Sets, CDS). Каждый CPC имеет в своем составе дисковые накопители DASD, содержащие множество наборов системных данных различного назначения. Эти наборы данных в рамках кластерной технологии Parallel Sysplex рассматриваются как общий (единый) набор наборов данных, необходимый для определения и функционирования кластера и его сервисов. Он разделяется всеми компонентами Parallel Sysplex. CDS определяет окружение кластера и содержит политики, используемые для описания способов управления функционированием Parallel Sysplex со стороны OS/390 или z/OS. В CDS можно выделить шесть Coupling-наборов:
Базовый Coupling-набор. Этот набор определяет структуру кластера и содержит информацию, относящуюся к таким компонентам Sysplex, как OS/390 или z/OS и компонентам специальных групп внутри него, называемых XCF-группами (будут рассмотрены ниже).
CFRM CDS (Coupling Facility Resource Management). Этот набор содержит политику управления ресурсами, которая определяет Coupling Facility и структуры, которые могут быть распределены внутри CF.
LOGR CDS (Logger CDS) содержит политику регистрации, используемую системным регистратором для построения регистрационных потоков клиентов. Клиентом системного регистратора является общий сервер очереди (Common Queue Server, CQS), который выполняет запись в два регистрирующих потока: один для очереди полностью разделяемых структур, второй - для локальных структур.
SFM CDS (Sysplex Failure Management CDS) содержит политику управления восстановлением после сбоев, которая определяет, как система реагирует на различные типы сбоев, такие как потеря связи между компонентами кластера, занятость адаптера CF и т. п.
ARM CDS (Automatic Restart Management CDS) содержит политику управления автоматическим рестартом (перезапуском) системы, которая определяет стратегию для рестарта заданий или задач в случае их аварийного завершения.
WLM CDS (WorkLoad Manager CDS) содержит политику, используемую менеджером загрузки для управления системными ресурсами с целью их равномерного распределения.
Под политикой в данном случае понимается описание того, как Sysplex должен управлять ресурсами и событиями. Политики обычно создаются администраторами кластера или системными программистами и загружаются при инсталляции. Например, политика ARM описывает действия сервиса восстановления, которые он должен выполнить при сбое в какой-либо подсистеме. Как было показано выше, каждая политика содержится в своем CDS.
В 1990 году наиболее широко известная операционная система IBM MVS была модернизирована с целью включения в ее состав специального системного программного обеспечения, получившего название <межсистемные сервисы>, Coupling Facility (XCF). С появлением технологии Parallel Sysplex XCF стало основной частью всех разрабатываемых в среде MVS, OS/390 и z/OS программных систем различного назначения. В настоящее время XCF обеспечивает сервисы Sysplex для операционных систем IBM и подсистем, таких как иерархическая база данных. Примерами таких сервисов могут служить групповые сервисы, сервисы мониторинга, сервисы восстановления и т. п. Более подробно сервисы XCF будут рассмотрены в следующем разделе. Однако и сейчас можно отметить, что фактически все они имеют отношение к коммуникациям между компонентами операционных систем и/или подсистемами и Sysplex.
В связи с развитием кластерной технологии появился еще один набор сервисов OS/390 и z/OS, известный в настоящее время как расширенные межсистемные сервисы Coupling Facility (XES). Эти сервисы обеспечивают компонентам операционных систем средства разделения данных для доступа к разделяемым данным в структурах Coupling Facility. Примерами таких сервисов могут служить сервисы соединений, блокирующие сервисы, сервисы кэширования и т. п.
Внутри Coupling Facility имеются блоки памяти, обращение к которым осуществляется как к структурам. Эти структуры содержат все относящиеся к пользователям разделяемые данные. Можно выделить три типа доступных пользователям структур, каждая из которых предоставляет различные наборы функций: структуры кэширования, структуры блокировки и списочные структуры. Эти структуры содержат информацию о разделяемых данных, разделяемых очередях сообщений и ресурсах. Определение этих структур и управление ими является одним из самых существенных моментов при реализации многих Sysplex-приложений.
Некоторые Sysplex-сервисы распределяют и используют внутреннюю память CPC для сигнализации о наступлении различных событий внутри Coupling Facility. Эта память распределяется в виде битовых векторов в аппаратной системной области памяти (Hardware System Area, HSA), в которых каждый бит сигнализирует о наступлении связанного с ним события. Имеется два типа таких битовых векторов:
локальные вектора кэширования, которые сигнализируют о том, что буфер базы данных был обновлен;
вектора списочных уведомлений, которые сигнализируют о том, что в списочную структуру пришло сообщение.
Вследствие того, что системы OS/390 и подсистемы работают в рамках Sysplex во взаимодействии с этими же подсистемами или с другими подсистемами и программами, очень важно, чтобы они использовали единое общее время. Например, две базы данных, разделяющие общие данные, фиксируют моменты времени, в которые происходили изменения данных в локальных файлах регистрации. Если эти моменты времени не будут синхронизированы, то восстановление данных (в случае их разрушения) будет затруднено. Поэтому все CPC в кластере связаны с Sysplex-таймером (IBM 9037), который и обеспечивает требуемую синхронизацию в рамках всего кластера. Существенным является также то, что два приложения, запрашивающие текущее время суток от любого CPC в кластере, обязательно получат одинаковое его значение.
Коммуникационные сервисы Sysplex
Межсистемные сервисы Coupling Facility XCF предоставляют пользователям набор коммуникационных сервисов, которые позволяют множеству программ или подсистем, выполняющихся на различных компонентах кластера, разделять информацию о состоянии и взаимодействовать друг с другом. Эти сервисы доступны только для компонентов
XCF-групп. Следующее определение вводит понятие XCF-группы (согласно z/OS VR3.0 MVS Sysplex Services Guide, SA22-7617).
Группой называется набор взаимосвязанных компонентов, определенным в XCF распределенным приложением, в котором компоненты группы могут взаимодействовать (принимать и передавать данные) с другими компонентами этой же группы, пользуясь услугами системы MVS.
В рамках Parallel Sysplex имеется множество групп, и, например, связанные с иерархической базой данных программы являются компонентами различных групп. Так, при инициализации каких-либо программ, разделяющих общие данные, они присоединяются к XCF-группе, используя соответствующую директиву. Информация о группах содержится в наборе CDS.
Сервисы групп XCF позволяют зарегистрированным программам присоединяться (создавая их, если это необходимо) к XCF-группам и выходить из них, а также получать информацию о других компонентах группы. Присоединенный к группе, компонент имеет возможность вызывать сервисы XCF, такие, как сигнальный сервис и сервис мониторинга. Присоединенный к группе компонент идентифицируется через групповую программу компонента. Когда новый компонент присоединяется к группе или существующий элемент покидает группу, все остальные компоненты извещаются об этом событии через XCF. Например, если какая-либо программа, разделяющая данные, аварийно завершается, то XCF через соответствующие групповые программы компонента извещает об этом другие компоненты, которые могут предпринять необходимые в таком случае действия.
Сигнальные сервисы XCF
Сигнальные сервисы XCF обеспечивают компонентам группы средства для передачи, приема сообщений и передачи ответов на принятые сообщения от других компонентов той же XCF-группы [4.5]. Например, программа А и программа В присоединены к XCF-группе С. Когда программа А передает сообщение программе В, она использует XCF для такой передачи, не принимая в расчет местонахождение адресата. Групповая программа сообщений группы С извещает В о том, что для нее есть сообщение от А. С помощью тех же средств В отправляет ответ в А. Такие действия возможны вследствие принадлежности компонентов А и В одной XCF-группе С.
Сервисы мониторинга XCF
Сервисы мониторинга XCF позволяют компонентам групп контролировать текущий статус других компонентов той же XCF-группы [4.5]. Когда компонент присоединяется к группе, он инициирует в XCF групповую программу состояния компонента, идентифицирует 32-байтное поле статуса компонента и определяет временной интервал проверки статуса. Этот компонент периодически обновляет (внутри интервала проверки статуса!) свое состояние. XCF проверяет поле статуса по истечении интервала проверки. Если статус компонента не изменился после предыдущей проверки, то XCF посредством программы состояния компонента пытается определить его статус. Если эта программа показала изменение статуса или не ответила, что может свидетельствовать о сбое компонента, то XCF через групповые программы оставшихся компонентов извещает их об изменившемся статусе данного компонента.
Собственно операционная система тоже имеет поле статуса. В случае ее сбоя или сбоя процессора ее поле статуса в течение интервала проверки останется неизменным. Когда XCF, выполняющиеся на других процессорах кластера, проверят поля статуса всех компонентов, эта ситуация будет обнаружена и аварийная система будет изолирована. Далее XCF известит о случившемся событии все выполняющиеся программы всех компонентов.
Сервисы Sysplex для восстановления
Существует два типа Sysplex-сервисов, которые решают проблемы доступности и восстановления во время работы Parallel Sysplex [4.5]. Как правило, эти проблемы возникают при сбоях операционных систем, приложений, или аппаратных сбоях. Это управление сбоями Sysplex и менеджер автоматического перезапуска (рестарта).
Управление сбоями Sysplex (Sysplex Failure Management, SFM) позволяет определить политику SFM в наборе данных CDS. В этом наборе можно описать действия, которые необходимо предпринять OS/390 или z/OS при возникновении сбойной ситуации внутри кластера. Ответственность за эту политику возлагается на администрацию и системных программистов. Сбои, относящиеся к политике SFM, включают в себя:
Сбои в работе системы. Компоненты Parallel Sysplex должны периодически обновлять поле статуса в наборе данных CDS. Политика SFM должна определить интервал, в течение которого статус компонентов должен обновляться, или установить <условие обновления статуса пропущено>, status update missing condition. Когда происходит сбой операционной системы или LPAR, в котором она выполняется, то поле статуса в наборе данных CDS окажется необновленным и будет установлено условие <status update missing condition>. Другие системы обнаруживают этот факт и могут его использовать для инициирования действий по восстановлению. Эти действия могут быть выполнены как с участием оператора системы, так и автоматически. В любом случае аварийная система изолируется, отменяются все ее операции ввода/вывода и доступ к Coupling Facility и производится попытка перезагрузить систему.
Сбои в соединениях. Все системы Parallel Sysplex в любой момент времени должны быть готовы к коммуникациям. Если это не так, то неготовые к коммуникациям системы должны быть удалены из кластера (изолированы). Эта ситуация называется сбоем в соединениях (Signaling Connectivity Failures). Для слежения за такими сбоями и их обработкой должна быть определена политика Sysplex Failure Management (см. выше). В ней, в частности, указывается вес (значимость) каждой системы в кластере. При изоляции аварийной системы этот вес учитывается для максимизации вычислительной мощности оставшихся систем кластера.
Сбои в соединениях с Coupling Facility. Потеря связи между Coupling Facility и системой может произойти из-за сбоя собственно CF. Эта ситуация называется сбоем в соединениях с Coupling Facility (Coupling Facility Connectivity Failure). В случае возникновения такого сбоя система теряет доступ к структурам Coupling Facility. Например, если CF содержит блокирующую структуру, то программы, имеющие доступ к разделяемым данным, более не смогут блокировать поступающие запросы и эти данные могут оказаться разрушенными. Выше было показано, что политика управления ресурсами Coupling Facility Resource Management (CFRM) содержит определение всех структур. В объявлении структуры, например, может содержаться параметр, который указывает, что в случае сбоя структура нуждается в переопределении на других CF кластера.
Менеджер автоматической перезагрузки
Менеджер автоматической перезагрузки (рестарта) (Automatic Restart Manager, ARM) обеспечивает всеобъемлющий сервис для управления сбоями кластера в целом [4.5]. В то время как SFM разделяется между системами и связями между ними, ARM выполняет операции над всей системой. Если некоторая программа аварийно завершается или происходит сбой системы, на которой она выполняется, ARM может выполнить рестарт такой программы в этой же или в другой системе соответственно. Для реализации такой возможности программа должна быть зарегистрирована в ARM как рестартируемый элемент. ARM активируется в кластере определением политики автоматического рестарта в наборе данных CDS.
Сервисы Sysplex для разделения данных
Для разделения данных в рамках структуры Parallel Sysplex имеются расширенные межсистемные сервисы (XES). Эти сервисы представляют собой средства для разделения данных между приложениями Sysplex. Они позволяют подсистемам и авторизованным программам использовать структуры Coupling Facility для высокопроизводительного разделения данных. Здесь под разделением данных понимается разделение любых типов данных между программами, выполняющимися на любых системах кластера [4.3,4.5].
Разделяемые данные могут располагаться в одной из трех структур Coupling Facility: структуры кэширования, структуры блокировки и списочные структуры. XES обеспечивает набор сервисов для связи с этими структурами в целом и определения их атрибутов (соединительные сервисы), а также другой набор сервисов, отдельный для каждой структуры. Это сервисы кэширования, сервисы блокировки и сервисы списков. Они используются коннекторами для вызова функций, поддерживаемых структурой соответствующего типа. Ниже даются определения перечисленных объектов.
Структуры и коннекторы
Структурой называется конструкция Coupling Facility, целью которой является поддержка разделения данных (например, данные в иерархической базе данных, сообщения в очереди сообщений) между многими коннекторами структур через набор XES-сервисов, не требующая непосредственного управления памятью [4.5]. Структура упрощает и стандартизирует доступ к памяти Coupling Facility. Все структуры Parallel Sysplex должны быть определены в политике управления ресурсами Coupling Facility CFRM.
В Coupling Facility существует три вида структур, которые могут быть распределены: структуры кэширования, структуры блокировки и списочные структуры. Каждый тип предназначен для поддержки определенных функций разделения данных и имеет собственный набор XES-сервисов. Например, программе, работающей с базой данных, нужно получить доступ к структуре и вызвать XES-сервисы для разделения данных. С помощью соединительных сервисов она связывается с нужной структурой, после чего получает доступ к содержащимся в ней данным, используя сервисы кэширования, блокировки или списочные сервисы.
Программа, использующая соединительные сервисы для соединения со структурой (и отсоединения от нее), а также для определения ее типа и атрибутов, называется коннектором. Соединенный со структурой, коннектор становится зарегистрированным для использования другими XES-сервисами в соответствии с типом структуры, к которой он подсоединен. Первый коннектор структуры определяет ее атрибуты, остальные коннекторы изменять их не могут. В структуре могут находиться, например, следующие атрибуты:
Информация о структуре, такая, как ее тип и постоянство. Тип структуры - это структура кэширования, блокировки или списочная. Следует отметить, что в то время, как структуры в целом предварительно определяются в политике CFRM, собственно тип структуры не определен до тех пор, пока с ней не свяжется первый пользователь. Постоянная структура - это такая структура, которая при отсоединении от нее всех коннекторов остается распределенной в Coupling Facility. Примерами таких структур являются разделяемые структуры очередей и блокирующие структуры. С другой стороны, структура виртуального метода доступа к данным (VTAM) не является постоянной структурой.
Информация о связях, такая, как постоянство связи. Постоянной называется связь, которая продолжает существовать, даже если работа коннектора завершилась аварийно. Непостоянная структура не будет удалена, если у нее существуют активные, или аварийные, но постоянные связи.
Информация о модификации структуры. Эта информация определяет, как структура может быть изменена после назначения. Кроме того, в аппаратной системной области памяти (HSA) находятся локальные векторы кэширования, обязательные для структур кэширования, и векторы списка извещений, необязательные для списочных структур. Они определяют взаимоотношения между коннекторами и структурами и оповещают о наступлении некоторого структурного события, например обновлении буфера данных или поступлении сообщения в списочную структуру.
Кэш-структуры и сервисы кэширования
Кэш-структуры и относящиеся к ним сервисы кэширования обеспечивают коннекторы последовательными данными и высокой скоростью доступа к ним [4.5]. Термин <последовательные данные> означает, что при добавлении к ним блока одним коннектором любой другой коннектор, взаимодействующий с этим же блоком через свой буфер, получит уведомление о необходимости обновления этих данных перед использованием. Этот процесс называется <обновлением буфера>. Любой коннектор может прочитать данные из кэш-структуры со скоростью, обеспечиваемой Coupling Facility, вместо чтения их с магнитного диска DASP (со значительно меньшей скоростью!). Для кэш-структур каждый коннектор указывает длину локального кэш-вектора в HSA. Каждый бит в локальном кэш-векторе указывает, были ли изменения содержания соответствующего локального буфера в пуле буферов коннектора.
После подключения к кэш-структуре коннекторы могут вызывать кэш-сервисы для доступа к данным. Эти сервисы вызываются через соответствующие макробиблиотеки и библиотеки функций.
Блокирующие структуры и блокирующие сервисы
Блокирующая структура может включать в себя две части. Первая часть - это блокирующая таблица. Назначением блокирующей таблицы является обеспечение эффективного способа сообщить о наличии потенциального соперничества за один и тот же ресурс между разделяющими данные клиентами [4.5]. Блокирующая таблица состоит из набора блокирующих входов, которые система ассоциирует с различными ресурсами. Количество входов в блокирующую таблицу определяется первым коннектором в момент подсоединения. Каждый вход в блокирующую таблицу идентифицирует коннекторы, которые могут претендовать на ресурс, <хешированный> на этот вход. (Под хешированием понимается способ организации таблиц, обеспечивающий эффективный поиск элементов и пополнение таблицы. Положение элемента в хеш-таблице определяется значением функции расстановки, отображающей множество значений возможных ключей элементов данных в множество индексов таблицы и обеспечивающей равномерное ее заполнение). Вход в блокирующую таблицу также идентифицирует
<менеджер соперничества>, или глобальный блокирующий менеджер для ресурсов, хешированных на данный вход.
Если опасность потенциального соперничества за ресурс отсутствует, то блокирующий запрос может быть немедленно выполнен (блокирующим называется запрос, делающий некоторый ресурс недоступным для других запросов на период его обработки). Если же блокирующая таблица показывает возможность возникновения потенциального соперничества, то производится определение места, где может возникнуть конфликт между двумя запросами. Перечисленные действия выполняются глобальным блокирующим менеджером.
Вторая (необязательная) часть блокирующей структуры - это набор входов в записи данных, содержащий связи пользователей с частными ресурсами. Он может использоваться для восстановления связей с разделяемыми ресурсами в случае аварийного завершения какого-либо коннектора.
Клиентские программы пользуются услугами блокирующих сервисов для управления блокировками при доступе к разделяемым данным. Основными сервисами этой группы являются:
Сервис захвата ресурса (OBTAIN). Этот сервис блокирует доступ к ресурсу, имя которого указывается в параметре вызова, для других клиентских приложений.
Сервис освобождения ресурса (RELEASE). Этот сервис освобождает ресурс, захваченный вышеуказанным сервисом, для доступа к нему клиентских приложений.
Глобальный блокирующий менеджер. Этот сервис поддерживает информацию о каждом ресурсе в пространстве данных и принимает решение об удовлетворении запросов на захват ресурсов, поступающих от клиентских программ.
Списочные структуры и списочные сервисы
Списочные сервисы позволяют подсистемам и зарегистрированным приложениям, выполняющимся на одном кластере, использовать Coupling Facility для разделения данных, организованных в списочные структуры. Списочная структура состоит из набора списков и необязательной блокирующей таблицы [4.5]. Информация заносится в список в виде набора входов в список. Входы в список, как правило, сортируются по значению какого-либо ключа. Блокирующая таблица, как и в случае блокирующих структур, может быть использована для упорядочивания доступа к ресурсам списочной структуры. Списочная структура с блокирующей таблицей называется списочной структурой с последовательным доступом.
В то время как кэш-сервисы и блокирующие сервисы имеют вполне определенное назначение, коннектор списочной структуры может использоваться для поддержки любого вида данных, требующих разделяемого доступа. Например, в рамках иерархической базы данных IMS списочные структуры используются для получения и поддержки информации о состоянии системы: в частности, о том, какие узлы зарегистрированы в IMS, какие пользователи осуществляют с ней диалог и т. п.
Списочные структуры содержат значительно больше компонентов, чем блокирующие или кэш-структуры. Первый коннектор к списочной структуре определяет ее атрибуты и наличие или отсутствие необязательных компонентов.
Точками входов в списки являются заголовки списков. Коннектор определяет, как будут использоваться заголовки списков. Например, сервер очередей (Common Queue Server, CQS) распределяет 192 заголовка в списках распределенных очередей сообщений. Одни из них назначаются для транзакций, другие - для организации очередей сообщений.
Одним из важнейших списочных сервисов является монитор управления событиями (Event Monitor Control, EMC). Этот сервис предназначен для информирования коннекторов о наступлении ожидаемых событий. EMC использует выделенную ему область в списочной структуре, называемой областью монитора событий. Первый коннектор может отвести часть списочной структуры под эту область. В дальнейшем в ней формируются очереди событий, назначенных как всему списку в целом, так и отдельным входам. Когда происходит одно из ожидаемых событий, соответствующий коннектор информируется об этом монитором управления событиями.
Списочные структуры имеют и другие связанные с ними сервисы, делающие разделение данных прозрачным для пользователей.
