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

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

Санкт-Петербургский государственный политехнический университет

Факультет технической кибернетики

Кафедра компьютерных систем и программных технологий

ДИПЛОМНЫЙ ПРОЕКТ

Тема: Разработка программного комплекса для анализа состояния

системы хранения данных EMC Centera

Выполнил студент гр. 6081/1в

Буйнов К.С.

Руководитель, руководитель проектной группы

Чуб И.А.

Санкт-Петербург 2011

ЗАДАНИЕ

РЕФЕРАТ

С. 136. Рис. 25. Табл. 2

ТЕХНИЧЕСКАЯ ПОДДЕРЖКА, EMC CENTERA, КЛИЕНТ-СЕРВЕРНОЕ ВЗАИМОДЕЙСТВИЕ, ПРОТОКОЛ ВЗАИМОДЕЙСТВИЯ, ГРАФИЧЕСКИЙ ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ, JAVA SWING, МЕТОДИКА ТЕСТИРОВАНИЯ

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

программный серверный хранение данный

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1.ОБЗОР МЕТОДОВ АНАЛИЗА СОСТОЯНИЯ СХД CENTERA

1.1Структура и функционирование СХД Centera

1.2Способы получения информации о состоянии СХД Centera

1.3Cуществующие средства анализа состояния СХД Centera

1.4Оценка эффективности средств анализа состояния СХД Centera при разных видах сбоя системы

1.4.1Определение источников информации и методов её получения для средств анализа состояния СХД Centera

1.4.2Определение наиболее распространённых видов сбоя в СХД Centera

1.4.3Определение методов анализа состояния СХД Centera, применяемых при сбоях

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

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

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

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

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

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

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

2.3Графический интерфейс пользователя

2.3.1Общий вид графического интерфейса

2.3.2Состав меню

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

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

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

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

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

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

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

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

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

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

3.4Реализация серверного компонента

4.РАЗРАБОТКА КЛИЕНТСКОГО КОМПОНЕНТА ПРОГРАММНОГО КОМПЛЕКСА С ГРАФИЧЕСКИМ ИНТЕРФЕЙСОМ ПОЛЬЗОВАТЕЛЯ

4.1Разработка структуры клиентского компонента

4.1.1Слой «Модель»

4.1.2Слой «Контроллер»

4.1.3Слой «Вид»

4.2Реализация слоя «Модель» клиентского компонента

4.3Реализация слоя «Контроллер» клиентского компонента

4.4Реализация слоя «Вид» клиентского компонента

5.ТЕСТИРОВАНИЕ ПРОГРАММНОГО КОМПЛЕКСА

5.1Выбор методик тестирования

5.2Компонентное тестирование

5.3Системное тестирование

5.4Анализ результатов тестирования

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЯ

Приложение 1. Техническое задание

Приложение 2. Текст программы

Приложение 3. Описание программы

Приложение 4. Программа и методика испытаний

Приложение 5. Спецификация

ВВЕДЕНИЕ

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

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

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

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

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

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

Воздействие на аппаратную часть системы

Изменение конфигурации функции системы, описанное в пользовательской документации

Изменение настройки внутреннего функционирования системы

и четырём типам уровня ответственности за выполняемую сервисную операцию:

Тип I - cтандартное изменение, документированное в пользовательской документации или руководстве для сервисных инженеров

Тип II - стандартное изменение, документированное программной документации для внутреннего использования

Тип III - нестандартное изменение, описанное в документации для внутреннего использования

Тип IV - нестандартное изменение, разработанное экспертной группой для конкретной конфигурации системы

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

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

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

1. ОБЗОР МЕТОДОВ АНАЛИЗА СОСТОЯНИЯ СХД CENTERA

.1 Структура и функционирование СХД Centera

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

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

Общая архитектура

СХД Centera представляет собой кластер с высоким показателем доступности (среднеквартальное значение держится выше уровня 0.99999 на протяжении последних нескольких лет), построенный по технологии «избыточный массив независимых узлов» - Redundant Array of Independent Nodes (RAIN). Высокая доступность достигается за счёт реализации принципа горячего резервирования, то есть нагрузка распределяется между всеми узлами кластера. При выходе одного из узлов из строя нагрузка перераспределяется между остальными узлами.

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

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

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

Репликация данных - узел имеет сконфигурированный внешний сетевой интерфейс, посредством которого осуществляется резервное копирование на или восстановление данных с удалённой СХД Centera

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

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

Аппаратное обеспечение

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

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

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

Программное обеспечение

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

Кластерное программное обеспечение состоит из трёх компонентов:

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

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

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

Клиентское программное обеспечение СХД Centera состоит из двух компонентов:

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

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

Интерфейсы

Интерфейсы пользователю предоставляются обеими частями программного обеспечения СХД Centera: и кластерной (серверной) [2], и клиентской.

Серверная часть СХД Centera предоставляет только программные интерфейсы и предполагает их использование только проприетарным ПО:

Интерфейс SmartPacket - предназначен для взаимодействия бизнес-логики СХД и библиотеки SDK по проприетарному протоколу; этот интерфейс может быть использован только опосредованно через библиотеку SDK.

Интерфейс Management API - предназначен для взаимодействия бизнес-логики СХД и ПО администратора, которое осуществляется по проприетарному протоколу; интерфейс может быть использован опосредованно через Centera Viewer.

Интерфейс Secure Shell (SSH) - предназначен для взаимодействия ПО администратора с программной платформой СХД; интерфейс может быть использован опосредованно через Centera Viewer или клиентскую SSH-программу, когда производится сервисная операция. Во время администрирования СХД пользователем данный интерфейс недоступен.

Клиентское ПО СХД Centera предоставляет слудующие интерфейсы:

Программный интерфес SDK API - предоставляется библиотекой SDK и является набором классов (функций) для манипуляций с данными, сохраняемыми или хранимыми на СХД Centera

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

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

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

1.2 Способы получения информации о состоянии СХД Centera

Отчёты и уведомления об изменении состояния

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

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

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

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

Графический интерфейс пользователя программы Centera Viewer

Графический интерфейс пользователя предоставляет широкий спектр возможностей по получению информации о состоянии СХД Centera:

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

Подробные отчёты о состоянии аппаратного обеспечения

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

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

Редактор конфигурации, содержащий тонкие настройки бизнес-логики

Доступ к журналам аудита и бизнес-логики СХД Centera

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

Регулярные оповещения об активности СХД Centera по протоколу SNMP

Для регулярных оповещений об активном статусе СХД Centera могут быть использованы отправки по протоколу Simple Network Management Protocol (SNMP) пользовательской SNMP-системе, которая осуществляет мониторинг состояния ресурсов вычислительной сети.

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

Интерфейс командной строки

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

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

Интерфейс администрирования Management API

Данный интерфейс предоставляет доступ к протоколу Management API, через который осуществляются любые имеющиеся операции администрирования СХД Centera. Команды протокола вместе с параметрами трудны для запоминания, а результаты представляются в неудобном для чтения формате. Тем не менее, этот интерфейс позволяет администрировать систему в случаях; когда ни графический интерфейс пользователя программы Centera Viewer, ни интерфейс командной строки не могут предоставить нужных средств (например, если необходимая команда администрирования заложена в протоколе, но в силу её специфики не включена в список доступных команд в пользовательском интерфейсе).

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

Командная строка ОС EMC Centera Linux

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

Данный интерфейс позволяет осуществлять администрирование СХД на очень низком уровне:

отслеживать состоянием ОС и управлять им

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

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

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

Командная строка может быть доступна как удалённо (через сетевое соединение используя протокол Secure Shell); так и локально, когда сервисный инженер приходит к пользователю и подключает консоль непосредственно к узлу кластера или же подключает переносной сервисный компьютер во внутреннюю сеть кластера.

.3 Cуществующие средства анализа состояния СХД Centera

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

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

Анализ проводится из полученных с кластеров Centera сводных отчётов (Health Report) и уведомлений (Alert).Viewer

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

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

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

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

Вспомогательные программы для обслуживающего персонала

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

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

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

1.4 Оценка эффективности средств анализа состояния СХД Centera при разных видах сбоя системы

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

Определение источников информации и методов её получения для средств анализа состояния СХД Centera

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

Использование источников информации и способов её получения имеющимися средствами анализа состояния приведено на Рис. 1.1.

Рис. 1.1. Схема потоков информации о состоянии СХД Centera от её источников до средств получения

Определение наиболее распространённых видов сбоя в СХД Centera

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

В настоящей работе имеет смысл рассматривать только виды сбоев, которые возникали в установленных кластерах Centera с сентября 2008 года, когда была выпущена новая версия ПО Centera с номером 4.0, которая пратически вытеснила все предыдущие версии ПО Centera, имеющиеся у конечных пользователей. Также следует заметить, что данная версия ПО содержит множество улучшений по сравнению с предыдущими версиями, что повлекло за собой изменение распределения количества сбоев по спектру их возможных разновидностей.

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

«Нарушение принципа SPOF» - нарушение принципа Single Point Of Failure (одиночный выход из строя): выход из строя за короткий промежуток времени двух или более дисковых накопителей, нарушающий защищённость пользовательских данных, достигнутых с помощью избыточности.

«Сбой внутренней ВС» - некорректное поведение внутренней вычислительной сети кластера, при котором нарушается обмен данными между узлами.

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

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

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

Определение методов анализа состояния СХД Centera, применяемых при сбоях

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

Как видно из табл. 1.1 перечень используемых средств анализа включает в себя средства ОС EMC Centera Linux, которые являются по сути простейшими программными средствами, включёнными в дистрибутив ОС, и не обладающими удобным функционалом для проведения анализа. С помощью этих средств требуется решать набор типовых задач анализа состояния СХД Centera, которые встречаются во многих случаях устранения сбоев СХД. Этот набор можно ограничить следующим списком, отсортированным по убыванию частоты возникновения этих задач:

Используемые методы и применяемые средства анализа состояния СХД Centera при различных видах сбоев

Таблица 1.1

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

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

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

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

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

Анализ состояния функциональных компонентов СХД 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) настоящего пункта). По окончании времени хранения результатов выполнения задачи такие результаты должны быть удалены из памяти и файловой системы, если они сохранены в «рабочую директорию».

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

Серверная библиотека

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

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

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

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

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

Серверный компонент должен исполнятся в среде исполнения Java Runtime Environment 6.0 под управлением ОС EMC Centera Linux. Образец данной системы предоставляется для осуществления разработки и тестирования серверного модуля.

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

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

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

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

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

Результаты выполнения задач пользователя следует хранить в соответствующей поддиректории «рабочей директории».

2.3 Графический интерфейс пользователя

Графический интерфейс пользователя выполнен с использованием библиотеки графических компонентов Java Swing, входящих в состав среды исполнения Java Runtime Environment 6.0.

Общий вид графического интерфейса

Графический интерфейс является многооконным, построенным по принципу Multiple Document Interface (MDI), когда пользователю доступны для просмотра и изменения сразу несколько разных типов окон (документов). Названия окон, описание их содержимого и пунктов меню клиентского компонента содержится в данном подразделе.

Запуск клиентского приложения начинается с появления диалогового окна «Choose connection» для выбора параметров соединения с СХД Centera, после чего при успешном установлении соединения пользователю показывается главное окно программы.

Основное окно программы имеет командное меню, из которого пользователю доступны все возможные функции программного комплекса, а также справка о пользовании программным комплексом.

Состав меню

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

Clusterin logs…logging…dumping……encode/decode…decodecompress/decompress’s manual page

About

Каждый подпункт меню инициирует какое-либо действие, описание которых приведены ниже:

«Cluster - Reconnect»

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

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

«Cluster - Sessions…»

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

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

«Cluster - Exit…»

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

«Logging - Search in logs…»

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

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

«Logging - Custom logging…»

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

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

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

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

«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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.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 байта).

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

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

Параметры запросов и результатов их выполнения указаны в табл. 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”/>

<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

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

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

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

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

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

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

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

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

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

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

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

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

Контроллер:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модуль очереди запросов ставит задачу в очередь модуля очереди задач и переходит к следующей итерации

Модуль очереди задач работает циклически, где каждая итерация выглядит следующим образом:

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

Модуль очереди задач запускает выполнение задачи

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

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

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

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

Модуль очереди задач переходит к следующей итерации

Рисунок 3.5 Схема структуры серверного компонента

.4 Реализация серверного компонента

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

Интегрированная среда разработки Eclipse (версия Helios Service Release 2), как отвечающая всем требованиям по разработке программного продукта на языке Java Standard Edition, имеющая множество вспомогательных средств для обеспечения удобного процесса разработки;

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

Рабочие станции программиста, имеющие характеристики не ниже следующего уровня: процессор частотой 2ГГц, объём оперативной памяти 1Гб, объём доступного дискового пространства 1Гб, размер дисплея 17 дюймов, разрешение экрана 1024*768 пикселей;

Операционная система Windows XP SP2 или SP3.

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

Модуль контроллера представлен следующими классами:

Класс контроллера серверного компонента, унаследованный от базового контроллера. Имеет статический метод main() - точку входя для запуска серверного компонента.

package server.controllerclass ServerController extends ModulesController {static void main(String[] args)

@Overridevoid initModules() throws ModuleException {void obtainServerLock() throws ModuleException

}

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

package common.controller;abstract class ModulesController {List<Module> modules = new ArrayList<Module>();void execute()abstract void initModules() throws ModuleExceptionboolean add(Module module)void startModules() throws ModuleExceptionvoid waitForStop()void stop()void stopModules() throws ModuleException

}

Интерфейс модуля, регистрируемого в контроллере и управляемого им.

package common.controller;interface Module {void start() throws ModuleExceptionvoid stop() throws ModuleException

}

Класс исключений, специфицирующий ошибки, произошедшие в коде контроллера.

package common.controller;class ModuleException extends Exception {

public ModuleException(String message)

}

Модуль серверной библиотеки представлен следующими классами:

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

package server.library;interface ServerLibrary {void initNodes();NodeEnvironment getNodeEnvironment(String nodeName);boolean decodeSmartPacket(byte[] content);

}

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

package server.library;interface NodeEnvironment {boolean searchInLogs(Date from, Date to, Collection<LogType> logTypes, String pattern, boolean isRegExp);boolean startCustomLog(String logName, LogLevel level, Collection<String> loggers, Collection<LogFilter> filters);boolean stopCustomLog(String logName);boolean startTcpDumping(String nic, String filters);boolean stopTcpDumping();boolean queryFiles(Collection<DataType> dataTypes, boolean allSessions);boolean downloadFiles(Collection<String> paths);

}

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

package server.modules;class ServerLibraryModule implements Module {

@Overridevoid start() throws ModuleException

@Overridevoid stop() throws ModuleExceptionServerLibrary getLibrary()

}

Модуль ФС представлен следующими классом:

Класс модуля управления файловой система - преимущественно методы по чтению задачи или её записиа.

package server.modules;class FilesystemModule implements Module {

@Overridevoid start() throws ModuleException

@Overridevoid stop() throws ModuleExceptionCollection<String> getRequestsList()InputStream getRequestStream(String request)void removeRequest(String request)void persistTask(Task task) throws IOExceptionvoid removeExpiredTasks(Collection<String> expiredTasks) throws IOException

}

Модуль очереди запросов представлен следующими классами:

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

package server.modules;class RequestProcessingModule implements Module, Runnable {FilesystemModule filesystemModule;JobProcessingModule jobProcessingModule;Thread queueProcessingThread;Map<String, TaskFactory> factories = new HashMap<String, TaskFactory>(); RequestProcessingModule(FilesystemModule filesystemModule, JobProcessingModule jobProcessingModule)

@Overridevoid start() throws ModuleException

@Overridevoid stop() throws ModuleExceptionvoid registerTaskFactory(String type, TaskFactory factory)void unregisterTaskFactory(String type, TaskFactory factory)

@Overridevoid run()

}

Модуль очереди задач представлен следующими классами:

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

package server.modules;class JobProcessingModule implements Module, Runnable {FilesystemModule filesystemModule;Thread jobsProcessor;Queue<Task> jobs = new ConcurrentLinkedQueue<Task>();JobProcessingModule(FilesystemModule filesystemModule) {

@Overridevoid start() throws ModuleException {

@Overridevoid stop() throws ModuleException {void createJob(Task request) {

@Overridevoid run() {

}

Модуль фабрик задач представлен следующими классами:

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

package server.modules;class FactoriesModule implements Module {ServerController serverController;ServerLibraryModule serverLibraryModule;FilesystemModule filesystemModule;RequestProcessingModule requestProcessingModule;Map<String, TaskFactory> factories;FactoriesModule(ServerController serverController, ServerLibraryModule serverLibraryModule, FilesystemModule filesystemModule, RequestProcessingModule requestProcessingModule)

@Overridevoid start() throws ModuleExceptionvoid initializeFactories()

@Overridevoid stop() throws ModuleException

}

4. РАЗРАБОТКА КЛИЕНТСКОГО КОМПОНЕНТА ПРОГРАММНОГО КОМПЛЕКСА С ГРАФИЧЕСКИМ ИНТЕРФЕЙСОМ ПОЛЬЗОВАТЕЛЯ

.1 Разработка структуры клиентского компонента

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

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

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

Слой «Модель»

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

Модуль хранилища настроек

Выполняет функции сериализации/десериализации настроек клиентского модуля в/из файлов, находящихся в «рабочей» директории клиентского компонента. «Рабочей» называется директория, в которой находится исполняемый файл клиентской программы. Настройки легко отображаются на документ формата XML, при маршаллинге настроек используется DOM-реализация XML-документа, поставляемая вместе с пакетом Java Runtime Environment 6.0 [8].

Модуль контекста соединения с СХД Centera

Модуль представлен набором сущностей, хранящих в себе свойства соединения с кластером. В частности сущность контекста соединения содержит в себе сущность параметров текущего соединения (адрес узла СХД, название соединения, используемая при установлении соединения учётная запись), пароль для установления соединения, состояние соединения (установлено, не установлено, прервано), версию ПО СХД Centera, контекст текущей клиент-серверной сессии, список узлов СХД Centera c указанием их ролей).

Модуль контекста клиент-серверной сессии

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

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

Общий модуль протокола

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

Общий модуль типовых задач

Часть модуля протокола - содержит реализацию для всех поддерживаемых типов задач.

Слой «Контроллер»

Слой состоит из трёх модулей - контроллеров клиентского компонента, соединения и задач.

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

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

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

Модуль контроллера соединения

Состоит из следующих сущностей:

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

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

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

Модуль контроллера задач

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

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

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

временное хранилище задач - хранит состояние и параметры актуальных задач без сохранения их на файловую систему; в отличие от хранилища задач слоя «Модель» (см п. 4.1.1 пп. 3) используется в текущей работе с задачами, то есть все пользователи модуля контроллера задач работают именно с копией задачи во временном хранилище; это позволяет производить обновление постоянной копии задачи и её результатов незаметно для клиентов модуля и производить быстрое переключение содержимого задачи при его обновлении;

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

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

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

Слой «Вид»

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

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

.2 Реализация слоя «Модель» клиентского компонента

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

Модуль хранилища настроек представлен следующими классами:

Класс предоставляет статические методы для получения настроек в виде обёртки над XML-документом, а также для сохранения этих настроек в хранилище. Каждый экземпляр документа с настройками доступен по своему имени (файла).

package client.model;class RepositoryUtils {final static String REPOSITORY_PATH_ENVIRONMENT_VARIABLE = "sustaining.suite.repository.path";static final String REPOSITORY_SUFFIX = ".repository.xml";static final String REPOSITORY_TAG = "repository";static String sRepositoryDirectoryPath;static Map<String, Params> sRepositories = new HashMap<String, Params>();synchronized static String getRepositoryDirectoryPath()static Params getRepository(String repositoryName)static Params loadRepositoryFromFile(String repositoryName)static void persistRepository(String repositoryName, Params newRepositoryContent)

}

Класс предоставляет методы для доступа к настройкам клиента в объектном виде, в том числе производит преобразование настроек клиентского компонента из объектного вида в древовидный вид документа XML и обратно.

package client.model;class ClientContext {static final String CONNECTIONS_REPOSITORY = "clusters.connections";static final String CONNECTION_TAG = "connection";static final String CONNECTION_NAME = "name";static final String CONNECTION_ADDRESS = "address";static final String CONNECTION_LOGIN = "login";static Map<String, ConnectionParams> connectionsParams = null;static Map<String, ConnectionParams> getConnectionsParams()static boolean updateConnectionsParams(ConnectionParams existingConnectionParams, ConnectionParams newConnectionParams) throws ClientContextException

private static void persistConnectionsParams()

}

Исключение специфичного типа, предназначенное для обозначения ошибки при работе с контекстом клиентского компонента.

package client.model;class ClientContextException extends Exception {ClientContextException(String message)

}

Модуль контекста соединения с СХД Centera представлен следующими классами:

Класс контекста соединения, по своей сути является объектом - хранилищем свойств, относящихся к текущему состоянию соединения с серверным компонентом (методы установки и получения значений полей опущены).

package client.model;class ConnectionContext {enum State {(false),(true),(false);final boolean isConnected;State(boolean isConnected)boolean isConnected()

};ConnectionParams connectionParams;String password;State state;String centrastarVersion;SessionContext sessionContext;Collection<Node> nodes;

...

Класс параметров соединения с кластером.

package client.model;class ConnectionParams {

private String connectionName;

private String address;

private String login;

public ConnectionParams(String connectionName, String clusterAddress, String login)String getConnectionName()

public String getAddress()

public String getLogin()

@Override

public String toString()

}

Модуль контекста клиент-серверной сессии представлен следующими классами:

Класс хранилища сессий, предоставляет интерфейс для создания новой сессии.

package client.model;class SessionsRepository {static SessionContext createSession()

}

Класс контекста сессии. Как и класс контекста соединения, по существу является хранилищем настроек и параметров текущего состояния клиент-серверной сессии. Для краткости методы установки и получения полей класса опущены.client.model;

public class SessionContext {Object sessionLock;int sessionId;int creationTimestamp;int lastUpdateTimestamp;long size;Map<Integer, Task> tasks;

...

Интерфейс хранилища задач. Предоставляет базовые методы для работы с задачами.

package client.model;interface TaskRepository {int createTask(Task task);Task getTask(int id);void removeTask(int id);

}

Класс хранилища задач, хранимого на диске. В качестве параметра конструктору передаётся директория сессии, в которой нужно создать хранилище задач (с результатами).

package client.model;class PersistedTaskRepository implements TaskRepository {PersistedTaskRepository(File directory)

@Overrideint createTask(Task task)

@OverrideTask getTask(int id)

@Overridevoid removeTask(int id)

}

Общий модуль работы с обёрткой XML представлен следующими классами:

Интерфейс для работы с объектной моделью набора параметров вместо древовидной XML.

package common.params;interface Params {void setName(String name);String getString(String name) throws ParamsException;void putString(String name, String value);void putParams(String name, Params params);Params[] getAllParamsWithName(String name);

Element getXmlContent();

}

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

package common.params;class ParamsImpl implements Params {static final String PARAMETERS_ROOT = "parameters";static final String PARAMETER = "parameter";static final String PARAMETER_NAME = "name";static final String PARAMETER_VALUE = "value";Document document;Element root;ParamsImpl(Node node)ParamsImpl()ParamsImpl(Params params)

@Overridevoid setName(String name)

@OverrideString getString(String name) throws ParamsException

@Overridevoid putString(String name, String value)

@Overridevoid putParams(String name, Params params)

@OverrideParams[] getAllParamsWithName(String name)

@Overridefinal Element getXmlContent()

@OverrideString toString()

}

Класс исключения, возбуждаемого в случаях возникновения ошибки при работе с сущностью Params.common.params;class ParamsException extends Exception {ParamsException(String message)

}

Общий модуль протокола представлен следующими классами:

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

package common.protocol;interface Task {void setId(int id);int getId();void setType(String type);String getType();void setCreationTime(Date creationDate);Date getCreationTime();void setModificationTime(Date modificationDate);Date getModificationTime();void setExpirationPeriod(int expirationPeriod);int getExpirationPeriod();void setState(State state);State getState();void setResults(Collection<Result> results);Collection<Result> getResults();Params getParams();interface State {enum Name { Pending, Initial, Running, Complete, Aborted };void setName(Name name);Name getName();void setTotalSteps(int totalSteps);int getTotalSteps();void setCompleteSteps(int completeSteps);int getCompleteSteps();void setFailedSteps(int failedSteps);int getFailedSteps();

}interface Result {void setId(int id);int getId();void setNode(String node);String getNode();void setPath(String path);String getPath();void setSize(long size);long getSize();void setSuccessful(boolean isSuccessful);

public boolean isSuccessful();

}

}

Класс реализации интерфеса обёртки, методы установки и получения значений полей класса опущены для краткости.

package common.protocol;class TaskImpl implements Task {int id;String type;Date creationTime;Date modificationTime;int expirationPeriod;State state;Collection<Result> results;Params params;TaskImpl()TaskImpl(Params params)

...

Класс маршиллинга задач из файла (потока) с XML и обратно

package common.protocol;class Marshaller {Task unmarshal(InputStream inputStream) throws MarshallerExceptionvoid marshal(Task task, OutputStream outputStream) throws MarshallerException

}common.protocol;class MarshallerException extends Exception {MarshallerException(String message)

}

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

package common.protocol.tasks;class SearchInLogTask extends TaskImpl {Date from;Date to;Set<String> nodes;Set<LogType> logTypes; boolean isPatternRegExp;String pattern;final static String TYPE = "SEARCH_IN_LOG";

...common.protocol.tasks;class CustomLoggingTask extends TaskImpl {Date startDate;Set<String> nodes;LogLevel level;Set<String> loggers;Collection<LogFilter> filters;final static String TYPE = "CUSTOM_LOGGING";

...common.protocol.tasks;class TcpDumpingTask extends TaskImpl {Date startDate;Set<String> nodes;Nic nic;String filter;final static String TYPE = "TCP_DUMPING";enum Nic { eth0, eth1, eth2 }

...common.protocol.tasks;class AbortTask extends TaskImpl {int abortedTaskId;final static String TYPE = "ABORT";

...common.protocol.tasks;class QueryDataTask extends TaskImpl {Set<String> nodes;Set<String> dataTypes; boolean queryForeignSessions;final static String TYPE = "QUERY_DATA";

...common.protocol.tasks;class DownloadTask extends TaskImpl {Map<String, Collection<String>> paths;final static String TYPE = "DOWNLOAD";

...common.protocol.tasks;class SmartPacketDecodeTask extends TaskImpl {String encodedPacketContent;final static String TYPE = "SMART_PACKET_DECODE";

...common.protocol.tasks;class StopServerTask extends TaskImpl {final static String TYPE = "STOP_SERVER";

...common.protocol.tasks;class Log {enum Level { Debug, Verbose, Status, Warning, Error };enum FilterType { Message };class Filter {FilterType type;String value;Filter(FilterType type, String value)void setType(FilterType type)FilterType getType()void setValue(String value)

public String getValue()

}

}

.3 Реализация слоя «Контроллер» клиентского компонента

Как и в описании реализации серверного компонента для краткости изложения приведены только сигнатуры классов (интерфейсов) c константами, полный исходный текст программного комплекса приведён в приложении 2.

Модуль контроллера соединения представлен следующими классами:

Класс контроллера клиентского компонента. Благодаря наличию статического метода main имеет точку входа для запуска клиентского компонента. Инициирует список модулей компонента и через базовый класс их запускает, впоследствие при заврешении работы компонента - останавливает..

package client.controller;class ClientController extends ModulesController {static void main(String[] args)

@Overridevoid initModules() throws ModuleException

}

Класс контроллера соединений. Предоставляет интерфейс для отслеживания состояния соединения с сервером, установки и завершения соедниения. Производит подписку на обновления статуса соединения.client.controller;class ConnectionController {

private ConnectionMonitor connectionMonitor;void registerHandler(ConnectionUpdateHandler handler)void unregisterHandler(ConnectionUpdateHandler handler)ConnectionContext establishConnection(ConnectionParams connectionParams)void disconnect(ConnectionContext connection)

}

Класс мониторинга соединения, реализует интерфейс Runnable для выполнения в параллельном потоке задачи мониторинга состояния соединения с узлом СХД Centera. При изменении состояния оповещает подписчиков (подписка происходит через контроллер соединения).

package client.controller;class ConnectionMonitor implements Runnable {Collection<ConnectionUpdateHandler> handlers;ConnectionMonitor()void registerHandler(ConnectionUpdateHandler handler)void unregisterHandler(ConnectionUpdateHandler handler)

@Overridevoid run()

}

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

package client.controller;interface ConnectionUpdateHandler {void handle(ConnectionContext context);

}

Модуль контроллера задач представлен следующими классами:

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

package client.controller;class TaskController implements ConnectionUpdateHandler {CachedTaskRepository taskCache;TaskMonitor taskMonitor;TaskUpdater taskUpdater;TaskController()TaskFactory getTaskFactory()Task getTask(int id)void registerTaskUpdateHandler(int id, TaskUpdateHandler handler)void unregisterTaskUpdateHandler(int id, TaskUpdateHandler handler)

@Overridevoid handle(ConnectionContext context)

}

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

package client.controller;interface TaskFactory {SearchInLogTask createSearchInLogTask(Date from, Date to, Set<String> nodes, Set<String> logTypes, boolean isPatternRegExp, String pattern);CustomLoggingTask createCustomLoggingTask(Date startDate, Set<String> nodes, Log.Level level, Set<String> loggers, Collection<Log.Filter> filters);TcpDumpingTask createTcpDumpingTask(Date startDate, Set<String> nodes, Nic nic, String filter);AbortTask createAbortTask(int abortedTaskId);QueryDataTask createQueryDataTask (Set<String> nodes, Set<String> dataTypes, boolean queryForeignSessions);DownloadTask createDownloadTask(Map<String, Collection<String>> paths);SmartPacketDecodeTask createSmartPacketDecodeTask(String encodedPacketContent);StopServerTask createStopServerTask();

}

Реализация фабрики задач.client.controller;class TaskFactoryImpl implements TaskFactory {

...

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

package client.controller;class CachedTaskRepository implements TaskRepository {CachedTaskRepository(TaskRepository taskRepository)

...

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

package client.controller;class TaskMonitor implements Runnable {TaskUpdater taskUpdater;

@Overridevoid run()void checkTasksStates()

}

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

package client.controller;class TaskUpdater {Map<Integer, TaskUpdateHandler> handlers;void update(Task task)void compareAndNotify(Task previous, Task actual)void registerTaskUpdateHandler(int id, TaskUpdateHandler handler)void unregisterTaskUpdateHandler(int id, TaskUpdateHandler handler)

}

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

package client.controller;interface TaskUpdateHandler {enum UpdateType { State, Result };

void handle(UpdateType type, Task task);

}

.4 Реализация слоя «Вид» клиентского компонента

Слой «Вид» реализован с помощью классов библиотеки Java Swing, в качестве дополнения к ней использована компонент библиотеки дизайна графического интерфейса JGoodies - модуль, отвечающий за организацию взаимного размещения компонентов окна.

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

Окно «Main window»

Основное окно является подписчиком на обновления о состоянии соединения с серверным компонентои и отображает текущий статус в строке состояния внизу окна. Вид окна представлен на рис. 4.1.

Рисунок 4.1 Вид окна «Main window»

Окно «Choose connection» приведено на рис. 4.2, для манипуляций с параметрами соединения использует соответствующий класс из слоя «Модель»

Окно «Edit cluster connection» приведено на рис. 4.3

Окно «Enter password» приведено на рис. 4.4

Окно «Exit» приведено на рис. 4.5

 Рисунок 4.2 Вид окна «Choose connection»

Рисунок 4.3 Вид окна «Edit cluster connection»

 Рисунок 4.4 Вид окна «Enter password»

Окно «Sessions» приведено на рис. 4.6, информация о сессиях запрашивается у клиентской библиотеки.

Рисунок 4.6 Вид окна «Sessions»

Окно «Search in logs» приведено на рис. 4.7.

Рисунок 4.7 Вид окна «Search in logs»

Окно «Select nodes» приведено на рис. 4.8

Рисунок 4.8 Вид окна «Select nodes»

Окно «Log» приведено на рис. 4.9, является подписчиком на обновления задачи поиска сообщений в журналах СХД, при нотификации об изменении задачи происходит анализ новых результатов (новых найденных сообщений) и добавление их в список.

Рисунок 4.9 Вид окна «Log»

Окно «Custom logging» приведено на рис. 4.10

Рисунок 4.10 Вид окна «Custom logging»

Окно «Create new custom log» приведено на рис. 4.11

Рисунок 4.11 Вид окна «Create new custom log»

Окно «TCP dumping» приведено на рис. 4.12

Рисунок 4.12 Вид окна «TCP dumping»

Окно «Create new TCP dump» приведено на рис. 4.13

Рисунок 4.13 Вид окна «Create new TCP dump»

Окно «Download» приведено на рис. 4.14, в списке «Existing data» отображается результат выполнения задачи поиска файлов с заданными параметрами.

Рисунок 4.14 Вид окна «Download»

Окно «Download progress» приведено на рис. 4.15, окно является подписчиком на обновления задачи копирования файлов.

Рисунок 4.15 Вид окна «Download progress»

Окно «Base64 encode/decode» приведено на рис. 4.16

Рисунок 4.16 Вид окна «Base64 encode/decode»

Окно «SmartPacket decode» приведено на рис. 4.17

Рисунок 4.17 Вид окна «SmartPacket decode»

Окно «ZLIB compress/decompress» приведено на рис. 4.18

Рисунок 4.18 Вид окна «ZLIB compress/decompress»

5. ТЕСТИРОВАНИЕ ПРОГРАММНОГО КОМПЛЕКСА

.1 Выбор методик тестирования

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

Для проверки качества реализации сущностей на уровне классов следует применить методику компонентного тестирования, обеспечивающую автоматизированное выполнение тестов, что сокращает скорость проверки; а также оперативное определение дефектов при внесении изменений в программный продукт. Для создания компонентных тестов в проекте используется библиотека JUnit 4.8.2 [9].

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

.2 Компонентное тестирование

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

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

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

Серверный компонент - 90%

Слой «Модель» клиентского компонента - 90%

Слой «Контроллер» клиентского компонента - 75%

Слой «Вид» клиентского компонента (классы, не реализующие оконные элекменты) - 50%

Общий модуль клиентского и серверного компонентов - 90%

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

При реализации серверного компонента и общего модуля протокола использовалась методика «Разработка через тестирование» (Test-driven development) [10], когда изначально для класса пишется набор тестов, описывающих все варианты исходных данных, которые могут возникать в процессе работы класса, а также конечные результаты; затем пишется минимальная реализация класса, обеспечивающая стопроцентное прохождение теста. В результате такого подхода к реализации в исходном коде практически нет неиспользуемых фрагментов кода, которые только занимают системные ресурсы и никоим образом не влияют на результат работы программы.

Благодаря хорошей декомпозиции задачи, инкапсуляции и использованию интерфейсов покрытие оставшейся части классов компонентными тестами не составило больших усилий и свелось только анализу вариантов использования класса и их описанию с использованием конструкций библиотеки JUnit. Совместно с библиотекой JUnit для описания окружения тестируемого класса использовались средства библиотеки EasyMock 3.0 [11], позволяющие легко реализовывать объекты-заглушки нужного типа, обладающие требуемым поведением.

Для анализа покрытия исходного кода тестами использовался модуль для ИСР Eclipse под названием EclEmma версии 1.5.3 [12].

Результаты тестирования и подсчёта покрытия исходного кода классов компонентными тестами:

Компонентные тесты выполняются в объёме 100%

Анализ степени покрытия по указанным структурным единицам программного комплекса: серверный компонент - 93%; слой «Модель» клиентского компонента - 84%; слой «Контроллер» клиентского компонента - 77%; слой «Вид» клиентского компонента (классы, не реализующие оконные элекменты) - 67%; общий модуль клиентского и серверного компонентов - 92%.

.3 Системное тестирование

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

5.4 Анализ результатов тестирования

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

EMC Corporation, «Demo: Centera complete» (на английском языке), <http://www.emc.com/collateral/demos/microsites/hardware/centera-complete/index.htm>, 2008

EMC Corporation. «Security in EMC CentraStar 4.1 A Detailed Review» (на английском языке), <http://russia.emc.com/collateral/hardware/white-papers/h4495-security-emc-centrastar-wp.pdf>, 2009Jacobson, Craig Leres and Steven McCanne. «Manual page. PCAP-FILTER(7)» (на английском языке), <http://www.unix.com/man-page/FreeBSD/7/pcap-filter/>, 2008.

Internet Engineering Task Force (IETF), Network Working Group. «Request for Comments 4648: The Base16, Base32, and Base64 Data Encodings» (на английском языке), <http://tools.ietf.org/html/rfc4648>, 2006Engineering Task Force (IETF), Network Working Group. «Request for Comments 1950: ZLIB Compressed Data Format Specification version 3.3» (на английском языке), <http://tools.ietf.org/html/rfc1950>, 1996Engineering Task Force (IETF), Network Working Group. «Request for Comments 4250:The Secure Shell (SSH) Protocol Assigned Numbers» (на английском языке), <http://tools.ietf.org/html/rfc4250>, 2006Wide Web Consortium (W3C). «Extensible Markup Language (XML)» (на английском языке), <http://www.w3.org/XML/>, 2011. «Java Platform, Standard Edition 6. API Specification. Package org.w3c.dom» (на английском языке), <http://download.oracle.com/javase/6/docs/api/org/w3c/dom/package-summary.html>, 2011

«Junit. Getting started» (на английском языке), <http://junit.sourceforge.net/>, 2011Koskela. «Test Driven: TDD and Acceptance TDD for Java Developers» (на английском языке), Manning Publications, 2007Freese, Henri Tremblay. «EasyMock 3.0 Readme» (на английском языке), <http://easymock.org/EasyMock3_0_Documentation.html>, 2010GmbH & Co. KG. «Java Code Coverage for Eclipse. User Guide» (на английском языке) <http://www.eclemma.org/userdoc/index.html>, 2011

Oracle. «Lesson:Using Swing components» (на английском языке), <http://download.oracle.com/javase/tutorial/uiswing/components/index.html>, 2010Gosling, Bill Joy, Guy Steele, Gilad Bracha «The Java Language Specification» (на английском языке), третье издание, Addison Wesley, 2005

ПРИЛОЖЕНИЕ 1

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

системы хранения данных EMC Centera

Техническое задание

Р.П.68124-01

Листов 2

Аннотация

Приведены требования к разрабатываемой программе.

Основание для разработки

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

Назначение

Программный комплекс предназначен для автоматизации процессов сбора и анализа данных о состоянии системы хранения данных EMC Centera.

Требования к программе

Функциональные требования

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

Требования к функциональным характеристикам

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

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

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

Текущую конфигурацию кластера

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

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

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

Содержимого сетевых пакетов типа SmartPacket проприетарного протокола сетевого взаимодействия СХД Centera

Представление содержимого указанного пользователем файла в системе исчисления с основанием 64 (Base64), а также обратное преобразование

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

Требования к составу и параметрам технических средств

Для использования программы требуется совместимый с IBM/PC компьютер, на котором можно использовать ОС Microsoft Windows XP Service Pack 2 или 3; а также СХД Centera с версией ПО не ниже 4.0

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

Программа предназначена для использования в операционной системе Microsoft Windows XP Service Pack 2 или 3 с установленным пакетом Java Runtime Environment версии не ниже 6.

Приложение 2

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

системы хранения данных EMC Centera

Текст программы

Р.П.68124-01.12

Листов 5

Аннотация

В данном приложении приведён текст программы для анализа состояния системы хранения данных EMC Centera.

Текст программы

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

package common.params;java.io.StringWriter;javax.xml.transform.Result;javax.xml.transform.Source;javax.xml.transform.Transformer;javax.xml.transform.TransformerConfigurationException;javax.xml.transform.TransformerException;javax.xml.transform.TransformerFactory;javax.xml.transform.dom.DOMSource;javax.xml.transform.stream.StreamResult;org.w3c.dom.Document;org.w3c.dom.Element;org.w3c.dom.NamedNodeMap;org.w3c.dom.Node;org.w3c.dom.NodeList;com.sun.org.apache.xerces.internal.dom.DocumentImpl;

/**

* Implementation of XML-wrapping class.

* Intended for usage as parameters bucket.

*

* @author buinok

*/class ParamsImpl implements Params {

// default name of root tag in wrapped XML documentstatic final String PARAMETERS_ROOT_DEFAULT = "parameters";

// tag name holding simple [name:value] pairstatic final String PARAMETER = "parameter";static final String PARAMETER_NAME = "name";static final String PARAMETER_VALUE = "value";

// XML document owning child tags which are wrapped by this class Document document;

// root element of XML documentElement root;

/**

* Constructor creates new parameters bucket where

* its content is duplicated from XML node's content

* @param node - source of content for parameters bucket

*/ParamsImpl(Node node) {= new DocumentImpl();(node == null) {= document.createElement(PARAMETERS_ROOT_DEFAULT);.appendChild(root);

} else {.appendChild(document.importNode(node, true));= document.getDocumentElement();

}

}

/**

* Default constructor. Creates empty parameters bucket

* with default root tag name

*/ParamsImpl() {= new DocumentImpl();= document.createElement(PARAMETERS_ROOT_DEFAULT);.appendChild(root);

}

/**

* De-facto copy constructor. Creates new parameters bucket

* then fill it by duplicated content of @param params argument

*/ParamsImpl(Params params) {= new DocumentImpl();(params == null) {= document.createElement(PARAMETERS_ROOT_DEFAULT);.appendChild(root);

} else {.appendChild(document.importNode(params.getXmlContent(),true));= document.getDocumentElement();

}

}

/**

* Sets name of root tag to @param name if it's not null,

* otherwise just ignores call

*/

@Overridevoid setName(String name) {(name != null).renameNode(root, null, name);

}

/**

* Tries to get String value of parameter with specified @param name

* @return String value if it exists in parameters bucket

* @throws ParamsException if there is a corruption in wrapped

* XML document

* @throws ParamsException if there are no parameters with specified @param name

*/

@OverrideString getString(String name) throws ParamsException {(name == null)new ParamsException("Invalid parameter name ["+name+"]");

// enumerate through all tags with endpoint parameterslist = root.getElementsByTagName(PARAMETER);(int index = 0; index < list.getLength(); index++) {attributes = list.item(index).getAttributes();

// check only tags with existing attributes(attributes != null) {

// try to find name attributenameAttribute = attributes.getNamedItem(PARAMETER_NAME);(nameAttribute == null)new ParamsException("Missing parameter name");nameString = nameAttribute.getNodeValue();(nameString == null)new ParamsException("Void parameter name");(!nameString.equals(name));

// try to find value attributevalueAttribute = attributes.getNamedItem(PARAMETER_VALUE);(valueAttribute == null)new ParamsException("Missing parameter value");valueString = valueAttribute.getNodeValue();(valueString == null)new ParamsException("Void parameter value");valueString;

}

}new ParamsException("There is no parameter ["+name+"]");

}

/**

* Store string parameter into bucket

* @param name - name to store parameter with

* @param value - value of stored parameter

*/

@Overridevoid putString(String name, String value) {(name == null || value == null)new IllegalArgumentException("name ["+name+

"] and value ["+value+"] are mandatory");node = document.createElement(PARAMETER);.setAttribute(PARAMETER_NAME, name);.setAttribute(PARAMETER_VALUE, value);.appendChild(node);

}

/**

* Stores parameters bucket as a parameter for another bucket.

* All nodes of stored bucket are duplicated

* @param name - name to store parameter with

* @param params - content of stored parameters bucket

*/

@Overridevoid putParams(String name, Params params) {(name == null || params == null)new IllegalArgumentException("name ["+name+

"] and parameter ["+params+"] are mandatory");node = document.createElement(name);xmlContent = params.getXmlContent();list = xmlContent.getChildNodes();(int nodeIndex = 0; nodeIndex < list.getLength(); nodeIndex++) {.appendChild(document.importNode(list.item(nodeIndex),true));

}.appendChild(node);

}

/**

* Returns all parameters buckets which are stored under actual one

* @param - name of all parameters bucket to retrieve

*/

@OverrideParams[] getAllParamsWithName(String name) {(name == null)new IllegalArgumentException("name ["+name+

"] is mandatory");list = root.getElementsByTagName(name);

[] paramsArray = new Params[list.getLength()];(int index = 0; index < list.getLength(); index++) {[index] = new ParamsImpl(list.item(index));

}

paramsArray;

}

/**

* Return root wrapped XML tag

*/

@Overridefinal Element getXmlContent() {root;

}

/**

* Implements standard method to serialize hits object to String

*/

@OverrideString toString() {factory = TransformerFactory.newInstance();{transformer = factory.newTransformer();source = new DOMSource(document);writer = new StringWriter();result = new StreamResult(writer);.transform(source, result);writer.toString();

} catch (TransformerConfigurationException e) {.printStackTrace();

} catch (TransformerException e) {.printStackTrace();

}null;

}

}

Приложение 3

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

системы хранения данных EMC Centera

Описание программы

Р.П.68124-01.13

Листов 3

Аннотация

Приводится краткая характеристика основных параметров программы, её структурное описание и условия её работоспособности

Общие сведения

Программа выполняет ряд задач:

производит поиск заданного шаблона сообщения в журналах событий системы хранения данных EMC Centera;

производит отладочное журналирование событий по заданным параметрам;

производит перехват и журналирование пакетов сетевого трафика c заданными параметрами фильтрации;

производит поиск и копирование указанных данных с узлов кластера EMC Centera на рабочую станцию пользователя;

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

производит декодирование содержимого пакетов сетевого трафика типа SmartPacket;

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

Функциональное назначение

Программа предназначена для автоматизированного сбора и анализа данных о состоянии системы хранения данных EMC Centera. Полученные данные позволяют оперативно получить информацию о причинах сбоя и его последствиях.

Описание структуры программы

Программа является клиент-серверным программным комплексом, реализованным в стиле ООП на языке Java.

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

Открытие файлов пользовательских запросов и представление их в виде объектов задач

Выполнение считанных задач

Сериализацию объектов задач с результатами в файлы результатов

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

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

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

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

Вызов и загрузка

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

Входные и выходные данные

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

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

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

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

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

Анализ сетевых пакетов SmartPacket. Взодные данные - содержимое сетевого пакета типа SmartPacket. Выходные данные - текстовое представление всех полей пакета с указанием мнемонических констант.

Используемые технические средства

Для использования программы необходима рабочая станция с ОС Windows XP SP2 или SP3; установленным пакетом Java Runtime Environment 6.0; подключением по сети к узлу СХД Centera, используя протокол TCP; СХД Centera с версией ПО не ниже 4.0.

Приложение 4

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

системы хранения данных EMC Centera

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

Р.П.68124-01.51

Листов 5

Аннотация

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

Объект испытаний

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

Цель испытаний

Удостовериться в соответствии программы техническому заданию.

Программа испытаний

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

Методика испытаний

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

Поиск шаблона в системных журналах СХД

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

Дата начала временного интервала: 25.05.2011

Дата конца временного интервала: 26.05.2011

Список узлов СХД: c001n01,c001n02,c001n04

Типы журналов: Бизнес-логика, программная платформа и ОС (во втором наборе отсутствует ОС)

Использование регулярных выражений в шаблоне: выключено

Шаблон сообщения: «/dev/sda3»

В результате поиска в окно с найденными сообщениями были выведены записи от всех трех компонентов ПО СХД Centera об ошибках чтения с раздела диска /dev/sda3.

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

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

Генерирование отладочного журнала СХД

Для данного испытания был задан следующий набор параметров генерирования:

Список узлов СХД: c001n03,c001n04

Минимальный уровень сообщений: Verbose

Список источников сообщений: ReplicationComponent

Список фильтров: не задан

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

Перехват сетевого трафика с записью в журнал

Для данного испытания был задан следующий набор параметров генерирования:

Список узлов СХД: c001n01,c001n02

Сетевой интерфейс для перехвата пакетов: eth2

Параметры фильтрации: src host 10.64.88.123 and dst port 623

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

Копирование файлов с СХД на рабочую станцию пользователя

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

Список узлов: c001n01,c001n02,c001n03,c001n04

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

Поиск файлов во всех имеющихся сессиях: отключен

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

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

Кодирование и декодирование алгоритмом Base64

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

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

Параллельно кодирование/декодирование было осуществлено с помощью специализированного веб-сервиса Online Base64, выполняющего данные преобразования.

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

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

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

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

Сжатие и декомпрессия алгоритмом ZLib

Для данного испытания были выбраны конфигурационные файлы бизнес логики, сжатые алгоритмом ZLib и закодированные алгоритмом Base64.

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

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

Результаты испытаний

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

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

Техническим средством отладки являются персональный компьютер Intel PentiumIV 2.8ГГц c оперативной памятью объемом 1Гб, дисковым пространством 10Гб и операционной системой Windows XP SP3 с установленным программным пакетом Java Runtime Environment 6.0, а также СХД Centera 4-го поколения аппаратной платформы из 4 узлов с ПО версии 4.1.1 Patch 2. Программное средство отладки - интегрированная среда разработки Eclipse.

ПРИЛОЖЕНИЕ 5

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

системы хранения данных EMC Centera

Спецификация

Р.П.68124-01

Листов 1