Главное управление ЦБ РФ по Псковской области

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

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

Системотехнические решения РВС должны отвечать требованиям международных и российских стандартов и обеспечивать открытость архитектуры, преемственность и развитие решений. Это требование в той или иной мере распространяется на все компоненты РВС, включая и подсистему управления. К задачам подсистемы управления можно отнести: сбор статистики о функционировании РВС, оперативное управление объектами системы, техническое взаимодействие со службами и др.

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

Разработчики стандартов таким подходом к определению функций управления попытались охватить все области проявления "узких" мест системы, оставляя при этом открытым достаточно широкий фронт для развития. Узкие места, как правило, возникают на стыке технологий и систем. Наиболее тонкий стык технологий не редко организационно-технический. Отмеченная особенность управления характерна и для РВС.

С точки зрения обеспечения надёжности при управлении ресурсами РВС, поддержании работоспособности ее компонентов главным является:

• определение элементов РВС как объектов управления с выделением критичных и наиболее уязвимых;
• распределение функций управления между службами РВС, определение наиболее значимых;
• определение номенклатуры паспортных данных по управляемым элементам (статус, конфигурация, статистика производительности, архив изменений состояния и др.).

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

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

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

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

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

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

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

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

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

Наряду с платформой управления важными понятиями управления АС являются консоль управления и зона (уровень, домен) ответственности.

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

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

Взаимосвязи клиентских и серверных компонентов, прозрачные для транспортного уровня, должны базироваться на технологиях управления объектами типа CORBA (Common Object Request Broker Architecture).

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

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

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

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

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

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

Идеология и архитектура современных платформ претендуют именно на такой уровень функциональности, поскольку зависимость от производителя в условиях отсутствия стандартов стала сейчас намного более жесткой и критичной. Однако пока претензии того или иного производителя на утверждение стандарта де факто очередной версией своего продукта - не более чем маркетинговый прием. И дело тут хотя бы в том, что принятие подобного стандарта, даже де факто, окажет существенное влияние на принятие других стандартов, связанных с частными аспектами архитектуры систем управления, например CORBA, DMI (Desktop Management Initiative), WBEM (Web-Based Enterprise Management) и проч.

Кроме требований к иерархии, реализующей управление по принципу “менеджер-агент”, архитектура системы управления должна обеспечивать:

• масштабируемость;
• независимость от производителя платформы управления;
• возможности по интеграции приложений от разных производителей.

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

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

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

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

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

• организационных;
• функциональных;
• топологических;
• географических.

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

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

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

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

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

Подсистема управления представляет организационно-техническую реализацию требований в части обеспечения надёжности РВС. Функции подсистемы должны выполнять следующие структурные единицы:

• узел административного надзора за состоянием РВС;
• узел управления рисками;
• узел паспортизации и контроля активности пользователей сетей;
• узел анализа и тестирования текущего состояния сетевых служб РВС.

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

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

Узел паспортизации позволяет:

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

- контролировать состав каждого вычислительного средства РВС в части установленных аппаратных (процессор, память, носители данных, сетевая карта и др.) и программ

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

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

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

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

- обеспечение выдачи на внешние устройства требуемую отчетность по паспортам, справкам и т.п.

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

Заключение

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