Управление человеческими ресурсами в сфере информационных технологий

Рисунок 7.9 Основные компоненты архитектуры SNMPv3.

Рис. 7.8 Основные управляющие стандарты и связи между ними.

Рис. 7.7. Схема взаимодействия менеджер-агент.

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

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

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

С точки зрения изучения возможностей систем управления следует учитывать полезное деление, введенное в X.701. Управление подразделяется на следующие аспекты:

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

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

Как видно из рисунка, ключевую роль играет модель управляющей информации. Она описывается рекомендациями X.720 [4]. Модель является объектно-ориентированной с поддержкой инкапсуляции и наследования. Дополнительно введено понятие пакета как совокупности атрибутов, операций, извещений и соответствующего им поведения. Класс объектов определяется позицией в дереве наследования, набором включенных пакетов и внешним интерфейсом, то есть видимыми снаружи атрибутами, операциями, извещениями и демонстрируемым поведением.

Помимо концепций, рекомендации семейства X.700 специфицируют две вполне практичные вещи: сервис управления — CMIS (Common Management Information Service) и протокол управления — CMIP (Common Management Information Protocol). CMIS определяет, в частности, следующие базовые операции:

M-GET — запрос на выборку управляющей информации;

M-SET — запрос на модификацию управляющей информации;

M-ACTION — запрос на выполнение действия;

M-CREATE — запрос на создание нового экземпляра управляемого объекта;

M-DELETE — запрос на удаление экземпляра управляемого объекта;

M-CANCEL-GET — запрос на отмену ранее выданного, но ставшего ненужным запроса M-GET.

Прежде чем выполнить операцию над объектом, его необходимо выбрать. CMIS предлагает для этого механизмы областей действия и фильтрации. В соответствии с дисциплиной именования управляемые объекты организуются в виде дерева. Область действия может задаваться как часть некоторого поддерева в общем дереве. Фильтр — это логическая связка утверждений. Таким образом, для операции выбираются все "успешно отфильтрованные" объекты из заданной области действия.

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

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

Интернет-стандарты: SNMP-управление

В то время, как стандарты OSI/ISO являются "фундаментальными академическими" разработками и дают некоторое представление как правильно действовать, дела в практической области управления идут своей дорогой. В рамках Тематической группы по технологии Интернет (Internet Engineering Task Force, IETF) был разработан протокол SNMP (Simple Network Management Protocol).

Напомним, как выглядит модель SNMP-управляемой системы. Она состоит из следующих элементов:

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

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

Именно концептуальная архитектурная простота и ясность модели привела к взрыву на рынке управляющих приложений в конце 80-х, начале 90-х годов [1], когда стали появляться десятки свободно распространяемых и коммерческих программных продуктов управления сетями передачи данных. Насыщение рынка привело к тому, что временное средство оказалось стандартом "de facto", и сейчас идет интенсивная работа уже над третьей версией протокола (SNMPv3, см., например, [5]).

[1] Первое описание SNMP версии 1 появилось в 1988 г. (RFC1067) и стало Интернет-стандартом в 1990 г. (RFC1157).

Модель управления, однако, не может ограничиваться только технологией изменения переменных, поэтому она включает еще и описание управляющей информации и событий. Эти описания составляют определение структуры управляющей информации SMI (Structure of Management Information)[2].

[2] SMI соответствует свой ряд документов RFC.

И, наконец, третьим компонентом являются описания управляющей информации, событий и связанных с этим требований по реализации, которые специфицированы в документах, называемых MIB (Management Information Base). Тут свой ряд RFC.

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

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

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

На рисунке представлены основные компоненты архитектуры SNMPv3. На верхнем уровне таких компонентов два:

• SNMP-машина;
• управляющие сервисы.

SNMP-машина присутствует во всех управляемых и управляющих компонентах. Она включает четыре компонента:

• диспетчер;
• подсистему обработки сообщений;
• подсистему безопасности;
• подсистему разграничения доступа.

Диспетчер занимается приемом и отправкой SNMP-сообщений.

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

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

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

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

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

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

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

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