WWW.LIB.KNIGI-X.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Электронные матриалы
 

Pages:   || 2 | 3 |

«IBM International Technical Support Organization Deployment Guide Series: IBM Tivoli Monitoring 6.1 Vas Gucer Ana Godoy December 2005 SG24-7188-00 Note: Before using this ...»

-- [ Страница 1 ] --

IBM

International Technical Support Organization

Deployment Guide Series:

IBM Tivoli Monitoring 6.1

Vas Gucer

Ana Godoy

December 2005 SG24-7188-00

Note: Before using this information and the product it supports, read the information

in “Notices”.

First Edition (December 2005)

This edition applies to IBM Tivoli Monitoring Version 6, Release 1.

© Copyright International Business Machines Corporation 2005. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADPSchedule Contract with IBM Corp.

IBM Международная организация по технической поддержке Руководство по внедрению IBM Tivoli Monitoring 6.1 Васфи Гусер Ана Годой Москва 2006 Переводчик Microsoft Business Solutions Certified Professional А. Петров Научный редактор IBM Certified Advanced Technical Expert.

Tivoli Certified Consultant Д. Миронов Москва, 2006 г.

Перед использованием сведений данного руководства и продукта, для поддержки которого оно предназначено, ознакомьтесь с информацией в разделе «Примечания».

Первое издание на русском языке (2006 г.) Издание охватывает IBM Tivoli Monitoring Version 6, издание 1.

© IBM Corporation (Корпорация International Business Machines), 2005 г.

Все права защищены.

Ограничение прав пользователей от правительства США: использование, копирование и раскрытие сведений настоящего руководства ограничено условиями контракта GSA ADP Schedule с корпорацией IBM.



Оглавление Рисунки............................................................................viii Таблицы...........................................................................xiii Примеры...........................................................................xiv Примечания........................................................................ xv Предисловие...................................................................... xvii Команда, написавшая книгу..............................................xvii Как стать автором...................

–  –  –

Информация в этом руководстве охватывает продукцию и услуги, предлагаемые в США.

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

IBM может обладать патентами и патентными заявками на технологии, описанные в настоящем руководстве, предоставление которого не означает предоставления лицензии на технологии. Письменные запросы лицензий следует направлять по адресу IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

Следующий абзац не относится к Соединенному Королевству и иным странам, законодательству которых противоречит: КОРПОРАЦИЯ IBM ПРЕДОСТАВЛЯЕТ ДАННОЕ

РУКОВОДСТВО «КАК ЕСТЬ» И НЕ ДАЕТ НИКАКИХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ (НО НЕ ОГРАНИЧИВАЯСЬ) ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПАТЕНТНОЙ ЧИСТОТЫ, КОММЕРЧЕСКОЙ ПРИГОДНОСТИ И СООТВЕТСТВИЯ КОНКРЕТНОМУ

НАЗНАЧЕНИЮ. В отдельных государствах отказ от явных и подразумеваемых гарантий по ряду сделок запрещен, так что указанное ограничение может вас не коснуться.

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

Любые ссылки на сайты сторонних компаний в этом руководстве носят исключительно информационный характер и не свидетельствуют об их поддержке корпорацией IBM.

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

По своему усмотрению и без каких-либо обязательств IBM может использовать и распространять любые предоставленные сведения.

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

Соответствующие вопросы следует направлять поставщикам этих продуктов.

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

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

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

Товарные знаки

Ниже перечислены товарные знаки корпорации IBM в США и (или) других странах:

–  –  –

Другим компаниям принадлежат следующие товарные знаки:

Java, JDBC, Solaris и все основанные на Java товарные знаки являются товарными знаками Sun Microsystems, Inc. в США и (или) других странах.

Microsoft, Windows Server, Windows и логотип Windows являются товарными знаками Microsoft Corporation в США и (или) других странах.

Intel, Xeon, логотипы Intel, Intel Inside и Intel Centrino являются товарными знаками или зарегистрированными товарными знаками Intel Corporation или дочерних компаний Intel Corporation в США и (или) других странах.

UNIX – зарегистрированный товарный знак Open Group в США и других странах.

Linux – товарный знак, принадлежащий Линусу Торвальдсу в США и (или) других странах.

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

xvi ПримечанияПредисловие

Эта книга из серии IBM® Redbook посвящена планированию внедрения, а также непосредственному развертыванию системы IBM Tivoli® Monitoring 6.1 в среде предприятий малого, среднего и крупного бизнеса.

Решение IBM Tivoli Monitoring 6.1 представляет собой новое поколение продуктов семейства IBM Tivoli для мониторинга критически важных программных и аппаратных ресурсов и управления ими в распределенной среде. Разработчики IBM Tivoli Monitoring 6.1 объединили в новой системе лучшие из технологий IBM Tivoli Monitoring V5 и OMEGAMON®. Интеграция этих программных средств позволила получить уникальное комплексное решение для мониторинга и управления как распределенными средами, так и средами на платформе z/OS®.

IBM Tivoli Monitoring 6.1 – продукт, который легко настраивается и предоставляет доступ к оперативным и историческим данным, позволяющим быстро обнаруживать и решать проблемы, используя новый графический интерфейс на основе компонента IBM Tivoli Enterprise™ Portal. Этот единый, гибкий и простой в применении интерфейс на базе Web-браузера поможет вам быстро изолировать и разрешить возможные проблемы производительности элементов инфраструктуры.





Книга адресована IT-специалистам, планирующим свое участие во внедрении IBM Tivoli Monitoring 6.1.

Команда, написавшая книгу Данная книга стала результатом совместной работы команды специалистов со всего мира, работающих в Международной организации технической поддержки (ITSO, International Technical Support Organization) в г. Остин.

Васфи Гусер (Vasfi Gucer) – сертифицированный консультант IBM (IBM Certified Consultant IT Specialist), работает в центре ITSO в Остине с января 1999 г. Ранее 10 лет состоял в штате IBM Turkey. Имеет более чем 13-летний опыт обучения и непосредственного развертывания систем управления, сетевого оборудования и программных средств для распределенных платформ. Как системный архитектор и консультант участвовал в различных проектах внедрения продуктов Tivoli. Является сертифицированным консультантом по решениям Tivoli (Certified Tivoli Consultant).

Ана Годой (Ana Godoy) приступила к работе в IBM Brasil в 1996 г. Тогда в ее обязанности входило обслуживание аппаратных средств PC Company. Два года Ана проработала в службе технической поддержки, после чего возглавила подразделение сопровождения таких продуктов, как Aptiva, Desktop, ThinkPad и ViaVoice. В январе 2002 г. вошла в состав бразильской группы поддержки Tivoli, где стала специализироваться на Tivoli Management Framework, Remote Control и Tivoli Workload Scheduler. В настоящее вре

–  –  –

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

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

Дополнительная информация о командировках и подача заявок — по адресу ibm.com/redbooks/residencies.html Дополнительные источники За более подробным разъяснением вопросов, изложенных в руководстве, рекомендуем вам обратиться к публикациям, перечисленным в настоящем разделе.

Прочие публикации

Дополнительными источниками информации для вас могут служить руководства:

IBM Tivoli Monitoring Installation and Setup Guide, GC32-9407 IBM Tivoli Monitoring Administrator’s Guide, SC32-9408 IBM Tivoli Monitoring User’s Guide, SC32-9409 Introducing IBM Tivoli Monitoring, V6.1.0, GI11-4071 Онлайновые ресурсы

Также дополнительными источниками могут быть следующие Web-сайты и URL:

Web-сайт с пакетами исправлений (Fix Pack) для DB2:

http://www.ibm.com/software/data/db2/udb/support/downloadv8.html

Web-сайт с драйверами для Microsoft SQL Server:

http://www.microsoft.com/sql/downloads/default.asp xviii Предисловие

Web-сайт с ODBC-драйверами для Oracle:

http://www.oracle.com/technology/software/tech/windows/odbc/htdocs/utilsoft.html

Web-сайт IBM Java JRE:

http://www.ibm.com/developerworks/java/jdk

Web-сайт IBM Tivoli Support:

ftp://ftp.software.ibm.com/software/tivoli_support/patches/ Как получить руководства Redbooks Искать, просматривать и загружать руководства серий Redbooks, Redpapers, Hints and Tips, черновики публикаций и дополнительные материалы, а также заказывать печатные версии книг серии Redbooks или компакт-диски вы можете на Web-сайте по адресу:

ibm.com/redbooks Помощь от IBM IBM Support and Downloads ibm.com/support IBM Global Services ibm.com/services Обратная связь Мы ценим замечания наших читателей и стремимся сделать руководства Redbooks™ максимально полезными для них.

Присылайте свои замечания об этом и других руководствах (на английском языке):

через форму Contact us на сайте: ibm.com/redbooks;

а также по электронной (redbook@us.ibm.com) и обычной почте:

IBM® Corporation, International Technical Support Organization Dept. JN9B Building 905 11501 Burnet Road Austin, Texas 78758 3493 xix Предисловие Введение В этой главе мы рассмотрим основные концепции и компоненты системы IBM Tivoli Monitoring Version 6.1. Если версия 6.1 является для вас новой, вы также можете обратиться к руководству IBM Tivoli Monitoring Version 6.1.0. Quick Start Guide, SC32-1802, в котором изложены краткие сведения о продукте.

Важно Все наше внимание здесь будет сосредоточено на распределенной среде.

Средам на основе z/OS посвящена другая книга (Redbook) IBM Tivoli OMEGAMON V3.1.0 Deep Dive on z/OS, SG24-7155, которая сейчас готовится к публикации.

Планируемая дата выхода – 31 марта 2006г. (Предварительный вариант опубликован в конце 2005 г.1)

Введение содержит следующие разделы:

«Проблемы управления предприятием»

«Решения на базе IBM Tivoli Monitoring»

«Что нового для клиентов IBM Tivoli Monitoring 5. x?»

«Что нового для клиентов OMEGAMON XE/DE?»

«Что нового для клиентов Distributed Monitoring V3.7?»

«Ценность IBM Tivoli Monitoring 6.1 для бизнеса»

«Компоненты IBM Tivoli Monitoring 6.1»

«Что нового в IBM Tivoli Data Warehouse V2.1?»

Прим. научн. ред.

Введение В.1 Проблемы управления предприятием Многие читатели, несомненно, знакомы с проблемами, стоящими перед IT-департаментами и отделами сопровождения и поддержки. В силу природы постоянно меняющихся запросов бизнеса и динамики рынка IT-ресурсы часто используются на грани возможного, нам же все время говорят: «Делайте больше, но тратьте на это меньше».

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

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

Любые меры – это реакция на случившееся, а не попытка предупредить возникающую проблему.

Ресурсы компании могут нормально функционировать на фоне неприемлемого уровня обслуживания клиентов.

События описывают не меры по решению проблем, а проблемы как таковые.

События поступают чрезмерно часто, и такие «ураганы» плохо влияют на эффективность системы.

Корректировки, как правило, неэффективны и делаются вручную.

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

Большую часть проблем нельзя попросту обнаружить. Более половины проблем становятся известными лишь от службы поддержки (help desk).

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

Отсутствие стратегических направлений и видения на перспективу повышает издержки.

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

Необходимость роста доходов, сокращения издержек; более эффективная конкуренция.

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

Потребность в управлении сложными аспектами сегодняшней бизнес-среды и в их моделировании.

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

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

Необходимость сокращения издержек в сфере IT и наиболее эффективное использование имеющейся в компании деловой информации.

Инвестиции в информационные системы сегодня – это существенная доля корпоративных расходов, и требуется не только снизить эти издержки, но и получить максимум пользы от информации, которой эти системы манипулируют. Такие новые информационные технологии, как интрасети, «тонкие» клиенты и доставка информации по подписке, помогают сократить затраты на предоставление доступа к системам бизнес-логики (business intelligence) более широкой аудитории, и особенно потребителям уровня менеджеров высшего и среднего звена предприятия. Все более критичной становится также поддержка работоспособности этих систем (уменьшение времени их простоя).

Введение В.2 Решения на базе IBM Tivoli Monitoring Решения на базе IBM Tivoli Monitoring предоставляют средства управления распределенными ресурсами предприятия посредством централизованного контроля над ними и их настройки. Много лет именно IBM Tivoli была лидером на рынке решений для мониторинга корпоративных инфраструктур. Все это время в основе мониторинга доступности операционных систем и прикладных компонентов лежит продукт IBM Tivoli Monitoring.

Объекты мониторинга и средства поддержки информационного окружения

–  –  –

Рис. В-1 Решения на базе IBM Tivoli Monitoring Решения IBM Tivoli Monitoring образуют прочный фундамент для разработки систем управления, призванных разрешить непростые проблемы обслуживания современных информационных инфраструктур. Набор модулей, выстроенный поверх IBM

Tivoli Monitoring, содержит полный спектр решений для предприятий, перед которыми стоит задача мониторинга составных инфраструктур приложений. Модули предлагаются к поставке в виде пакетов, среди которых:

IBM Tivoli Monitoring for Applications.

IBM Tivoli Monitoring for Business Integration.

IBM Tivoli Monitoring for Databases.

IBM Tivoli Monitoring for Messaging and Collaboration.

4 ВведениеРис. В-2 Мониторинг составных инфраструктур приложений

Лейтмотивом решений IBM Tivoli Monitoring последнего поколения является ориентация на услуги, и теперь в центре внимания решений стоят такие вопросы, как:

Консолидация мониторинговых платформ.

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

Повышение наглядности и расширение средств анализа данных, полученных при мониторинге.

Повышение качества управления средой мониторинга.

Облегчение установки, конфигурирования и развертывания решений через упрощенный пользовательский интерфейс.

Развитие возможностей интеграции с продуктами Tivoli.

Повышение ценности продуктов посредством интеграции процессов.

Введение В.3 Что нового для клиентов IBM Tivoli Monitoring 5. x?

IBM Tivoli Monitoring 6.1 поддерживает многие компоненты IBM Tivoli Monitoring 5. x, в частности интеграцию с Common Information Model (CIM) и Windows® Management Instrumentation (WMI), а также мощную и обладающую невероятными возможностями настройки функцию мониторинга на базе модели ресурсов. Говоря об IBM Tivoli

Monitoring 6.1, подчеркнем следующее:

На клиентских местах компоненты IBM Tivoli Monitoring 6.1 могут быть установлены как полностью, так и частично.

Интерфейс пользователя с IBM Tivoli Monitoring 6.1 реализован в новом интегрированном портале (Tivoli Enterprise Portal), а на смену Web Health Console пришли универсальные приложения, формирующие единое управленческое и оперативное видение корпоративной инфраструктуры. Портал имеет огромное значение, объединяя вокруг себя все решения по управлению предприятием.

Перечислим его функции и возможности:

– Создание большего комфорта в работе и обеспечение наглядности.

– Встроенный Administration and Runtime Portal.

– Контроль авторизации для систем, приложений, функций и географических представлений.

– Представления, которые можно настроить и связать воедино для эффективного применения в конкретной аудитории.

– Простое администрирование управляющих правил.

Сохранена поддержка всех конфигураций IBM Tivoli Monitoring 5.1.

Имеется возможность интегрировать данные, приходящие из разных источников, таких, как IBM Tivoli Monitoring 5, OMEGAMON, OMEGAMON Z, IBM Tivoli Enterprise Console® и IBM Tivoli Data Warehouse.

Расширенное управление процессами ведется через единую консоль менеджмента событий и происшествий с поддержкой модифицируемых рабочих процессов и процедур [посредством связывания и модифицируемых рабочих пространств (custom workspace)].

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

Подробные данные исторического характера подвергаются тщательной обработке:

– Проводится анализ тенденций с применением Data Warehouse.

– По сохраненным данным можно реконструировать возникновение проблемы.

– Для облегчения извлечения данных и манипуляций с ними используется упрощенная схема.

Для обращения к историческим данным и данным в реальном времени предназначен интерфейс на базе Web-служб и SOAP-протокола.

6 Введение В.4 Что нового для клиентов OMEGAMON XE/DE?

Клиенты OMEGAMON получат целый ряд новых и усовершенствованных возможностей, а именно:

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

Поддержка развертывания:

– Централизованное развертывание агентов.

– Расширенное управление внутренней инфраструктурой.

– Интеграция со средой Tivoli Management Framework.

Поддержка командного интерфейса и интерфейса Web-служб.

Улучшенные возможности масштабирования.

Расширенная интеграция с такими продуктами Tivoli, как:

– IBM Tivoli Enterprise Console.

– IBM Tivoli Monitoring 5.1.

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

В.5 Что нового для клиентов Distributed Monitoring V3.7?

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

Процедура обновления дает им следующие преимущества:

Автоматизированный процесс программного перехода на IBM Tivoli Monitoring 6.1.

Новые наглядные интерфейсы, простота применения, новый репозитарий Data Warehouse.

Внедрение фирменных (IBM Supported) процедур обновления IBM при дальнейшем развитии модулей.

–  –  –

Рис. В-3 IBM Tivoli Monitoring 6.1: лучшее из OMEGAMON и ITM 5

Система IBM Tivoli Monitoring 6.1 стала результатом объединения двух лучших решений: OMEGAMON и IBM Tivoli Monitoring 5. x. В ее основе лежат следующие характеристики и идеи:

Простота применения:

– Гибкий интерфейс с персонализированной выдачей информации.

– Интеграция управления событиями, анализа данных в реальном времени и данных исторического характера.

Proactive Analysis Components – наборы мониторов и моделей ресурсов для отдельных приложений 8 Введение

Наглядное представление информации:

– Удобные для восприятия отчеты о текущем положении дел и исторической ретроспективе.

– В центре внимания – производительность и доступность.

– Видимость инфраструктуры мониторинга.

Снижение общей стоимости владения (TCO):

– Простое развертывание агентов и внедрение управляющих правил.

– Компактные по размерам агенты.

– Поддержка новых технологий (кластеризация, виртуализация).

Интеграция процессов и продуктов:

– Корпоративные представления (enterprise view) для Distributed и zSeries®.

– Объединенное представление существующей, новой консоли мониторинга и IBM Tivoli Enterprise Console.

– Дополнительное внимание библиотеке IT Infrastructure Library (ITIL) – перечню документов, используемых для поддержки внедрения структуры (framework) ITSM (IT Service Management). Эта структура описывает, как конкретная организация обеспечивает обслуживание клиентов (Service Management), и являются полностью настраиваемой для применения в любой сфере бизнеса или организации, зависящей от информационной инфраструктуры.

В.7 Компоненты IBM Tivoli Monitoring 6.1 Система IBM Tivoli Monitoring 6.1 создавалась для предоставления доступа к информации, имеющей критическое значение для ежедневной работы компании и касающейся доступности и производительности компонентов, приложений и служб в рамках корпоративной инфраструктуры.

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

Службы Tivoli Monitoring Службы Tivoli Monitoring – это каркас IBM Tivoli Monitoring 6.1, который включает в себя все компоненты решения, а также описывает их взаимодействие.

В неполный перечень компонентов данной категории входят:

Tivoli Enterprise Monitoring Agent (TEMA) Tivoli Enterprise Monitoring Server (TEMS) Tivoli Enterprise Portal Server (TEPS) Tivoli Enterprise Portal (TEP) Компоненты IBM Tivoli Monitoring представлены на рис В-4.

Введение Рис. В-4 Компоненты IBM Tivoli Monitoring 6.1

Tivoli Enterprise Monitoring Agent Агенты Tivoli Enterprise Monitoring (TEMA) производят сбор данных и с этой целью инсталлируются на одну или несколько систем, мониторинг которых планируется вести. Полученные при этом данные передаются в центральный репозитарий. Каждый TEMA-агент собирает сведения об атрибутах (параметрах) конкретной управляемой системы.

Примерами агентов являются:

Агент операционной системы (Operating System Agent).

Универсальный агент (Universal Agent). Tivoli Universal Agent – это агент, который можно настроить на мониторинг любых данных, которые вы намерены собирать. Он позволяет объединять данные практически с любой платформы и из любого источника, например заказных приложений, баз данных, систем и их компонентов.

Агент приложения (Application Agent). Такие агенты собирают сведения из баз данных, WebSphere® Application Server, WebSphere MQ и т. д.

10 Введение К моменту выхода общедоступной (GA, General Availability) версии в продукте будут реализованы агенты для следующих операционных систем:

AIX 5.1, 5.2, 5.3 Solaris™ 8, 9, 10 HP UX 11i, 11.23 Windows 2000 Server, Advanced Server Windows XP Pro Windows 2003 Server 32-bit (SE & EE) OS/400® 5.2, 5.3 RHEL 2.1 RHEL 3 (Intel®, zSeries) RHEL 4 (Intel, AMD64/EM46T, zSeries) SLES 8 (Intel, zSeries) SLES 9 (Intel, zSeries) Примечание Поддержка 64-разрядной версии Windows 2003 Server будет реализована как пакет исправлений (fix pack) после выхода GA-версии.

Tivoli Enterprise Monitoring Server Tivoli Enterprise Monitoring Server (TEMS) является центральным репозитарием данных, поступающих от агентов TEMA.

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

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

К моменту выхода GA-версии TEMS-сервер будут поддерживать следующие платформы:

AIX 5.2, 5.3 Solaris 9, 10 Windows 2000 Server, Advanced Server Windows XP Pro (только демо-версия установки) Windows 2003 Server 32-bit (SE & EE) RHEL 4 (Intel, zSeries) SLES 9 (Intel, zSeries) Введение Tivoli Enterprise Portal Server Tivoli Enterprise Portal Server (TEPS) работает как хранилище информации обо всех пользователях, их идентификаторов (user ID) и прав доступа к полученным в ходе мониторинга данным (то есть содержит сведения о том, к каким данным имеет право обращаться каждый пользователь и как эти данные будут ему представлены).

TEPS связан с hub-сервером TEMS и обеспечивает согласованное представление информации.

Базой данных для хранения информации на сервере TEPS могут быть:

MS SQL Server 2000 IBM UDB 8.1 IBM UDB 8.2 К моменту выхода GA-версии TEPS-сервер будет поддерживать следующие платформы:

Windows 2000 Server, Advanced Server Windows XP Pro (только для демонстрации) Windows 2003 Server 32-bit (SE & EE) RHEL 4 (Intel, zSeries) SLES 9 (Intel, zSeries) Tivoli Enterprise Portal Tivoli Enterprise Portal (TEP) – это консолидированный пользовательский интерфейс IBM Tivoli Monitoring, который служит для подключения к Tivoli Enterprise Portal Server.

Портал Tivoli Enterprise Portal можно загрузить средствами Internet Explorer или установить на рабочей станции как клиентское приложение.

Важно Internet Explorer – единственный браузер, который поддерживает TEP.

К моменту выхода GA-версии TEP клиента будут поддерживать следующие платформы:

Windows 2000 Pro Windows 2000 Server, Advanced Server Windows XP Pro Windows 2003 Server 32-bit (SE & EE) RHEL 4 (Intel) SLES 9 (Intel) Рис. В-5 показывает Tivoli Enterprise Portal (в режиме Web-браузера).

12 Введение Рис. В-5 Tivoli Enterprise Portal В.8 Что нового в IBM Tivoli Data Warehouse V2.1?

Приведем краткий перечень нововведений в IBM Tivoli Data Warehouse V2.1:

Шаг 1 процедуры Extract, Transform, and Load (ETL1) больше не требует выполнения.

Перед загрузкой в хранилище данные больше не агрегируются.

Потребности в Crystal Enterprise больше не существует.

Система больше не содержит компонентов категории data marts.

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

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

Tivoli Enterprise Portal может отображать оперативные и исторические данные и различные диаграммы.

Все это означает: Tivoli Data Warehouse стал теперь полезнее, чем когда-либо ранее.

–  –  –

Архитектура и планирование В этой главе книги речь пойдет об архитектуре системы IBM Tivoli Monitoring 6.1 и работе каждого компонента. Используя сценарии, в основу которых будут положены различные показатели: число агентов, доступность аппаратуры, а также сетевые ограничения, – мы проанализируем четыре варианта архитектуры IBM Tivoli Monitoring

6.1. Кроме того, один из разделов главы мы посвятим обзору развертывания агента IBM Tivoli Monitoring 6.1 с применением нескольких уникальных стратегий.

Глава содержит описание следующих вопросов:

компоненты IBM Tivoli Monitoring 6.1 сценарии развертывания IBM Tivoli Monitoring 6.1 масштабируемость архитектура развертывания агента 14 Глава 1

1.1 Компоненты IBM Tivoli Monitoring 6.1 Решение на базе IBM Tivoli Monitoring 6.1 содержит множество компонентов, совместно именуемых структурой (framework) Tivoli Monitoring Services. Последняя объединяет в себе ряд обязательных элементов. В дополнение к ним вы можете установить факультативные компоненты, которые расширят функции мониторинга, реализованные структурой. Подробнее поддержка важных составляющих IBM Tivoli Monitoring 6.1 на конкретных платформах описана в разделе 1.1.1 «Поддержка IBM Tivoli Monitoring 6.1 на различных платформах», с. 20.

При каждой инсталляции IBM Tivoli Monitoring 6.1 необходимо установить следующие компоненты системы:

Tivoli Enterprise Monitoring Server (TEMS) Tivoli Enterprise Monitoring Server, называемый сервером мониторинга (monitoring server), – это начальный компонент, который требует установки для закладки фундамента IBM Tivoli Monitoring Services. TEMS – это центральный элемент, от которого напрямую зависят все прочие архитектурные компоненты. Он служит местом накопления предупреждений, принимаемых от агентов, управления ими, а также занимается сбором данных о производительности и доступности агентов как таковых.

TEMS отвечает за прослеживание интервала запросов «пульса» (heartbeat) от всех подключенных к нему агентов Tivoli Enterprise Management.

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

Кроме того, он несет ответственность за активизацию инициированных им действий по запуску сценариев или программ на агентах Tivoli Enterprise Management и контроль над этими действиями.

Репозитарий хранилища TEMS представлен собственным форматом баз данных (известным как Enterprise Information Base – EIB ), а также набором файлов, размещенных на сервере Tivoli Enterprise Monitoring Server.

Имена названных файлов начинаются с префикса qa1, а сами файлы располагаются в каталогах

– installation_dir/tables/tems_name

– installation_dir: домашний каталог IBM Tivoli Monitoring 6.1

– tems_name: имя сервера Tivoli Enterprise Monitoring Server.

Примечание tems_name – имя сервера мониторинга, не обязательно совпадающее с именем хоста сервера Tivoli Enterprise Monitoring.

Первичный сервер TEMS конфигурируется как ядро – Hub (*LOCAL). Как минимум один TEMS-сервер должен иметь такую конфигурацию в каждой установке IBM Tivoli Monitoring 6.1. Дополнительные удаленные TEMS-серверы – Remote (*REMOTE) – могут быть инсталлированы позднее и могут придавать архитектуре иерархическую структуру с возможностью масштабирования.

Архитектура и планирование Взаимосвязь ядра (hub-сервера) и удаленного сервера лежит в основе иерархической схемы, которая позволяет удаленному TEMS управлять состоянием собственных агентов, собирать данные об их статусе и передавать их ядру. Благодаря этому механизму hub-сервер TEMS способен поддерживать единую – в пределах инфраструктуры – видимость всей информационной среды. Параметры видимости передаются серверу Tivoli Enterprise Portal Server, где предварительно форматируются, после чего отображаются клиентом Tivoli Enterprise Portal.

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

Tivoli Enterprise Portal Server (TEPS) Tivoli Enterprise Portal Server, известный как сервер портала (portal server), является репозитарием всех графических представлений данных наблюдения и контроля. В базу данных этого сервера также входят все идентификаторы пользователей и средства контроля доступа к рабочей области мониторинга. Сервер TEPS реализует фундаментальный уровень представления, который допускает извлечение, анализ, предварительное форматирование данных и манипуляции ими. Управление доступом ведется через консоли рабочих сред пользователей. TEPS поддерживает постоянное подключение к hub-серверу TEMS и может рассматриваться как логический шлюз между hub-сервером TEMS и клиентом Tivoli Enterprise Portal.

Любая потеря связи между тем и другим немедленно блокирует доступ к данным мониторинга со стороны клиента Tivoli Enterprise Portal.

Прежде, чем будет инсталлирован TEPS, на той же физической системе необходимо установить реляционную СУБД. Соблюсти это предварительное условие нужно ввиду того, что установочная программа TEPS принудительно создаст базу данных TEPS и ряд вспомогательных таблиц к ней. Помимо этого, имя источника данных (Data Source Name) ODBC-интерфейса (Open Database Connectivity) требуется сконфигурировать так, чтобы непосредственно подключаться к реляционной СУБД хранилища Tivoli Data Warehouse. Это ODBC-подключение станет использоваться каждый раз при поступлении запроса на извлечение из Tivoli Data Warehouse данных исторического характера.

Примечание Не рекомендуется использовать в связке с TEPS-сервером удаленную РСУБД, хотя это и допустимо с точки зрения техники. TEPS тесно связан с РСУБД, а удаленную систему баз данных трудно поддерживать ввиду ее сложности.

В ходе установки TEPS для работы с клиентом Tivoli Enterprise Portal через браузер инсталлируется встроенный проприетарный Web-сервер. В зависимости от топологии сети и возможных соображений по безопасности это может сыграть свою роль в построении решения. Взамен встроенного Web-сервера на ту же систему, что и TEPS, можно установить внешний. Детали см. в руководстве IBM Tivoli Monitoring Installation and Setup Guide, GC32-9407.

16 Глава 1 При крупномасштабных внедрениях рекомендуется установка множества TEPS, подключенных к единственному hub-серверу TEMS. Дальнейшие и более подробные инструкции см. в разделе «Внедрение для крупного предприятия (до 4000 агентов)».

Tivoli Enterprise Portal (TEP) Клиент TEP, именуемый клиентом портала (portal client), представляет собой подключенный к Tivoli Enterprise Portal Server пользовательский интерфейс на базе технологии Java™, который служит для демонстрации всех коллекций данных мониторинга (data collections). Это компонент уровня представления/отображения данных, нацеленный на взаимодействие с пользователем. TEP сводит все отображения в едином окне, что позволяет заметить, что какой-то из элементов системы работает не так, как мы того ожидали. В клиенте предусмотрены два режима функционирования: настольный Java-клиент и HTTP-браузер.

Пусть мы произвели установку по умолчанию; тогда работающий в режиме браузера клиент TEP можно найти по адресу:

http://hostname:1920///cnp/kdh/lib/cnp.html Здесь hostname – имя хоста Tivoli Enterprise Portal Server.

Важно В режиме браузера на Windows-платформе IBM Tivoli Monitoring 6.1 поддерживает только Internet Explorer.

Интегрированный интерфейс с TEP имеют следующие продукты:

– OMEGAMON Z

– OMEGAMON Distributed

– IBM Tivoli Monitoring 5.1.2

– IBM Tivoli Monitoring 6.1

– NetView® for z/OS (release 5.2)

– IBM Tivoli Enterprise Console

– IBM Tivoli Composite Application Manager for Response Time Tracking

– IBM Tivoli Composite Application Manager for WebSphere

– IBM Tivoli Composite Application Manager for SOA Примечание В 2006 г. в Tivoli Enterprise Portal будут интегрированы и другие продукты, такие как IBM Tivoli Service Level Advisor, System Automation и Tivoli Business System Manager. Интеграция с IBM Tivoli Service Level Advisor будет доступна с выходом Tivoli Data Warehouse V2.1.1.

Tivoli Enterprise Management Agent (TEMA) Агенты, или управляемые системы (managed systems), инсталлируются на той системе или той подсистеме, которая требует сбора данных и мониторинга. Они ответственны за накопление данных, а также пересылку собранных ими параметров на серверы мониторинга, включая инициацию «пульса».

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

Что заставляет сервер мониторинга собирать данные от агентов?

– Открытие или обновление рабочего пространства (workspace), включающего представления данных (табличные представления или представления-диаграммы).

При наступлении этих событий сервер TEPS запрашивает сбор данных на hub-сервере TEMS. Запрос передается агенту (если с ним есть прямое соединение) или отправляется на удаленный TEMS-сервер, к которому этот агент мониторинга подключен. Агент осуществляет сбор данных и через серверы мониторинга и портала возвращает свой результат в рабочее пространство последнего.

– Интервал сбора данных о ситуации (путем проверок, выполняемых на контролируемых системах).

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

Хотя это необязательно, системы-агенты можно сконфигурировать так, чтобы те передавали коллекции данных не удаленному TEMS, а напрямую агенту Warehouse Proxy. Если ограничения, связанные с защитой сети, отключены или сведены к минимуму, то непосредственную отсылку данных агенту Warehouse Proxy следует настроить на каждом агенте. Иначе ключевым фактором в расположении агента Warehouse Proxy по отношению к зоне действия сетевого экрана (firewall) и размещению агентов являются параметры сетевого экрана. Хранение данных с использованием удаленного TEMS имеет ограниченные возможности, и прибегать к нему следует лишь в последнюю очередь.

Агенты Tivoli Enterprise Management объединяют в две категории:

– Агенты операционной системы (ОС) Агенты операционной системы (Operating System Agents) получают и накапливают все те группы параметров мониторинга, которые касаются условий управления конкретной операционной системой и связанными с ней данными.

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

К числу общих агентов, включенных в пакет IBM Tivoli Monitoring 6.1, относятся:

– Windows OS Agent

– Linux® OS Agent 18 Глава 1

– UNIX® OS Agent

– UNIX Log Agent

– i5 OS Agent

– Universal Agent Универсальный (Universal) агент – специальный агент, использующий интерфейс программирования (API) для мониторинга и сбора данных, приходящих от приложений всех типов. Он может контролировать любую программу, выдающую данные, и собирать их значения. Теперь IBM Tivoli Monitoring 6.1 может, по сути, осуществлять наблюдение и контроль за каждым из приложений независимо от того, реализован мониторинг этого приложения в базовой версии или нет.

Другими управляющими агентами, не входящими в обязательные и поставляемыми отдельно, являются:

– Monitoring Agent for IBM Tivoli Monitoring 5. x Endpoint

– DB2® Agent

– Oracle Agent

– MS SQL Agent

– MS Exchange Agent

– Active Directory Agent Агент Warehouse Proxy Агент Warehouse Proxy является уникальным агентом, решающим только одну задачу сбора и консолидации всех совокупностей исторических данных, приходящих от индивидуальных агентов, с целью их сохранения в Tivoli Data Warehouse.

При пользовании этой системой вам требуется по одному агенту Warehouse Proxy на каждую из инсталляций IBM Tivoli Monitoring 6.1. Для записи данных исторического характера в связанную с ним реляционную базу данных агент использует ODBC-интерфейс (Open Database Connectivity).

Ограничение Сейчас IBM Tivoli Monitoring 6.1 поддерживает агент Warehouse Proxy только на Windows-платформе. Поддержка UNIX-систем будет включена в более поздний релиз IBM Tivoli Monitoring 6.1.

Агент Warehouse Summarization and Pruning (S&P) Агент формирования итогов и сокращения (Summarization and Pruning) – единственный в своем роде агент, выполняющий функции агрегирования и уменьшения объема исходных данных исторического характера в хранилище Tivoli Data Warehouse. Он обладает развитыми возможностями конфигурирования, позволяющими произвести исключительно тонкую настройку хранилища исторических данных.

Для управления данными исторического характера в Tivoli Data Warehouse рекомендуется один агент S&P. При этом ввиду невероятно большого масштаба требуемой обработки данных S&P должен всегда устанавливаться на ту же физическую систему, что и репозитарий Tivoli Data Warehouse.

Архитектура и планирование Tivoli Data Warehouse (TDW) Tivoli Data Warehouse – хранилище базы данных, где расположены все наборы данных исторического характера. Для получения доступа к функциям TDW из информационного окружения необходимо установить Warehouse Proxy. При крупномасштабных внедрениях Tivoli Data Warehouse может совместно использоваться несколькими системами мониторинга.

Установка IBM Tivoli Monitoring 6.1 может включать в себя следующие необязательные компоненты:

Monitoring Agent for IBM Tivoli Monitoring 5. x Endpoint Этот интеграционный агент, также именуемый IBM Tivoli Monitoring 5. x Endpoint Agent, дает возможность сбора и наглядного представления моделей ресурсов IBM Tivoli Monitoring 5. x. в Tivoli Enterprise Portal. Реализуемая им визуализация служит прямой заменой Web Health Console. Помимо этого, агент содержит функцию пересылки данных в Tivoli Data Warehouse.

Синхронизация событий в Tivoli Enterprise Console Модуль синхронизации событий для TEC занят отправкой обновлений ситуационных событий, переданных серверу событий, обратно серверу мониторинга.

Действия, предпринимаемые в Tivoli Enterprise Console в ответ на ситуации от IBM Tivoli Monitoring 6.1, отражаются на сервере Tivoli Enterprise Portal Server.

IBM Tivoli Business Systems Manager (TBSM) IBM Tivoli Business Systems Manager предоставляет программные средства интеллектуального управления, призванные помочь компаниям улучшить показатели оперативного реагирования, выстраивая работу в сфере ИТ в соответствии с приоритетами бизнеса. Программы интеллектуального управления оказывают поддержку в оптимизации процессов в ИТ с учетом задач и целей организации, позволяя не концентрироваться на технологии как самоценном объекте.

Примечание Для интеграции IBM Tivoli Monitoring 6.1 и IBM Tivoli Business Systems Manager будет предложена особая программа, названная TBSM Feed from OMEGAMON (или XE Feed). Выпуск XE Feed как LA-fix к IBM Tivoli Business Systems Manager 3.1 запланирован на первый квартал 2006 г. Позднее он войдет в состав итоговой версии IBM Tivoli Business Systems Manager, выход которой намечен на сентябрь 2006 г.

1.1.1 Поддержка IBM Tivoli Monitoring 6.1 на различных платформах Чтобы получить самую актуальную информацию о поддержке IBM Tivoli Monitoring

6.1 на разных платформах, воспользуйтесь ссылкой:

http://www-306.ibm.com/software/sysmgmt/products/support/Tivoli_Supported_ Platforms.html 20 Глава 1 1.1.2 Поддержка баз данных Сведения о поддержке баз данных системой IBM Tivoli Monitoring 6.1 отражены в табл. 1-1.

Примечание Система не поддерживает не указанные в таблице названия и номера версий баз данных, включая DB2 на мэйнфрэймах (на базе zLinux, OS/390®, z/OS и т. д.).

Табл. 1-1 Поддержка баз данных

–  –  –

1.2 Сценарии развертывания IBM Tivoli Monitoring 6.1 Сценарии развертывания системы – это попытка дать реалистичное видение модели архитектуры. Использовать их надо прежде всего для руководства и помощи в выработке стратегии планирования и реального развертывания системы, так как стратегия каждого внедрения уникальна, и успех установки может быть гарантирован лишь правильностью планирования.

Рассмотрим четыре типа информационного окружения:

«Внедрение-демонстрация (единственная машина)» (раздел 1.2.1, с. 23) «Внедрение для малого или среднего предприятия (до 400 агентов)»

(раздел 1.2.2, с. 23) «Внедрение для крупного предприятия (до 4000 агентов)» (раздел 1.2.3, с. 26) «Внедрение для сверхкрупного предприятия (более 4000 агентов)»

(раздел 1.2.4, с. 29) Примечание Наша классификация основана здесь на количестве агентов IBM Tivoli Monitoring 6.1. На практике для определения размеров организации иногда пользуются количеством сотрудников в ней; например компании с числом занятых до 1000 человек относят к сегменту малого и среднего бизнеса.

Архитектура и планирование Рис. 1-1 показывает взаимосвязи различных компонентов системы, максимально их упрощая. В других главах книги мы раскроем эти взаимосвязи более детально и глубоко. Все аппаратные и программные ограничения будут описаны позже.

Рис. 1-1 Лабораторная топология IBM Tivoli Monitoring 6.1

Примечания:

Как горячий резерв (Hot Standby) используется система Milan (AIX 5.3.0), не показанная на схеме.

На каждом TEMA-агенте имеется как минимум один агент ОС; на некоторых есть дополнительные агенты.

22 Глава 1 Для изложения самых разнообразных вопросов по ходу книги произведем тестовое внедрение IBM Tivoli Monitoring 6.1, которое включает в себя все, что нам требуется.

В архитектуру внедрения входят все компоненты, образующие установку IBM Tivoli Monitoring, включая встроенный hub-сервер горячего резерва Tivoli Enterprise Manager Server. Кроме того, для демонстрации возможностей взаимодействия IBM Tivoli Monitoring 6.1, IBM Tivoli Monitoring V5.1.2 Fix Pack 6, IBM Distributed Monitoring V3.7 и IBM Tivoli Enterprise Console V3.9 к инфраструктуре подключен унаследованный продукт Tivoli Management Framework V4.1.1. Чтобы гарантировать правильность реализации, а также продемонстрировать лучшие практические примеры, мы включим в нашу среду соразмерное число неоднородных аппаратных конфигураций с различными по своим характеристикам операционными системами и платформами.

Внимание Все числовые значения – особенно в отношении агентов Tivoli Enterprise Management – основаны на приближенном подсчете. Ниже в заголовках разделов дается рекомендуемая максимальная численность агентских систем.

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

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

1.2.1 Внедрение-демонстрация (единственная машина) Для демонстрации система IBM Tivoli Monitoring 6.1 может быть установлена на единственную машину на базе Windows XP. Эта установка IBM Tivoli Monitoring 6.1 должна использоваться лишь в целях показа; поддержка инсталляций такого рода не производится. При помощи Windows Install Shield установить IBM Tivoli Monitoring

6.1 можно с одного компакт-диска. Минимально необходимый набор программ включает в себя:

Tivoli Enterprise Monitoring Server (TEMS) Tivoli Enterprise Portal Server (TEPS) Tivoli Enterprise Portal Client (TEP) Windows OS Agent Опционально на эту же систему для демонстрации возможностей сбора исторических данных в IBM Tivoli Monitoring 6.1 могут быть установлены Tivoli Warehouse Proxy, Tivoli Data Warehouse, агент Summarization and Pruning и DB2.

1.2.2 Внедрение для малого или среднего предприятия (до 400 агентов) Внедрение для малых и средних организаций – это реализация базисной модели внедрения, в которой задействован лишь минимум необходимых компонентов системы. Данный сценарий идеален для построения прототипов развертываний IBM Tivoli Monitoring 6.1 или использования в промышленной инсталляции, где будут Архитектура и планирование установлены 400 агентов. На деле же IBM Tivoli Monitoring 6.1 по внутреннему устройству превосходит внедрения на предприятиях малого и среднего бизнеса. Коллекции средств мониторинга, готовые к работе непосредственно «из коробки», графический уровень представления, механизм сбора исторических данных и надежность продукта делают его завершенным мониторинговым решением с умеренной полной стоимостью владения (TCO).

Система реализована так, что при промышленном внедрении IBM Tivoli Monitoring 6.1 к аппаратуре предъявляются минимальные требования.

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

Tivoli Enterprise Monitoring Server Tivoli Enterprise Portal Server Tivoli Enterprise Portal Агент Tivoli Warehouse Proxy Tivoli Data Warehouse Агент Summarization and Pruning Топологию внедрения для малых и средних организаций отражает рис. 1-2. Эта схема дает общее представление о каждом из подключенных к IBM Tivoli Monitoring 6.1 компонентов. Для полного представления архитектуры на схеме показан опциональный узел горячего резерва.

Хотя внедрение для малой или средней организации и позволяет использовать единственный TEMS-сервер, мы все же рекомендуем при этом сценарии установить как минимум три сервера TEMS (включая узел горячего резерва). Реализация архитектуры с ядром и удаленным сервером (Hub/Remote) на ранних стадиях установки дает возможность роста и масштабирования. Больше того, подобный вариант инсталляции базируется на встроенных в IBM Tivoli Monitoring 6.1 функциях перехода на резервный компонент при сбое основного (failover). Внедрение для малых и средних организаций поддерживает около 250 контролируемых систем. Эта оценка предполагает, что каждая такая система содержит по два агента. В реальности фактическое распределение агентов не обязательно равномерно, поэтому данный расчет дает рекомендуемое общее количество систем в одной инсталляции IBM Tivoli Monitoring

6.1. Все агенты подключаются к удаленному TEMS, используя Hub TEMS-сервер как сервер мониторинга только в случае сбоя (failover).

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

Внимание Внедрение для малых и средних форм бизнеса не допускает использования для горячего резерва удаленного TEMS-сервера. Узлы горячего резерва всегда должны конфигурироваться как *LOCAL.

24 Глава 1 Рис. 1-2 IBM Tivoli Monitoring 6.1, модель топологии для малого или среднего предприятия Hub-сервер TEMS способен напрямую решать задачи агентов, однако использовать его для этой цели мы не советуем. Напротив, его работа должна концентрироваться на сборе и обработке данных между ним самим и TEPS-сервером. С ростом масштабов среды понадобится установить еще один удаленный TEMS, что даст возможность удовлетворить дополнительные требования агентов. Внедрение новых агентов поднимет уровень вычислительных требований к hub-серверу TEMS, производительность которого может значительно уменьшиться, если позволить серверу решать агентские задачи самостоятельно.

При обычной установке Tivoli Data Warehouse в среде для малого и среднего бизнеса развертывания агента Warehouse Proxy и репозитария Tivoli Data Warehouse в пределах одной системы вам вполне хватит. Такое внедрение позволит вести сбор данных исторического характера без лишних аппаратных затрат. Тем не менее, разумно все же провести мониторинг Tivoli Data Warehouse по окончании установки и убедиться в достижении приемлемой скорости обработки Архитектура и планирование 1.2.3 Внедрение для крупного предприятия (до 4000 агентов) Имея в своей основе внедрения для малых и средних организаций, внедрение для крупного бизнеса сосредоточено на возможности масштабирования. Такое окружение Tivoli Monitoring содержит 4000 агентов при единственном развертывании системы. Чтобы инфраструктура имела надлежащую масштабируемость, необходима аппаратура, которая соответствует требуемой спецификации или превосходит ее.

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

Tivoli Enterprise Monitoring Server Tivoli Enterprise Portal Server Tivoli Enterprise Portal Агент Tivoli Warehouse Proxy Tivoli Data Warehouse Агент Summarization and Pruning Tivoli Enterprise Console Полное представление архитектуры со всеми взаимосвязанными компонентами дает рис. 1-3. Он отражает рекомендуемую в продуктах Tivoli стратегию сбора данных исторического характера. Мы настоятельно советуем организовывать структуру потока исторических данных так, как это продемонстрировано на схеме.

Важно Для простоты на схеме топологии не показан узел горячего резерва.

При инсталляции для крупной организации такой узел рекомендуется создать обязательно.

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

26 Глава 1Рис. 1-3 IBM Tivoli Monitoring 6.1, модель топологии для крупного предприятия

IBM Tivoli Monitoring 6.1 идеально подходит для внедрения на предприятиях малых и средних форм бизнеса. По завершении установки система, функционал которой построен с учетом лучшего опыта, начинает давать отдачу немедленно. Запускаются ситуационные проверки по умолчанию, и если включен сбор исторических данных, то в созданных по умолчанию группах параметров инициируется анализ и накопление информации. При крупномасштабном внедрении эти службы «по умолчанию» способны помешать достичь нужной производительности, особенно если не отключить сбор сведений о ненужных параметрах. Наша настоятельная рекомендаАрхитектура и планирование ция – после установки TEMS, TEPS и TEP перевести свойство Run at Startup в значение NO для всех ситуационных проверок. Эта практика гарантирует вам свободу в реализации стратегии (определение перечня контролируемых систем, формирование особых проверок, работа с событиями, задание интервалов хранения данных и т. д.), созданной по результатам этапа оценки и этапа планирования. Для поддержания функционального состояния крупномасштабных внедрений жизненно важно, чтобы в работе находились лишь нужные ситуации и группы параметров (attribute groups) наблюдения.

Внедрение в крупной организации поддерживает порядка 1500 контролируемых систем в составе информационного окружения. Оценка при такой инсталляции предполагает по три агента на каждую управляемую систему. С большой степенью вероятности агенты в такой среде будут распределяться неравномерно, поэтому сценарий необходимо дополнить фазой анализа именно вашего окружения. Рекомендуемая схема распределения – по 400 агентов на каждом из 10 удаленных TEMS-серверов. Неизменность верхней границы в 400 агентов на каждом сервере мониторинга дает возможность наращивать объем, не истощая ресурсы инфраструктуры. Дальнейшие подробности расширения крупномасштабных внедрений см. в разделе 1.3 «Масштабируемость», с. 46.

Совет Поскольку IBM Tivoli Monitoring 6.1 поддерживает первичные и вторичные маршруты коммуникации, мы предлагаем установить несколько резервных удаленных TEMS, существующих исключительно в роли резерва (failover) на случай сбоя TEMA. При нарушении работы удаленного TEMS мы не советуем удваивать максимальную нагрузку на рабочем удаленном TEMS-сервере. Лучший выход из ситуации – направить лишившихся подключения агентов Tivoli Enterprise Management на незанятый удаленный TEMS-сервер.

Существенные требования к хранению данных предъявляет Tivoli Data Warehouse.

Рекомендуем вам изолировать агента Tivoli Warehouse Proxy от репозитария Tivoli Data Warehouse, установив их на две машины. Агент Summarization and Pruning должен быть установлен в системе с Tivoli Data Warehouse. Никогда не отделяйте друг от друга эти два компонента.

Частью топологии внедрения для крупного бизнеса также становится модуль IBM Tivoli Enterprise Console. IBM Tivoli Monitoring 6.1 содержит встроенные функции обработки событий, которые крайне удачно работают при установке в среде малых и средних организаций. Однако крупномасштабные развертывания могут давать существенный рост объема потоков событий. Tivoli Enterprise Console лучше приспособлен для управления мощными потоками событий и корреляции их между собой.

Этот модуль можно считать «менеджером менеджеров», консолидирующим события.

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

28 Глава 1 1.2.4 Внедрение для сверхкрупного предприятия (свыше 4000 агентов) Сценарий сверхкрупных внедрений служит руководством для любого развертывания IBM Tivoli Monitoring, выходящего за пределы 4000 агентов, или приблизительно 1500 контролируемых систем. Сверхкрупные внедрения по своему масштабу похожи на крупные, исключение составляют лишь руководства по дополнительному конфигурированию.

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

Tivoli Enterprise Monitoring Server Tivoli Enterprise Portal Server Tivoli Enterprise Portal Агент Tivoli Warehouse Proxy Tivoli Data Warehouse Агент Summarization and Pruning Tivoli Enterprise Console Рис. 1-4 показывает взаимосвязи между двумя независимыми внедрениями IBM Tivoli Monitoring 6.1. Он демонстрирует высокоуровневое взаимодействие компонентов обоих внедрений, каждое из которых содержит 4000 агентов. Общее число агентов в этих внедрениях – 8000.

Рекомендуемая стратегия развертывания, за исключением развертывания Tivoli Data Warehouse, а также агента Summarization and Pruning, аналогична стратегии для крупномасштабной организации. Сверхкрупная инсталляция способна в единственном репозитарии на сервере базы данных хранить наборы исторических данных, приходящие от двух различных инсталляций IBM Tivoli Monitoring 6.1.

Важно Как было отмечено в разделе 1.2.3 «Внедрение для крупного предприятия (до 4000 агентов)», с. 26, необходимо убедиться, что в Tivoli Data Warehouse активны только необходимые группы параметров наблюдения. Два крупномасштабных развертывания IBM Tivoli Monitoring 6.1 способны порождать неимоверное количество данных. Решающее значение в гарантированном создании стабильной, масштабируемой среды имеет выбор варианта внедрения, разработанного с учетом лучших практических достижений.

Каждая из двух инсталляций по-прежнему строится независимо от другой. Единственное отличие заключается в том, что одну инсталляцию IBM Tivoli Monitoring 6.1 требуется логически привязать к агенту Summarization and Pruning как управляющую систему (master control).

Особую гибкость при сверхкрупном внедрении должна демонстрировать функция настройки множества экземпляров TEP на работу с единственным настольным TEPклиентом. Если один-единственный настольный TEP-клиент должен соединяться с самостоятельными и независимыми инсталляциями IBM Tivoli Monitoring 6.1, то для

–  –  –

Рис. 1-4 IBM Tivoli Monitoring 6.1, модель топологии для сверхкрупного предприятия Примечание На одну установку Tivoli Data Warehouse может приходиться только один агент Summarization and Pruning. Поскольку агенту требуются подключения к TEMS, одна из инсталляций системы мониторинга должна быть логически объявлена основной – master. При этом речь идет не о программном присваивании, а о логической идентификации при конфигурировании и управлении S&P.

30 Глава 1 Создание экземпляров TEP средствами графического интерфейса Tivoli Manage Service Чтобы создать новые экземпляры TEP для дополнительного hub-сервера TEMS, выполните указанные далее операции через графический интерфейс Manage Tivoli Enterprise Monitoring Services.

1. Запустите графический интерфейс Manage Tivoli Enterprise Monitoring Services.

Выберите Start Programs IBM Tivoli Monitoring Manage Tivoli Windows Enterprise Monitoring Services UNIX/Linux Наберите itmcmd manage

2. Щелкните правой кнопкой мыши по строке Tivoli Enterprise Portal и выберите Create Instance, как показано на рис. 1-5.

Рис. 1-5 Нажатие правой кнопки на Tivoli Enterprise Portal и выбор опции Create Instance

–  –  –

Рис. 1-6 Ввод имени экземпляра в диалоговое окно

4. Наберите имя хоста Tivoli Enterprise Portal и нажмите OK (рис. 1-7).

Рис. 1-7 Ввод имени хоста Tivoli Enterprise Portal в поле TEP Server 32 Глава 1

5. Теперь в интерфейсе Manage Tivoli Enterprise Monitoring появится новый Tivoli Enterprise Portal (рис. 1-8).

Рис. 1-8 Вновь созданный экземпляр Tivoli Enterprise Portal Для создания последующих экземпляров Tivoli Enterprise Portal повторите шаги с 1 по 4 (рис. 1-9).

Рис. 1-9 Пример дополнительных экземпляров Tivoli Enterprise Portal Архитектура и планирование 1.2.5 Расширенное крупномасштабное внедрение с сетевыми экранами Важную роль в архитектуре большинства внедрений IBM Tivoli Monitoring 6.1 играют сетевые экраны. Для успеха развертывания системы важно понимать, каким образом осуществляется связь ее компонентов.

В настройке IBM Tivoli Monitoring 6.1 для поддержки функционирования в среде с сетевыми экранами выделим две главные составляющие:

протокол коммуникации между TEMS, TEPS и TEMA протокол коммуникации между TEP и TEPS Совет Рекомендации экспертов в отношении сценариев установки в средах с сетевыми экранами ищите в руководстве IBM Tivoli Monitoring Installation and Setup Guide, GC32-9407. Оно содержит несколько превосходных примеров работы с сетевыми экранами при внедрении TEP и TEPS-сервера.

Выбор протокола коммуникации При установке компонентов IBM Tivoli Monitoring 6.1 по разные стороны сетевого экрана рекомендуется настроить их на работу по IP.PIPE-протоколу (связь по TCP).

IP-протокола (связи по UDP) в конфигурациях с сетевыми экранами недостаточно.

Протокол UDP, работающий без установления соединения, для организации множества подключений к каждому отдельному компоненту IBM Tivoli Monitoring 6.1 требует, чтобы на сетевом экране был открыт целый ряд портов. Это необходимо, например, для нормальной связи по IP-протоколу (связи по UDP) TEMA и TEMS. Применение же IP.PIPE (связи по TCP) – при выполнении определенных условий – позволяет работать с «эфемерным» каналом (ephemeral pipe) автоматически.

Примечание Если в качестве протокола коммуникации вы укажете IP.PIPE, то сможете увидеть и другие порты, которые используются при трассировке и ведении журналов коммуникации, однако они являются виртуальными и мультиплексируются через порт IP.PIPE по умолчанию.

Протокол IP.PIPE имеет ряд заметных ограничений:

При его применении основной порт (по умолчанию – порт 1918) на одной интерфейсной сетевой карте в пределах одной системы могут совместно использовать только 16 процессов IBM Tivoli Monitoring 6.1. Любой процесс, не входящий в эти 16, будет вынужден задействовать протокол связи IP (но лишь в том случае, если IP настроен). Это ограничение главным образом затрагивает запуск на одной физической системе большого числа агентов Tivoli Enterprise Management. Оно не лимитирует общее количество TEMA-подключений к одному TEMS-серверу и может возникнуть только тогда, когда в системе требуется запустить больше 16 универсальных (Universal) агентов или система содержит больше 16 экземпляров 34 Глава 1 агента Database Agent. Если к применению протокола IP.PIPE вынуждают ограничения сетевого экрана, то единственным выходом является перенос «лишних»

агентов Tivoli Enterprise Management, которые не укладываются в число первых 16, на другую систему.

TEMS-серверу может не хватать сокетов (потоков прослушивания). Подтверждением этого станет его журнал:

message KDSMA010 – Communication did not succeed.

Если это произошло, число сокетов надлежит увеличить, изменив для этого параметр KDS_NCSLISTEN. Максимальное значение, которое этот параметр может принять, – 256.

Выбираемые по умолчанию порты компонентов IBM Tivoli Monitoring 6.1 приведены в табл. 1-2. Используйте ее, чтобы оперативно уточнять стандартные порты при инсталляции. Замена значений по умолчанию не приветствуется, хотя и возможна технически.

Табл. 1-2 Применение стандартных портов в IBM Tivoli Monitoring 6.1

–  –  –

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

Тестирование модификации портов группой IBM Tivoli Software Group проведено не было.

Применение IP.PIPE позволяет держать открытыми для сетевого экрана лишь несколько известных портов. Чтобы рассчитать номер открываемого порта, вы можете использовать пример 1-1. Если на сетевом экране не производится трансляция сетевых адресов (NAT, Network Address Translation), то приведенных расчетов должно быть достаточно для соединения с компонентами по другую сторону от экрана.

Пример 1-1 Алгоритм расчета номера порта прослушивания в IBM Tivoli Monitoring 6.1 "зарезервированный порт" = порт под известным номером + (N*4096), где N = порядок запуска компонента Архитектура и планирование Любая машина, на которой установлен IBM Tivoli Monitoring 6.1, автоматически резервирует для связи с сервером Tivoli Enterprise Monitoring Server порт под известным номером (по умолчанию 1918). При этом не важно, в каком порядке на ней запускаются одновременно установленные в ней компоненты IBM Tivoli Monitoring 6.1, по умолчанию указанный порт используется только TEMS-сервером.

Примечание Принятым по умолчанию портом с известным номером (well-known port) является порт 1918. Однако вы вправе сделать таковым любой порт, и его номер будет иметь силу во всей программной среде.

Все прочие компоненты, за исключением TEMS, для резервирования портов используют в IBM Tivoli Monitoring 6.1 внутрисистемный расчет, приведенный в примере 1-1.

Пусть запуск компонентов IBM Tivoli Monitoring 6.1 на машине Izmir происходит в следующем порядке:

1. Первым запускается агент Universal Agent: порт 6014 (1918 + 1* 4096)

2. Вторым – удаленный TEMS-сервер: порт 1918 (всегда зарезервирован для TEMS)

3. Третьим – агент Windows OS Agent: порт 10110 (1918 + 2* 4096)

4. Четвертым – Warehousing Proxy: порт 14206 (1918 + 3* 4096) Частичный выход за периметр сетевого экрана При помощи алгоритма из примера 1-1 мы можем управлять использованием портов на конкретной машине. Кроме того, задействовав два параметра переменной окружения KDC_FAMILIES, можно достичь такой степени управляемости, которая превзойдет даже метод, основанный на очередности запуска. В идеале все компоненты, которым необходим доступ к ресурсам по другую сторону сетевого экрана, должны использовать порты с меньшими, а все остальные – порты с большими номерами.

Чтобы достичь подобного результата, для каждого отдельного компонента IBM Tivoli Monitoring 6.1 надо определить параметры SKIP и COUNT переменной окружения KDC_FAMILIES (см. пример 1-2).

Например:

KDC_FAMILIES=IP.PIPE COUNT:1 PORT:1918 IP use:n SNA use:n IP.SPIPE use:n

Параметр COUNT (записанный в виде COUNT:N, где N – целочисленный номер порта, который мы резервируем) задается для компонентов, требующих доступа к ресурсам за пределами сетевого экрана. Если процесс нельзя связать с портом, номер которого определен значением N, он сразу терпит неудачу при запуске.

Параметр SKIP (записанный как SKIP:N, где N – целочисленный номер резервируемого порта + 1) задается для компонентов, не требующих доступа к ресурсам за пределами сетевого экрана. Если процесс нельзя связать с портом, номер которого определен значением N, поиск порта по алгоритму продолжится до тех пор, пока не будут использованы все доступные порты.

36 Глава 1Пример 1-2 Случай KDC_FAMILIES=IP.PIPE COUNT

В системе Izmir установлены компоненты:

Tivoli Enterprise Monitoring Server Агент ОС Windows Агент Warehousing Proxy Портом с известным номером является порт 1918 (по умолчанию).

Его всегда использует сервер Tivoli Enterprise Monitoring Server.

Агенту ОС Windows не требуется доступ к ресурсам за пределами сетевого экрана, и для его настройки следует записать: KDC_FAMILIES=IP.PIPE SKIP:2 (порт 10110).

Если открыть порт 10110 окажется невозможно, агент ОС Windows попытается связаться с портом 10370 (SKIP:3). При втором сбое он выберет SKIP:4, продолжив перебирать все возможные варианты после очередной неудачи.

Агенту Warehouse Proxy необходим доступ по другую сторону от экрана, и его следует настраивать командой вида KDC_FAMILIES=IP.PIPE COUNT:1 (порт 6014).

Если Warehouse Proxy не сможет открыть порт 6014, его запуск завершится с ошибкой.

Применение нескольких сетевых интерфейсов При каждом запуске любого из компонентов IBM Tivoli Monitoring 6.1 тот по умолчанию обнаруживает все доступные в системе интерфейсы сети и активно использует их в работе. Но это не всегда может дать желаемый результат.

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

Когда во время своего запуска TEMA-агент (или другая система) производит начальное подключение к TEMS, используя для этого Global Location Broker, он(а) подключается к первому интерфейсу TEMS-сервера. Допустим также, что соединение между интерфейсом TEMA и ограниченным сегментом сети для нужд резервирования отсутствует. TEMS-сервер выдает TEMA ответ с сетевым адресом, выбранным TEMS для подключения агента. Однако данный адрес может оказаться адресом карты, подключенной к сети для резервирования. В итоге TEMA не сможет успешно соединиться с TEMS даже в том случае, если их начальное взаимодействие было удачно завершено.

Во избежание этой проблемы для каждого компонента IBM Tivoli Monitoring 6.1 можно определить параметр окружения, требующий принудительного использования конкретного интерфейса сети, а не любого интерфейса среди доступных.

Для этого включите в команду одно из следующих ключевых слов:

KDCB0_HOSTNAME: Здесь вы можете указать имя хоста, которое соответствует используемой сетевой карте, или IP-адрес в десятичном формате с разделителем «.». Данный параметр, если он есть, имеет приоритет над параметром KDEB_ INTERFACELIST.

KDCB0_HOSTNAME может использоваться лишь в средах без трансляции сетевых адресов (NAT); кроме того, указанный параметр блокирует применение эфемерных каналов коммуникации (Ephemeral Pipe).

Загрузка...

Архитектура и планирование KDEB_INTERFACELIST: В этом случае сетевой интерфейс должен быть задан как IP-адрес в десятичном формате с разделителем «.». Данный параметр рекомендуется к применению в случаях, когда продукт IBM Tivoli Monitoring 6.1 установлен в среде с трансляцией адресов.

Впрочем, определение этих параметров – в любом случае «хороший тон», гарантирующий, что агенты Tivoli Enterprise Management будут подключены к нужному TEMSинтерфейсу.

Установки с сетевыми экранами Если агенты Tivoli Enterprise Management находятся в самой незащищенной зоне, отделенной экраном, то наиболее грамотное решение заключается в развертывании удаленного TEMS-сервера по ту же сторону сетевого экрана. Это позволит всем TEMAагентам подключаться к удаленному TEMS – единственному из компонентов, соединение с которым выйдет за периметр безопасности.

Такой подход минимизирует число систем, нуждающихся в доступе к сетевому экрану, и сохранит в силе ограничения, наложенные на использование портов. Наглядное представление сказанного дают рис. 1-10 и рис. 1-11.

Особые случаи Сетевой экран с трансляцией адресов – эфемерный канал связи Сегодня многие сетевые экраны осуществляют трансляцию сетевых адресов (Network Address Translation), что повышает степень защиты систем в периметре безопасности, делая их «невидимыми» и пользуясь для этого IP-адресами из собственного набора. Если ваша конфигурация содержит экран, реализующий NAT, то провести настройку TEMA, TEPS или TEMS для подключения к другому TEMS-серверу проще всего, используя эфемерный канал связи (Ephemeral Pipe). Когда такой канал связи активен, он служит виртуальным туннелем, пропускающим все соединения пар компонентов через единый порт.

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

– Файл с определением KDC_PARTITION не существует; применение KDC_ PARTITION дезактивирует эфемерный канал связи.

– Параметр KDCB0_HOSTNAME должен оставаться незаданным; вместо него пользуйтесь переменной KDEB_INTERFACELIST.

– Инициаторами коммуникации должны стать агенты, но не TEMS-сервер, на стороне которого в прежних конфигурациях все еще может присутствовать предназначенная Location Broker команда KDSSTART LBDAEMON. Для активации эфемерного канала от нее следует отказаться.

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

38 Глава 1

Сконфигурировать эфемерный канал явно можно, установив следующий параметр:

KDC_FAMILIES=IP.PIPE PORT 1928 EPHEMERAL:Y

Такая запись требует от клиента использовать эфемерные исходящие подключения. К такому варианту конфигурирования следует прибегать, если в журнале TEMS вы находите сообщения об ошибке при появлении дублирующих каналов (duplicate pipe setup failure), возникающей при запуске в той же системе, где работает TEMS, нескольких агентов, каждый из которых подключен к тому самому TEMS, причем по единственному каналу. В этом случае использовать эфемерный канал связи агентов вынуждает параметр EPHEMERAL:Y.

Хотя такого рода канал стоит на первом месте в списке альтернатив, пригодных для работы в средах с трансляцией адресов, его использование для связи через периметр безопасности в определенном окружении может быть неудачным. Если в процессе коммуникации TEMA и TEMS возникают ошибки, вам может потребоваться более подробная трассировка соединения. Для генерации развернутого отчета с детализацией на нужном вам уровне установите KDC_DEBUG=Y.

Если возвращаемая при KDC_DEBUG=Y трассировочная информация содержит IP-адреса, равные 0.0.0.0, это указывает на правильное использование эфемерного канала. Однако если установить связь по-прежнему невозможно, необходимо воспользоваться альтернативным подходом, требующим определения разделов (partitions). Подобное может произойти, если соединения TEMA и TEMS проходят несколько сетевых экранов или трансляция адресов организована без применения шаблонов настройки (generic patterns).

Сетевой экран с трансляцией адресов – использование разделов Если установить соединение между агентами и hub-сервером TEMS по эфемерному каналу не удается, единственной альтернативой этому в данном релизе IBM Tivoli Monitoring 6.1 является использование файлов разделов (partition files). Полное описание всех аспектов этой проблемы приведено в руководстве IBM Tivoli Monitoring Installation and Setup Guide, GC32-9407.

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

Приведенные ниже рекомендуемые варианты архитектуры послужат вам наглядным пособием и помогут понять, какие потоки данных проходят между компонентами IBM Tivoli Monitoring 6.1. Превосходное владение протоколами коммуникации в IBM Tivoli Monitoring 6.1 даст вам как архитектору контроль над топологией сети в целом. Опишем две распространенные реализации.

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

Здесь в самой незащищенной зоне находится агент Warehouse Proxy.

Одна из рекомендуемых архитектур развертывания IBM Tivoli Monitoring 6.1 с ограничениями на уровне сетевого экрана и агентом Warehouse Proxy в зоне с наименьшей защитой показана на рис. 1-10.

Рис. 1-10 Расширенное внедрение в зоне с меньшей защитой

40 Глава 1 Этот сценарий удерживает весь трафик по сбору данных агентом TEMA по одну сторону от экрана, при этом реальный репозитарий баз данных находится в более защищенном сегменте. Следить за портом агента Warehouse Proxy и соблюдением правил сетевого экрана нет ни малейшей необходимости. На экране, чтобы позволить агенту установить ODBC-соединение с хранилищем Tivoli Data Warehouse в зоне с большей защитой, требуется открыть точно заданный порт. Порт, выделенный для подключения по интерфейсу ODBC, уникален для каждой РСУБД. За помощью по этим вопросам обращайтесь к документации по БД или собственному администратору локальных баз данных.

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

Рекомендуемая архитектура внедрения IBM Tivoli Monitoring 6.1 при более сильных ограничениях на уровне сетевого экрана и размещении агента Warehouse Proxy в более безопасном сегменте представлена на рис. 1-11.

Сценарий вынуждает TEMA передавать трафик через экран. Агент Warehouse Proxy и репозитарий Tivoli Data Warehouse расположены в более безопасной сетевой зоне.

Такое решение усложняет развертывание агента Warehouse Proxy, однако не повышает защищенности находящихся в хранилище данных.

Для открытия соответствующих портов, с тем чтобы TEMA-агент смог передавать через экран данные исторического характера, агенту Warehouse Proxy требуется указать порт с заданным номером для прослушивания. Номер этого порта определяется согласно механизму KDC_FAMILIES.

Совет Рассчитанный для нужд агента Warehouse Proxy номер порта имеет значение только в тех случаях, когда:

Агенты TEMA передают данные непосредственно агенту Warehouse Proxy, не сохраняя их на удаленном TEMS-сервере.

Политики сетевого экрана не допускают создания ODBC-подключений, ведущих от менее безопасных сегментов инфраструктуры к более безопасным, при этом агент Warehouse Proxy должен быть защищен сетевым экраном от агентов TEMA.

TEMA для подключения к агенту Warehouse Proxy должны пройти через сетевую защиту.

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

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

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

Архитектура и планирование Свертки исторических данных можно хранить на удаленном TEMS-сервере. Однако при этом есть строгое ограничение: на каждый удаленный TEMS-сервер должно прийтись не более 250 TEMA.

Windows позволяет открыть не более 2000 сокетов одновременно. В среде с сетевыми экранами необходим протокол IP.PIPE. Он лимитирует передачу исторических данных 1500 TEMA-агентами (500 сокетов зарезервированы для внутренней обработки) в расчете на инсталляцию IBM Tivoli Monitoring 6.1.

Рис. 1-11 Расширенное внедрение в зоне с большей защитой

42 Глава 1 Важно Если вы знакомы с функциями Tivoli Firewall Security Toolbox (TFST), то имейте в виду, что поддержка сетевых экранов в IBM Tivoli Monitoring 6.1 не обеспечивает реализации всех функций TFST, в частности подключения с безопасного сайта и выполнения задач прокси-системы в среде с несколькими экранами (для работы через разные порты). Эти функции ожидаются в пакете обновлений (fix pack) IBM Tivoli Monitoring 6.1.

1.2.6 Расширенное сверхкрупное внедрение с несколькими процессами TEMS Данный сценарий расширенного внедрения иллюстрирует мощь, гибкость и потенциал IBM Tivoli Monitoring 6.1. Эта стратегия развертывания потребует задействовать удвоенные технические средства по сравнению с рекомендуемыми спецификациями, однако позволит меньше заниматься физическим размещением аппаратуры. На этом примере мы раскроем техническую способность запуска нескольких серверов мониторинга (TEMS) на одной физической системе. Тем самым мы подтвердим способность IBM Tivoli Monitoring 6.1 к адаптации, но и признаем невероятные сложности, которые могут возникнуть в процессе его развертывания.

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

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

Установка включает в себя следующие компоненты системы:

Tivoli Enterprise Monitoring Server Tivoli Enterprise Portal Server Tivoli Enterprise Portal Агент Tivoli Warehouse Proxy Tivoli Data Warehouse Агент Summarization and Pruning Tivoli Enterprise Console Этим решением мы стремимся акцентировать внимание на возможном оперативном развертывании с использованием нескольких процессов сервера TEMS, настроенных на разные порты прослушивания. Архитектурно оно близко к внедрению для крупного предприятия. Однако теперь множество процессов удаленного TEMS-сервера работают на одной физической системе.

В качестве иллюстрации метода на рис. 1-12 приведена простая архитектура. Инсталляция IBM Tivoli Monitoring 6.1 может расти и дальше, позволяя запускать более двух процессов kdsmain на каждой системе. Это дает возможность реализации более масштабных внедрений на меньших аппаратных ресурсах. Чтобы схема оставалась Архитектура и планирование ясной и очевидной, удаленные TEMS-серверы для краткости сведены воедино. И хотя данная стратегия аналогична крупномасштабным внедрениям (реализация обоих идентична до мелочей), мы не советуем доводить описанную инсталляцию IBM Tivoli Monitoring 6.1 до максимальной нагрузки.

По сути дела, такое крупномасштабное развертывание системы способно включать в себя до 10 удаленных серверов TEMS, на каждом из которых в пределах одной системы могут работать два или более процесса Tivoli Enterprise Monitoring Server.

IBM Tivoli Monitoring 6.1 имеет программное ограничение, не позволяющее нескольким процессам TEMS-сервера прослушивать порт с заданным номером (по умолчанию порт 1918). Для построения описанной выше архитектуры любые дополнительные процессы TEMS-сервера, выполняемые на той же системе, должны быть настроены на использование незанятого порта, что фактически удваивает возможности IBM Tivoli Monitoring 6.1 без трат на дополнительную аппаратуру. Впрочем, мы рекомендуем запускать в системе только один hub TEMS-сервер. Хотя поддержка нескольких сконфигурированных как (*HUB) процессов сервера TEMS реализована, такое решение не приветствуется.

При данном внедрении для установки IBM Tivoli Monitoring 6.1 необходимы отдельные каталоги. Несмотря на то что исполнимые модули будут находиться при этом в одной системе, инсталляции будут полностью обособлены. В процессе развертывания следуйте обычным установочным процедурам, действующим для единичного внедрения в среде крупного предприятия. Единственное необходимое изменение в процедуре – это настройка имеющего заданный номер порта для каждого выполняемого процесса TEMS. Для сбора исторических данных решение не отличается от сверхкрупных развертываний: один репозитарий Tivoli Data Warehouse и множество агентов Warehouse Proxy.

Примечание Агент Warehouse Proxy требуется для каждого отдельного экземпляра процесса TEMS. Например, для экземпляров процессов TEMS, работающих на трех различных портах, необходимо три агента Warehouse Proxy.

И еще одно соображение, о котором следует помнить: все многочисленные процессы TEMS – это по-прежнему логически самостоятельные инсталляции, каждую из которых нужно сопровождать независимо. Системы в составе инфраструктуры должны иметь собственные установочные каталоги CANDLEHOME. Модули IBM Tivoli Monitoring 6.1 на каждой системе требуют поддержки каждого обособленного каталога развертывания.

Внимание Технически IBM Tivoli Monitoring 6.1 поддерживает работу нескольких TEMS в пределах одной системы. Однако необходимо тщательно исследовать все возможные варианты. Общая стоимость владения с учетом поддержки столь сложной среды может быть выше стоимости дополнительного аппаратного обеспечения.

44 Глава 1Рис. 1-12 Крупномасштабное внедрение: одна система для нескольких TEMS

Архитектура и планирование

1.3 Масштабируемость Масштабируемость присуща распределенной инфраструктуре сети уже в силу организации. В конце концов, распределенные системы и создают затем, чтобы наращивать и сокращать их путем увеличения и уменьшения ресурсов аппаратуры. Следует уточнить, что масштабируемость (scalability) – это не то же самое, что настройка производительности (performance tuning), которая имеет дело с увеличением отдачи имеющихся ресурсов без подключения новых.

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

В этом смысле IBM Tivoli Monitoring 6.1 обладает всеми основными признаками масштабируемой системы. Подключение новых ресурсов аппаратуры в виде удаленных серверов TEMS распределяет нагрузку и позволяет работать с большим числом агентов. Эта методология представляет собой фундамент, который строится на основе текущих рассчитанных значений реального окружения. Заметим, что IBM Tivoli Monitoring 6.1 во многом расширяет возможности масштабирования и управления производительностью, заложенные в OMEGAMON XE, и представляет собой замечательный симбиоз зрелого решения корпорации Candle Corp. и квалификации сотрудников подразделения IBM Tivoli Software.

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

Приведем пример.

Руководство пользователя утверждает: «Не ограничено»

Служба поддержки заявляет: «Не более n…»

Разработчики приложения уточняют: «n*3…»

Программа Early Support Program указывает: «n^3…»

Специалисты по обслуживанию системы полагают: «n/3…»

В отделе контроля производительности признают: «Мы это не проверяли».

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

С точки зрения масштабируемости, ключевое значение имеет сервер TEMS. Как архитектор внедрения IBM Tivoli Monitoring 6.1, не забывайте о следующих моментах:

Физическое количество хостов и типов используемых платформ Число и тип приложений и операционных систем на каждом из хостов

–  –  –

Рис. 1-13 Масштабируемость и производительность: источники и оценки Топология среды с позиции географии и, в частности, мест, где будут расположены управляемые системы Оценочное количество генерируемых событий; пороги, которые нужно установить; либо то и другое Степень автоматизации, которой требуется или планируется достичь Примерное количество пользователей TEP и ожидаемый режим их работы (формирование сложных видов отчетности, частые обновления данных в реальном времени и т. д.) Топология сети и размещение экранов Информацию, полученную при рассмотрении этих вопросов, можно использовать параллельно с правилами и руководствами по масштабированию, содержащимися в исходном выпуске IBM Tivoli Monitoring 6.1.

Архитектура и планирование Приведенные ниже числовые оценки стали известны в ходе проверочного тестирования GA-релиза IBM Tivoli Monitoring 6.1. Вкратце они представляют собой результаты реального испытания. Тем не менее, их нельзя считать решающим аргументом в пользу масштабируемости и производительности системы. Эти данные показывают тот уровень, достижимость которого подтверждена в тестовой среде разработки.

Однако каждая установка IBM Tivoli Monitoring 6.1 уникальна и требует собственного исследования в процессе развертывания.

Оценка всех аспектов работы продукта дана в табл. 1-3, где представлены максимальные для IBM Tivoli Monitoring 6.1 показатели с учетом объема нагрузки. Каждый из показателей представляет один экземпляр установки.

Табл. 1-3 Полный перечень показателей

–  –  –

Важно Приведенные показатели не отражают подлинный верхний предел IBM Tivoli Monitoring 6.1. Эти значения были получены путем реального испытания, не обязательно ведущего к выявлению ограничений продукта.

Масштабируемость Tivoli Data Warehouse и показатели таковой выходят за рамки этой главы.

1.4 Архитектура развертывания агентов Существует несколько способов установки агентов Tivoli Enterprise Management.

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

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

Не забывайте также о таких факторах, как:

Общее количество физических систем и полная численность развернутых на каждой из них агентов 48 Глава 1 Полоса пропускания и задержка сети, соединяющей TEMS и TEMA Размер системы IBM Tivoli Monitoring 6.1 при ее установке Наличие или отсутствие соединений с управляемыми системами 1.4.1 Встроенный контроллер развертывания IBM Tivoli Monitoring 6.1 IBM Tivoli Monitoring 6.1 содержит несложный и эффективный механизм развертывания, помогающий при установке агентов операционной системы (Operating System Agent) и приложений (Application Agent) на удаленных системах. В рамках этого механизма реализована и возможность их обновления. Таким образом, IBM Tivoli Monitoring 6.1 предоставляет мощный встроенный инструмент интеллектуального обновления агентов средствами графического или командного интерфейса.

Архитектура агентских компонентов IBM Tivoli Monitoring 6.1 представлена на рис. 1-14. Набор их функций делится между TEPS- и TEMS-серверами и агентом ОС, соответственно.

Рис. 1-14 Архитектура развертывания агентов

Входящие в IBM Tivoli Monitoring 6.1 агенты ОС, реализованные как DLL-файлы, могут управлять действиями по развертыванию агентов на агентском конце.

Хранилище агентов (Agent Depot) – это каталог установки на сервере мониторинга, откуда вы производите развертывание агентов и пакетов сопровождения (maintenance packages) по всей среде предприятия. Местом расположения хранилища должны являться локальный TEMS-сервер или настроенная как его домашний каталог (depot home directory) удаленная файловая система. Прежде чем приступать к развертыванию агентов с сервера мониторинга, хранилище требуется наполнить так называемыми связками (bundles). В состав связки входит образ для установки агента, а также все прочие необходимые для инсталляции элементы.

Загрузку агентов в хранилище можно произвести во время установки системы.

Для этого в инсталляторы под Windows и UNIX введена функция «наполнить хранилище» (populate depot).

Архитектура и планирование Примечание Продукт не поддерживает перенос пакетов между TEMS-серверами.

Любую агентскую связку в Agent Depot можно распознать по идентификатору (product ID) и атрибутам платформы. Помимо прочего, Agent Depot может содержать MDL-файлы и сценарии, применяемые в развертывании универсального (Universal) агента. Хранилище Agent Depot можно настроить по типам связок, которые вы хотите развертывать и которыми желаете управлять со своего сервера мониторинга.

При установке агентов роль «движущей силы» играет контроллер развертывания (deployment controller), являющийся одной из служб в составе Management Server.

Именно он запрашивает содержимое Agent Depot и, пользуясь RPC-протоколом, пересылает агентские связки. Решение всех прочих задач инициируется вызовами языка SQL1. Посредством написанных на нем обращений к Management Server производятся и запросы на развертывание агентов. Возможность запуска команд развертывания из интерфейса SQL1 предоставляет контроллер развертывания.

Примечания:

RPC (Remote Procedure Call) – это протокол, который одна программа может использовать, чтобы запросить сервис другой программы на другой машине сети.

При этом вызывающая программа не должна знать деталей построения сети.

(Вызов процедур также иногда называют вызовом функций или вызовом подпрограмм.) SQL1 – основанная на стандарте ANSI-1989 SQL1 реализация SQL.

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

Примечание Запросы на развертывание агентов являются асинхронными – при поступлении такой запрос ставится в очередь на обработку.

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

Благодаря этому протоколу, программа, выполняемая в ОС одного вида (например, Windows 2000), может установить связь с программой, выполняемой в ОС того 50 Глава 1 же или другого вида (например, Linux), используя как механизмы обмена информацией принятые в World Wide Web протокол Hypertext Transfer Protocol (HTTP) и язык Extensible Markup Language (XML). Поскольку Web-протоколы установлены и доступны во всех ведущих операционных системах, HTTP и XML являются готовым решением проблемы коммуникации программ, работающих под разными платформами и системами в пределах сети. Протокол SOAP содержит точные инструкции по кодированию HTTP-заголовка и XML-файла, дабы программа с одной машины могла вызвать программу с другой машины и передать ей необходимую информацию. Там же указано, как вызываемая программа может вернуть полученный результат.

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

1.4.2 Tivoli Configuration Manager V4.2 Большинство тех, кто пользуется продуктами IBM Tivoli Software, уже вложили средства в структуру управления Tivoli Management Framework V4.1.1 и систему IBM Tivoli Configuration Manager V4.2. Последняя может использоваться как механизм развертывания агентов IBM Tivoli Monitoring 6.1.

Применение IBM Tivoli Configuration Manager V4.2 как средства установки агентов IBM Tivoli Monitoring 6.1 эффективно с точки зрения затрат. IBM Tivoli Configuration Manager V4.2 – надежный инструмент, созданный для крупномасштабного размещения программного обеспечения. По сравнению с контроллером развертывания IBM Tivoli Monitoring 6.1 его выигрышность несомненна.

1.4.3 Развертывание образа операционной системы Чтобы получить собственный вариант образа и включить его в образ операционной системы для репликации, файлы пакета можно разархивировать и вручную. Этот метод похож на тот, который используется в случае с продуктом Tivoli Configuration Manager V4.2. Единственное отличие – программный дистрибутив не служит для размещения пакетов установки системы.

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

После восстановления операционной системы по ее образу для инсталляции исполняемых компонентов продукта через стандартный механизм silent install может быть запущен процесс «тихой» установки системы.

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

–  –  –

В этой главе будет описан порядок установки IBM Tivoli Monitoring 6.1 и связанных компонентов, а также обозначены цели демонстрации и проверки жизнеспособности (PoC, Proof of Concept). Внедрения данного типа также могут использоваться в среде малого предприятия.

В главе будут рассмотрены следующие вопросы:

установка и конфигурирование DB2 Workgroup Server Edition установка компонентов IBM Tivoli Monitoring 6.1 52 Глава 2

2.1 Установка и конфигурирование DB2 Workgroup Server Edition Прежде чем мы займемся установкой IBM Tivoli Monitoring 6.1, нам нужно установить базу данных. Служба Tivoli Enterprise Portal Service (TEPS) требует наличия одной реляционной базы для хранения в ней всех данных и идентификаторов пользователей, рабочих пространств, связей, запросов. Хранилищу Tivoli Data Warehouse (TDW) требуется еще одна реляционная база для записи данных исторического характера.

В целях демонстрации и установки IBM Tivoli Monitoring 6.1 поставляется вместе с IBM DB2 Workgroup Server Enterprise Server Edition, поэтому мы и намерены установить именно эту базу. Перечень поддерживаемых баз данных, а также программных и аппаратных требований см. в версии 6.1.0 руководства IBM Tivoli Monitoring Installation and Setup Guide, GC32-9407.

Далее мы по шагам опишем процедуру установки DB2 Workgroup Server Edition в среде Windows 2000, а также настройку требуемых компонентов баз данных.

2.1.1 Установка DB2 Workgroup Server Edition

Для установки IBM DB2 Workgroup Server Enterprise Server Edition выполните следующие шаги:

1. Войдите в систему, используя учетную запись Administrator.

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

В нашем случае это путь C:\ITM61_image\db2_image.

3. Запустите setup.exe.

4. В IBM DB2 Setup Launchpad щелкните по Install Product.

5. Для начала работы DB2 Setup Wizard нажмите Next в окне DB2 Workgroup Server Edition.

6. Прочтите лицензионное соглашение и примите его условия. Выберите I accept the terms in the license agreement и щелкните Next.

7. Отметьте опцию Typical и щелкните Next в окне Select the installation type, как показано на рис. 2-1.

Демонстрация, проверка жизнеспособности и внедрение для малого предприятия Рис. 2-1 Окно DB2 Setup Wizard – Select the installation type

8. Укажите, где будет установлен продукт, и нажмите Next (рис. 2-2).

Примечание Оставим здесь путь к каталогу по умолчанию: C:\Program Files\ IBM\SQLLIB.

9. Мастер DB2 Setup Wizard создаст пользователя с целью администрирования DB2.

В окне Set user information for the DB2 Administration Server (рис. 2-3) выберите Local user or Domain user account и Use the same user name and password for the remaining

DB2 services. На панели User Information введите такие данные:

Domain (оставьте поле пустым, если вы не используете запись пользователя в домене.) User name db2admin Password itm61dgrb Confirm password itm61dgrb Нажмите Next.

54 Глава 2 Рис. 2-2 Окно DB2 Setup Wizard – Select installation folder Рис. 2-3 Окно Set user information for the DB2 Administration Server Демонстрация, проверка жизнеспособности и внедрение для малого предприятия

10. Нажмите Next в окне настройки списка контактов администратора. В текущей установке мы оставили конфигурацию его параметров неизменной.

11. Нажмите OK в окне Warning.

12. Нажмите Next в окне Configure DB2 instances.

13. В окне Prepare the DB2 tools catalog выберите Do not prepare the DB2 tools catalog on this computer и щелкните Next.

14. В окне Specify a contact for health monitor notification отметьте пункт Defer the task until after installation is complete.

15. В последнем окне представлены текущие настройки конфигурации (рис. 2-4).

Чтобы начать копирование файлов, нажмите Install.

Рис. 2-4 Окно DB2 Setup Wizard – Start copying files

16. Нажмите Finish для завершения установки DB2.

Примечание По окончании инсталляции DB2 модуль DB2 Setup запустит приложение IBM DB2 First Steps Launchpad и проверит наличие обновлений для DB2. Эти действия можно отложить, щелкнув по кнопке No и выбрав Exit First Steps.

56 Глава 2 2.1.2 Создание базы данных Tivoli Data Warehouse В этом разделе мы создадим базу данных для Tivoli Enterprise Portal Server.

Прежде всего, нам следует убедиться в том, что сервер баз данных запущен. Для этого проверим состояние служб DB2: Start Settings Control Panel Administrative Tools Services.

Состояние «Started» должны иметь следующие две службы, запускаемые DB2. (На рис. 2-5 они выключены по умолчанию.) DB2 Governor Service DB2 License Server

Рис. 2-5 Консоль управления службами

Теперь мы можем создать базу данных. Щелкните Start Run, наберите в окне Open команду db2cmd и нажмите OK для запуска окна с приглашением командной строки (CLP, command line prompt) DB2.

Для создания базы данных введите в DB2 CLP следующую команду:

db2 create database tdw21 using codeset utf-8 territory US Создание базы данных tdw21 займет какое-то время; по окончании создания базы на экране появится сообщение вида DB20000I The CREATE DATABASE command completed successfully.

Демонстрация, проверка жизнеспособности и внедрение для малого предприятия 2.1.3 Создание учетной записи базы данных Когда мы создавали базу данных tdw21 из-под учетной записи пользователя Administrator, то выдали ему права администрирования DB2. Теперь нам требуется создать другую учетную запись, которой будут пользоваться Tivoli Enterprise Portal Server и Tivoli Data Warehouse для доступа к базе.

Чтобы создать новую учетную запись, выполните следующие шаги:

1. Нажмите Start Settings Control Panel Administrative Tools Computer Management, разверните пункт Local Users and Groups и щелкните по строке Users.

2. В строке меню щелкните Action New User (рис. 2-6).

Рис. 2-6 Консоль Computer Management, добавление нового пользователя системы

3. Введите следующую информацию о новом пользователе системы:

User name itm61 Password itm61dgrb Confirm Password itm61dgrb

4. Сбросьте флажок User cannot change password и установите признак Password never expires.

5. Нажмите кнопку Create, а затем Close (рис. 2-7).

–  –  –

Для добавления этого пользователя в группу администраторов (Administrator Group):

1. В интерфейсе Computer Management разверните пункт Local Users and Groups, затем разверните пункт Users.

2. На правой панели выделите пользователя itm61.

3. В строке меню выберите пункт Actions Properties.

4. Перейдите на вкладку с именем Member Of и щелкните Add (рис. 2-8).

Рис. 2-8 Назначение групп пользователю itm61

Демонстрация, проверка жизнеспособности и внедрение для малого предприятия

5. Выделите на верхней панели Administrators и щелкните Add. Группа Administrators окажется на нижней панели (рис. 2-9). Нажмите OK для завершения действия и еще раз OK, чтобы закрыть окно itm61 Properties; закройте консоль Computer Management.

Рис. 2-9 Добавление группы Administrators

2.1.4 Настройка ODBC для Tivoli Data Warehouse Proxy Чтобы передать данные с сервера Tivoli Enterprise Portal в хранилище Tivoli Data Warehouse, IBM Tivoli Monitoring 6.1 пользуется агентом Warehouse Proxy. Для пересылки в базу накопленных агентами исторических данных агент Warehouse Proxy использует соединение ODBC.

Для того чтобы создать такое соединение:

1. Нажмите Start Settings Control Panel Administrative Tools Data Sources (ODBC).

2. Выберите вкладку System DNS и щелкните Add.

3. Выделите строку ODBC IBM DB2 DRIVER и нажмите Finish, как показано на рис. 2-10.

4. В окне ODBC IBM DB2 Driver – Add выполните следующие шаги:

a. Введите в поле Data source name строку ITM Warehouse.

b. В поле Database Alias выберите TDW21.

c. Нажмите OK.

5. Для проверки ODBC-подключения к базе данных:

a. Выберите ITM Warehouse в окне ODBC Data Source Administrator.

b. Нажмите Configure.

–  –  –

c. Введите в окне CLI/ODBC Settings – ITM Warehouse идентификатор и пароль пользователя itm61 и нажмите Connect.

d. На экране появится сообщение об успешной проверке соединения. Нажмите OK.

e. Нажав OK, закройте окно.

2.2 Установка компонентов IBM Tivoli Monitoring 6.1 Этот раздел описывает процесс установки нескольких компонентов: Tivoli Enterprise Monitoring Server, Tivoli Enterprise Portal Server, Tivoli Enterprise Monitoring Agents и Tivoli Enterprise Portal.

2.2.1 Установка IBM Tivoli Monitoring 6.1

Для установки IBM Tivoli Monitoring 6.1 выполните следующие шаги:

1. Войдите в систему, используя учетную запись Administrator.

2. Перейдите к месту хранения инсталляционного образа IBM Tivoli Monitoring 6.1.

В нашем случае это путь C:\ITM61_image\itm61_image.

Примечание IBM Tivoli Monitoring 6.1 также можно установить с образа на компакт-диске.

3. Откройте каталог Windows и запустите setup.exe. Перед вами откроется мастер установки IBM Tivoli Monitoring – InstallShield Wizard.

4. В окне Welcome to IBM Tivoli Monitoring (рис. 2-11) нажмите Next.

Демонстрация, проверка жизнеспособности и внедрение для малого предприятия Рис. 2-11 Окно Welcome to IBM Tivoli Software

5. В окне Software License Agreement нажмите кнопку Accept, чтобы принять лицензионную информацию (рис. 2-12).

Рис. 2-12 Окно Software License Agreement 62 Глава 2

6. После принятия лицензионного соглашения мастер установки продукта проверяет наличие корректно развернутой базы данных и нужной версии JRE, что и показывает рис. 2-13. В нашем случае среда Java Runtime Environment будет установлена в процессе развертывания системы. Нажмите Next для продолжения инсталляции.

Рис. 2-13 Проверка наличия необходимого программного обеспечения Примечание Если у вас уже имеется корректная версия JRE и правильно установлена база, окно, изображенное на рис. 2-13, появляться не будет.

7. Нажав Next в окне Choose Destination Location (рис. 2-14), оставьте без изменений каталог, выбранный системой по умолчанию.

Демонстрация, проверка жизнеспособности и внедрение для малого предприятия Рис. 2-14 Окно Choose Destination Location

8. Теперь мы можем задать ключ шифрования SSL. Нажмите Next, чтобы оставить назначенный по умолчанию ключ IBMTivoliMonitoringEncryptionKey (рис. 2-15).

Рис. 2-15 Окно User Data Encryption Key 64 Глава 2

9. Нажмите OK в диалоговом окне Encryption Key, как показано на рис. 2-16.

Рис. 2-16 Окно Encryption Key Внимание Вы можете сменить ключ шифрования данных (Encryption Key), однако должны запомнить его для дальнейшего применения.

10.В окне на рис. 2-17 выберем компоненты, которые хотим инсталлировать.

Рис. 2-17 Выбор компонентов IBM Tivoli Monitoring 6.1 Демонстрация, проверка жизнеспособности и внедрение для малого предприятия

11. Нажмите значок («плюс»), чтобы развернуть пункт Tivoli Enterprise Monitoring Agents, и выберите строки Warehouse Proxy и Summarization and Pruning Agent (рис. 2-18).

Не нажимайте Next.

Рис. 2-18 Выбор агентов Tivoli Enterprise Monitoring Важно Не устанавливайте флажок напротив строки Tivoli Monitoring Agents – это приведет к инсталляции всех имеющихся агентов. Модуль Tivoli Enterprise Monitoring Agent Framework включается в установку при выборе других агентов из списка.

12. Установите флажки напротив строк Tivoli Enterprise Monitoring Server, Tivoli Enterprise Portal Server и Tivoli Enterprise Portal Desktop Client, как показано на рис. 2-19.

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

13. Нажмите для продолжения Next.

14. В окне Agent Deployment выберите опции Universal Agent и Monitoring Agent for Windows OS (рис. 2-20) и щелкните Next, разрешая установку этих агентов на удаленной площадке.

66 Глава 2 Рис. 2-19 Выбор остальных компонентов IBM Tivoli Monitoring Рис. 2-20 Окно Agent Deployment Демонстрация, проверка жизнеспособности и внедрение для малого предприятия

15. Нажмите Next в окне Select Program Folder.

16. Очередное окно (рис. 2-21) покажет вам текущие параметры установки. Нажмите Next, чтобы начать копировать файлы. IBM Tivoli Monitoring – InstallShield Wizard произведет установку IBM Java2 Runtime Environment 1.4.2 и приступит к копированию файлов системы.

Рис. 2-21 Окно Start Copying Files

17. Когда копирование файлов будет завершено, на экране появится окно Setup Type (рис. 2-22). Оставьте все флажки установленными, как они есть, и щелкните Next для начала конфигурирования компонентов IBM Tivoli Monitoring.

18. Чтобы согласиться с найденным именем хоста, нажмите Next в окне Define TEP Host Information (рис. 2-23).

68 Глава 2 Рис. 2-22 Окно Setup Type Рис. 2-23 Окно Define TEP Host Information Демонстрация, проверка жизнеспособности и внедрение для малого предприятия

19. В окне TEPS Data Source Config Parameters – DB2 (рис. 2-24) введите:

Admin User ID db2admin Admin Password itm61dgrb Database User ID TEPS Database Password itm61dgrb Reenter Password itm61dgrb Нажмите OK.

Рис. 2-24 Окно TEPS Data Source Config Parameters – DB2

20. Нажмите OK (рис. 2-25) и еще раз OK для завершения конфигурирования Tivoli Enterprise Portal Server.

Рис. 2-25 Окно-подтверждение TEPS configuration completes successfully Внимание Завершение конфигурирования Tivoli Enterprise Portal Server может занять определенное время, – не паникуйте.

70 Глава 2

21. В окне Warehouse ID and Password for TEP Server (рис. 2-26) сконфигурируем полномочия доступа к базе данных Tivoli Data Warehouse. Введите данные пользователя, созданного вами для ODBC-подключения в разделе 2.1.4 «Настройка ODBC для

Tivoli Data Warehouse Proxy», с. 60:

ID itm61 Password itm61dgrb Confirm Password itm61dgrb Нажмите Next.

Рис. 2-26 Окно Warehouse ID and Password for TEP Server

22. Нажмите OK, чтобы принять предлагаемые в окне TEP Server Configuration значения по умолчанию (рис. 2-27).

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

IP.PIPE использует небезопасные TCP-подключения IP.SPIPE использует безопасные TCP-подключения с защитой по SSL-протоколу SNA использует протокол SNA (Systems Network Architecture) для сред, содержащих мейнфреймы IP.UDP использует небезопасные UDP-подключения.

Демонстрация, проверка жизнеспособности и внедрение для малого предприятия Рис. 2-27 Окно TEP Server Configuration

23. Нажмите OK, чтобы принять предлагаемые по умолчанию настройки Tivoli Enterprise Monitoring Server (рис. 2-28).

Рис. 2-28 Окно TEP Server Configuration 72 Глава 2

24. Ответьте Yes на вопрос, следует ли повторно настраивать подключение к хранилищу для Tivoli Enterprise Portal Server (рис. 2-29).

Рис. 2-29 Запрос повторной настройки подключения к хранилищу

25. В окне Warehouse Proxy Database Selection отметьте опцию DB2 (рис. 2-30).

Рис. 2-30 Окно Warehouse Proxy Database Selection

26. Введите следующую информацию в окне Configure DB2 Data Source for Warehouse

Proxy (рис. 2-31):

Data Source Name ITM Warehouse Database Name tdw21 Admin User ID db2admin Admin Password itm61dgrb Database User ID itm61 Database Password itm61dgrb Reenter Password itm61dgrb Нажмите OK.

Демонстрация, проверка жизнеспособности и внедрение для малого предприятия Рис. 2-31 Окно Configure DB2 Data Source for Warehouse Proxy

27. Для завершения конфигурирования источника данных хранилища нажмите OK (рис. 2-32).

Рис. 2-32 Окно Manage Tivoli Enterprise Monitoring Services

28. Через какое-то время IBM Tivoli Monitoring начнет процесс создания презентационных файлов Tivoli Enterprise Portal, иллюстрируемый рисунком 2-33.

74 Глава 2 Рис. 2-33 Презентационные файлы Tivoli Enterprise Portal

29. В следующем окне (рис. 2-34) настройте сервер Tivoli Enterprise Monitoring: установите переключатель TEMS Type в положение Hub, проверьте значение поля TEMS Name и параметры протокола (для данного TEMS-сервера Protocol 1 и IP.PIPE). Нажмите OK.

Рис. 2-34 Окно Tivoli Enterprise Monitoring Server Configuration Демонстрация, проверка жизнеспособности и внедрение для малого предприятия

30. В окне Hub TEMS Configuration нажмите OK, чтобы принять предложенную по умолчанию настройку параметров IP.PIPE Settings: Hub, показанную на рис. 2-35.

Рис. 2-35 Окно Hub TEMS Configuration

31. На следующем шаге дополним сервер мониторинга поддержкой таких приложений, как рабочие пространства (workspaces) и проверки-ситуации (situations) для агентов. Установите TEMS Location в значение On this computer и щелкните OK (рис. 2-36).

Рис. 2-36 Переключатель TEMS Location

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

Рис. 2-37 Окно Manage Tivoli Enterprise Monitoring Services 76 Глава 2

33. На рис. 2-38 отберите те данные, которые вы хотите связать с сервером мониторинга. Проверьте, что вами выбраны строки с поддержкой каждого доступного приложения, и нажмите OK.

Рис. 2-38 Окно Select the application support to add to the TEMS

34. Нажмите Next в окне Application support addition complete.

35. Сконфигурируйте соединение между любым из компонентов IBM Tivoli Monitoring и hub-сервером мониторинга: убедитесь, что выбран Protocol 1, настроенный как IP.PIPE, и нажмите OK (рис. 2-39).

Рис. 2-39 Окно Configuration Defaults for Connecting to a TEMS

36. После небольшой паузы IBM Tivoli Monitoring – InstallShield Wizard выведет окно с информацией о перезапуске служб, затем на экране появится уведомление об окончании установки, представленное на рис. 2-40. Для завершения инсталляции компонентов IBM Tivoli Monitoring 6.1 нажмите Finish.

Демонстрация, проверка жизнеспособности и внедрение для малого предприятия Рис. 2-40 Окно InstallShield Wizard Complete

37. Далее перед вами будут открыты два текстовых файла: IBM Tivoli Monitoring Readme.txt и Post_Install_Info.txt. Самым важным и требующим особого внимания в них является предупреждение относительно Java 2 v1.4.2, размещенное нами в примере 2-1.

Пример 2-1 Readme.txt If you will be viewing the help for the TEP Server or TEP Client in Internet Explorer, be sure to clear the "Use Java 2 v1.4.2 for applet (requires restart)" checkbox under Tools-Internet Options-Advanced-Java (IBM).

Otherwise, you will not be able to enter Index or Search text.

38. В заключение будет запущена консоль Manage Tivoli Enterprise Monitoring Services – TEMS Mode – [Local Computer], показанная на рис. 2-41. В ней вы можете

– просматривать состояние служб

– перезапускать службы

– перенастраивать их

– запускать Tivoli Enterprise Portal Примечание Агент Warehouse Summarization and Pruning остался в ненастроенном состоянии. См. раздел 2.2.3 «Конфигурирование агента Warehouse Summarization and Pruning».

78 Глава 2 Рис. 2-41 Консоль Manage Tivoli Enterprise Monitoring Services 2.2.2 Запуск Tivoli Enterprise Portal Чтобы удостовериться в том, что установка прошла успешно, воспользуйтесь клиентом Tivoli Enterprise Portal, который вы можете запустить как настольное (desktop) или Web-приложение.

Запуск Tivoli Enterprise Portal из Internet Explorer

Для запуска Tivoli Enterprise Portal при помощи браузера:

1. Нажмите Start Programs Internet Explorer.

2. Введите http://kcbd0nr:1920/client/client

3. Щелкните Yes, чтобы принять сообщение Warning – Security, показанное на рис. 2-42.

Рис. 2-42 Сообщение о сертификате безопасности Демонстрация, проверка жизнеспособности и внедрение для малого предприятия

4. В окне Logon (рис. 2-43) на панели User Credentials наберите sysadmin как идентификатор для входа, оставив поле для пароля пустым. Нажмите OK.

Примечание Мы не должны вводить пароль, поскольку не задействовали защиту.

Рис. 2-43 Окно Logon

5. В окне Security Alert (рис. 2-44) нажмите Always Accept и примите сертификат.

Рис. 2-44 Окно Security Alert Перед нами открыты два окна Internet Explorer: Welcome to IBM Tivoli Monitoring и Tivoli Enterprise Portal. Так как агентов мы не настраивали и не устанавливали, то можем увидеть лишь Enterprise Navigator и ни одного выполняемого агента.

6. Нажмите Exit, чтобы закрыть окно Welcome to IBM Tivoli Monitoring. Выберите File Exit, а затем Yes, чтобы закрыть Tivoli Enterprise Portal. Браузер Internet Explorer также можно закрыть.

80 Глава 2 Запуск Tivoli Enterprise Portal Client как настольное приложение Во время установки Tivoli Enterprise Portal Client создает пункт меню и значок на рабочем столе компьютера. Запустить Tivoli Enterprise Portal Client (рис. 2-45) можно, щелкнув по созданному значку или выбирая Start Programs IBM Tivoli Monitoring Tivoli Enterprise Portal.

Рис. 2-45 Настольная версия Tivoli Enterprise Portal Client Примечание Прежде чем запускать настольный клиент портала, нужно установить данное приложение из образа IBM Tivoli Monitoring 6.1. Работая через Web, достаточно иметь доступ к сети и Internet Explorer или другой Web-браузер.

Демонстрация, проверка жизнеспособности и внедрение для малого предприятия 2.2.3 Конфигурирование агента Warehouse Summarization and Pruning Агент Warehouse Summarization and Pruning осуществляет перенос данных, поступающих от агентов и сервера мониторинга, в базу данных Tivoli Data Warehouse. Мы уже установили этот агент. Теперь нам надо его настроить.

1. Нажмите Start Programs IBM Tivoli Monitoring Manage Tivoli Enterprise Services.

2. Щелкните правой кнопкой по строке Warehouse Summarization and Pruning Agent и выберите пункт Configure Using Defaults, как показано на рис. 2-46.

Рис. 2-46 Конфигурирование агента Warehouse Summarization and Pruning

3. Ответьте Yes в окне Would you like to configure this Summarization and Pruning Agent.

4. На вкладке Source окна Java-программы Configure Summarization and Pruning Agent можно оставить настройки базы данных без изменений.

5. Щелкните по вкладке Defaults и установите флажок Apply settings to default tables for all agents.

6. Перейдите к Scheduling, где можно определить, как часто и когда именно должен выполняться агент. Оставьте настройки на этой вкладке без изменений.

7. Щелкните по Work Days. Здесь можно выделить рабочие и нерабочие часы суток, а также настроить дни отдыха. Оставьте вкладку без изменений.

8. Выберите последнюю вкладку Additional Parameters, которой можно воспользоваться для настройки оставшихся параметров базы. Ее также можно оставить без изменений.

82 Глава 2

9. Нажмите Save, а затем Close.

10. Теперь запустите программу-агент Warehouse Summarization and Pruning. Правой кнопкой щелкните по строке Warehouse Summarization and Pruning Agent. Выберите пункт Start (рис. 2-47).

–  –  –

Рис. 2-47 Запуск агента Warehouse Summarization and Pruning На этом конфигурирование агента Warehouse Summarization and Pruning завершено.

Далее нам предстоит настроить, какие из компонентов системы будут вести журнал данных в Tivoli Data Warehouse.

2.2.4 Установка агентов IBM Tivoli Monitoring

Для установки IBM Tivoli Monitoring 6.1 выполните следующие шаги:

1. Войдите в систему, используя учетную запись Administrator.

2. Перейдите к месту хранения инсталляционного образа IBM Tivoli Monitoring 6.1.

В нашем случае это путь C:\ITM61_image\itm61_image.

3. Откройте каталог Windows и запустите setup.exe. Перед вами откроется мастер IBM Tivoli Monitoring – InstallShield Wizard.

4. В окне Welcome (рис. 2-48) отметьте опцию Modify и щелкните Next.

Демонстрация, проверка жизнеспособности и внедрение для малого предприятия Рис. 2-48 Окно Welcome – Modify, repair, or remove program

5. Нажмите кнопку OK в информационном окне, показанном на рис. 2-49.

Рис. 2-49 Информационное окно

6. Разверните пункт Tivoli Enterprise Monitoring Agents и установите флажок Monitoring Agent for Windows OS, как показывает рис. 2-50.

Внимание Не снимайте флажки напротив установленных модулей. Тем самым вы требуете их удалить.

7. Поскольку на компьютере установлен Tivoli Enterprise Monitoring Server, очередной шаг (на рис. 2-51) связан с размещением агентов. Оставьте флажки в строках Universal Agent и Monitoring Agent for Windows OS и щелкните Next.

8. Нажмите Next в окне Start Copying Files.

84 Глава 2 Рис. 2-50 Выбор Monitoring Agent for Windows OS Рис. 2-51 Выбор агентов для развертывания в системе Демонстрация, проверка жизнеспособности и внедрение для малого предприятия

9. В окне Setup Type выберите единственную настройку Configure agents default connect to Tivoli Enterprise Monitoring Server. Нажмите Next (рис. 2-52).

Рис. 2-52 Настройка Configure agents’ default connection to TEMS

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

11. Нажмите Finish, чтобы закрыть окно InstallShield Wizard Complete. Нажмите Finish, чтобы закрыть окно Maintenance Complete.

Завершив установку агента Tivoli Monitoring, запустим консоль Manage Tivoli Enterprise Monitoring Services, чтобы узнать статус агентской службы. Нажмите Start Programs IBM Tivoli Monitoring Manage Tivoli Monitoring Services. Как показывает рис. 2-53, Monitoring Agent for Windows инсталлирован и работает.

86 Глава 2Рис. 2-53 Статус агента Monitoring Agent for Windows OS

Также мы можем запустить Tivoli Enterprise Portal Client (см. раздел 2.2.2 «Запуск Tivoli Enterprise Portal», с. 79) и увидеть Windows-агент в состоянии выполнения. Чтобы убедиться в том, что мониторинг уже работает, вы можете совершить в рабочем пространстве один или несколько переходов.

Демонстрация, проверка жизнеспособности и внедрение для малого предприятия

–  –  –

В данной главе мы подробно обсудим этапы и опыт наиболее успешных внедрений IBM Tivoli Monitoring 6.1 с использованием двух различных сценариев: на базе серверов TEMS для платформ Windows и UNIX. Помимо этого, мы приведем практические рекомендации по выбору класса и конфигурации аппаратного обеспечения.

Глава посвящена обсуждению следующих вопросов:

лабораторное окружение установка IBM Tivoli Monitoring 6.1 удаление IBM Tivoli Monitoring 6.1 88 Глава 3

3.1 Лабораторное окружение В этом разделе будут описаны программные и аппаратные компоненты, применявшиеся в ходе внедрения IBM Tivoli Monitoring 6.1 в нашей лабораторной среде. Здесь же будет дано краткое описание архитектуры, реализованной при построении данного окружения.

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

Раздел 3.2.

5 «Установка и конфигурирование среды: сценарий 1» (с. 100) описывает типичное внедрение IBM Tivoli Monitoring 6.1 с двумя Windows TEMS-серверами, где второй сервер предназначен для горячего резерва.

В разделе 3.2.16 «Установка и конфигурирование среды: сценарий 2» (с. 186) речь пойдет о внедрении двух UNIX TEMS-серверов, где второй сервер опять-таки используется как горячий резерв для первого.

Помимо серверов TEMS, все компоненты IBM Tivoli Monitoring 6.1 будут в обоих сценариях одинаковы. В зависимости от выбранной вами платформы для TEMS вы сможете воспользоваться любым сценарием из описанных.

Если вы установите TEMS-сервер на одну платформу (например, Windows), а затем решите перейти на другую (например, UNIX), то при миграции можете прибегнуть к инструкциям, изложенным в разделе 3.2.17 «Замена hub-сервера TEMS новым сервером мониторинга», с.194.

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

Также ввиду наличия возможности использовать в качестве горячего резерва Windows-сервера сервер под управлением UNIX и наоборот вы можете использовать один Windows- и один UNIX TEMS-сервер. При написании книги этот сценарий был с успехом нами опробован.

Внедрение в среде среднего и крупного предприятия 3.1.1 Программная и аппаратная конфигурация Программная и аппаратная конфигурация нашей лабораторной среды показана в табл. 3-1.



Pages:   || 2 | 3 |


Похожие работы:

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ КАЗАНСКИЙ ГОСУДАРСТВЕННЫЙ АРХИТЕКТУРНО-СТРОИТЕЛЬНЫЙ УНИВЕРСИТЕТ Утверждаю Проректор по учебной работе _ И.Э.Вильданов “ ” _ 201г...»

«Частное образовательное учреждение высшего образования "Ростовский институт защиты предпринимателя" "01" июля 2016 г. Рекомендована кафедрой таможенного дела протокол № 10 от 19.05.2016 РАБОЧАЯ ПРОГРАММА ДИСЦИПЛИНЫ "Основы технических средств таможенно...»

«Информатика, вычисл. техника и управление 8 ТРУДЫ МФТИ. 2016. Том 8, № 4 УДК 519.237.8 Г. И. Турканов1, Е. В. Щепин1,2 Московский физико-технический институт (государственный университет) Математический институт име...»

«Подъемно-транспортные машины и оборудование УДК 621.86 ФАКТОРЫ, ВЛИЯЮЩИЕ НА ТЕХНИЧЕСКОЕ СОСТОЯНИЕ И ДИАГНОСТИРОВАНИЕ КАНАТОВ ЛИФТОВЫХ УСТАНОВОК В.И. Сероштан, П.В. Витчук Рассмотрены факторы, вл...»

«НАУМОВ Игорь Владимирович ФОРМИРОВАНИЕ И ОПТИКО ЛАЗЕРНАЯ ДИАГНОСТИКА ВИНТОВЫХ ВИХРЕВЫХ СТРУКТУР В ЖИДКОСТИ 01.02.05 – Механика жидкости, газа и плазмы ДИССЕРТАЦИЯ на соискание ученой степени доктора технических наук Научные консультанты: доктор физико-математических наук, доцент О...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное автономное образовательное учреждение высшего образования "НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТОМСКИЙ ПОЛИТЕХ...»

«СВЕДЕНИЯ ОБ АВТОРАХ Аверков А.М. – инженер-химик НТФ "Сибирския технология", averkov@chemomsu.ru. Адеева Л.Н. – д-р техн. наук, профессор кафедры неорганической химии Омского государственного университета им. Ф.М. Достоевского, adeeva...»

«ФГОБУ ВПО "Поволжский государственный университет телекоммуникаций и информатики" ФГБОУ ВПО "Казанский национальный исследовательский технический университет им. А.Н. Туполева-КАИ" ФГБОУ ВПО "Уфимский государстве...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Сыктывкарский лесной институт (филиал) федерального государственного бюджетного образовательного учреждения высшего профессионального образования "Санк...»

«Общество с Ограниченной Ответственностью 141100, Московская обл., г. Щёлково, ул. Свирская, д. 3 тел/факс: (495) 510-63-23, (496-56) 9-11-09 E-mail: info@s-complect.ru телефон: (495) 510-71-51 Web-site: www.s-c...»

«ПАРСАЕВ Николай Владимирович СИНТЕЗ И АНАЛИЗ ФАЗОКОДИРОВАННЫХ ПОСЛЕДОВАТЕЛЬНОСТЕЙ С ОДНОУРОВНЕВОЙ ПЕРИОДИЧЕСКОЙ АВТОКОРРЕЛЯЦИОНОЙ ФУНКЦИЕЙ Специальность 05.12.04 – Радиотехника, в том числе системы и устройства телевидения Автореферат диссерт...»

«том 1 Перевод смыслов Священного Корана в контексте современности начала XXI века и под углом зрения той части людей, которые говорят и думают на русском языке Канонический редактор Ильдар Аляутдинов www.umma.ru Перевод смыслов Священного Корана В 5 т. Т....»

«Молодіжний науковий вісник (2012). УДК: 618.14, 331.015.11. Юрий Попадюха*, Сохиб Бахджат Махмуд Аль Маваждех**, Лилия Катюкова***, Алла Алёшина**** Укрепление поясничного отдела позвоночника с помощью нестабильных сфер-тренажеров * Национальный технический университет Украины;...»

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

«Федеральное агентство научных организаций Федеральное государственное бюджетное учреждение науки Уральское отделение Российской академии наук Федеральное государственное бюджетное учреждение науки Институт механики сплошных сред...»

«УСТАНОВКИ УМЯГЧЕНИЯ серии TS 91 Fleck Руководство по эксплуатации   СОДЕРЖАНИЕ 1. Назначение 2 стр.2. Условия применения 2 стр.3. Технические характеристики 2 стр.4. Описание и принцип работы 5 стр.5. Размещение и подключение. Монтаж установки 7 стр.6. Программирование электронного управляющего блока 1...»

«Приборы приемно-контрольные охранно-пожарные "ПРОТОН-16", "ПРОТОН-8" Руководство по эксплуатации ПРОТ.425522.100 РЭ Содержание 1 Описание и работа 3 1.1 Назначение прибора 3 1.2 Технические характеристики 6 1.3 Состав изделия...»

«АВИАЦИОННЫЙ ДВУХКОНТУРНЫЙ ТУРБОРЕАКТИВНЫЙ ДВИГАТЕЛЬ АИ-25 I серии ТЕХНИЧЕСКОЕ ОПИСАНИЕ Допущено в качестве учебного пособия для личного состава ИЗДАТЕЛЬСТВО "М А Ш И Н О С Т Р О Е Н И Е" М о с к в а 1971 УДК 029.7.030.004.1 (087.23) Техническое описание составили Афанасьев А. Ф., Барани...»

«Научно-исследовательская лаборатория "Компьютерные системы автоматики" С.В. Бушуев – кандидат технических наук (НИЛ КСА) А.Н. Михалев – кандидат технических наук (УрГУПС) Е.В. Паршина – ведущий...»

«"Научно-практические принципы применения визуально-измерительного контроля в строительной экспертизе" Грунин И.Ю., Будько В.Б., Липин Д.А., Горкин Д.С., Блинова Ю.М. 2011г. Выпуск 2. (Москва, изд.Пресса-Принт 2011г., 320стр.) Применение ВИК, органолептических и лабораторных методов исследований...»

«"Ученые заметки ТОГУ" Том 6, № 4, 2015 ISSN 2079-8490 Электронное научное издание "Ученые заметки ТОГУ" 2015, Том 6, № 4, С. 539 – 547 Свидетельство Эл № ФС 77-39676 от 05.05.2010 http://pnu.edu.ru/ru/ejournal/about...»

«Собьянин Денис Николаевич ЗАПОЛНЕНИЕ ЭЛЕКТРОН-ПОЗИТРОННОЙ ПЛАЗМОЙ МАГНИТОСФЕРЫ СИЛЬНО ЗАМАГНИЧЕННЫХ НЕЙТРОННЫХ ЗВЁЗД Специальность 01.04.02 теоретическая физика АВТОРЕФЕРАТ диссертации на соискание учёной степени кандидата физико-математических наук Москва 2010 Рабо...»

«Вестник КрасГАУ. 2012. №1 Литература 1. Воскресенский Н.А., Логунов Л.Л. Технология рыбных продуктов. – М.: Пищевая пром-сть, 1968. – 424 с.2. Мезенова О.Я., Ким И.Н., Бредихин С.А. Производство копченых пищевых продуктов. – М.: Колос, 2001. – 208 с.3. Устройство...»

«УГЛОВА Евгения Владимировна ТЕОРЕТИЧЕСКИЕ И МЕТОДОЛОГИЧЕСКИЕ ОСНОВЫ ОЦЕНКИ ОСТАТОЧНОГО УСТАЛОСТНОГО РЕСУРСА АСФАЛЬТОБЕТОННЫХ ПОКРЫТИЙ АВТОМОБИЛЬНЫХ ДОРОГ 05.23.11 – Проектирование и строительство дорог, метрополитенов, аэро...»

«стр. 96 из 116 УДК 641.05 К ВОПРОСУ ОБ ОСОБЕННОСТЯХ ПИТАНИЯ ПРИВЕРЖЕНЦЕВ РАЗЛИЧНЫХ РЕЛИГИОЗНЫХ ТРАДИЦИЙ Новикова Маргарита Владимировна, доктор технических наук, профессор технологий и организации ресторанного и гостиничного сервиса, margo.nov@mail.ru, Султае...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ "САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ ИМЕНИ АКАДЕМИКА С.П. КОРОЛЕВА (НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ)"...»

«НАУЧНЫЙ ВЕСТНИК МГТУ ГА № 160 УДК 629.735:620.193 ИНСТРУМЕНТАЛЬНАЯ ОЦЕНКА ВНУТРЕННЕЙ КОРРОЗИОННОЙ ПОВРЕЖДАЕМОСТИ ЭЛЕМЕНТОВ АВИАЦИОННЫХ КОНСТРУКЦИЙ С.Г. ХРУСТИКОВ Статья представлена доктором технических наук, профессором Пивоваровым В.А. В статье анализируются методы неразрушающего контроля, применяемые для контроля межкристаллитной коррози...»

«ООО "Компания "АЛС и ТЕК" УТВЕРЖДЕН 643.ДРНК.501592-02 31 01-ЛУ ШЛЮЗ ДОСТУПА АЛС-7300 AG Описание применения 643.ДРНК.501592-02 31 01 ( CD-R ) Листов 32 643.ДРНК.501592-02 31 01 СОДЕРЖАНИЕ Введение 1.Общие сведения о системе 2.Фун...»

«Атрошенко Юлиана Константиновна ПРОГНОСТИЧЕСКОЕ МОДЕЛИРОВАНИЕ ПРОЦЕССОВ ТЕПЛОПЕРЕНОСА ПРИ ОЦЕНКАХ ПОГРЕШНОСТЕЙ ИЗМЕРЕНИЙ ТЕМПЕРАТУР В УЗЛАХ, БЛОКАХ И АГРЕГАТАХ ТЕПЛОВЫХ ЭЛЕКТРИЧЕСКИХ СТАНЦИЙ 05.14.14 – Тепловые электрические станции, их энергетиче...»

«Преимущества никеля Применение никеля в составе нержавеющей стали Институт никеля декабрь 2008 г. Возможности при использовании никеля.. широкий диапазон универсальных видов нержавеющей стали различных классов: аустенитной стали серий 200 и 300, дуплексной, дисперсионно-...»








 
2017 www.lib.knigi-x.ru - «Бесплатная электронная библиотека - электронные матриалы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.