1.5. Постановка задачи
Целью дипломного проекта является разработка программного модуля диспетчера высокой готовности для ОСРВ QNX 4.25, позволяющего запускать различные конфигурации отказоустойчивого кластера, а также в режиме реального времени проводить мониторинг его состояния. Исходя из требований, предъявляемых проекту необходимо разработать 3 основных блока программного комплекса:
блок менеджера проектов;
блок создания и изменения конфигураций кластера;
блок мониторинга состояния кластера.
Рисунок 4. Структурная схема комплексного программного обеспечения «Кластер»
При этом каждый из блоков, с которыми взаимодействует пользователь, должен обладать своим графическим интерфейсом, позволяющим оператору производить нужные операции в максимально упрощенной форме, а режим мониторинга должен быть максимально информативным визуально.
Кроме того, каждый из блоков будет взаимодействовать со сторонними элементами операционной системы:
блок менеджера проектов должен производить функции записи и чтения из файловой системы
блок конфигуратора кластера должен иметь доступ как к файловой системе для хранения и изменения конфигураций, так и доступ к сети, позволяющей отдавать команды стороннему программному обеспечению для инициализации конфигурационных файлов будущих узлов кластера
блок мониторинга состояния должен иметь доступ к сети для постоянного обмена пакетами статистики состояния узлов и последующего ее отображения оператору
Следовательно, каждую из особенностей блоков необходимо вынести как отдельную составляющую каждого блока.
Глава 2. Разработка алгоритмов программного обеспечения 2.1. Разработка алгоритмов и программного обеспечения модуля создания и изменения конфигураций кластера
Одним из основных блоков комплекса программного обеспечения отказоустойчивого кластера является модуль конфигуратора кластера. Создание конфигураций и их дальнейшая инициализация – первая задача, которую должен решать программный продукт, рассматриваемый в данном дипломном проекте.
Отказоустойчивый кластер – вычислительный комплекс из 3-х узлов, на каждом из которых могут быть запущены различные процессы. Конфигурацией в текущем контексте называется совокупность параметров, характеризующих каждый из узлов кластера, перечень задач, запущенных на узлах и особенности взаимосвязи этих задач между собой. Поскольку такой набор параметров представляет собой достаточно большой объем структурированной информации, необходимо реализовать программный пользовательский интерфейс, позволяющий задавать эти параметры в удобной оператору форме и дающий возможность максимально быстро их изменять и модифицировать.
2.1.1. Блок создания, изменения и хранения конфигураций
Структура конфигураций кластера состоит главным образом из элементов, отвечающих за параметры узла и элементов, отвечающих за параметры процессов запущенных на каждом из узлов. Для того, чтобы информация была в достаточной мере структурирована и удобна в использовании, была разработана иерархия хранения информации конфигурации и формат хранения данных конфигурации.
Суть иерархии заключается во вложенности параметров. Для пользователя главной сущность является сама конфигурация, модифицируя которую он прежде всего столкнется с добавлением в нее узлов и заданием их параметров. После того как узел добавлен в конфигурацию, можно приступать к добавлению процессов, которые при инициализации конфигурации будут запущены на выбранном узле.
Схематично иерархия конфигурации представлена на Рис. 5.
 Рисунок 5. Иерархия формата конфигурации кластера
Настройки узлов в конфигурации кластера
В соответствии с требованиями заказчика каждый узел должен иметь в конфигурации некий минимум информации, характеризующей его назначение. В связи с этим при создании узла оператор назначает уникальный цифровой идентификатор узла кластера, задает имя узла (к примеру «Главный») и может добавить к нему краткое описание, чтобы в дальнейшем, при редактировании или пересмотре конфигурации можно было понять функции выбранного узла. К примеру, на первом узле будут запущены все процессы, которые должны выполняться системой. А оставшиеся 2 узла будут выполнять резервирующую функцию. Тогда первому можно будет в описании указать, что все процессы должны выполняться на нем, а двум другим, что они резервные. В итоге изменяя информацию о процессах, оператор уже заранее будет знать, что распределение процессов на другие узлы в начальной конфигурации выбранного проекта не предусматривалось и, следовательно, не допустит ошибок.
Также стоит отметить, что после распределения процессов по узлам пользователю доступна возможность упорядочивания запуска заданных процессов, что позволяет изменять очередность запуска задач не прибегая к редактированию самих задач.
Вся конфигурация хранится единой структурой, записываемой в конфигурационный файл проекта. Для хранения параметров узлов в ее состав входят структуры, отвечающие за узлы.
Разработанный тип хранения данных узлов, оформленный в виде структуры, выглядит на языке Си следующим образом:
typedef struct
{ int NodeId;
char Name[20];
char Descr[255];
char ProcFile[20];
struct Node *next;
} Node;
Node Nodes[3];
Следовательно, для трех узлов объявляется 3 структуры такого типа.
Настройки процессов на узлах в конфигурации кластера
После добавления в конфигурацию узлов оператор может распределить процессы по узлам кластера. При этом есть 2 возможных варианта распределения, подходящих для разных ситуаций:
распределение всех процессов по узлам после добавления узлов;
распределение процессов на конкретном узле сразу же после его создания.
Первый вариант удобен когда между процессами на разных узлах должна быть установлена некая зависимость или связь, тогда невозможно задать эту зависимость, если узла и, соответственно, нужного процесса на нем в конфигурации еще нет. Второй же вариант позволяет распределить процессы на узле сразу же после его создания, используется, если конфигурация линейна.
Каждый процесс, также как и узел, имеет свой уникальный идентификатор, имя и описание. Но помимо стандартных параметров процессу могут быть заданы дополнительные свойства:
параметры запуска процесса;
приоритет запуска процесса;
флаг запуска при старте;
весовой коэффициент процесса;
индекс очередности запуска;
привязка процесса к определенному IP-адресу;
зависимость от другого процесса.
Такие параметры как приоритет, индекс и флаг запуска, а также весовой коэффициент созданы для дальнейшего учета при возникновении ситуаций, когда процессы необходимо перераспределить. К примеру, чем выше приоритет процесса, тем больше процессорного времени он получит, чем выше весовой коэффициент, т.е. важность процесса, тем на более свободный узел он будет перенаправлен. Привязка к адресу может быть сделана для того, чтобы при миграции с одного узла на другой, система учла этот параметр и переназначила новому узлу старый адрес для дальнейшего корректного функционирования мигрирующего процесса.
Каждый из данных параметров также хранится в структурах, характеризующих каждый из процессов. Для этого был разработан формат хранения структур и на языке Си он выглядит следующим образом:
typedef struct
{ int Num;
int Descr[255];
char FileName[100];
char Opts[20];
int Deps[299];
int Prio;
int Run;
int Order;
int Weight;
} Process NodePcs[3][300];
Нижняя строчка информирует нас о том, что данным типом будет объявлен двумерный массив, первый идентификатор которого привязывает процесс к узлу, а второй закрепляет за процессом его уникальный идентификатор на этом узле. Количество процессов в 300 штук вызвано ограничением на узел, установленным заказчиком.
Помимо возможностей добавления узлов, редактор конфигурации также позволяет удалять и изменять уже имеющиеся в конфигурации элементы. При этом данные, загруженные ранее из структур, обнуляются, а флаги их существования устанавливаются в значение «-1», что делает адресное пространство, ранее используемое ими, снова доступным для заполнения уже новыми данными.
После создания в визуальном редакторе конфигурации для кластера для ее дальнейшего использования ее необходимо сохранить. Сохранение конфигурации происходит на жесткий диск в конфигурационный файл, находящийся в папке с проектом, в бинарном виде для простоты последующего считывания.
Перед сохранением конфигурации она может быть проверена встроенным анализатором. Это первичная диагностика ошибок ввода оператора. К примеру, пользователь ввел вместо имени узла последовательность знаков препинания, тогда процедура проверки, обнаружив некорректный ввод, выведет предупреждение и предложит пользователю заполнить имя названием по умолчанию, к примеру, Node1.
Стоит отметить очень важную особенность, присутствующую в каждой конфигурации – наличие главного узла сети. Главный узел – такой же узел кластера, как и остальные с технической точки зрения, но имеющий некоторые отличия в полномочиях и функционале. Прежде всего главный узел тот, который был добавлен в систему первым и в случае его аварии все его права и обязанности будут переданы следующему узлу по порядку добавления. Основная задача главного узла – сбор статистики со всех второстепенных узлов, превращение общей статистики в единый пакет заранее разработанного формата и его пересылка остальным узлам для резервирования. То есть с точки зрения информации, основное отличие главного узла – то, что он является первым из узлов, имеющих полную статистику по всем узлам, а не только по самому себе. После пересылки ее остальным узлам, уже все узлы будут располагать достаточной информацией для восстановления.
Вторым отличием главного узла от остальных является наличие полномочий принятия решения о перераспределении ресурсов между узлами кластера. Поскольку именно главному узлу первому доступна вся статистики использования и загрузки всех узлов сети, то именно на него возложена роль анализа состояния кластера и его оптимизация. Функции анализа загрузки и операции распределения задач по узлам кластера выполняются сторонним статистическим модулем, входящим в состав программного комплекса «Кластер».
Обязанности узлов и пути передачи информации иллюстрированы на рис. 6.
Рисунок 6. Обязанности узлов кластера
Алгоритм, отражающий работу блока создания конфигураций, приведен на рис. 7.
Рисунок 7. Алгоритм работы модуля создания конфигурации кластера
2.1.2. Блок инициализации кластера по созданной конфигурации
После создания конфигурации в редакторе, она может быть сразу превращена в реальную систему. Для этого в интерфейсе конфигуратора предусмотрена кнопка «Создать».
После нажатия пользователем кнопки «Создать» узел, на котором запущена программа конфигурации, дает команды всем узлам сети для создания в корневом разделе их файловых систем файловой структуры определенной иерархии, хранящей конфигурационные файлы, отвечающие за параметры узлов и процессов. После создания файловой иерархии, узел рассылает всем узлам соответствующие пакеты с данными, характеризующими каждый из узлов, и этими данными заполняются рабочие файлы. Файловая иерархия, создаваемая на каждом из узлов, приведена на рис. 8.
Рисунок 8. Файловая иерархия узла кластера
Каталог с рабочими фалами всех узлов находится по адресу //home/cluster каждого из узлов и содержит приведенный на рис. 6 набор файлов и директорий.
Папка +bin при работе кластера будет содержать уже скомпилированные для исполнения файлы процессов. Файл f_cluster.cfg содержит конфигурационную информацию, касающуюся узла. Папка +node_1 хранит в себе все файлы, отвечающие за пути к выбранным процессам, временные файлы, общие ресурсы узла и конфигурационные файлы процессов. Цифра в названии этой папки говорит об уникальном идентификаторе рассматриваемого узла.
После того, как файлы были скопированы и заполнены, на узле в соответствии с настройками начинается последовательный запуск процессов, указанных в файле procfile.cfg. Фактически, каждый узел кластера начинает функционирование в своем рабочем режиме.
2.1.3. Графический интерфейс пользователя для создания конфигураций кластера
Графический интерфейс пользователя в режиме создания и редактирования конфигураций кластера оформлен в виде отдельного всплывающего окна, вызываемого из главного меню программы.
Для удобства восприятия окно конфигуратора поделено на 3 области:
область задания и настройки узлов;
область задания и настройки процессов;
управляющая область – кнопки сохранения, проверки и применения созданной конфигурации.
Каждый управляющий блок кнопок, относящийся к свой области (узлы, процессы), имеет отличный от всего стиля интерфейса цвет надписей и хорошо выделяется, что делает интерфейс интуитивно понятным. Интерфейс окна конфигуратора показан на рис. 9.
После создания узла или процесса его можно повторно отредактировать в дальнейшем. Для этого его просто необходимо выделить в списке узлов/процессов и нажать клавишу изменить. Поля параметров станут доступными для редактирования. Также для удаления элемента из конфигурации его необходимо выделить и нажать соответствующую кнопку удаления.
Рисунок 9. Пользовательский интерфейс в режиме конфигуратора
Все поля, где необходимо вводить цифровые значения, дополнены «качельками» вверх-вниз, для возможности альтернативного ввода без использования клавиатуры.
Также стоит отметить, что несмотря на то, что окно является всплывающим, оно не имеет кнопок закрытия и его невозможно свернуть. Это одна из мер безопасности, принятых для того, чтобы пользователь не мог выйти из режима редактирования, сознательно сохранив или отменив внесенные в конфигурацию изменения.
Все списковые элементы, а именно: узлы, процессы и зависимости между процессами выделяются синим цветом, как показано на рисунке 8. Яркий цвет выбран для того, чтобы пользователь всегда четко видел выделенный элемент, с которым он работает и не мог допустить случайную ошибку.
Рисунок 10. Пользовательский интерфейс в режиме конфигуратора при добавлении процессов на узел
|
