Управлять всем и отовсюду

2 октябрь, 2008 - 10:31Андрей Зубинский

Хотим мы того или нет, существуют высказывания, истинность которых лучше не оспаривать даже сгоряча. В контексте статьи и темы этого номера первым таким высказыванием будет следующее: «Всякая большого масштаба система нетривиальна уже потому, что она большая». Второе же звучит так: «Рациональная линия поведения при столкновении с нетривиальным – тщательные изучение, понимание, моделирование, проверка моделей и только после этого – синтез».

Приступая к подготовке нынешней Темы номера, мы ясно понимали, что принципиально невозможно охватить все ее аспекты в рамках одного выпуска еженедельника. Ведь проблему управления ИТ-инфраструктурой можно рассматривать на самых разных уровнях: от интеллектуальных систем коммутации СКС до высокоуровневых интегрированных решений класса HP OpenView. Так что развернуться тут есть где, однако, по нашим оценкам, наибольшей популярностью среди читателей «Компьютерного Обозрения» пользуются материалы, посвященные продуктам и решениям класса mainstream, которые сочетают довольно широкую функциональность и доступную цену. Поэтому в одном из материалов Темы проанализирована проблематика удаленного управления серверами с помощью встраиваемых средств и внешних решений. Актуальность этой задачи в последнее время повышается для все большего числа украинских компаний, строящих либо модернизирующих свои информационные системы. Ведь по мере роста серверного парка в геометрической прогрессии усложняется управление им. А уж если речь идет о географически распределенной структуре, то тут особенно ощущается необходимость в удобных и эффективных средствах удаленного управления. Надеемся, что предложенный вашему вниманию обзор поможет сориентироваться в имеющихся ныне решениях данного класса. А первая статья Темы введет вас в мир стандартов WBEM, на базе которых создаются программные средства удаленного управления.

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

Раз уж речь идет о системах управления масштабными структурами, давайте для начала определимся с предметом обсуждения. И уже с этого момента начинает сказываться проклятие масштаба – «масштабная информационная структура», «ИС масштаба предприятия» и т. п., – все это эволюционно развивающаяся во всех аспектах большая человеко-машинная система, состоящая из тысяч вычислительных комплексов самого разного назначения. Давайте добавим к этому неизбежную технологическую особенность современности – виртуализацию, на деле означающую, что незначительная часть этих тысяч вычислительных машин может сама по себе являться тысячами совершенно иных вычислителей с собственными операционными системами, сервисами, с весьма специфическим системным и прикладным программным обеспечением, политиками безопасности и даже пользователями, организационно никакого отношения не имеющими к оригинальной, реальной системе. Чем можно и нужно управлять в подобной структуре? Единственно верный ответ на этот вопрос является наименее информативным, но и самым простым – всем. А дальше уже начинаются сплошные сложности. Например, сколько нужно различных инструментальных средств для управления «всем»? Сколько времени надо затратить на подготовку специалистов, способных управлять «всем» с помощью достаточного для решения подобной задачи количества инструментальных средств? И т. д.

Итак, без ненужного на нашем уровне углубления в детали мы можем говорить о следующих специфических свойствах больших информационных систем: эволюционный характер развития, гетерогенность, виртуализация, масштаб. К этому перечню следует добавить территориальную распределенность, которая вносит весьма специфические коррективы. Естественно, вряд ли кто-то найдет в себе возможности, позволяющие, как говорится, бухнуть на стол подобный перечень в качестве особенностей задачи «и вот в этом нам надо управлять всем». Не существует приемов, систем и даже подходов, чтобы решить подобную задачу «одним махом» (да и не одним – тоже). Такое резкое утверждение, безусловно, требует пояснений. И они могут быть весьма пространными. Но давайте лучше посмотрим на то, какими интеллектуальными и технологическими усилиями решается относительно несложная задача управления... всего лишь одним утилитарным приложением – заслуженно популярным компилятором gcc. На самом деле эта задача не такая уж и надуманная, как кажется, – нахождение оптимальных настроек компилятора по заданным высокоуровневым критериям, предъявляемым к результирующему коду, может оказаться весьма полезным в самых неожиданных системах (например, в масштабных, ориентированных на финансовое моделирование или оптимизацию). Даже для такой сугубо «гомогенной» и утилитарной задачи (речь идет не только всего об одном компиляторе, но и, на самом деле, об одном критерии – быстродействии кода) пришлось использовать алгоритмы генетического программирования и специально разработанное уникальное программное обеспечение (проект Acovea). Естественно, подобную задачу можно отнести к разным классам, но она – яркий представитель задач управления. И для управления всего одной утилитой (далеко, кстати, не самой сложной на командном уровне, если считать опции компилятора командами) понадобилась серьезная математика и уникальное ПО. Так что если уж управлять «всем» и с какой-то осмысленной целью, то потребуется, примерно, как минимум – серьезная математика и уникальное ПО. С одним нюансом – для каждого из перечня «всего». И большинство потребителей это почему-то не устраивает.

От протоколов – к конгломератам стандартов

История развития технологий управления информационными системами дает наглядный пример той скорости, с которой только что считавшиеся совершенными разработки теряют не только ореол совершенства, но иногда и вообще целесообразность. Разнообразие стандартов (в технологиях управления широко используются и SNMP, и CORBA, и CMIP), умноженное на огромное количество управляемых объектов – программно-аппаратных систем, формирует идеальные условия для того, чтобы управление ИT-структурами превратилось в крайне затратную область с высокими рисками. Для полноты картины стоит упомянуть, что некоторые стандарты в результате эволюции порождают принципиально несовместимые версии спецификаций, например SNMP v1 и v3.

Ранние попытки создать некий унифицированный механизм управления сводились фактически к спецификациям протоколов. Их «обкатке» способствовала специфика ряда аппаратных средств, для которых удаленное управление было жизненно необходимым. В первую очередь, это были сетевые весьма скромно по нынешним меркам интеллектуальные устройства. Естественно, они не предлагали богатый набор управляемых ресурсов, и для них не требовались сложные управляющие механизмы. И те же спецификации протокола SNMP, например, прекрасно соответствовали этим особенностям. С другой стороны, богатые наборы системных и административных утилит UNIX-совместимых операционных систем и мощные командные языки позволяли решать ряд специфических для многопользовательских систем задач управления с помощью протокола SSH. Увы, в масштабных гетерогенных ИT-структурах эти уже ставшие классическими протоколы, несмотря на ревизии их спецификаций, применимы для решения далеко не всех задач. Естественно, эволюция этих протоколов будет продолжаться, и для них всегда найдется применение в несложных системах, но реальность требует адекватных задачам решений. Самой серьезной попыткой найти их можно считать разработку конгломерата стандартов WBEM (Web-Based Enterprise Management) и программные системы, созданные на их основе.

Разработкой стандартов WBEM занимается открытая организация DMTF (Distributed Management Task Force), созданная в 1992 г. В рабочих группах DMTF участвуют специалисты более 200 компаний, в списке которых все гранды ИT – Microsoft, Cisco, Hewlett-Packard, IBM, Intel, Sun, Oracle, Fujitsu Siemens, Dell.

Ключевое понятие, без которого невозможно дальнейшее ознакомление со стандартами WBEM и их «овеществлениями» в исполняемом коде разных систем (в семействе Windows – WMI, в Sun Solaris – Solaris WBEM Services, в RedHat Linux – OpenPegasus, в Novell Suse Linux – OpenWBEM и т. д.) – управляемость (manageability). Оно, естественно, означает способность быть управляемым и определяет принципы взаимодействия управляемых объектов с управляющими функциями. На более «техническом» языке управляемость – это оснащенность средствами контроля, характеристики интерфейсов этих средств, формы представления и семантика информации, функциональная совместимость с управляющими системами. И стандарты WBEM строятся, естественно, вокруг главной составляющей управляемости – стандартной информационной модели, CIM (Common Information Model). Этот стандарт специфицирует расширяемое множество объектно-ориентированных моделей управленческой информации для самого разнообразного оборудования и систем, а целью его является достижение возможности моделирования любой управленческой информации для любой системы. Для описания классов CIM используется специальный язык – MOF (Managed Object Format). Он основан на известном языке описания интерфейсов IDL, с которым хорошо знакомы программисты, работающие с компонентным программным обеспечением. Транслятор MOF входит во все реализации WBEM (например, в вашей ОС семейства Windows NT и старше он наверняка есть – c:WINDOWSsystem32wbemmofcomp.exe). Следует заметить, что CIM – не специфический для WBEM стандарт, он имеет самостоятельную ценность и широко используется в информационной индустрии (например, DEN (Directory Enabled Network) – стандарт, определяющий способы описания и хранения в репозитории информации о сетевых пользователях, приложениях и данных, основывается на CIM). В реализующих стандарт WBEM программных системах CIM обычно овеществляется модулем CIMOM (Common Information Model Object Manager) – менеджером объектов CIM. CIMOM – ядро сервера WBEM, дающее клиентам доступ к стандартизованной информации об управляемом объекте. Для устранения бреши между абстрактным стандартизированным представлением и реальным объектом WBEM-сервер располагает набором так называемых WBEM-провайдеров. Для «общения» между клиентом и сервером в качестве транспортного обычно используется http-протокол, но это требование не является принципиальным, так, в ОС семейства Windows в WBEM-подсистеме (WMI) транспортным протоколом является DCOM. CIM-информация передается в XML-форме и способность XML-http-обмена ею является фундаментальным требованием для WBEM-совместимости. Так как стандарты WBEM – область больших систем, очевидно, что в реальных ИT-проектах количество CIM-объектов будет очень большим. И необходим какой-то механизм, позволяющий эффективно описывать группу объектов для выполнения управляющих команд сразу над всей группой. WBEM располагает таким механизмом – SQL-совместимым языком запросов к базе CIM-объектов, WBEMSQL. Наличие транслятора WBEMSQL-запросов обязательно для каждого WBEM-сервера. Немаловажным достоинством WBEM является то, что входящие в него стандарты не определяют практически никаких специфических требований к пользовательскому интерфейсу клиентской подсистемы. Это означает, что она может быть любой – от привычной системным администраторам старой UNIX-школы консольно-языковой до специально разработанной для данного класса задач с самым передовым GUI.

Итак, макромодель WBEM-управления можно описать следующим образом. Администратор с помощью WBEM-клиента выбирает сервер управляемого объекта, формирует XML-запрос и передает его серверу, который транслирует запрос в обращения к CIMOM, инициирующие работу соответствующих WBEM-провайдеров, играющих, по большому счету, роль драйверов для физических устройств, подсистем ОС, исполняющихся прикладных программ и т. п. Язык XML-запросов строится на основе «понимаемых» WBEM-сервером функций, в числе которых операции с классами моделей (GetClass – запрос спецификаций модели, CreateClass, DeleteClass, ModifyClass – создание-удаление-изменение модели), операции с объектами классов (в том числе и GetProperty/SetProperty – получение-изменение свойства объекта) и так далее, вплоть до ExecQuery – функции выполнения сложной операции над группой объектов, заданной языком запросов WBEMQL.

По сути, мы говорим об аналоге операционной системы. Да, именно операционной системы – WBEM-управление создает единый механизм абстрактного представления управляемого объекта, скрывая за ним множество практически любых систем любого масштаба и степени территориальной распределенности. Как и в обычных ОС, WBEM оставляет место для низкоуровневого системно-зависимого программирования – разработку «драйверов», WBEM-провайдеров, для этого есть необходимые детально документированные стандартные API.

Несмотря на сложность и обширность спецификаций, создано несколько программных реализаций, соответствующих WBEM-стандартам. Причем многие из них – с открытыми исходными текстами и легально бесплатные. К ним можно отнести OpenPegasus, SBLIM, OpenWBEM, Purgos, WBEM Services.

Поиск управляемых ресурсов

В действительно больших ИT-структурах, где количество управляемых ресурсов исчисляется сотнями тысяч и даже миллионами, отдельной задачей, не имеющей единственно наилучшего решения, является определение «местоположения» (естественно, не географического, а в инфраструктуре) этих ресурсов. Иными словами – надо иметь возможность в динамически изменяющемся WBEM-окружении отыскивать WBEM-управляемые системы (серверы) и уметь выделять множество управляемых ресурсов (и отвечающих за них серверов), представляющих интерес для администратора. Кроме того, могут возникать определенные нюансы при взаимодействии клиентского ПО одной из реализаций WBEM с сервером от другой, и нужен механизм, позволяющий определять возможности серверов и взаимодействие с ними. Список возможных альтернативных подходов к решению этих задач невелик. Во-первых, можно поддерживать простой предварительно определенный список управляемых ресурсов. Естественно, этот способ самый простой на бумаге и самый неработоспособный в сложной изменяющейся ИT-структуре. Во-вторых, можно проводить регулярные «разведки» инфраструктуры с помощью традиционного набора сетевого инструментария и испытанных приемов опроса IP-адресов и сканирования портов. Увы, и этот подход далек от совершенства и в действительно больших распределенных структурах неэффективен. В-третьих, существуют специальные протоколы, созданные исключительно для облегчения решения такой задачи, например, SLP (Service Location Protocol). В-четвертых, можно применить один из вариантов CIM – DEN, который упомянут в статье, или какие-либо аналогичные сервисы, например, LDAP. Выбором DTMF, организации, занимающейся разработкой стандартов WBEM, является открытый протокол SLP, изначально создаваемый с целью эффективного поиска управляемых ресурсов (серверов) и с учетом требования легковесности к реализациям как клиентской, так и серверной. SLP является стандартом (RFC 2608). Также с целью повышения эффективности WBEM-инфраструктура предусматривает и использование сервиса директорий, DEN. Существует несколько открытых реализаций SLP, в том числе и начатая еще фирмой Caldera и доведенная Open Source сообществом до стабильной и пригодной для реальных проектов версии разработка OpenSLP. Кроме того, специалистами Колумбийского университета и компаний Sun и IBM создана открытая кросс-платформенная улучшенная Java-реализация mSLP.

Это ознакомительное описание дает возможность понять главное: и сами WBEM-системы далеки от простоты, а созданные на их основе масштабные системы управления – тем более. А латентные их особенности в некоторых аспектах могут вносить существенные коррективы вообще в применимость WBEM-идеологии. Так, всего один XML-http запрос информации об одном объекте передается примерно килобайтным «посланием». Что означает – об этом нельзя забывать, и если к удаленному управляемому объекту ИT-инфраструктуры есть доступ только по каналу с узкой полосой пропускания, следует принимать во внимание, что по сравнению с управлением на основе SMTP-протокола для WBEM-систем может потребоваться полоса на 1000% больше. Ситуация может усугубляться исключительно важной подсистемой WBEM-реализаций, отвечающей за оповещение администраторов о событиях управляемых объектов.