Руководство по внедрению IBM Tivoli Monitoring 6.1

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

Уровень сложности: простой

Васфи Гусер, консультант, ITSO
Ана Годой, специалист по поддержке продуктов Tivoli Distributed Monitoring, IBM

01.04.2007

В этой главе книги речь пойдет об архитектуре системы 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. Кроме того, один из разделов главы мы посвятим обзору развертывания агента IBM Tivoli Monitoring 6.1 с применением нескольких уникальных стратегий.

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

• компоненты IBM Tivoli Monitoring 6.1
• сценарии развертывания IBM Tivoli Monitoring 6.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.

  При крупномасштабных внедрениях рекомендуется установка множества 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///cn p/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
  • 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

1.1.2 Поддержка баз данных

Сведения о поддержке баз данных системой IBM Tivoli Monitoring 6.1 отражены в табл. 1-1.

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

Примечания:
A - платформа поддерживается
D - платформа не поддерживается в данной версии, однако ее поддержка может быть включена в последующие релизы системы.

В начало

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 показывает взаимосвязи различных компонентов системы, максимально их упрощая. В других главах книги мы раскроем эти взаимосвязи более детально и глубоко. Все аппаратные и программные ограничения будут описаны позже.

Примечания:

• Как горячий резерв (Hot Standby) используется система Milan (AIX 5.3.0), не показанная на схеме.
• На каждом ТЕМА-агенте имеется как минимум один агент ОС на некоторых есть дополнительные агенты.

Для изложения самых разнообразных вопросов по ходу книги произведем тестовое внедрение 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. Чтобы гарантировать правильность реализации, а также продемонстрировать лучшие практические примеры, мы включим в нашу среду соразмерное число неоднородных аппаратных конфигураций с различными по своим характеристикам операционными системами и платформами.

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.

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 стратегию сбора данных исторического характера. Мы настоятельно советуем организовывать структуру потока исторических данных так, как это продемонстрировано на схеме.

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

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

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 по сравнению с его функциональностью по-прежнему незначительна. Управлять внедренной системой вплоть до установки и обновления агентов можно через единый графический уровень представления.

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, то для сведения информации, приходящей по разным TEPS-подключениям, организуются экземпляры (instances) Tivoli Enterprise Portal.

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

Создание экземпляров TEP средствами графического интерфейса Tivoli Manage Service

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

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

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

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

3. Введите имя экземпляра (Instance Name) и нажмите OK (рис. 1-6).

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

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

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

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) - при выполнении определенных условий - позволяет работать с «эфемерным» каналом (ephemeralpipe) автоматически.

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

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

• При его применении основной порт (по умолчанию - порт 1918) на одной интерфейсной сетевой карте в пределах одной системы могут совместно использовать только 16 процессов IBM Tivoli Monitoring 6.1. Любой процесс, не входящий в эти 16, будет вынужден задействовать протокол связи IP (но лишь в том случае, если IP настроен). Это ограничение главным образом затрагивает запуск на одной физической системе большого числа агентов Tivoli Enterprise Management. Оно не лимитирует общее количество TEMA-подключений к одному TEMS-серверу и может возникнуть только тогда, когда в системе требуется запустить больше 16 универсальных (Universal) агентов или система содержит больше 16 экземпляров агента 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. Используйте ее, чтобы оперативно уточнять стандартные порты при инсталляции. Замена значений по умолчанию не приветствуется, хотя и возможна технически.

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

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

"зарезервированный порт" = порт под известным номером + (N4096),
где
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, поиск порта по алгоритму продолжится до тех пор, пока не будут использованы все доступные порты.

В  системе 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, работающих вне сетевого экрана.

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

  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.

Этот сценарий удерживает весь трафик по сбору данных агентом 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.

Если вы знакомы с функциями 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 в пределах одной системы. Однако необходимо тщательно исследовать все возможные варианты. Общая стоимость владения с учетом поддержки столь сложной среды может быть выше стоимости дополнительного аппаратного обеспечения.

В начало

1.3 Масштабируемость

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