Кластерная технология Parallel Sysplex

Коммуникационные сервисы 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.