"Построение кластера высокой доступности на основе осрв qnx neutrino"


Использование источников бесперебойного питания



страница6/9
Дата04.11.2016
Размер2.34 Mb.
Просмотров2678
Скачиваний0
ТипПояснительная записка
1   2   3   4   5   6   7   8   9

Использование источников бесперебойного питания.


Такие источники позволяют избежать повреждения оборудования при кратковременных сбоях электричества. Также позволяют штатно завершить работу оборудования при длительных неполадках с электричеством.

Теперь рассмотрим плюсы и минусы вышеприведенных систем и системы QNX, выбранной для построения кластера.


Достоинства системы QNX Neutrino.


Кластерные системы сами по себе обычно делят на три типа:


  1. Кластеры высокой доступности, обеспечивающие бесперебойную работу критически важных сервисов

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

  3. Вычислительные кластеры, используются для высокопроизводительных вычислений, задача разбивается на несколько подзадач и выполняется на разных узлах кластера

QNX Neutrino - операционная система жесткого реального времени. QNX может работать как на встраиваемых системах с ограниченными ресурсами так и как полноценная надежная ОС. Это возможно благодаря микроядерной архитектуре системы. Благодаря ей же система легко масштабируется.

e

c:\users\alex\appdata\local\temp\снимок экрана 2013-05-20 в 13.07.07.png
Микроядерность также дает преимущества в построении систем высокой доступности. Все компоненты работают в своих отдельных модулях минимально взаимодействующих друг с другом. Все драйверы , стеки протоколов, файловые системы и приложения выполняются в защищенном пространстве пользователя, вне ядра. На уровне ядра выполняются только самые необходимые службы. Благодаря этому при обновлении какого либо компонента не нужно перезагружать систему целиком. Также если повредится какая та часть одного модуля это не скажется на других . Теоретически любой компонент при отказе может быть перезагружен и это не скажется на других компонентах системы. В совокупности это позволяет строить оптимизированные и очень доступные системы.

Как видно из схемы выше, QNX поддерживает множество платформ, начиная от x86 и заканчивая MIPS и PowerPC.
QNX - POSIX совместимая операционная система. Это позволяет легко портировать под нее приложения, написанные для Unix/Linux.
QNX поддерживает технологию динамического распределения процессорного времени между группами процессов, так называемую технологию адаптивной декомпозиции. Технология адаптивной декомпозиции позволяет обеспечить дополнительный уровень надежности и задействовать процессор на полную его мощность. Это может быть очень критично в маломощных встраиваемых системах. Но и в многопроцессорных/многоядерных серверах правильный расход процессорного времени важен.




Технология адаптивной декомпозиции позволяет объединять процессы и потоки в группы и обеспечивать гарантированное процессорное время для этих групп. Объединение в группы не позволяет какому то процессу забирать все процессорное время, вместо этого оно динамически распределяется между группами. Технология позволяет передавать ресурсы процессора от менее загруженных блоков к блокам, требующим дополнительного процессорного времени. Технология адаптивной декомпозиции идеально подходит для встраиваемых систем, требующих высокого уровня отказоустойчивости и гарантированного времени отклика.
В отказоустойчивой системе гарантированное процессорное время позволяет быстро восстанавливать отказавший компонент. Независимо от загрузки процессора администратор системы может подключиться к ней и продиагностировать неполадку.
QNX Neutrino – система жесткого реального времени. Это значит, что задача будет выполнена даже в самом худшем случае. Это дает нам дополнительные плюсы в обеспечении безотказной работы.

В QNX реализованы основные функции POSIX используемые в системах реального времени совместно с основным средством взаимодействия процессов в QNX–передачей сообщений. Функции POSIX не встроены в микроядро QNX, они реализованы в виде опциональных процессов и общих библиотек.


На низком уровне QNX содержит фундаментальные объекты, на высоком уровне функции, манипулирующие этими объектами.

Минимальной единицей выполнения в QNX является поток (thread). Несколько потоков выполняются внутри процесса. Каждый процесс в QNX защищен с помощь блока управления памятью от других процессов. То есть один процесс не может залезть в адресное пространство другого и нарушить работу всей системы.

Рассмотрим, как взаимодействуют между собой потоки и процессы и что из этого мы можем использовать при построении нашей системы высокой доступности.
Основным, как я уже писал, способом взаимодействия между потоками является передача сообщений. Помимо передачи сообщений существует и другие примитивы синхронизации, такие как сигналы, очереди сообщений POSIX, разделяемая память, каналы, семафоры и мьютексы. Такое разнообразие примитивов синхронизации дает нам некую гибкость в построении приложений.
Рассмотрим передачу сообщений подробнее. Осуществляется передача с помощью функций MsgSend(),MsgReceive()и MsgReply(). Поток посылает сообщение другому потоку (он может быть внутри другого процесса) и блокируется, до тех пор, пока поток, которому предназначается сообщение не вызовет MsgReply(), обработает сообщение и ответит с помощью MsgReply(). Если же поток вызвал MsgReply() он будет блокирован до тех пор пока кто нибудь не пошлет ему сообщение с помощью MsgSend(). Это так называемая синхронная передача сообщений.


Таким образом, выполняется синхронизация между посылающим и принимающим потоками. Посылающий поток блокируется, а принимающий запускается на выполнение. Это не требует никакой дополнительной работы от ядра по определению какой поток выполнять следующим. Это позволяет избежать потребления ресурсов и возникновения задержек.
Сообщение копируется непосредственно из адресного пространства одного потока в адресное пространство другого, без дополнительной буферизации. Таким образом, производительность передачи сообщений зависит от аппаратного обеспечения. Ядро не добавляет никакой дополнительной информации в сообщение. Сообщения имеют взаимно определенный смысл только между посылающим и принимающим потоками. Однако QNX поддерживает и расширенные сообщения с дополнительной информацией от пользовательских процессов или потоков. Примитив передачи сообщений поддерживает передачу несколькими частями, поэтому все равно ни посылающей, ни принимающей стороне не нужен промежуточный буфер.Вместо этого обе стороны определяют таблицу векторов в которой указано где в памяти находятся фрагменты сообщений.

Передача по частям позволяет сообщениям в которых заголовок отделен от данных быть переданными без потерь в производительности. Обычно такие потери связаны с копированием блока данных и присоединением к заголовку для составления целикового сообщения.



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


Есть несколько вариаций передачи сообщений. Сообщения передаваемые не по частям, без использования дополнительного вектора в памяти назовем простыми.




Функция

Посылаемое сообщение

Ответное сообщение

MsgSend()

Простое

Простое

MsgSendsv()

Простое

По частям

MsgSendvs()

По частям

Простое

MsgSendv()

По частям

По частям

Остальные функции (MsgReceive, MsgReply()) просто добавляют vк себе в конец для сообщения по частям.


Сообщения передаются с помощью специально созданных каналов. Поток, желающий получать сообщений создает канал, другой поток, который хочет сообщения отправлять присоединяется к этому каналу. Как только соединение установлено, через него можно посылать сообщения с помощью MsgSend().Каналы и связи идентифицируются целочисленным идентификатором. Связи отображаются напрямую в дескрипторы файлов, поэтому можно посылать сообщение прямо файловому дескриптору.
Для создания канала и установки соединения используется следующее API:

ChannelCreate() – создает канал для приема сообщений

ChannelDestroy() – уничтожает канал

ConnectAttach() –устанавливает соединение с каналом

ConnectDetach()- разрывает соединение.

Соединения

Клиент

Канал

Канал

Сервер

Сервер

Процессы, действующие как серверы, могут обрабатывать сообщения например так:


chid = ChannelCreate(flags);

SETIOV(&iov, &msg, sizeof(msg));

while(true)

rcd_id = MsgReceivev(chid, &iov, parts, &info);

switch( msg.type) {

// Здесь выполняется обработка сообщений

}

MsgReplyv(rcv_id, &iov, rparts);



}

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




Несколько потоков могут ожидать на канале

Канал

Несколько клиентов могут быть поставлены в очередь на одном канале

Клиент

Клиент

Канал

Находящееся в любой очереди сообщение блокирует ожидающий поток.
Помимо синхронной посылки сообщений поддерживаются также короткие неблокирующие сообщения (пульс). Такие сообщения могут состоять максимум из 5 байтов (4 на данные, 1 на код). Пульс часто используется для уведомления потока о прерывании или еще каком - либо событии без блокировки.


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

При использование Qnet можно использовать стандартные системные утилиты (mv, cp и т.д.) для манипулирования файлами так, как будто они находятся на локальной машине. Помимо файлов также можно работать с процессами на других машинах.


Иными словами Qnet предоставляет возможность легкого масштабирования системы. При добавление машины в сеть Qnet она получает доступ к ресурсам сети, и все машины сети получают доступ к ресурсам новой машины.
Можно также распараллелить программу на несколько машин. Процессы, выполняющиеся на разных машинах, с помощью Qnet могут прозрачно взаимодействовать между собой с помощью передачи друг другу сообщений. Ровно так же процессы взаимодействуют на одной машине.
Иные формы межпроцессорного взаимодействия также работают через Qnet (сигналы, очереди сообщений, именованные семафоры)
Для понимания того, как это работает, рассмотрим например системный вызов open() для открытия файла. В сети Qnet open() вызывается точно также, как и в случае одной машины, за одним исключением - необходимо дополнительно указать имя узла, на который отправляется команда. По этому имени впоследствии получается дескриптор узла, которые используется для коммуникации на низком уровне ядра.
Рассмотрим, как это работает подробнее. При подключении узла к сети Qnet, пространство путей файловой системы становится доступно всем машинам сети, т.е. мы получаем как бы примонтированную файловую систему добавленной машины ко всем машинам сети. Пространство путей каждой машины хранится в каталоге /net. Каталог /net создается менеджером Qnet. Каталог доступен только после включения Qnet.
Если, например, мы добавили узел node2 к нашей сети, то в каталоге /net мы увидим следующее:

/net/node2/bin

/net/node2/home

….. И так далее.

Таким образом, можно открывать файлы на удаленных машинах так, как будто они находятся на локальной машине.
Некоторые примеры использования Qnet:


  • Отобразить содержимое файла на машине node2:

less /net/node2/etc/TIMEZONE


  • Получение системной информации обо всех машинах подключенных к Qnet:

pidinnet


  • Получение информации о процессах на другой машине

pidin -nnode2 | less


  • Возможно, даже запускать процессы на удаленной машине:

on -fnode2 date
Открыть устройство, подключенное к последовательному порту на удаленной машине:
fd = open("/net/node2/dev/ser1", O_RDWR….);
Также можно получать доступ к очередям сообщений другой машины. При создании очереди с помощью mq_open() очередь появляется в системе в каталоге /dev/mqueue. На другой машине она будет доступна в каталоге /net/nodename/dev/mqueue.
Точно так же можно получить доступ к именованным семафорам на другой машине. Например, можно использовать адрес /net/nodename/semaphore_location в системном вызове sem_open().
Благодаря Qnet расширяется функционал моего кластера. Становится проще писать приложения для распределенного вычисления на нескольких узлах кластера. Программисту нужно будет указывать, с какими сервисами работать с помощью их путей в файловой системе удаленного узла. Если путь в удаленной системе заранее неизвестен, то к ресурсу можно обращаться по именам с помощью менеджера GlobalNameService.

GNS работает в двух режимах: серверном и клиентском. Серверный GNS - центральная база данных, которая хранит короткие имена и обрабатывает запросы на получение имени по пути в файловой системе и запросы на подключение. Клиентский GNS отдает имена ресурсов GNS серверу и обрабатывает запросы между локальными приложениями и GNS сервером.




Путь

Имя


Когда приложение взаимодействует с GNS оно использует следующее API:



  • Сервер использует name_attach() для регистрации сервиса в GNS и name_deattach для обратного процесса.

  • Клиент использует name_open() для открытия зарегистрированного сервиса и name_close() соответственно для его закрытия.

Так как такой функционал полезен в построении кластера рассмотрим этот процесс подробнее:


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


if ((attach = name_attach(NULL, "printer", NAME_FLAG_ATTACH_GLOBAL) == NULL){

returnEXIT_FAILURE;

}

В качестве аргументов в функцию передается имя сервиса, флаг глобальный/локальный и обработчик распределенного выполнения, который получается после создания структуры распределенного выполнения . Если в качестве первого аргумента указан ноль, структура распределенного выполнения создается автоматически.


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

if ((fd = name_open("printer", NAME_FLAG_ATTACH_GLOBAL)) == -1)

{

returnEXIT_FAILURE;



}

Если флаг не указывать GNS будет искать ресурс только локально.


Все зарегистрированные сервисы хранятся в каталоге /dev/name/global или /dev/name/local в зависимости от того, как они зарегистрированы.

Для всех узлов в локальной сети каталог /dev/name/global одинаковый. А каталог /dev/name/local хранит информацию о локально зарегистрированных сервисах.


Для корректной работы GNS нужен как минимум один GNS сервер. Он содержит у себя база данных всех зарегистрированных сервисов и управляет этой базой. GNS клиентов может быть много на разных узлах системы.
Для обеспечения нужной нам избыточности можно запустить 2 GNS сервера на разных узлах. Они будут содержать одинаковую базу данных сервисов. Также можно запустить два GNS сервера для работы в различных глобальных доменах.

В случае с избыточным GNS каждый клиент регистрирует сервис в каждом GNS сервере. Между собой GNS сервера общаться не могут.


c:\users\alex\appdata\local\temp\evernote camera roll 20130523 094027.jpg
Вот так выглядит избыточная конфигурация GNS сервера.
Два сервера GNS не обязательно запускать одновременно. Можно запустить сначала один, а затем через некоторое время второй с ключом -sbackup_server. То есть мы указываем второму серверу скачать все текущую базу с первого и уведомить всех клиентов о том, что появился еще один сервер.
Есть ситуации, когда одни клиенты подключены к одному серверу, а другие к другому. Для каждого сервера сервисы будут уникальны.
c:\users\alex\appdata\local\temp\evernote camera roll 20130523 094540.jpg
Таким образом, клиент определяет по какой схеме работают GNS сервера. Если клиент сконфигурирован на взаимодействие с двумя и более серверами значит конфигурация избыточная.
Нет никакого ограничения на количество запущенных GNS серверов, однако чем их больше, тем больше накладные расходы вызывает функция регистрации сервиса name_attach().
Помимо всего прочего QNET поддерживает QoS. В зависимости от заданной политики qnet распределяет трафик между сетевыми интерфейсами.
Существует три политики выбора интерфейса:


  • loadbalancing ( политика по умолчанию ) - равномерно распределяет трафик между интерфейсами




  • preffered - использует один интерфейс, игнорируя все другие, до тех пор пока интерфейс не откажет




  • exclusive - использует только один интерфейс, даже если он откажет

Рассмотрим подробнее каждую из них:




  • loadbalancing - Qnet решает какой из сетевых интерфейсов использовать в зависимости от текущей загруженность и скорости интерфейсов. Пакаты становятся в очередь к тому интерфейсу, который быстрее всех их обработает. Это позволяет повысить пропускную способность сети между узлами кластера. Если один из интерфейсов откажет, QNET автоматически переключится на другой доступный. Время переключения можно настроить. Qnet переодически шлет пакеты отказавшему интерфейсу для проверки того восстановился он или нет. Если интерфейс восстановлен Qnet снова его задействует.




  • preffered - В данном случае можно назначить интерфейс, который будет использоваться в одиночку до тех пор пока не откажет. После этого Qnet переключается на другой доступный интерфейс и продолжает передачу данных, но уже с политикой loadbalancing. Когда предпочитаемый интерфейс восстанавливается, Qnet снова использует только этот интерфейс.




  • exclusive - Здесь используется только один интерфейс, не зависимо от того сколько интерфейсов еще доступно. Если такой интерфейс откажет Qnet не будет использовать доступные интерфейсы.

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

/net/node1~exclusive:en0/dev/ser1
Помимо всего вышеописанного QNX поддерживает очень важный и ключевой механизм для моей работы: менеджер высокой доступности (HAM – High Avaliability Manager).
Существуют ситуации, когда добавление избыточного железа просто не подходит. Да и само по себе избыточное железо может стать причиной сбоев, т.к. чем сложнее система и чем больше в ней компонентов, тем больше шансов, что какой-то из компонентов откажет.
QNX сама по себе является системой высокой доступности и поэтому отлично подходит для таких ситуаций. Помимо уже описанной микроядерности QNX предоставляет компоненты высокой доступности: HAM - high avaliability manager (менеджер высокой доступности) и high availability client-side library (клиентская библиотека высокой доступности).
Клиентская библиотека высокой доступности предоставляет функции, позволяющие автоматически и прозрачно восстановить подключения ресурсов, вышедшие из строя. Клиент может выбрать какие именно подключения сделать высоко доступными. В обычной системе, когда клиент общается с сервером и происходит сбой, клиенту возвращается ошибка. В случае использования библиотеки соединение восстанавливается практически незамедлительно.
Рассмотрим в качестве примера ситуацию, когда клиент открывает файл через сетевую файловую систему. Если вдруг NFS сервер, по какой-то причине отключится HAM перезапустит его и примонтирует заново. В обычной ситуации все открытые сессии будут устаревшими. Если же использовать функцию библиотеки высокой доступности ha_attach, все сессии сами восстановятся. Функция ha_attach позволяет клиенту предоставить собственную функцию восстановления соединения, которая будет вызвана автоматически. Функция восстановления может просто перезапустить сессию или же произвести более детальное восстановление.


#include

#include

#include

#include

#include

#include

#include

#include


#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(), то стандартные библиотечные функции (open(), read(), write(), printf() и т.д.) также можно сделать высокодоступными.
Непосредственно процесс восстановления осуществляет HAM - менеджер ресурсов, мониторит критически важные ресурсы и выполняет многоступенчатое восстановления после сбоя. HAM использует простую систему издатель/подписчик для мониторинга возникновения различных событий. Реакцией на возникновение события может быть действие или последовательность действий. К примеру мы запустили NFS, а затем примонтировали несколько директорий из различных мест. Можно указать менеджеру просто перезапустить NFS в случае сбоя, а можно кроме перезапуска еще и заново примонтировать соответствующие директории.
HAM является каналом, по которому остальные части системы могут получать и доставлять информацию о состоянии системы в целом.
В построении отказоустойчивой системы очень важно чтобы не было так называемой единой точки отказа - компонента, выход из строя которого приведет к выходу из строя всей системы. HAM, осуществляющий мониторинг системы и ресурсов сам по себе никогда не должен стать единой точкой отказа. Во время запуска HAM создает точную копию себя - процесс под названием Guardian. Guardian ждет пока HAM откажет и, в этом случае, становится на его место. Если, по какой то причине, откажет сам Guardian то HAM заменит его, создав новую копию себя.
Рассмотрим подробнее как устроен HAM.
HAM состоит из трех основных частей :


  • Сущности

  • Условия

  • Действия




  • Сущности - объекты, за которыми следит HAM. Обычно это pid процесса. Так же как и процессы сущности идентифицируются по уникальному дескриптору. С каждой сущностью ассоциировано символьное имя, уникальное в пределах одной системы.

Существует три фундаментальных типа сущностей:




  • Самоприсоединенные сущности. Такие сущности сами выбирают что и когда мониторить, а также когда остановить мониторинг. Такие сущности говорят менеджеру "Сделай то то если я умру".




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




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




  • Условия - представляют состояние сущностей.




Условие

Описание

CONDDEATH

Сущность умерла.

CONDABNORMALDEATH

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

CONDDETACH

Сущность больше не является объектом мониторинга HAMа.

CONDATTACH

HAM мониторит сущность.

CONDBEATMISSEDHIGH

The entity missed sending a "heartbeat" message specified for a condition of "high" severity.

CONDBEATMISSEDLOW

The entity missed sending a "heartbeat" message specified for a condition of "low"

CONDRESTART

Сущность была успешно перезапущена.

CONDRAISE

Произошло какое то внешнее событие. Подписчики на это события могут указывать что делать при его возникновении.

CONDSTATE

Состояние сущности изменилось. Подписчики на изменения могут также указывать что при этом делать.

CONDANY

Любое условие. Можно также ассоциировать какое то действие с этим условием

     

Для всех условий, кроме CONDRAISE и CONDSTATE HAM является издателем. Подписчики могут объявлять набор действий производимых при появлении соответствующего условия.




  • Действия

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





Действие

Описание

ham_action_restart()

Перезапустить сущность.

ham_action_execute()

Запустить какую - либо команду.

ham_action_notify_pulse()

Уведомить процессы о возникновении условия. Уведомление посылается со специальной переменной pulse, значение которой задает процесс, желающий получить уведомление.

ham_action_notify_signal()

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

ham_action_notify_pulse_node()

То же самое что и ham_action_notify_pulse() только с указанием конкретного узла

ham_action_notify_signal_node()

То же самое что и ham_action_notify_signal() только с указанием конкретного узла

ham_action_waitfor()

Позволяет организовывать паузы между действиями, если их несколько

ham_action_heartbeat_healthy()

Если сущность перестает посылать сигналы heartbeat функция перезапускает механизм и запускает условие CONDBEATMISSEDHIGH или CONDBEATMISSEDLOW.

ham_action_log()

Посылает условие в лог.

На случай если эти действия вдруг не сработают или откажут можно указать дополнительные функции обработки таких отказов: 




  • 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 об изменении своего состояния. HAM в ответ на это генерирует определенные события. Заинтересованный компонент подписывается на эти события и обрабатывает их. 

Для уведомления об изменении состояния необходимо вызвать функцию ham_entity_condition_state(). Для подписки на такие уведомления необходимо вызвать функцию ham_condition_state().




  • Другие уведомления.

В дополнении к вышеописанному сущности могут уведомлять HAM о событиях с помощьюфункции ham_entity_condition_raise(). При этом дополнительно можно указывать тип, класс и приоритет события. Благодаря этому можно подписываться на более специфические условия. Подписка осуществляется с помощью функции ham_condition_raise().

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



Каталог: data -> 2013
2013 -> Федеральное государственное автономное образовательное
2013 -> «Визуальный образ персонажей массового кинематогрфа в историческом контексте»
2013 -> 2 раздел анализ предметной области 5
2013 -> Магистерская диссертация
2013 -> Влияние вовлеченности на готовность платить за коллекционные товары
2013 -> Выражение гендерных характеристик в англоязычном "глянцевом" дискурсе
2013 -> Продакт Плейсмент и перспективы его развития в сети Интернет
2013 -> 1Лекции первого полугодия
2013 -> «Правовое рассмотрение компьютерного мошенничества», Ницца, 22 октября 1992 года, грамота «весьма достойно»


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал