Материал: Разработка программного комплекса для анализа состояния системы хранения данных EMC 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 байта).