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

«Logging - Search in logs…»

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

Подпункт недоступен, если соединение с СХД в настоящий момент не установлено.

«Logging - Custom logging…»

Отображает окно со списком текущих генерируемых отладочных журналов.

Подпункт недоступен, если соединение с СХД в настоящий момент не установлено.

«Logging - TCP dumping…»

Отображает окно со списком текущих генерируемых журналов сетевого трафика.

Подпункт недоступен, если соединение с СХД в настоящий момент не установлено.

«Logging - Download…»

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

Подпункт недоступен, если соединение с СХД в настоящий момент не установлено.

«Analysis - Base64 encode/decode…»

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

«Analysis - SmartPacket decode…»

Открывает стандартное окно открытия файла с содержимым пакета типа SmartPacket, затем происходит запрос к серверному компоненту для декодирования и в случае успеха выводится окно с результатами декодирования.

Подпункт недоступен, если соединение с СХД в настоящий момент не установлено.

«Analysis - ZLIB compress/decompress…»

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

«Help - User's manual page»

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

«Help - About»

Открывается диалоговое окно с кратким описанием программного комплекса и его выполняемой версией.

«Windows»

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

Требования к окнам графического интерфейса

Окно «Choose connection»

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

Окно должно содержать:

поле ввода адреса узла СХД;

поле ввода имени профиля;

кнопку «Ok», при нажатии данное окно пропадает и перед началом установки соединения с кластером выводится окно «Enter password» для ввода пароля (см пп 3);

кнопку «Cancel», при нажатии которой завершается выполнение клиентского компонента;

список ранее введённых параметров соединений (имя соединения, адрес узла СХД Centera, имя профиля); при выборе элемента списка соединение с кластером будет производиться, используя параметры элемента списка;

кнопки «Add…», «Edit…» и «Remove» для соответственно добавления, редактирования и удаления элемента списка; при нажатии кнопок «Add…» и «Edit…» открывается окно «Edit cluster connection» (см пп 2) для редактирования параметров соединения.

Изменение размера окна пользователем не допускается.

Окно «Edit cluster connection»

Модальное диалоговое окно, предназначенное для редактирования параметров соединения с узлом СХД Centera.

Окно должно содержать:

поле ввода названия соединения;

поле ввода адреса узла СХД;

поле ввода имени профиля;

кнопку «Ok», при нажатии которой изменения параметров указанного соединения сохраняются;

кнопку «Cancel», при нажатии которой отменяется редактирование параметров соединения;

Изменение размера окна пользователем не допускается.

Окно «Enter password»

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

Окно должно содержать:

поле ввода пароля, скрывающее символы, вводимые пользователем;

кнопку «Ok», при нажатии которой окно пропадает и начинается установка соединения с кластером, используя параметры соединения и пароль, указанные пользователем; при успешной установке соединения отображается окно «Main frame» (см пп 4), в противном случае выводится информационное сообщение «Can't establish connection with specified address» и снова отображается окно «Choose connection» (см пп 1);

кнопку «Cancel», при нажатии которой отменяется попытка установить соединение, окно пропадает и снова отображается окно «Choose connection» (см пп 1);

Изменение размера окна пользователем не допускается.

Окно «Main window»

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

Окно должно содержать:

кнопки в заголовке окна для развёртывания до полного размера рабочего стола, а также свёртывания в панель задач;

меню команд, размещённое в верхней части рабочей области окна; состав меню и описание действий пунктов меню приводится в п 2.3.2;

строку состояния в нижней части рабочий области, в которой отображается статус соединения с кластером и параметры этого соединения;

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

Окно «Exit»

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

Окно должно содержать:

текст подтверждения желания пользователя завершить работу с клиентским компонентом;

триггер остановки серверного компонента при выходе из клиентского компонента (по умолчанию выключен);

триггер удаления содержимого сессии на стороне серверного компонента (по умолчанию выключен);

кнопку «Yes», при нажатии которой окно пропадает и завершается работа клиентского компонента с закрытием всех его окон;

кнопку «No», при нажатии которой окно пропадает, но работа программы продолжается без изменений;

Изменение размера окна пользователем не допускается.

Окно «Sessions»

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

Окно должно содержать:

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

имя узла СХД, на которой находится содержимое сессии

является ли сессия активной

дата и время создания сессии

суммарный размер файлов, принадлежащих сессии

кнопку «Resume», при нажатии которой произойдёт подмена текущей установленной сессии выбранной сессией, а текущая сессия станет неактивной; кнопка должна быть активирована только для неактивных выбранных сессий, находящихся на узле СХД, с которым установлено соединение;

кнопку «Remove», при нажатии которой содержимое выбранной в списке сессии удаляется с кластера; кнопка должна быть активирована только для неактивных сессий;

кнопку «Cancel», при нажатии которой происходит закрытие окна.

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

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

Окно «Search in logs»

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

Окно должно содержать:

поля ввода «From date» и «To date», содержащие дату начала и соответственно конца временного диапазона в журналах, в котором будет производиться поиск сообщений;

поле ввода «Nodes», содержащее отделённые запятой имена узлов СХД Centera, на которых будет производиться поиск в журналах;

кнопку «Select nodes…», открывающую диалоговое окно для удобного выбора набора узлов СХД, на которых будет производиться поиск (см пп. 8);

триггеры «Business-logic», «Platform» и «OS», разрешающие поиск сообщения в журналах соответственно бизнес-логики, программной платформы и ОС EMC Centera Linux (по умолчанию все триггеры выключены);

поле ввода «Search pattern», содержащее шаблон сообщения, поиск которого будет производиться в журналах;

триггер «Regular expression», включение которого будет означать, что шаблон сообщения задан в виде регулярного выражения (по умолчанию выключен);

поле ввода пароля, скрывающее символы, вводимые пользователем;

кнопку «Search», при нажатии которой окно пропадает и открывается окно «Log» для вывода найденных в журналах сообщений (см пп 9) согласно заданным пользователем параметрам; кнопка активирована, если включено не менее одного триггера выбора типа журнала, в котором производится поиск;

кнопку «Cancel», при нажатии которой отменяется поиск сообщения в журналах и окно пропадает.

Изменение размера окна пользователем не допускается.

Окно «Select nodes»

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

Окно должно содержать:

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

выпадающий список с предустановленными наборами узлов, при выборе которых происходит автоматическое выделение подходящих узлов в списке узлов этого окна; минимальный перечень предустановленных наборов должен содержать: «All» (все узлы), «Access» (только узлы с ролью Access), «Replication» (только узлы с ролью Replication), «Storage» (только узлы с ролью Storage);

кнопку «Ok», при нажатии которой окно пропадает и выбранный пользователем набор узлов возвращается родительскому окну;

кнопку «Cancel», при нажатии которой отменяется выбор пользователя и родительское окно сохраняет предыдущий выбор узлов СХД Centera;

Изменение размера окна пользователем не допускается.

Окно «Log»

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

Окно должно содержать таблицу размером во всю рабочую область окна со следующими колонками:

время добавления сообщения в журнал

узел СХД, на котором произошло добавление

текст сообщения

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

Допускается изменение размеров окна пользователем вместе с размерами таблицы сообщений.

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

Окно «Custom logging»

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

Окно должно содержать:

список созданных в рамках текущей сессии отладочных журналов в виде таблицы со следующими колонками:

минимальный уровень сообщений, добавляемых в журнал

название модуля бизнес-логики, сообщения которого добавляются в журнал

набор узлов, на которых генерируется журнал

дата и время начала генерирования журнала

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

кнопку «Start new log…», при нажатии которой откроется окно «Create new custom log» (см пп. 11) для выбора параметров создания отладочного журнала; при успешном задании параметров нового журнала он добавляется в список журналов;

кнопку «Stop log», при нажатии которой генерирование выбранного в списке журнала заканчивается, а журнал удалается из списка; кнопка должна быть активирована только при выбранном в списке журнале;

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

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

Окно «Create new custom log»

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

Окно должно содержать:

поле ввода «Nodes», содержащее отделённые запятой имена узлов СХД Centera, на которых будет производиться создание журнала;

кнопку «Select nodes…», открывающую диалоговое окно для удобного выбора набора узлов СХД, на которых будет производиться создание журнала (см пп. 8);

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

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

список фильтров сообщений в виде таблицы, содержащей следующие колонки:

тип фильтра; поля элементов в данной колонке представляют собой выпадающие списки; в данной версии допускается наличие только одного типа фильтра - «message»;

значение фильтра; поля элементов списка в данной колонке представляют собой текстовые поля ввода, в которое пользователь вводит значение фильтра;

кнопку «Add…», при нажатии которой в список фильтров добавляется ещё одна строка для ввода параметров фильтра;

кнопку «Remove», при нажатии которой выбранный элемент списка фильтров удаляется;

кнопку «Create», при нажатии которой окно пропадает, начинается генерирование журнала с заданными параметрами и фокус ввода переключается обратно на окно «Custom logging» (см пп 10), в которое добавляется информация о вновь созданном отладочном журнале;

кнопку «Cancel», при нажатии которой отменяется создание нового отладочного журнала и окно пропадает.

Изменение размера окна пользователем не допускается.

Окно «TCP dumping»

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

Окно должно содержать:

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

набор узлов, на которых генерируется журнал

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

дата и время начала генерирования журнала

кнопку «Start new capture…», при нажатии которой откроется окно «Create new TCP dump» (см пп. 13) для выбора параметров создания нового журнала сетевого трафика; при успешном задании параметров нового журнала он добавляется в текущий список журналов;

кнопку «Stop capture», при нажатии которой генерирование выбранного в списке журнала заканчивается, а журнал удаляется из списка; кнопка должна быть активирована только при выбранном в списке журнале;

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

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

Окно «Create new TCP dump»

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

Окно должно содержать:

поле ввода «Nodes», содержащее отделённые запятой имена узлов СХД Centera, на которых будет производиться создание журнала;

кнопку «Select nodes…», открывающую диалоговое окно для удобного выбора набора узлов СХД, на которых будет производиться создание журнала (см. пп. 8);

выпадающий список с допустимыми сетевыми интерфейсами, на которых возможен захвать сетевого трафика; список должен содержать следующие названия сетевых интерфейсов: «eth0», «eth1» и «eth2»; выбранное значение по умолчанию - «eth0»;

поле ввода «Pcap filter», содержащее параметры фильтрации сетевых пакетов в формате библиотеки LibPcap;

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

кнопку «Cancel», при нажатии которой отменяется создание нового журнала сетевого трафика и окно пропадает.

Изменение размера окна пользователем не допускается.

Окно «Download»

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

Окно должно содержать:

поле ввода «Nodes», содержащее отделённые запятой имена узлов СХД Centera, на которых будет производиться поиск файлов для копирования;

кнопку «Select nodes…», открывающую диалоговое окно для удобного выбора набора узлов СХД, на которых будет производиться поиск файлов для копирования (см. пп. 8);

список типов журналов и конфигураций ПО СХД Centera, среди которых будет производиться поиск файлов для копирования; список должен поддерживать множественное выделение; минимальный набор эелементов списка должен включать следующие: «Business-logic logs», «Platform logs», «OS logs», «TCP dumps», «Cluster parameters» и «Node parameters».

триггер, разрешающий поиск файлов для копирования в содержимом других сессий, имеющихся на кластере;

кнопку «Query data», при нажатии которой инициируется поиск файлов, соответствующих критериям выбора пользователя;

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

узел СХД, на котором находится файл;

полный путь к файлу;

имя файла;

дата и время создания файла;

кнопку «Download selected data», при нажатии которой открывается стандартное окно выбора директории для сохранения копируемых файлов; при успешном выборе директории окно пропадает, открывается окно «Download progress» (см. пп 15), в которое добавляется список выбранных пользователем для копирования файлов;

кнопку «Cancel», при нажатии которой отменяется копирование файлов и окно пропадает.

Изменение размера окна пользователем не допускается.

Окно «Download progress»

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

Окно должно содержать:

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

узел СХД Centera, с которого необходимо скопировать выбранный файл;

полный путь к копируемому файлу;

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

статус копирования; допускается наличие одного из статусов: «queued», «downloading», «complete» и «error» (с указанием в скобках причины ошибки);

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

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

Окно «Base64 encode/decode»

Модальное диалоговое окно, предназначенное для кодирования и декодирования упорядоченной последовательности байтов, используя алгоритм кодирования Base64 [4].

Окно должно содержать:

кнопку «Open encoded file…», при нажатии которой будет появляться стандартное окно выбора файла с закодированным Base64 содержимым, а после выбора содержимое данного файла будет отображено в текстовом поле кодированного содержимого и использовано для декодирования;

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

кнопку «Decode», при нажатии которой будет происходить декодирование кодированного содержимого (введённого в соответствующее текстовое поле или открытого из файла) с последующим отображением его в текстовом поле декодированного содержимого;

кнопку «Decode and save as…», нажатие которой вызовет действия как для кнопки «Decode», но дополнительно будет открыто стандартное окно выбора файла для сохранения результатов декодирования;

кнопку «Open decoded file…», при нажатии которой будет появляться стандартное окно выбора файла с содержимым для Base64 кодирования, а после выбора содержимое данного файла будет отображено в текстовом поле содержимого для декодирования и впоследствии использовано для кодирования;

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

кнопку «Encode», при нажатии которой будет происходить кодирование содержимого (введённого в соответствующее текстовое поле или открытого из файла) с последующим отображением его в текстовом поле кодированного содержимого;

кнопку «Encode and save as…», нажатие которой вызовет действия как для кнопки «Encode», но дополнительно будет открыто стандартное окно выбора файла для сохранения результатов кодирования.

Допускается изменение размеров окна пользователем вместе с размерами текстовых полей. Остальные элементы окна не должны менять размеры и взаимное расположение.

Допускается открывать несколько таких окон, при открытии следующего окна для Base64 кодирования/декодирования данное окно просто добавляется в список открытых окон клиентского компонента.

Окно «SmartPacket decode»

Немодальное окно программы, предназначенное для отображения декодированного содержания сетевого пакета типа SmartPacket

Окно должно содержать текстовое поле размером во всю рабочую область окна, которое отображает декодированное содержимое сетевого пакета типа SmartPacket, полученное от серверного компонента. Текстовое поле должно позволять копировать своё содержимое в будер обмена.

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

Окно «ZLIB compress/decompress»

Модальное диалоговое окно, предназначенное для сжатия и декомпрессии упорядоченной последовательности байтов, используя алгоритм ZLIB [5].

Окно должно содержать:

кнопку-переключатель «ZLIB encode data», при нажатии которой кнопка-переключатель «ZLIB decode data» будет отжиматься и будет происходить выбор операции сжатия над данными в выбранном пользователем файле;

кнопку-переключатель «ZLIB decode data», при нажатии которой кнопка-переключатель «ZLIB encode data» будет отжиматься и будет происходить выбор операции декомпрессии над данными в выбранном пользователем файле;

кнопку «Save…», при нажатии которой окно пропадает и выводится стандартное окно выбора файла для сохранения результатов преобразования;

кнопку «Cancel», при нажании которой операция преобразования отменяется и фокус ввода возвращается к главному окну клиентского компонента.

Изменение размера окна пользователем не допускается.

Окно «About Sustaining suite»

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

Окно должно содержать:

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

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

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

кнопку «Ok», закрытия диалогового окна.

Изменение размера окна пользователем не допускается.

3. РАЗРАБОТКА СЕРВЕРНОГО КОМПОНЕНТА ПРОГРАММНОГО КОМПЛЕКСА

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

Данный раздел состоит из четырёх подразделов, которые описывают фазы разработки серверного компонента:

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

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

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

Подраздел «Реализация серверного компонента» содержит информацию об использованных средствах разработки, выборе подходов и приёмов реализации модулей серверного компонента.

3.1 Разработка методик сбора и анализа информации о состоянии СХД Centera

Методики сбора и анализа информации разрабатываются до уровня детализации, который может быть успешно реализован равно как на языке Java SE, так и с использованием встроенных команд языка оболочки ОС bash. Основные усилия при разработке методик применяются для чёткой формулировки всех исходных данных, необходимых для сбора и анализа информации о состоянии СХД, чётко описанных требований к искомому результату и чётко изложенному алгоритму получения результата исходя из набора исходных данных.

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

Разработка методики выборки заданных записей из журналов СХД Centera

Описание методики

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

Исходные данные:

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

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

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

временной интервал - определяет соответствие как конечной записи, так и целого журнала условиям отбора при поиске

местонахождение, имя, формат и количество файлов с результатами

Искомый результат

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

Алгоритм получения результата представлен на рис. 3.1

Нештатные ситуации

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

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

Размещено на http://www.allbest.ru

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

Разработка методики генерирования отладочных журналов бизнес-логики СХД Centera

Описание методики

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

Исходные данные

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

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

атрибуты команды для начала генерирования отладочного журнала - имя и формат команды, протокол и параметры отсылки команды ПО СХД Centera

атрибуты команды для прекращения генерирования отладочного журнала - имя и формат команды, протокол и параметры отсылки команды ПО СХД Centera

Искомый результат

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

Алгоритм получения результата представлен на рис. 3.2

Размещено на http://www.allbest.ru

Рисунок 3.2 Схема алгоритмов запуска и остановки отладочного журналирования

Нештатные ситуации

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

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

Разработка методики сбора сетевого трафика на СХД Centera

Описание методики

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

Исходные данные

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

параметры фильтрации сетевого трафика -сетевой интерфейс, с которого производить захват, и выражение фильтра сетевых пакетов в формате библиотеки LibPcap

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

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

Искомый результат

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

Алгоритм получения результата приведён на рис. 3.3

Размещено на http://www.allbest.ru

Рисунок 3.3 Схема алгоритмов запуска и остановки журналирования сетевых пакетов

Нештатные ситуации

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

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

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

Описание методики

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

Исходные данные

типы файлов, которые нужно внести в список для предоставления клиентскому компоненту

список узлов СХД, на которых производить включения фалов в список

триггер поиска в контекстах всех имеющихся на узлах СХД сессий

местонахождение и имена файлов, подлежащих копированию

имя директории для результатов копирования

Искомый результат

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

Алгоритм получения результата приведён на рис. 3.4.

Нештатные ситуации

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

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

Размещено на http://www.allbest.ru

Рисунок 3.4 Схема алгоритма поиска и копирования заданного типа файлов

Разработка методики декодирования содержимого сетевого пакета типа SmartPacket

Описание методики

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

Исходные данные

Содержимое пакета типа SmartPacket

Имя директории и файла для сохранения результата

Искомый результат

Текстовое представление декодированного пакета типа SmartPacket, сохранённое в файл результатов

Алгоритм получения результата

Получить содержимое пакета типа SmartPacket

Получить доступ к ПО СХД Centera, декодирующему пакеты такого типа

Произвести операцию декодирования

Результат операции декодирования сохранить в локальном файле результатов

Нештатные ситуации

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

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

3.2 Разработка протокола взаимодействия клиентского и серверного компонентов

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

Разработке подлежат следующие вопросы:

какой канал используется для передачи запроса от клиента серверу;

какой канал используется для доставки результата от сервера клиенту;

какой компонент ответственен за доставку запросов от клиента к серверу;

как сервер получает запрос;

какой компонент ответственен за доставку результата;

как клиент получает результат;

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

в каком формате доставляется запрос;

в каком формате доставляется результат.

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

Канал передачи запроса от клиента серверу и результата в обратном направлении

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

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

В свете имеющихся знаний о специфике канала связи можно предложить следующие решения для организации канала связи между сервером и компонентом:

Обмен информацией между клиентским и серверным компонентами через консольный ввод-вывод, предоставляемый протоколом SSH. То есть в контексте SSH-сессии запускается серверный компонент программного комплекса, а потоки ввода-вывода перенаправляются через SSH-соединение к клиентскому компоненту. Тот аспект, что вместе с обрывом SSH-соединения будет уничтожем и процесс серверного компонента, может быть устранён за счёт запуска серверного компонента в контексте приложения screen, которое позволяет создать собственную консольную сессию, к которой можно подключаться через нестабильное соединение. Минусом данной реализации была бы необходимость усложнения протокола взаимодействия, который должен был бы учитывать особенности поведения предоставляемой screen консоли (при частичной передаче данных на сервер или клиенту, при восстановлении состояния взаимодействия после разрыва в середине передачи данных).

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

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

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

Доставка запроса

На ФС узла СХД создаётся директория, в которой будут размещены запросы от клиентского компонента; в эту директорию клиентский компонент копирует файл с содержимым запроса, используя команду scp, использующую протокол SSH для передачи данных, но имя файла с запросом на момент записи устанавливается в формате «незавершённого» запроса, чтобы серверный компонент не пытался прочитать созданный файл с не до конца переданным запросом. После записи файла с запросом он переименовывается в формат «завершённого» файла запроса, готового для обработки серверным компонентом.

Обработка запроса сервером

При обнаружении серверным компонентом в соответствующей директории нового запроса, происходит создание в директории результатов файла с предварительными результатами, свидетельствующими о начале обработки запроса сервером. Оригинальный файл запроса удаляется из директории запросов. Создание и обновление файла результатов происходит по такой же схеме, по которой происходит и создание файла запроса - сначала создаётся «незавершённый» файл результата с соответствующим именем, который после завершения формирования переименовывается в «завершённый» формат. Таким образом достигается атомарность операций над файлами средствами ОС EMC Centera Linux.

Доставка результата

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

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

Каждый запрос должен иметь свой уникальный идентификатор, чтобы избежать коллизий между обработкой запросов. Ответственность за уникальность идентификатора возлагается на клиентский компонент, как создающий эапросы. Идентификатор должен быть объектом типа «целое» (4 байта).

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

Состояние обработки запроса может быть одним из пяти:

pending - запрос создан, но ещё не передан в обработку серверным компонентом;

initial - запрос передан в обработку серверным компонентом, но никакие результаты ещё не известны;

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

complete - запрос обработан, результаты доступны;

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

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

Формат записи запроса и результатов

В качестве формата записи параметров запроса и результа был выбран синтаксис языка разметки XML [7], как гибкий способ выражения различных структур данных, легко подвергающийся модификации и имеющий множество реализаций, снижающих затраты на разработку сериализации собственных структур данных. Пример задачи копирования файлов, обращённой в документ XML, приведён ниже:

<?xml version=”1.0” encoding=”utf-8”?>

<task>

<parameter name=”task_id” value=”223”/>

<parameter name=”task_type” value=”DOWNLOAD”/>

<parameter name=”creation_date” value=”1303033975”/>

<parameter name=”modification_date” value=”1303036333”/>

<parameter name=”task_expiration” value=”86400”/>

<state>

<parameter name=”name” value=”Running”/>

<parameter name=”total_steps” value=”4”/>

<parameter name=”complete_steps” value=”2”/>

<parameter name=”failed_steps” value=”0”/>

</state>

<results>

<result_1>

<parameter name=”node” value=”c001n01”/>

<parameter name=”path” value=”/var/log/messages.log”/>

<parameter name=”size” value=”65821”/>

<parameter name=”is_successful” value=”true”/>

</result_1>

<result_2>

<parameter name=”node” value=”c001n03”/>

<parameter name=”path” value=”/var/log/messages.log”/>

<parameter name=”size” value=”365112”/>

<parameter name=”is_successful” value=”true”/>

</result_2>

</results>

</task>

Параметры запросов протокола клиент-серверного взаимодействия

Таблица 3.1

Тип запроса	Параметры	Время жизни	Метрика прогресса	Результат
Поиск сообщения в журналах	From: дата начала периода To: дата окончания периода Nodes: список узлов для поиска LogTypes: список типов просматриваемых журналов Pattern: шаблон для поиска IsRegExp: флаг регулярного выражения в шаблоне	1 сутки	Всего: количество узлов, помноженное на 100% Выполнено: сумма долей просмотренных журналов на всех узлах (в процентах) Ошибки: количество неудочно просмотренных журналов	Список файлов журналов, сохранённых на узле серверного компонента
Генерирование отладочных журналов	StartDate: дата начала генерирования журнала Nodes: список узлов LogLevel: минимальный уровень важности сообщений Loggers: список компонентов - источников сообщений Filters: список фильтров сообщений	30 суток	Всего: количество узлов Выполнено: количество обработанных узлов Ошибки: количество узлов, вернувших ошибку	Отладочные журналы, сохранённые на генерирующих узлах
Создание журнала сетевых пакетов	StartDate: дата начала генерирования журнала Nodes: список узлов Nic: сетевой интерфейс для захвата пакетов Filters: список фильтров пакетов	30 суток	-//-	Журналы сетевого трафика, сохранённые на генерирующих узлах
Прерывание задачи генерирования отладочных или сетевых журналов	TaskId: идентификатор задачи генерирования журналов	10 минут	-//-	Отсутствует
Поиск файлов журналов или конфигурации для копирования	Nodes: список узлов для поиска DataTypes: список типов искомых данных QueryAllSessions: флаг поиска файлов во всех сессиях	1 час	Всего: количество узлов, помноженное на количество типов данных Выполнено: суммарное количество просмотренных типов данных на всех узлах Ошибки: количество неудачно просмотренных типов данных на всех узлах	Список найденных файлов на узле серверного компонента
Копирование файлов журналов или конфигурации	DataPaths: список путей к копируемым файлам	1 сутки	Всего: количество копируемых файлов Выполнено: количество файлов, начатых копироваться Ошибки: количество нескопированных из-за ошибок файлов	Указанные файлы на узле серверного компонента
Декодирование содержимого пакета типа SmartPacket	Data: Base64 - закодированное содержимое пакета	10 минут	Всего: количество декодируемых пакетов Выполнено: количество декодированных пакетов Ошибки: количество недекодированных пакетов	Декодированное содержимое пакета на узле серверного компонента
Остановка серверного компонента	Без параметров	10 минут	Всего: 1 Выполнено: 1 Ошибки: 0	Отсутствует

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

3.3 Разработка структуры серверного компонента

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

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

модуль серверной библиотеки - инициализирует использование библиотеки, предоставляет её интерфейс остальным модулям;

библиотека протокола - предоставляет единые средства для маршаллинга экземпляров сущностей в файлы и из файлов

модуль работы с файловой системой - предоставляет работу с состоянием и содержимым директорий, как со списками объектов-потоков ввода или вывода

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

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

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

Компоновка и взаимодействие модулей показано на рис. 3.5. Штриховыми линиями показаны действия по созданию и инициализации модулей, выполняемые главным модулем «Контроллер», сплошными линиями показаны взаимодействия модулей, связанные с обработкой запросов от клиентского модуля.

Контроллер, модуль очереди запросов и модуль очереди задач работают параллельно, поэтому следует рассмотреть их работу по-отдельности.

Контроллер:

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

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

Контроля за временем жизни компонента и его модулей

Создания и хранения списка компонентов

Вызова абстрактного метода инициализации списка компонентов

Запуска модулей компонента в порядке их нахождения в списке

Ожидания остановки компонента

Остановки компонента

Остановки модулей компонента в порядке, обратном их нахождению в списке

Специфичный контроллер серверного компонента осуществляет:

Реализацию функции main, создающей экземпляр контроллера и запускающей его

Захват уникального в рамках ОС объекта блокировки, чтобы обеспечить единственность экземпляра серверного компонента в пространстве процессов ОС, при неудачной попытке завершает работу серверного компонента

Модуль очереди запросов работает циклически, каждая итерация которого происходит не чаще 1 раза за заданный интервал времени (5 секунд) и выглядит следующим образом:

Модуль очереди запросов запрашивает у модуля ФС о наличии новых запросов

Модуль ФС проверяет состояние директории с запросами и возвращает статус наличия новых запросов модулю очереди запросов

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

Модуль ФС открывает файл с запросом и возвращает модулю очереди запросов поток ввода из файла с запросом

Модуль очереди запросов создаёт новый запрос, используя маршаллер протокола (общий для клиентского и сереврного компонентов) по данным из потока и сообщает модулю ФС о завершении выборки запроса

Модуль ФС закрывает файл и удаляет его из директории запросов

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

При создании экземпляра задачи ей передаётся интерфейс модуля ФС и маршаллер протокола (общий для клиентского и серверного компонентов)