15. Высокая готовность

Что такое "высокая готовность"?

Клиентская библиотека

Администратор высокой готовности

Что такое "высокая готовность"?

Термин высокая готовность (ВГ) (high availablity, HA) обычно используется в сфере телекоммуникаций и других индустриях для обозначения способности системы сохранять рабочее состояние без продолжительных периодов простоя. Знаменитое выражение "пять девяток" относится к такому уровню готовности системы, при котором она остается работоспособной в течение 99,999% рабочего времени в год, что означает приблизительно пять минут простоя за тот же период.

Очевидно, что эффективное решение, реализующее высокую готовность, включает в себя различные аппаратные и программные компоненты, сочетание которых позволяет создать стабильно работающую систему. Например, имеются надежные аппаратные компоненты с достаточным уровнем избыточности. Каким же образом ОС может сохранить работоспособность и производительность при сбое какого-либо компонента или приложения? Каким образом ОС может обеспечить высокую готовность в случае, если достаточная избыточность аппаратных компонентов не может быть достигнута (например, в потребительских устройствах)?

ОС для ВГ

Если бы пришлось с нуля создавать операционную систему, способную обеспечить высокую готовность, нужно ли использовать единую среду исполнения? В такой простой, высокопроизводительной архитектуре все компоненты ОС, драйверы устройств, приложения, задачи и так далее исполняются без защиты памяти в режиме ядра (kernel mode).

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

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

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

"Врожденная" высокая готовность

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

ОС QNX Neutrino изначально обладает важными свойствами, которые особенно подходят для систем высокой готовности, а именно:

стабильность системы обеспечивается посредством полной защиты памяти для всех системных и пользовательских процессов;
системные компоненты (драйверы устройств, администраторы файловых систем и т. д.) могут динамически загружаться и выгружаться;
все программные компоненты изолированы друг от друга, что упрощает разработку и обслуживание.

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

Модули обеспечения высокой готовности

Кроме отказоустойчивой архитектуры, ОС QNX Neutrino имеет несколько компонентов, которые позволяют разработчикам упростить задачу построения и обслуживания эффективных систем высокой готовности:

клиентская библиотека высокой доступности (HA client-side library) для реализации функций-заменителей (cover functions), которые обеспечивают механизмы автоматического и прозрачного восстановления соединений с сервером;
администратор высокой готовности (HA Manager) — "интеллектуальный сторож", который способен выполнять многостадийное восстановление при отказе системных служб или процессов.

Поддержка специализированного оборудования

Многие операционные системы обеспечивают поддержку высокой готовности только с конкретным оборудованием (например, с шиной PCI Hot Plug), однако ОС QNX Neutrino не ограничивается только шиной PCI. Если ваша система высокой готовности основана только на какой-нибудь специализированной шине, то ОС, которая обеспечивает такое "решение высокой готовности", может совсем не отвечать вашим требованиям.

Замечание

Компания QNX Software Systems является активным участником форума Service Availability (www.saforum.org), который разрабатывает открытые стандарты для построения систем высокой готовности.

Клиентская библиотека

Клиентская библиотека высокой готовности служит для расширения возможностей библиотеки Си по выполнению операций ввода/вывода. Функции-заменители из библиотеки высокой готовности обеспечивают механизмы автоматического и прозрачного восстановления неисправных соединений, которые могут быть восстановлены с помощью сценария высокой готовности. Следует отметить, что библиотека высокой готовности может безопасно использоваться в многопоточной среде (thread-safe) и при работе с точками завершения (cancellation-safe).

Основной принцип работы клиентской библиотеки состоит в замене всех функций доставки сообщений (т. е. MsgSend*). Клиент может выбрать, какие именно соединения должны быть в состоянии высокой готовности, а какие должны быть обычными соединениями (т. е. вне среды высокой готовности).

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

Пример сценария восстановления

Листинг 15.1 показывает простой сценарий восстановления, в котором клиент открывает файл с помощью сетевой файловой системы. Если NFS-сервер дает сбой, администратор высокой готовности перезапускает его и заново монтирует файловую систему. В такой ситуации все клиенты, у которых были открытые файлы по аварийному соединению, обычно получают идентификатор неисправного соединения. Однако если клиент использует функции ha_attach, он может восстановить соединение.

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

Листинг 15.1

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <unistd.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <errno.h>

#include <ha/cover.h>

#define TESTFILE "/net/machine99/home/test/testfile"

typedef struct handle {

int nr;

int curr offset;

} Handle ;

int recover conn(int oldfd, void *hdl)

{

int newfd;

Handle *thdl;

thdl = (Handle *)hdl;

newfd = ha reopen(oldfd, TESTFILE, O RDONLY);

if (newfd >= 0) {

// перемещение на предыдущую известную позицию в файле

lseek(newfd, thdl->curr offset, SEEK SET);

// увеличить значение счетчика успешных восстановлений

(thdl->nr)++;

}

return(newfd);

}

int main(int argc, char *argv[])

{

int status;

int fd;

int fd2;

Handle hdl;

char buf[80];

hdl.nr = 0;

hdl.curr offset = 0;

// открывается соединение

// далее используется recover_conn

// hdl передается в качестве параметра

fd = ha open(TESTFILE, O RDONLY, recover conn, (void *)&hdl, 0);

if (fd < 0) {

printf("could not open file\n");

exit(-1);

}

status = read(fd,buf,15);

if (status < 0) {

printf("error: %s\n",strerror(errno));

exit(-1);

}

else {

hdl.curr offset += status;

}

fd2 = ha dup(fd);

// fs-nfs2 перезапускается после ошибки.

// сетевые точки монтирования перемонтируются

// предыдущий fd освобождается

sleep(18);

// При попытке чтения из дублированного fd произойдет ошибка,

// после чего выполняется восстановление с помощью recover_conn

status = read(fd,buf,15);

if (status < 0) {

printf("error: %s\n",strerror(errno));

exit(-1);

}

else {

hdl.curr offset += status;

}

printf("total recoveries, %d\n",hdl.nr);

ha close(fd);

ha close(fd2);

exit(0);

}

Поскольку библиотека функций-заменителей обрабатывает вызовы нижнего уровня типа MsgSend*, большинство стандартных библиотечных функций (read(), write(), printf(), scanf() и т. д.) также автоматически определяют среду высокой готовности. Библиотека содержит функцию ha-dup(), которая в контексте соединений высокой готовности семантически эквивалента стандартной функции dup(). Можно заменять функции восстановления в течение существования соединения, что значительно упрощает задачу разработки высокоспециализированных механизмов восстановления.

Администратор высокой готовности

Администратор высокой готовности (High Availability Manager, HAM) обеспечивает механизм контроля системных процессов и служб. Другими словами, это гибкий администратор ("умный сторож"), который способен выполнять многокаскадное восстановление в тех случаях, когда системные службы или процессы дают сбой, не отвечают или оказываются в состоянии, в котором не могут обеспечить необходимый уровень функционирования. В среде высокой готовности (в т. ч. в администраторе этой среды) используется простой механизм публикации и подписки (publish/subscribe mechanism) для передачи необходимых системных событий между теми или иными системными компонентами. Посредством автоматической интеграции в сетевой механизм Qnet среда высокой готовности прозрачным образом расширяет локальный механизм контроля, превращая его в сетевой.

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

Во многих системах высокой готовности тщательно идентифицируется и обрабатывается каждая единая точка сбоя (Single Point Of Failure, SPOF). Поскольку администратор высокой готовности выполняет сохранение информации о состоянии системы и обеспечивает основной механизм восстановления, он никогда не должен становится точкой сбоя.

Администратор высокой готовности и его дублер (Guardian)

Администратор высокой готовности является самоконтролирующим процессом, поэтому он устойчив к внутренним сбоям. Если по каким-либо причинам в администраторе высокой готовности случается сбой, он может немедленно и полностью восстановить свое состояние. Дублер (администратора высокой готовности) (Guardian) постоянно находится в состоянии готовности и в любой момент может заменить HAM-администратор. Поскольку вся информация о состоянии хранится в разделяемой памяти, дублер может полностью воспроизвести то состояние, в котором HAM-администратор был перед сбоем.

Но что происходит в случае аварийного останова дублера? Дублер (который стал новым администратором высокой готовности) создает для себя нового дублера, прежде чем занять место администратора высокой готовности. Фактически, один дублер не может существовать без другого.

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

Структура администратора высокой готовности

Администратор высокой готовности оперирует тремя основными понятиями:

сущности (entities);
условия (conditions);
действия (actions)

Сущности

Сущности (Entities) — это основные предметы наблюдения/контроля в системе. Сущность, фактически, это процесс (pid). Как нормальные процессы, все сущности имеют уникальный идентификатор. С каждой сущностью связано символьное имя, которое служит для ссылок на данную конкретную сущность. Имена, связанные с сущностями, естественно, являются уникальными для всей системы. Администраторы в настоящее время связаны с узлами, поэтому правило уникальности относится к узлу. Как будет рассмотрено далее, это требование уникальности очень напоминает схему именования, применяемую в иерархических файловых системах.

Существует три основополагающих типа сущностей.

Самоприсоединяемые (self-attached), или "пассивные" сущности (компоненты с поддержкой высокой готовности) — процессы, автоматически отправляющие квитанции работоспособности (heartbeats) администратору высокой готовности, который в результате начинает контролировать их работу. Самоприсоединяемые сущности могут самостоятельно решать, в какой именно точке их жизненного цикла необходимо их контролировать, при каких условиях необходимо выполнять заданные действия и когда контроль должен быть завершен. Другими словами, такой процесс как бы говорит: "В случае моей смерти сделать следующее".
Внешне-присоединяемые (Externally attached), или "активные" сущности (компоненты без поддержки высокой готовности) — обычные процессы (в том числе унаследованные компоненты), которые контролируются системой. Это могут быть любые демоны или службы, состояние которых считается особенно важным. Данный метод полезен для тех случаев, когда, например, процесс A говорит: "Сообщите мне, когда процесс B умрет", при этом процесс B не обязательно должен знать об этом.
Глобальная (Global) сущность — заменитель любой сущности. Глобальная сущность может использоваться для связывания действий с событиями. При возникновении некоторых событий в отношении какой-либо сущности система запускает заданные действия. Термин "глобальный" относится к набору контролируемых сущностей и позволяет процессу сказать что-то вроде: "Когда любой процесс умирает или пропускает отправку квитанции работоспособности, выполните следующее". Глобальную сущность нельзя добавить или удалить, на нее можно только сослаться. Конечно, внутри глобальной сущности можно добавлять или удалять условия, а внутри условий можно добавлять или удалять действия.

Условия

Условия связаны с сущностями. Условие определяет состояние сущности (табл. 15.1).

Таблица 15.1. Условия

Условие	Описание
CONDDEATH	Сущность умерла
CONDABNORMALDEATH	Сущность умерла неестественной смертью¹². При всякой смерти сущности это условие запускается механизмом, который создает "посмертный" дамп
CONDDETACH	Отсоединение сущности, которая контролировалась администратором высокой готовности, в результате чего контроль завершается
CONDATTACH	Сущность, для которой ранее был создан заменитель (т. е. некоторый процесс подписался на события, связанные с этой сущностью), присоединилась к системе. Одновременно это означает запуск контроля данной сущности со стороны администратора высокой готовности
CONDBEATMISSEDHIGH	Сущность пропустила отправку квитанции работоспособности, заданную для условий с "высокой" серьезностью ("high" severity)
CONDBEATMISSEDLOW	Сущность пропустила отправку квитанции работоспособности, заданную для условий с "низкой" серьезностью ("low" severity)
CONDRESTART	Сущность была перезапущена. Это условие становится истинным после того, как сущность успешно перезапускается
CONDRAISE	Внешне-определяемое условие передается администратору высокой готовности. Подписчики могут связывать действия с этими условиями
CONDSTATE	Сущность сообщает администратору высокой готовности о смене состояния. Подписчики могут связывать действия теми или иными изменениями состояния
CONDANY	Этот тип условия подходит для любых условий. Он может использоваться для связывания некоторых действий с одним из множества условий

Для приведенных в табл. 15.1 условий (кроме CONDSTATE, CONDRAISE и CONDANY) администратор высокой готовности является публикатором (publisher), так как он автоматически определяет и/или запускает эти условия. Что касается условий CONDSTATE и CONDRAISE, то их публикуют администратору высокой готовности внешние обнаружители.

Со всеми условиями подписчики (subscribers) могут связывать списки действий, предназначенных для последовательного выполнения при возникновении соответствующего условия. Условия CONDSTATE и CONDRAISE обеспечивают возможности фильтрации, с помощью которых подписчики могут выборочно связывать действия с отдельными условиями на основе опубликованной информации.

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

Действия

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

Таблица 15.2. Действия

Действие	Описание
ham_action_restart()	Это действие перезапускает сущность
ham_action_execute()	Выполняет заданную команду (например, запустить процесс)
ham_action_notify_pulse()	Извещает некоторый процесс о возникновении данного условия. Это извещение отправляется с помощью импульса со значением, заданным процессом, который запросил такое извещение
ham_action_notify_signal()	Извещает некоторый процесс о возникновении данного условия. Это извещение отправляется с помощью сигнала реального времени со значением, заданным процессом, который запросил такое извещение
ham_action_notify_pulse_node()	Аналогично действию ham_action_notify_pulse() (см. ранее), за исключением того, что имя узла, заданное в качестве получателя импульса, может быть определено в виде полного имени (fully qualified node name)
ham_action_notify_signal_node()	Аналогично действию ham_action_notify_signal()(см. ранее), за исключением того, что имя узла, заданное в качестве получателя сигнала, может быть определено в виде полного имени
ham_action_waitfor()	Позволяет добавлять задержки между действиями в последовательности. Также с помощью данного действия можно ожидать появление указанных имен в именном пространстве
ham_action_heartbeat_healthy()	Сбрасывает состояние механизма отправки квитанций работоспособности для сущности, которая пропустила отправку квитанции и тем самым вызвала соответствующее условие, но в данный момент уже восстановила свою работу
ham_action_log()	Передает данное условие механизму регистрации событий

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

Альтернативные действия

Что происходит, если само действие дает сбой? Можно задать альтернативный список действий, которые должны выполняться для восстановления после таких сбоев. Эти альтернативные действия связываются с основными действиями с помощью нескольких функций типа ham_action_fail*:

ham_action_fail_execute()

ham_action_fail_notify_pulse()

ham_action_fail_notify_signal()

ham_action_fail_notify_pulse_node()

ham_action_fail_notify_signal_node()

ham_action_fail_waitfor()

ham_action_fail_log()

Публикация автономно выявленных условий

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

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

В настоящее время имеется два разных способа публикации информации HAM-администратору, оба из которых достаточно общие для того, чтобы клиенты могли строить более сложные механизмы обмена информацией:

публикация информации об изменениях состояния;
публикация информации о других условиях.

Изменения состояния

Сущность может сообщать об изменениях своего состояния администратору высокой готовности, который отслеживает текущее состояние каждой сущности (в соответствии с передаваемыми от нее сообщениями). HAM-администратор не интерпретирует смысл значения переменной состояния и не подтверждает эти изменения состояния, но он может генерировать события в связи с переходами сущности из одного состояния в другое.

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

Для того чтобы известить администратор высокой готовности об изменении состояния, компоненты могут использовать функцию ham_entity_condition_state(). HAM-администратор получает информацию о следующем состоянии при его изменении, поскольку только эта информация необходима для него. Затем HAM-администратор запускает событие по условию изменения состояния, на которое другие компоненты могут подписаться с помощью API-вызова ham_condition_state() (см. далее).

Другие условия

Компоненты системы также могут публиковать автономно выявленные условия с помощью API-вызова ham_entity_condition_raise(). Компонент, вызывающий такое условие, может задавать тип, класс и уровень серьезности для того, чтобы подписчики могли точнее фильтровать условия для подписки. В результате этого вызова администратор высокой готовности запускает событие по возникновению условия, на которое другие компоненты могут подписаться с помощью API-вызова ham_condition_raise() (см. далее).

Подписка на автономно опубликованные условия

Для того чтобы получать информацию о событиях, опубликованных другими компонентами, подписчики могут использовать API-вызовы ham_condition_state() и ham_condition_raise(). Эти вызовы аналогичны API-вызову ham_condition() (например, они также возвращают условию идентификатор (handle)), но, кроме того, они позволяют подписчику указывать, в каких именно из нескольких опубликованных условий они заинтересованы.

Триггер по изменению состояния

Когда сущность публикует информацию об изменении состояния, для этой сущности вызывается соответствующее условие, основанное на двух состояниях, связанных с этим переходом: исходного (from) и результирующего (to). Подписчики указывают, информация о каких состояниях им требуется, задавая значения параметров fromstate и tostate в API-вызове. Более подробные сведения о вызове ham_condition_state() можно найти в электронном документе «QNX Neutrino High Availability Framework. Developer's Guide».

Триггер по опубликованному условию

Для получения информации об условиях, инициированных сущностями, подписчики могут использовать API-вызов ham_condition_raise(), указывая в качестве его параметров необходимую для них информацию о типе вызовов. Более подробные сведения о вызове ham_condition_raise() можно найти в электронном документе «QNX Neutrino High Availability Framework. Developer's Guide».

Администратор высокой готовности как "файловая система"

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

Администратор высокой готовности отображает свое состояние в виде файловой системы, доступной только для чтения в каталоге /proc/ham. В результате любые процессы могут видеть текущее состояние администратора (например, можно применить команду ls /proc/ham).

Файловая система /proc/ham содержит много информации о текущем состоянии системных сущностей. Она также предоставляет полезную статистику о квитанциях работоспособности, перезапусках и завершениях, что позволяет получить мгновенное отображение состояния различных сущностей, условий и действий в системе.

Многостадийное восстановление

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

Например, запущен fs-nfs2 (файловая система NFS) и затем смонтировано несколько каталогов из различных источников. Можно дать администратору высокой готовности инструкцию перезапустить fs-nfs2 при сбое, а также заново смонтировать соответствующие каталоги после перезапуска файловой системы.

Другой пример: произошел сбой сетевого администратора io-pkt*. Можно дать администратору высокой готовности инструкцию перезапустить сетевой администратор и подключить соответствующие сетевые диски (а также, если необходимо, другие службы, которые зависят от сетевых служб).

Программный интерфейс администратора высокой готовности

Основным механизмом взаимодействия с администратором высокой готовности является его программный интерфейс (API). Он реализован в виде библиотеки, с которой можно компоновать свой код. Эта библиотека может безопасно использоваться в многопоточной среде и при работе с точками завершения.

Программный интерфейс администратора высокой готовности предоставляет следующий набор функций — табл. 15.3.

Таблица 15.3. Функции администратора высокой готовности

Функция	Описание
ham_action_control()	Выполнить операции контроля для данного действия
ham_action_execute()	Добавить действие к условию
ham_action_fail_execute()	Добавить другое действие, которое должно быть выполнено при сбое соответствующего действия
ham_action_fail_log()	Добавить сообщение в журнал действий
ham_action_fail_notify_pulse()	Добавить действие отправки импульса при сбое соответствующего действия
ham_action_fail_notify_pulse_node()	Добавить действие отправки импульса заданному узлу при сбое соответствующего действия
ham_action_fail_notify_signal()	Добавить действие отправки сигнала при сбое соответствующего действия
ham_action_fail_notify_signal_node()	Добавить действие отправки сигнала заданному узлу при сбое соответствующего действия
ham_action_fail_waitfor()	Добавить действие ожидания, которое должно быть выполнено при сбое соответствующего действия
ham_action_handle()	Получить дескриптор для действия, находящегося в условии, которое создано внутри сущности
ham_action_handle_node()	Используя имя узла, получить дескриптор для действия, находящегося в условии, которое создано внутри сущности
ham_action_handle_free()	Освободить ранее полученный дескриптор действия, находящегося в условии, которое создано внутри сущности
ham_action_heartbeat_healthy()	Обнулить состояние счетчика квитанций работоспособности
ham_action_log()	Добавить сообщение в журнал действий
ham_action_notify_pulse()	Добавить к условию действие отправки импульса
ham_action_notify_pulse_node()	Добавить к условию действие отправки импульса, используя имя узла
ham_action_notify_signal()	Добавить к условию действие отправки сигнала
ham_action_notify_signal_node()	Добавить к условию действие отправки сигнала, используя имя узла
ham_action_remove()	Удалить действие из условия
ham_action_restart()	Добавить к условию действие перезапуска
ham_action_waitfor()	Добавить к условию действие ожидания
ham_attach()	Присоединить сущность
ham_attach_node()	Присоединить сущность, используя имя узла
ham_attach_self()	Присоединить приложение как самоприсоединяемую сущность
ham_condition()	Связать вызов условия с возникновением некоторого события
ham_condition_control()	Выполнить операции контроля для данного условия
ham_condition_handle()	Получить дескриптор для условия в сущности
ham_condition_handle_node()	Используя имя узла, получить дескриптор для условия в сущности
ham_condition_handle_free()	Освободить ранее полученный дескриптор условия в сущности
ham_condition_raise()	Присоединить условие, связанное с условием вызова условия, которое вызывается сущностью, вызывающей условие
ham_condition_remove()	Удалить условие из сущности
ham_condition_state()	Присоединить условие, связанное с условием изменения состояния, которое вызывается сущностью, сообщающей об изменении состояния
ham_connect()	Соединиться с администратором высокой готовности
ham_connect_nd()	Соединиться с удаленным администратором высокой готовности
ham_connect_node()	Используя имя узла, соединиться с удаленным администратором высокой готовности
ham_detach()	Отсоединить сущность от администратора высокой готовности
ham_detach_name()	Отсоединить сущность от администратора высокой готовности, используя имя сущности
ham_detach_name_node()	Отсоединить сущность от администратора высокой готовности, используя имя сущности и имя узла
ham_detach_self()	Отсоединить самоприсоединяемую сущность от администратора высокой готовности
ham_disconnect()	Разорвать связь с администратором высокой готовности
ham_disconnect_nd()	Разорвать связь с удаленным администратором высокой готовности
ham_disconnect_node()	Разорвать связь с удаленным администратором высокой готовности, используя имя узла
ham_entity()	Создать объекты-заменители сущности в администраторе высокой готовности
ham_entity_condition_raise()	Вызвать условие
ham_entity_condition_state()	Сообщить администратору высокой готовности об изменении состояния
ham_entity_control()	Выполнить операции контроля для сущности в администраторе высокой готовности
ham_entity_handle()	Получить дескриптор для сущности
ham_entity_handle_node()	Получить дескриптор для сущности, используя имя узла
ham_entity_handle_free()	Освободить ранее полученный дескриптор сущности
ham_entity_node()	Создать объекты-заменители сущности в администраторе высокой готовности, используя имя узла
ham_heartbeat()	Отправить квитанцию работоспособности администратору высокой готовности
ham_stop()	Остановить администратор высокой готовности
ham_stop_nd()	Остановить удаленный администратор высокой готовности
ham_stop_node()	Остановить удаленный администратор высокой готовности, используя имя узла
ham_verbose()	Изменить уровень детализации диагностических сообщений (verbosity) администратора высокой готовности

¹² Т. е. произошло т. н. ненормальное завершение. С точки зрения ОС, процесс может завершиться или "нормально" (т. е. либо самостоятельно, пусть даже в результате внутренней семантической ошибки, либо по некритическому сигналу), или "ненормально" (т. е. принудительно — например, по сигналу SIGKILL или SIGSEGV). — Прим. научн. ред.