Материал: Разработка программного комплекса для анализа состояния системы хранения данных EMC Centera

Анализ журналов ОС, программной платформы и бизнес-логики кластера за определённый промежуток времени с целью поиска заданного шаблона сообщения

Генерирование и анализ отладочных журналов ОС, программной платформы и бизнес-логики кластера

Анализ файлов конфигурации ОС, программной платформы и бизнес-логики

Анализ состояния сетевых интерфейсов узлов кластера

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

Анализ состояния функциональных компонентов СХД Centera

Анализ состояния ресурсов ОС EMC Centera Linux и их потребителей

Анализ состояния коммутаторов внутренней ВС кластера

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

Автоматизация и создание реализации в виде удобного программного средства для методик 1-3 и 5 позволит сократить время анализа причин сбоя, при которых ранее предполагалось использовать только средства командной строки ОС EMC Centera Linux; в свою очередь такая автоматизация позволит повысить эффективность труда сотрудников, вовлечённых в устранение таких сбоев, а также повысить удовлетворённость пользователей, СХД Centera которых испытала указанный вид сбоя.

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

.5 Постановка задачи дипломного проектирования

Задачей данного проекта является проведение комплекса работ, направленных на создание программного комплекса для анализа состояния СХД Centera, соответствующего заданным требованиям и ограничениям, пригодного к использованию в предназначенной области.

Перечень работ, подлежащих выполнению в ходе дипломного проектирования:

анализ требований и ограничений, предъявляемых к программному комплексу, с целью выработки стратегии его разработки;

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

реализация программного комплекса с помощью указанных в задании средств согласно разработанной структуре;

выбор методик тестирования реализации программного комплекса, а также проведение тестирования с целью проверки пригодности полученной реализации к использованию по назначению - для проведения анализа состояния СХД Centera;

создание технической документации на программный комплекс.

. АНАЛИЗ ТРЕБОВАНИЙ И ОГРАНИЧЕНИЙ РЕАЛИЗАЦИИ ПРОГРАММНОГО КОМПЛЕКСА

Необходимо разработать программный комплекс для выполнения задач, связанных с анализом состояния СХД Centera.

Кроме перечисленных в п. 1.4.3 четырёх основных задач программный комплекс для анализа состояния СХД Centera предназначен для выполнения следующих вспомогательных задач, которые позволяют сократить время на анализ состояния СХД Centera:

Преобразование упорядоченного битового набора из 8-разрядного (байтового) представления в 6-разрядное (Base64) представление, а также выполнение обратного преобразования.

Декодирование содержимого сетевого пакета типа SmartPacket в его текстовое представление.

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

Детальное описание всех задач приводится далее в данном разделе. Задачи, имеющие своей целью сбор информации с узлов СХД, имеют исчерпывающее описание за исключением путей к файлам, содержащим требуемую информацию. Непосредственный доступ к файлам с информацией должен быть осуществлён через серверную библиотеку, предоставляемую отделом разработки СХД Centera и описанную далее в этом разделе.

Программный комплекс представляет собой два компонента - клиентский и серверный, взаимодействующих согласно протоколу; при этом серверный компонент выполняется на одном из узлов СХД Centera, а клиентский компонент выполняется на рабочей станции сервисного инженера, имеющей соединение с узлом СХД Centera, на которой выполняется серверный компонент. В этом разделе также приводится описание особенностей и ограничений, предъявляемых к реализации обоих компонентов и протокола взаимодействия.

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

.1 Выполняемые программным комплексом задачи по анализу состояния СХД Centera

Поиск записей в журналах СХД по заданному шаблону.

Пользователем задаются следующие исходные данные:

Временной интервал с точностью до суток, за который будет производиться поиск сообщений в журналах; при отсчёте начала и завершения суток время принимается в часовом поясе всемирного координированного времени (Coordinated Universal Time - UTC).

Список узлов системы, на которых будет производиться поиск.

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

Шаблон сообщения, которому должны соответствовать все найдённые в журналах сообщения; шаблон может быть задан пользователем в формате регулярных выражений (RegExp - regular expressions).

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

Генерирование отладочных журналов бизнес-логики с указанными пользователем параметрами:

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

Минимальный уровень важности сообщений, записываемых в отладочный журнал; всего имеется 5 уровней важности от самой низкой к самой высокой: DEBUG, VERBOSE, STATUS, WARNING, ERROR.

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

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

Пользователь инициирует начало генерирования отладочного журнала с заданными параметрами, а впоследствие и завершает его генерирование. Допускается прерывание генерирования отладочного журнала при перезагрузке ОС узла СХД, на котором оно производится.

Генерирование журналов сетевого взаимодействия на одном из интерфейсов узла СХД Centera. Журнал должен представлять собой файл в формате программной библиотеки LibPcap (формат результирующего файла утилиты tcpdump). Создание журналов должно производиться в соответствии с заданными пользователем условиями:

Список узлов системы, на которых будет производиться генерирование журналов трафика ВС.

Трафик должен перехватываться только на интерфейсе, указанном пользователем; для выбора могут быть предоставлены только интерфейсы eth0, eth1 и eth2.

Сетевой пакет может быть зажурналирован, если он удовлетворяет условиям фильтра, указанного пользователем с использованием синтаксиса фильтра пакетов утилиты tcpdump [3].

Пользователь инициирует начало генерирования журнала сетевого взаимодействия, а впоследствие и завершает его генерирование. Допускается прерывание генерирования журнала сетевого взаимодействия при перезагрузке ОС узла СХД, на котором оно производится. В один момент времени на узле может происходить создание только одного журнала сетевого трафика.

Копирование файлов конфигурации и журналов СХД Centera на рабочую станцию пользователя для последующего анализа. Процесс копирования должен соответствовать следующим условиям:

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

Доступные для копирования файлы должны быть указаны только для узлов СХД, которые задал пользователь

Доступные для копирования файлы должны соотвтетствовать тому перечню типов, который указал пользователь; полный список доступных типов файлов должен быть изменяем через конфигурационный файл на стороне клиентского компонента с указанием доступных для копирования типов журналов и конфигураций СХД. Минимальный список доступных для скачивания файлов должен включать журналы ОС, программной платформы, бизнес логики и сетевого трафика, а также конфигурацию СХД уровня кластера (Cluster Parameters) и уровня узлов (Node Parameters).

После выбора файлов для копирования пользователь инициирует этот процесс и задаёт путь для сохранения получаемых с СХД Centera данных; в процессе копирования пользователю предоставляется информация о прогрессе копирования.

Кодирование упорядоченного набора байтов в печатные символы ASCII, используя алгоритм Base64 [4], а также обратное декодирование; при этом исходные данные и результат должны соответствовать следующим параметрам:

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

Пользователь указывает местоположение файла для результатов кодирования/декодирования.

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

Декодирование содержимого сетевого пакета типа SmartPacket в его текстовое представление, подчиняющееся следующим правилам:

Пользователь указывает местоположение файла с содержимым сетевого пакета типа SmartPacket.

Декодирование содержимого должно происходить на узле СХД Centera с использованием версии бизнес-логики, совпадающей с версией бизнес-логики, создавшей декодируемый SmartPacket.

Декодированный пакет должен быть представлен пользователю в текстовом виде с расшифровкой всех полей SmartPacket, в каком он представляется после декодирования бизнес-логикой СХД Centera.

Сжатие и декомпрессия набора байтов, используя алгоритм сжатия ZLIB [5]. Пользователь задаёт местоположение файла с исходными данными, направление преобразования (сжатие/декомпрессия) и местоположение файла для сохранения результата.

2.2 Взаимодействие клиентского и серверного компонентов программного комплекса

Клиентский компонент выполняется на рабочей станции пользователя (сервисного инженера), серверный компонент выполняется на узле СХД Centera, для чего он предварительно загружается на узел.

Взаимодействие между компонентами программного комплекса происходит внутри соединения Secure Shell (SSH) [6], установленного между клиентским компонентом и ОС узла СХД Centera. Это единственное соединение, которое гарантированно работает при функционирующих сетевом интерфейсе и ОС узла СХД. В контексте этого соединения происходит взаимодействие двух компонентов по протоколу.

Общая структура компонентов программного комплекса и узла СХД, а также способы их взаимодействия изображены на рис. 2.1 .

Канал управления и передачи данных по протоколу SSH

Взаимодействие между клиентским компонентом, выполняемом на рабочей станции пользователя, и серверным компонентом, выполняемым на узле СХД Centera, осуществляется через соединение по протоколу Secure Shell (SSH). В рамках этого соединения посылаются команды от клиентского компонента серверному и происходит передача данных, используя ФС узла СХД как промежуточное звено в передаче.

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

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

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

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

Ограничения на реализацию клиентского компонента

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

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

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

Стремлением произвести структурную декомпозицию клиентского компонента с целью уменьшения количества зависимостей между его модулями. В случае смены протокола взаимодействия между клиентским компонентом и ОС СХД Centera потребуется только адаптировать реализацию клиентской библиотеки.

Требованием скрыть пути к системным директориям и файлам СХД Centera, чтобы не влиять тем самым на защищённость СХД Centera.

Рисунок 2.1 Схема взаимодействия компонентов СХД Centera и программного комплекса для анализа состояния СХД

Окружение среды исполнения

Клиентский компонент должен исполнятся в среде исполнения Java Runtime Environment 6.0 под управлением ОС Microsoft Windows XP Service Pack 2 или Service Pack 3.

Потребление ресурсов ОС

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

Хранение временных и служебных файлов, «рабочая директория»

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

Хранение результатов работы

Если получение результатов работы от серверного компонента не подразумевает их сохранение в директории, указанной пользователем, то для хранения таких результатов следует пользоваться директорией для временных и служебных файлов (см. пп 4) настоящего пункта). По окончании времени хранения результатов выполнения задачи такие результаты должны быть удалены из памяти и файловой системы, если они сохранены в «рабочую директорию».