Инфраструктура управления

Если управление системами ПК напоминает вам погоню за стадом разбегающихся мустангов, то новые аппаратные и программные средства, вполне вероятно, позволят удержать их в узде.

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

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

ИЗЪЯНЫ ИНФРАСТРУКТУРЫ

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

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

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

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

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

Учитывая, что более 90% настольных машин и серверов имеют процессоры Intel и что значительная часть систем обоих типов использует обслуживающие микросхемы и системные платы той же компании, резонно предположить, что Intel первой позаботится о восполнении недостатков аппаратной инфраструктуры. Фактически спецификация Wired for Management Baseline компании Intel предлагает решение всех выше описанных задач. (Management Baseline 1.1 можно найти по адресу: www.intel.com/managedpc/wired/wfm_spec.htm.)

КОНТРОЛЬНО-ИЗМЕРИТЕЛЬНАЯ АППАРАТУРА

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

В том, что касается компьютера, контрольно-измерительная аппаратура не имеет ничего общего с видеокамерами или датчиками давления; различные процессоры и низкоуровневые программные процессы предоставляют, как правило, необходимые управляющему приложению данные, без помощи каких-либо специальных аппаратных датчиков. Большинство системных плат с Pentium Pro имеет специальные управляющие контроллеры и шину для проведения инвентаризации, обработки событий, защиты и других видов контроля. Единственное, что требуется, - это стандартизованный доступ к имеющимся данным.

Производители, поддерживающие Wired for Management Baseline компании Intel, должны внедрить Systems Standard Groups Definition, определенный инженерной группой по управлению настольными системами (Desktop Management Task Force, DMTF). В состав DMTF Standard Group входят рабочие группы по дискам, клавиатуре, манипуляторам, операционным системам, физическим корпусам, процессорам, системной BIOS, системному кэшу и видео (Disks, Keyboard, Pointing Device, Operating System, Physical Container, Processor, System BIOS, System Cache и Video). Кроме того, помимо структур данных в формате Management Information Format (MIF) производи-

тели должны предоставить программное обеспечение Desktop Management Interface (DMI) 2.0 Service Provider и обеспечить поддержку одного из стандартных механизмов доступа к DMI, что позволит управляющим приложениям, обменивающимся информацией по сети, собирать данные об оборудовании. В состав DMTF входят не только партнеры Intel, но и все крупнейшие производители систем - AMD, National Semiconductor, Sun Microsystems и IBM. А раз так, то проблема стандартизации оборудования, по всей вероятности, вскоре будет решена, хотя многие системы, созданные более двух лет назад, а также любые новые системы, не поддерживающие стандарт, останутся по-прежнему неуправляемыми.

УДАЛЕННОЕ ПРОБУЖДЕНИЕ

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

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

Наконец, практически "спящая" сетевая плата должна распознавать специальный шаблон, присылаемый по сети и сообщающий о том, что пришло время "пробуждения". В своей серии сетевых плат AMD реализовала специальный кадр пробуждения, названный Magic Packet. Компании Hewlett-Packard и IBM применяют системы Magic Packet в некоторых из своих настольных ПК. Microsoft сообщила о намерении поддерживать шаблоны пробуждения в Windows 98 и NT 5. Более того, эти новые операционные системы будут также поддерживать отложенный режим, или режим сна, при котором после пробуждения ОС возобновит свою работу с того момента, где та была прервана.

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

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

СЕРВИСНАЯ ЗАГРУЗКА

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

Базовая спецификация Intel для выполнения сервисной загрузки предусматривает использование Trivial File Transfer Protocol (TFTP) и расширенной версии Dynamic Host Configuration Protocol (DHCP). Поля меток внутри пакета DHCP идентифицируют тип сетевой платы, архитектуру клиентской системы и, возможно, самого клиента. Как и в случае обычного DHCP, клиент посылает широковещательный запрос DHCP. Этот исполняемый код процедуры запуска может быть записан в ПЗУ сетевой платы или выполняться с дискеты. Помимо обычной функции DHCP по передаче

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

Расширения Intel для DHCP не влияют на работу других клиентов или серверов, использующих этот протокол. Однако текущая версия спецификации Wired for Management Baseline не касается таких вопросов защиты, как секретность, идентификация и целостность данных. Более того, данное предложение нацелено на настройку новой системы и не предназначено для загрузки в случае необходимости.

УПРАВЛЕНИЕ ПИТАНИЕМ

В начале 1997 года Intel, Microsoft и Toshiba приняли спецификацию Advanced Configuration and Power Interface (ACPI). Большинство производителей основных систем и периферии согласились реализовать методы ACPI для управления потреблением электроэнергии как в настольных, так и в мобильных системах. ACPI определяет стандартный уровень между аппаратными компонентами и уровнем аппаратной абстракции операционной системы, тем самым позволяя ОС стандартным образом управлять выбором схемы потребления электроэнергии и освобождая производителей аппаратного обеспечения от обременительной задачи разработки различных приложений для каждой комбинации компьютера и периферийных устройств (см. Рисунок 1). После реализации и развертывания ACPI будет играть важную роль в спецификации Intel Baseline.

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

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

ИНФРАСТРУКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Еще один серьезный, препятствующий решению задач управления, изъян инфраструктуры можно обнаружить в современном управляющем программном обеспечении. SNMP и связанные с ним программные платформы и приложения имеют серьезные недостатки с точки зрения выполнения задач управления системами. Базы управляющей информации SNMP редко реализуются в клиентских системах и серверах. Даже когда стандартные MIB и фирменные расширения реализуются на сетевых устройствах - маршрутизаторах, концентраторах и коммутаторах - система опроса SNMP ограничивает масштабируемость управляющей системы. Кроме того, модель SNMP, предусматривающая единую консоль, служит препятствием к широкому распространению управляющей информации. Приложения на базе RMON обладают большим потенциалом для управления коммутируемой инфраструктурой, но сами по себе они мало что могут предложить для системного управления. Именно эти недостатки управляющих структур на базе стандартов IETF применительно к задачам управления системами заставили рабочую группу DMTF заняться разработкой спецификации DMI.

Спецификации DMI MIF были созданы быстро, и большинство крупных производителей систем, в том числе Compaq, Hewlett-Packard, IBM и Dell, теперь в своих настольных и серверных системах поддерживают DMI. К ним также присоединились Microsoft и Novell. Основные продукты управления настольными системами, в том числе созданные компаниями Intel, IBM, HP и Seagate Software, понимают данные DMI. Тем не менее лишь небольшая часть потребителей на деле использует преимущества DMI.

Значительно расширить возможности управляющего программного обеспечения и, в конечном итоге, сократить затраты и увеличить ценность компьютерных сетей могут две новые технологии. Первая - это группа протоколов и программного обеспечения, связанного с World Wide Web; вторая - одна широко используемая объектно-ориентированная технология. В июле 1996 года Microsoft и несколько ее партнеров сформулировали предложения по комплекту стандартов для управления предприятием на базе Web (Web-Based Enterprise Management, WBEM), определяющие схему управления на основе объектов, изначально известную как Hypermedia Management Schema (HMMS). Предложения по HMMS были переданы в DMTF, где был сформирован подкомитет Common Information Model (CIM), в состав которого входят HP, Computer Associates, IBM/Tivoli, Intel, Microsoft, Novell и SunSoft. Трудно поверить, но в апреле 1997 года эта группа ярых конкурентов подготовила версию CIM 1.0. Параллельно, но не в пику предыдущему проекту, компания Sun разрабатывает Java Management API, или JMAPI, в рамках своей инициативы, связанной с объектно-ориентированным управлением.

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

Модель CIM, предложенная DMTF, позволяет осуществить одно из самых заветных желаний тех, кто работает на рынке систем управления, - она объединяет все управляющие данные SNMP, DMI и даже CMIP в одной объектной модели. Объекты CIM могут автоматически наполняться данными других систем, а кроме того, принятие модели CIM не предполагает отказа от других технологий. Таким образом, вся информация из SNMP MIB, DMI MIF, CMIP и даже из операционной системы или специфичных для каталога структур данных может сохраняться и использоваться управляющими приложениями.

В рамках инициативы WBEM был предложен также протокол по типу запрос/ответ, который в конечном итоге мог бы заменить SNMP. Речь идет о HMMP (Hypermedia Management Protocol). Данный протокол основан на HTTP с расширениями для транспортировки объектов CIM. Самое большое достоинство HTTP в том, что любой браузер Web и, таким образом, любая платформа могут обращаться к управляющим данным в формате HTML. Еще одним положительным моментом применения HTTP в качестве базового транспорта является возможность использовать все наработки в области защиты браузеров и серверов - Secure Sockets Layer и Secure-HTTP.

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

Полный комплект предварительных документов, описывающих HMMP, можно найти по адресу: www.wbem.freerange.com. Судя по дате, май 1997 года, эти документы еще не были предложены в качестве Internet Draft одной из рабочих групп IETF.

Архитектура WBEM позволяет упаковать элементы управляющей информации в объекты Hypermedia Managed Objects (HMMO). Объекты HMMO обслуживаются программным процессом, выполняющим функции брокера и получившим название Hypermedia Object Manager, или HMOM. Поскольку HMMO поддерживают такие объектные свойства, как наследование, полиморфизм и хранимость, HMOM-подобные приложения могут производить весьма мощные преобразования и выполнять роль шлюзов. К примеру, такое приложение может быть центральным компонентом для доступа к управляющим данным через Web (см. Рисунок 2).

JMAPI

Нет никаких внутренних препятствий к использованию Java с CIM или HMMP. Управляющие приложения и агенты на базе технологии WBEM можно безусловно написать на Java. А JMAPI мог бы существенно упростить их разработку. WBEM не зависит от каких-либо специфичных для Microsoft компонентов. Кроме того, разработчики рады использовать преимущества программирования на Java, в том числе быстроту разработки, межплатформенное исполнение, повторное использование программ и встроенную защиту. Единственное, чего стоит опасаться, так это другой крайности: простота разработки чревата массовым "изобретательством велосипедов", вследствие чего начнут создаваться структуры данных или транспортные протоколы, с которыми другие управляющие приложения не смогут работать. К примеру, если компания решила принять CIM для других приложений, то приложение, взаимодействующее с существующими управляющими агентами по протоколу SNMP, придется, возможно, переписать.

Технология Web и объектно-ориентированные разработки станут основой создания универсальных управляющих приложений. Даже устройства, в которых производителями контрольно-измерительная система не была предусмотрена, смогут загружать управляющие агенты (возможно, написанные на Java). CIM предоставит богатые комбинации функций для приложений системного управления и приложений сетевого управления. К примеру, идентификация узких мест в работе с Internet значительно упростится и потребуется немного времени, чтобы сети решали автоматически проблемы производительности. Усовершенствованные механизмы запросов и транспортные механизмы увеличат масштабируемость управляющих систем. Еще до конца этого столетия сетевые ПК и мобильные устройства станут намного надежнее, удобнее и производительнее.