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

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

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

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

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

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

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

системы хранения данных 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.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); так и локально, когда сервисный инженер приходит к пользователю и подключает консоль непосредственно к узлу кластера или же подключает переносной сервисный компьютер во внутреннюю сеть кластера.

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

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

EMC Centera Console

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

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

Centera Viewer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 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
Нарушение принципа SPOF	Составление цепочки событий отказа дисковых накопителей и регенерации данных, на них хранимых.	Графический интерфейс Centera Viewer
	Составление списка данных, находящихся под угрозой утраты; а также поиск имеющихся копий таких данных.	Вспомогательные программы для обслуживающего персонала
Сбой внутренней ВС	Анализ состояния коммутаторов ВС и сетевых интерфейсов узлов	Средства командной строки ОС EMC Centera Linux
	Анализ журналов ОС и программной платформы за время сбоя.	Просмотр журналов средствами ОС EMC Centera Linux
	Анализ трафика внутренней ВС на предмет выявления отклонений от нормальной работы ВС.	Команда tcpdump ОС EMC Centera Linux
Повреждение системной конфигурации	Анализ текущей системной конфигурации	Графический интерфейс Centera Viewer
		Просмотр файлов конфигурации средствами командной строки ОС EMC Centera Linux
Истощение доступных ресурсов ОС	Анализ состояния ресурсов ОС и их потребителей	Средства командной строки ОС EMC Centera Linux
	Анализ журналов ОС, программной платформы и бизнес-логики СХД Centera для выявления причин истощения выделенных ресурсов ОС	Просмотр журналов средствами ОС EMC Centera Linux
Сбой функциони-рования компонента	Анализ статистических показателей бизнес-логики СХД Centera	Графический интерфейс Centera Viewer
	Анализ состояния функциональных компонентов СХД Centera	Средства командного интерфейса СХД Centera
	Анализ текущей системной конфигурации	Графический интерфейс Centera Viewer
		Просмотр файлов конфигурации средствами командной строки ОС EMC Centera Linux
	Анализ журналов (в том числе и отладочных журналов) ОС, программной платформы и бизнес-логики СХД Centera	Просмотр журналов средствами ОС EMC Centera Linux
	Анализ трафика внутренней и/или внешней ВС на предмет выявления отклонений от ожидаемого сетевого взаимодействия функционального компонента	Команда tcpdump ОС EMC Centera Linux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.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, после чего при успешном установлении соединения пользователю показывается главное окно программы.

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

Состав меню

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

Cluster

Reconnect

Sessons

Exit

Logging

Search in logs…

Custom logging…

TCP dumping…

Download…

Analysis

Base64 encode/decode…

SmartPacket decode

ZLIB compress/decompress

Help

User's manual page

About

Windows

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

«Cluster - Reconnect»

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

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

«Cluster - Sessions…»

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

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

«Cluster - Exit…»

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