Руководство по проектированию Operations

Руководство по проектированию
Operations Manager 2007 R2
Корпорация Майкрософт
Опубликовано: май 2009 г.
Автор
Кристофер Фокс (Christopher Fox)
В настоящем документе представлена точка зрения корпорации Майкрософт по
обсуждаемым вопросам на момент публикации. Поскольку корпорация Майкрософт должна
реагировать на меняющиеся условия рынка, эта информация не может считаться
обязательством со стороны корпорации Майкрософт и корпорация Майкрософт не может
гарантировать точность информации, представленной здесь, после даты публикации.
Этот документ предоставляется только для информационных целей. КОРПОРАЦИЯ
МАЙКРОСОФТ НЕ ДАЕТ НИКАКИХ ГАРАНТИЙ (ЯВНЫХ, ПОДРАЗУМЕВАЕМЫХ ИЛИ
ПРЕДУСМОТРЕННЫХ ЗАКОНОДАТЕЛЬСТВОМ) В ОТНОШЕНИИ ИНФОРМАЦИИ,
ПРЕДСТАВЛЕННОЙ В ДАННОМ ДОКУМЕНТЕ.
Соблюдение всех применимых законов об авторских правах является обязанностью
пользователя. Воспроизведение, сохранение или введение в любую систему поиска какойлибо части данного документа, а также его передача в любой форме, с любой целью и с
помощью любых средств (электронных, механических, фотокопирования, записи или иных
других) без письменного разрешения корпорации Майкрософт является нарушением
авторских прав.
Корпорация Майкрософт может обладать патентами, заявками на патенты, товарными
знаками, авторскими правами или другими средствами зашиты прав на интеллектуальную
собственность, относящимися к предметам и темам, описанным в данном документе.
Получение данного документа не предоставляет лицензию на вышеуказанные патенты,
товарные знаки, авторские права или другие права на интеллектуальную собственность, за
исключением случаев, когда это явно оговорено в письменном лицензионном соглашении,
выданном корпорацией Майкрософт.
Если не указано иное, представленные в примерах компании, организации, изделия, имена
доменов, адреса электронной почты, эмблемы, люди, места и события являются
вымышленными. Возможное сходство с реально существующими организациями,
предприятиями, изделиями, именами доменов, адресами электронной почты, эмблемами,
лицами и событиями следует рассматривать как случайное.
© Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.
Microsoft, Active Directory, ActiveSync, Internet Explorer, JScript, SharePoint, SQL Server, Visio,
Visual Basic, Visual Studio, Win32, Windows, Windows PowerShell, Windows Server и
Windows Vista являются товарными знаками группы компаний Майкрософт.
Все прочие товарные знаки являются собственностью соответствующих владельцев.
История редакций
Дата выпуска
Изменения
Май 2009
Версия этого руководства по Operations
Manager 2007 R2 содержит следующие
Дата выпуска
Изменения
обновления и дополнения.

Удалена схема документа

Добавлены сведения о безопасности
отслеживания UNIX или Linux, а также
показатели производительности и
масштабируемости.

Обновлены показатели
производительности.
Содержание
Введение в руководство по проектированию Operations Manager 2007 R2 ............................. 7
Обзор Operations Manager 2007 ................................................................................................ 8
Определение требований для Operations Manager 2007 ..................................................... 19
Составление требований к проекту Operations Manager 2007 ............................................. 24
Развертывание плана реализации Operations Manager 2007 .............................................. 47
Введение в руководство по
проектированию Operations Manager 2007
R2
Каждая ИТ-среда уникальна, и эффективная инфраструктура наблюдения за такой средой
должна учитывать уникальные особенности среды. Не существует универсального
решения по отслеживанию, которое могло бы обеспечить удовлетворительные результаты
во всех случаях. С другой стороны, компании не могут позволить себе индивидуальную
разработку решений по наблюдению с начального этапа в силу высокой стоимости и
трудоемкости такой задачи.
Microsoft System Center Operations Manager 2007 позволяет найти компромисс между этими
характеристиками, предоставляя элементы для построения решения в соответствии с
бизнес-требованиями. Расположение этих блоков и установка связей между ними
определяется заказчиком. Этот процесс называется планированием топологии. Топология
должна определяться бизнес-требованиями компании, технологическими возможностями,
требованиями к безопасности и необходимостью соблюдения нормативов. На этапе
проектирования в топологии Operations Manager должна отражаться уникальность среды.
Перед началом проектирования необходимо получить полное представление о системе
безопасности Operations Manager 2007, включая необходимые учетные записи и группы, а
также разрешения для них. В процессе проектирования крайне важно понимать систему
ролей и ролевой безопасности, реализованной в Operations Manager 2007, а также
последствия использования обязательной взаимной проверки подлинности. Полный
пример системы безопасности Operations Manager 2007 см. в руководстве по безопасности
Operations Manager 2007 на странице http://go.microsoft.com/fwlink/?LinkId=64017.
Operations Manager 2007 применяет модельный подход к наблюдению. В управлении на
основе моделей все элементы, выполняющие какую-либо функцию в организации,
представляются в виде моделей. Дополнительные сведения об управлении на основе
моделей см. в руководстве по основным принципам Operations Manager 2007 на странице
http://go.microsoft.com/fwlink/?LinkId=124799.
Общие сведения об этом руководстве
Руководство состоит из разделов, содержащих пошаговые руководства по задачам
проектирования и тестирования системы Operations Manager 2007. Руководство поможет
разобраться в компонентах-блоках Operations Manager 2007, представляя сводки по ролям.
В руководстве приводятся вопросы, которые нужно задать, чтобы обеспечить соответствие
проекта задачам компании. Руководство позволяет решить самые важные вопросы по
проектированию, чтобы обеспечить гибкость и масштабируемость решения. Оно поможет
выполнить планирование и определение размера топологии Operations Manager 2007 с
7
использованием данных из руководства по производительности и выбору размера.
Руководство содержит указания по проверке проекта в лабораторных условиях.
После завершения работы с руководством будет получена подробная схема
инфраструктуры и готовый план конфигурации компонентов Operations Manager 2007.
Проектные решения будут проверены в лабораторных условиях, и все будет готово к
пилотному развертыванию в рабочей среде. На этом этапе следует перейти к руководству
по развертыванию Operations Manager 2007.
Учтите, что руководство содержит лишь рекомендации и общие указания, а принимаемые
решения и конечный проект должны определяться актуальными потребностями.
Руководство позволяет убедиться, что собраны все данные, необходимые для принятия
оптимальных решений в конкретной ситуации.
Основные сведения о процессе
проектирования Operations Manager 2007
Проектирование реализации Operations Manager фактически представляет выполнение
следующих действий.

Анализ функций, выполняемых Operations Manager 2007.

Анализ бизнес-требований и технических требований компании, текущей
инфраструктуры и текущих процедур наблюдения.

Сопоставление этих требований с возможностями инфраструктуры Operations
Manager 2007.

Проверка проекта инфраструктуры Operations Manager 2007 в лабораторных условиях.
В ходе этого процесса выполняется планирование размеров и емкости групп управления. В
руководство включены данные, необходимые для этой задачи.
Обзор Operations Manager 2007
Инфраструктура Operations Manager 2007 состоит из определенных компонентов, которые
подлежат обязательной реализации, а также из дополнительных компонентов и функций,
которые реализуются при необходимости. Такие обязательные и дополнительные
компоненты и функции описаны в этом разделе. Компонент — это то, что устанавливается
с исходного носителя, а функция — это то, что подлежит настройке и используется после
того, как установлены все необходимые компоненты.
Необходимые роли и компоненты сервера
Основной единицей работы всех реализаций Operations Manager 2007 является группа
управления. Она состоит из установки Microsoft SQL Server 2005 с пакетом обновления 1 и
выше или Microsoft SQL Server 2008, на котором размещена база данных
OperationsManager. Корневой сервер управления, консоль управления и один или
8
несколько агентов развертываются на отслеживаемые компьютеры или устройства и
являются основными компонентами группы управления.
База данных OperationsManager
База данных OperationsManager — это первый устанавливаемый компонент во всех
группах управления. База устанавливается на платформе Microsoft SQL Server 2005 с
пакетом обновления 1 и выше или Microsoft SQL Server 2008 с пакетом обновления 1. В
этой базе данных содержится вся информация о конфигурации группы управления, а также
данные мониторинга, собранные и обработанные агентами.
Для оптимизации производительности Operations Manager следует контролировать размер
базы данных OperationsManager. Тестирование показывает, что оптимальный размер для
базы составляет 50 Гб. Чтобы не допускать превышения этого ограничения, Operations
Manager 2007 будет автоматически производить очистку устаревшей и ненужной
информации согласно устанавливаемым параметрам.
Так как в группе управления можно задать только одну базу OperationsManager, от ее
нормальной работы зависит работа всей группы. Для устранения уязвимости
единственного экземпляра базы данных OperationsManager ее можно разместить в
отказоустойчивом кластере службы кластера (прежнее название — MSCS). Кроме того, для
отправки данных о текущей конфигурации и операциях на другой сервер Microsoft SQL той
же версии, на котором размещена копия основной базы OperationsManager, можно
использовать функцию доставки журналов. Если в основной базе данных обнаружится
ошибка, то это позволит обновить резервную базу и переключиться на нее.
Корневой сервер управления
Корневой сервер управления — это особый тип сервера управления в группе, который
устанавливается в первую очередь. В группе управления одновременно может быть только
один корневой сервер управления. Корневой сервер является основным звеном в
администрировании конфигурации группы, управлении и взаимодействии с агентами и
базой данных OperationsManager и другими базами группы.
Корневой сервер управления также служит целевым объектом консоли управления и
предпочтительным целевым объектом для веб-консолей.
На корневом сервере размещена служба доступа к данным System Center и службы
конфигурации управления System Center. Эти службы выполняются только на корневом
сервере управления. Служба доступа к данным System Center обеспечивает безопасный
доступ к базе данных OperationsManager для всех клиентов, включая консоль управления,
оболочку управления и веб-консоль. Служба конфигурации управления System Center
отвечает за вычисление и распределение конфигурации всех серверов управления и
агентов, включая получаемые ими пакеты управления.
Подобно базе данных OperationsManager, роль корневого сервера можно установить в
отказоустойчивый кластер MSCS для повышения его доступности. Кроме того, другие
9
серверы управления группы (при их наличии) можно вручную перевести в роль корневого
сервера.
Агент
Агент Operations Manager 2007 — это служба, которая развертывается на отслеживаемом
компьютере. На отслеживаемом устройстве агент отображается как служба управления
System Center. Все агенты отправляют отчеты на сервер управления в группе. Этот сервер
считается основным сервером управления агента. Агенты отслеживают источники данных
на устройствах и собирают сведения по конфигурации, которая отправляется им с сервера
управления. Агент также определяет состояние работоспособности отслеживаемого
объекта и отправляет эти сведения на сервер управления. При изменении состояния
работоспособности объекта или выполнении других условий агент может создавать
предупреждения. Это свидетельствует о некорректной работе устройства и позволяет
привлечь внимание оператора.
Агенты также могут принимать различные типы действий для диагностики или исправления
ошибок. Передавая данные о работоспособности отслеживаемого устройства на сервер
управления, агент описывает текущую картину работоспособности устройства и всех
приложений.
Мониторинг устройств можно также выполнять без агента. В этом случае сервер
управления выполняет мониторинг удаленным образом.
Консоль управления
Консоль управления предоставляет единый пользовательский интерфейс для
взаимодействия с Operations Manager 2007. Через консоль управления осуществляется
доступ к данным мониторинга, основным средствам создания и настройки, отчетам
Operations Manager 2007, ко всем элементам управления и инструментам, необходимым
для администрирования Operations Manager 2007, а также к настраиваемому рабочему
пространству.
Для доступа к консоли управления учетная запись пользователя Active Directory должна
быть присвоена к роли пользователя Operations Manager 2007. Роль пользователя — это
сочетание устройств, к которым разрешен доступ, и профиля, который определяет
действия, которые разрешены для данной роли в пределах определенной области.
Политика безопасности на основе ролей определяется консолью управления, что
позволяет администраторам Operations Manager определять отображаемые
пользователям объекты и действия, которые пользователь может выполнять с этими
объектами. Дополнительные сведения см. в разделе "Безопасность на основе ролей"
данного документа.
Пакеты управления
Пакеты управления содержат определение работоспособности приложения,
установленное его разработчиками. При импорте в Operations Manager они позволяют
10
агенту отслеживать работоспособность приложения, создавать предупреждения при
серьезных ошибках приложения и предпринимать различные действия с приложениями и
его инфраструктурой для дальнейшей диагностики и восстановления работоспособности
приложения. Без пакетов управления для конкретных приложений, операционных систем и
устройств программа Operations Manager 2007 не имеет алгоритмов работы с такими
сущностями, а их мониторинг невозможен.
Дополнительные роли и компоненты сервера
Дополнительные роли сервера расширяют функциональность группы управления.
Большинство компонентов устанавливаются отдельно от необходимых основных
компонентов, но некоторые могут устанавливаться одновременно с основными. Полная
информация по установке компонентов Operations Manager 2007 содержится в руководстве
по развертыванию Operations Manager 2007.
Сервер управления
Сервер управления в основном используется для получения пакетов конфигурации и
управления от корневого сервера управления и их распределения по агентам, которые
отправляют данные на сервер управления. Сервер управления не выполняет особых
функций корневого сервера управления. Сервер управления можно преобразовать в роль
корневого сервера управления при ошибке самого сервера, если сервер управления
находился в группе управления до момента возникновения ошибки. В группе управления
устанавливается несколько серверов управления, что обеспечивает дополнительные
возможности при управлении агентами. Помимо этого наличие дополнительных серверов
управления в группе позволяет агентам выполнять резервное переключение и передавать
данные на другие серверы управления, если связь с основным сервером управления была
потеряна.
Сервер управления также может использоваться для удаленного мониторинга (например,
для мониторинга URL и кроссплатформенного мониторинга). Сервер управления также
позволяет размещать роль сборщика службы сбора аудита (ACS). Сборщик службы ACS
может устанавливаться только в сервере управления или сервере шлюзов. См. раздел
"Служба сбора аудита (ACS)" далее в этом документе для получения дополнительных
сведений о службах сбора аудита. Доступна также роль общего использования файлов
отслеживания ошибок без агентов, которая описана позже в документе.
Сервер шлюза
Operations Manager 2007 требует взаимной проверки подлинности агентов и серверов
управления и установления зашифрованного соединения перед обменом информацией.
По умолчанию для проверки подлинности используется протокол Kerberos. Если агент и
сервер управления находятся в одном лесе Active Directory или в доверенных лесах, то
взаимная проверка подлинности выполняется автоматически. Это вызвано тем, что
протокол Kerberos по умолчанию используется в Active Directory.
11
Если агенты и серверы управления не находятся в одной доверенной среде Kerberos (то
есть не в одном лесе Active Directory и не в доверенных лесах), то должны использоваться
способы проверки подлинности с сертификатами. В этом случае для этих агентов и
серверов управления, с которыми они обмениваются информацией, должен быть выдан
сертификат. Кроме того, если между агентами и сервером управления имеется
брандмауэр, то его правила должны разрешать каждому компьютеру, на котором
размещен агент, прямое взаимодействие через брандмауэр по зашифрованному каналу. В
противном случае порт Operations Manager должен принимать входящие подключения.
Сервер шлюза Operations Manager 2007 может использоваться для уменьшения сложности
администрирования связи между агентами и серверами управления, находящимися в
разных доверенных средах. Сервер шлюзов выполняет роль прокси-сервера для связи с
агентами. Сервер шлюзов располагается в доверенной среде агентов (например, в
домене), а все агенты взаимодействуют с ним. Затем сервер шлюзов выполняет
двустороннюю проверку подлинности с помощью сертификата компьютера и
перенаправляет данные, передаваемые при взаимодействии агента и сервера управления.
В этой ситуации достаточно наличия одного сертификата для сервера управления и одного
сертификата для шлюза В ситуации с брандмауэром для взаимодействия необходима
только взаимная авторизация сервера шлюзов и сервера управления.
Несколько серверов шлюзов могут устанавливаться в группе управления для
масштабируемости и резервного переключения. Если агент потеряет связь с сервером
шлюзов, то он может переключиться на другой сервер шлюзов, находящийся в той же
группе управления и в доверенной среде агента.
Подобным образом серверы шлюзов можно настроить на переключение между серверами
управления группы. Это позволяет создать полностью полностью дублируемые каналы
связи, находящиеся вне доверенной среды сервера управления.
Сервер веб-консоли
Сервер веб-консоли предоставляет интерфейс для группы управления, который доступен
через веб-браузер. Этот интерфейс не обеспечивает полной функциональности консоли
управления и позволяет обращаться только к представлениям "Мониторинг", "Отчеты",
"Моя рабочая область". Веб-консоль предоставляет доступ ко всем данным мониторинга и
задачам, которые представляют собой действия, выполняемые с отслеживаемыми
компьютерами из консоли управления. Доступ к данным в веб-консоли имеет те же
ограничения, что и доступ к содержимому в консоли управления.
Консоль создания и настройки пакета управления
Консоль создания и настройки Operations Manager 2007 является отдельным приложением,
которое предоставляет большие возможности по созданию и настройке по сравнению с
функциональностью панели создания и настройки консоли управления. Консоль создания
и настройки позволяет создавать новые пакеты управления, просматривать и изменять
существующие пакеты, проверять целостность пакетов, импортировать и экспортировать
12
их из групп управления. Консоль создания и настройки Operations Manager 2007 можно
загрузить по адресу http://go.microsoft.com/fwlink/?LinkId=136356.
Хранилище данных отчетов
Хранилище данных отчетов содержит архивные данные о мониторинга и предупреждениях.
Серверы управления записывают данные в хранилище одновременно с их записью в базу
данных OperationsManager, поэтому созданные отчеты всегда содержат последние
данные. Хранилище данных автоматически собирает информацию о производительности
на почасовой и ежедневной основе. Это позволяет создавать долгосрочные аналитические
отчеты значительно быстрее и хранить меньший объем данных для поддержки таких
отчетов.
Хранилище данных отчетов может получать данные из нескольких групп управления, что
позволяет создавать в отчетах накопительные представления данных.
Сервер отчетов
Сервер отчетов Operations Manager устанавливается в экземпляр служб отчетов Microsoft
SQL 2005 с пакетом обновления 1 и позже или в экземпляр служб отчетов Microsoft SQL
Server 2008 с пакетом обновления 1. Сервер отчетов используется для построения и
представления отчетов на основе данных, полученных из хранилища данных отчетов. Все
отчеты доступны из консоли управления, что позволяет управлять доступом к отчетам с
помощью ролей.
Службы ACS
Высокопроизводительные и безопасные службы ACS позволяют собирать и сохранять
события журнала событий безопасности на компьютерах, для которых осуществляется
мониторинг. События сохраняются в отдельной базе данных ACS (описывается дальше в
этом документе), расположенной в Microsoft SQL Server 2005 с пакетом обновления 1 и
позже или Microsoft SQL Server 2008 с пакетом обновления 1. ACS собирает все события,
записываемые в журнал событий безопасности на компьютерах, для которых включено
средство пересылки ACS. События перенаправляются с отслеживаемых компьютеров в
сборщик ACS, который запущен на сервере управления. Затем данное средство
обрабатывает события и записывает их в базу данных ACS. События передаются
зашифрованным образом практически в реальном времени из средства пересылки в
сборщик. Отдельный компонент отчетов ACS используется для последующего создания
отчетов из хранимой информации ACS.
Для эффективного использования ACS необходимо разработать четкую групповую
политику аудита Windows, которая реализуется в качестве доменной групповой политики.
Дополнительные сведения о групповой политике аудита Windows и реализации ACS см. по
адресу http://go.microsoft.com/fwlink/?LinkId=144734.
13
Средство пересылки ACS
Средство пересылки ACS встроено в агент Operations Manager 2007, поэтому не требует
отдельного развертывания или конфигурации. Средство пересылки ACS отображается как
служба пересылки аудита и по умолчанию отключено. Для включения средства пересылки
ACS на отдельном компьютере или в группе компьютеров используется задача консоли
управления.
Сервер сбора ACS
Основная задача сервера сбора ACS состоит в сборе, фильтрации и предварительной
обработке всех событий журнала безопасности Windows для вставки в базу данных. Так
как ACS собирает все события безопасности практически в режиме реального времени, то
средства пересылки отправляют в систему большие объемы данных. Не все данные будут
представлять интерес для организации, что отражено в групповой политике аудита
Windows. Механизм фильтрования сборщика позволяет указать события, которые
необходимо записать в базу данных ACS для долгосрочного хранения.
Программа установки сервера сбора ACS поставляется отдельно от серверов, агентов и
компонентов отчета Operations Manager. Ее можно установить только на существующий
сервер управления или корневой сервер управления, если не установлены
дополнительные серверы управления. Один сервер сбора ACS может поддерживать от
сотен до тысяч серверов в зависимости от роли сервера и групповой политики аудита
Windows, а также десятки тысяч рабочих станций. В то же время между сервером сбора
ACS и базой данных ACS (рассматривается в следующем разделе) имеется
индивидуальная связь. Если для обеспечения масштабируемости или управляемости
необходимы дополнительные сборщики ACS, то на каждый сборщик ACS будет
требоваться одна база данных ACS.
База данных ACS
После того, как данные были предварительно обработаны сервером сбора ACS, они
записываются в базу данных ACS, которая представляет собой базу данных, созданную в
экземпляре Microsoft SQL Server 2005 с пакетом обновления 1 или 2. Так как эта база
является стандартной базой SQL, она может быть кластеризована для повышения
доступности. Для установления индивидуальных отношений между сборщиками и базами
данных пользователь может создать несколько баз данных ACS на одном сервере SQL
Server 2005 с помощью именованных экземпляров, если сервер способен выдерживать
дополнительную нагрузку. Дополнительные сведения об изменении размера и
планировании мощности ACS см. соответствующий раздел в этом руководстве.
Средство отчетов ACS
Сервер отчетов ACS также является отдельным компонентом. Доступно несколько
предварительно настроенных отчетов. Установка ACS требует наличия экземпляра служб
отчетов SQL Server 2005 с пакетом обновления 1 и позже или служб Microsoft SQL
14
Server 2008. Возможно использование отдельного экземпляра, но средство отчетов ACS
можно также установить вместе со средством отчетов Operations Manager 2007 с одним
недостатком.
При установке средства отчетов ACS в тот же экземпляр служб отчетов, что и средство
отчетов Operations Manager 2007, средство отчетов ACS полностью интегрируется со
средством отчетов Operations Manager. Это упрощает администрирование, так как все
участники роли отчетов Operations Manager смогут обращаться к отчетам ACS. Для
некоторых организаций такая конфигурация может оказаться нежелательной, поэтому в
таких случаях средство отчетов ACS устанавливается в отдельный экземпляр средства
отчетов SQL Server. При этом следует определить собственные группы и роли
безопасности, что усложняет администрирование, но обеспечивает строгий контроль
доступа к данным ACS.
Прокси-агент
Operations Manager 2007 позволяет выполнять мониторинг сетевых устройств через SNMP
v2, компьютеров без операционной системы Windows, а также компьютеров без агентов. В
этих случаях мониторинг выполняется удаленным образом с другого компьютера, на
котором установлен агент. Компьютер, выполняющий удаленный мониторинг, называется
прокси-агентом. Агент, выполняющий функции прокси-сервера для мониторинга других
устройств, является стандартным агентом Operations Manager. Единственное отличие
состоит во включенном параметре Разрешить агенту работать как прокси и
обнаруживать управляемые объекты на других компьютерах в свойствах агента.
Затем выполняется настройка управляемого устройства без агента для назначение проксиагента, который должен использоваться устройством. Дополнительные сведения о
развертывании агента и управлении устройствами см. в руководстве пользователя
Operations Manager 2007.
Командная оболочка Operations Manager 2007
В 2006 году корпорация Майкрософт представила новый интерфейс командной строки
Windows PowerShell, использующийся в операционных системах Windows Server 2003,
Windows Server 2008, Windows XP и Vista. Этот интерфейс предназначен для
автоматизации задач, выполняемых системными администраторами. Интерфейс содержит
интерактивную среду командной строки и разработки, которая может использоваться
отдельно или в сочетании с другими средствами. Объекты, с которыми пользователь
взаимодействует в оболочке PowerShell, называются командлетами и представляют собой
двоичные встроенные команды Windows PowerShell. Команды Windows PowerShell
позволяют оперировать объектами, то есть со структурированной информацией, которая
является не только строкой символов на экране. Вывод команд всегда содержит
дополнительные сведения, которые при необходимости можно использовать.
Командная оболочка Operations Manager 2007 содержит 203 отдельных командлета,
которые были разработаны специально для автоматизации административных задач
15
Operations Manager 2007. Командная оболочка может устанавливаться на любой
компьютер с установленной консолью управления.
Функции
Функции установлены по умолчанию и требуют настройки для использования.
Возможности неограниченной настройки и использования свойств в Operations
Manager 2007 являются отличительной чертой программы.
Кроссплатформенное отслеживание (компьютеры UNIX и Linux)
Серверы управления и серверы шлюзов Operations Manager 2007 R2 могут отслеживать
компьютеры UNIX и Linux. Полный список ОС Unix и Linux, для которых поддерживается
отслеживание, см. в руководстве по поддерживаемым конфигурациям по адресу
http://go.microsoft.com/fwlink/?LinkId=144400.
При кроссплатформенном мониторинге все действия выполняются службой управления
System Center на сервере управления или сервере шлюзов. Служба мониторинга System
Center взаимодействует с отслеживаемым компьютером на уровне служб WSMAN,
установленных на сервере управления и на отслеживаемом компьютере. На
отслеживаемом компьютере обязательно должен быть установлен уровень служб WSMAN.
Взаимодействие между уровнями WSMAN выполняется через TCP-порт 1270 и всегда
производится со стороны сервера управления или сервера шлюза. В некоторых случаях
(например, если уровень WSMAN не присутствует на отслеживаемом компьютере или
вызвал сбой) взаимодействие может выполняться через SSH TCP-порт 22. SSH может
использоваться для установки уровня WSMAN и для выполнения диагностики.
16
Безагентное отслеживание исключений
При возникновении ошибки приложения в операционных системах Windows служба "Доктор
Ватсон" обнаруживает ошибку и перенаправляет информацию об ошибке в корпорацию
Майкрософт, чтобы определить ее основную причину. Обычно каждый компьютер делает
это индивидуально. Так как мониторинг ошибок и сообщение о них выполняется
индивидуально, ИТ-администраторы не имеют четкой картины таких исключений в своей
организации.
Если функция безагентного отслеживания исключений включена, то все исключения могут
направляться на сервер управления группы и накапливаться на нем. Концентрация таких
данных в одном месте позволяет компании использовать их для анализа и диагностики
ошибок приложений на компьютерах и серверах всей организации. При необходимости
сервер управления также можно настроить для отправки информации отслеживания
исключений в корпорацию Майкрософт для анализа сбоев. Дополнительные сведения об
этом см. по адресу http://go.microsoft.com/fwlink/?LinkID=11699.
Платформа Connector Framework
Connector Framework — это интерфейс прикладного программирования (API), который
предоставляет функциональность Operations Manager для интеграции с другими
17
продуктами управления или другими технологиями (например, с системами нумерации
неполадок). Данная платформа позволяет разрабатывать соединители, который
обеспечивают двусторонний обмен информацией с Operations Manager. Connector
Framework в первую очередь взаимодействует со службой доступа к данным System Center
на корневом сервере управления. Дополнительные сведения о разработке приложений,
использующих Operations Manager 2007 Connector Framework см. пакет разработки
программного обеспечения Operations Manager 2007.
Основные понятия
При планировании топологии следует понимать основные принципы безопасности на
основе ролей, используемые в программе Operations Manager.
Безопасность на основе ролей
Безопасность на основе ролей используется для управления отображаемыми объектами и
возможных действий, выполняемых с этими объектами. Роль состоит из двух частей.
Первая часть — это область действия, которая содержит доступные или отображаемые
объекты. Например, область действия содержит только контроллеры доменов или SQLсерверы. Вторая часть — это профиль. Каждый профиль определяет действия, которые
можно выполнить с видимыми объектами. Operations Manager 2007 содержит пять готовых
профилей:

Администратор — этот профиль имеет полные права на работу с Operations Manager.

Оператор с расширенными правами — этот профиль имеет ограниченные
возможности изменения конфигурации мониторинга путем настройки переопределений
правил и мониторов.

Дизайнер — этот профиль позволяет создавать элементы конфигурации мониторинга,
например правила, задачи, мониторы и представления.

Оператор — этот профиль позволяет обращаться к предупреждениям,
представлениям и задачам.

Оператор только для чтения — этот профиль разрешает доступ только для чтения к
предупреждениям и представлениям.

Оператор отчетов — этот профиль позволяет осуществлять доступ только для чтения
к отчетам Operations Manager.
Operations Manager также имеет пять предварительно определенных ролей, для каждой из
которых определена глобальная область действия. Например, роль администратора
Operations Manager использует профиль администратора и имеет глобальную область
действия, то есть пользователи могут просматривать все объекты Operations Manager и
управлять ими. Для каждого из перечисленных профилей существуют предварительно
определенные роли.
В дополнение к предварительно определенным ролям пользователь может создать новые
роли на основе профилей Оператор с расширенными правами, Дизайнер, Оператор и
18
Оператор только для чтения. При создании новой роли после выбора используемого
профиля определяется круг объектов, к которым роль будет иметь доступ. Это позволяет
создать роль, которая использует профиль Оператор и ограничена только серверами
Microsoft Exchange для администраторов Exchange. При последующем присвоении
администраторов Exchange к роли (по членству в группе Active Directory или
индивидуально) они получат возможность открывать консоль управления, но смогут
просматривать только серверы Exchange и выполнять действия только для
предупреждений, представлений и задач, связанных с Exchange.
Безопасность на основе ролей применяется вне зависимости от способа обращения к
функциям Operations Manager: через веб-консоль или через командную оболочку.
Дополнительные сведения о ролях и безопасности на основе ролей см. в руководстве по
безопасности Operations Manager 2007.
Определение требований для Operations
Manager 2007
Следующим шагом в процессе проектирования Operations Manager является определение
требований компании. Требования можно разделить на три категории: бизнес-требования,
ИТ-требования и требования оптимизации (целевые показатели). Сбор требований
является самым важным этапом разработки структуры Operations Manager 2007.
Исчерпывающее представление о требованиях позволяет построить решение в
соответствии с ожидаемым результатом. Проект, результат которого не соответствует
ожиданиям, обречен на неудачу.
Чтобы получить точное представление о требованиях, необходимо поговорить с
различными группами людей. Сначала нужно понять, каковы ожидания влиятельных
представителей компании и спонсоров. Если они ожидают от Operations Manager
результатов, которых невозможно достичь, следует разъяснить им возможности системы,
чтобы соответствующим образом задать уровень ожиданий. Также необходимо работать с
группами, которые будут использовать или обрабатывать данные из Operations Manager.
Сюда входят не только сотрудники справочной службы и администраторы приложений, но
также руководящий состав, который предположительно будет работать с отчетами,
полученными в Operations Manager, и которым требуется быстро представить ситуацию на
своем участке работ.
После завершения сбора требований обработайте данные и опубликуйте их, чтобы с ними
смогли ознакомиться все заинтересованные стороны. Это дает дополнительную
возможность уточнить возможности. Соглашение по требованиям можно скрепить
подписями спонсоров проекта и влиятельных представителей компании.
Бизнес-требования
Владельцы бизнеса, с которыми необходимо вести работу — это не просто высший
исполнительный орган, обеспечивающий финансирование проекта Operations Manager.
Это руководители, отвечающие за бизнес-процессы, приносящие доход компании. Продукт
19
Operations Manager может не представлять для них интереса сам по себе, однако они
весьма заинтересованы в повышении уровня обслуживания, которое ИТ-служба
предоставляет для важнейших бизнес-приложений.
Лиц, исполняющих такие роли, в ходе переговоров скорее всего будут интересовать
четыре области:

текущий уровень обслуживания, предоставляемый ИТ-службой;

сведения о производительности приложений;

обеспечение соответствия нормативным требованиям;

окупаемость затрат на ИТ-сферу.
Текущий уровень обслуживания, предоставляемый ИТ-службой
Главной задачей, которую ставят перед ИТ-службой владельцы организации, является
обеспечение работоспособности приложений. Если работа бизнес-приложения
прерывается, руководители должны немедленно узнать об этом. Им необходимо
представлять воздействие возможно перерыва в течение бизнес-процесса и ожидаемую
продолжительность простоя. Полное понимание бизнес-процессов служит ключом к
выполнению бизнес-требований. В ходе переговоров с руководителями убедитесь, что
получены ответы на следующие вопросы.

Какие приложения используются для выполнения операций, связанных с основным
видом деятельности? Ответ на этот вопрос позволяет определить, за какими
приложениями должно вестись сквозное наблюдение.

Из каких компонентов состоят эти приложения? Ответ на этот вопрос позволяет
построить распределенную модель отслеживаемых приложений.

Входит ли в приложение важный компонент, работающих на рабочих станциях или
других клиентах? Ответ на этот вопрос поможет спланировать стратегию наблюдения
за клиентами.

Составьте по итогам переговоров полное описание транзакции в приложении.
Operations Manager 2007 может использовать синтетические транзакции для
регулярной проверки приложения, а также передавать данные наблюдения за работой
конечных пользователей с приложением.
Сведения о производительности
В ходе обсуждения показателей производительности приложений, о которых необходимо
сообщать владельцам бизнеса, важно различать производительность бизнес-процессов и
производительность приложений. Показатели производительности (метрики) бизнеспроцессов предоставляются приложениями бизнес-аналитики, обычно в виде отчетов и
сбалансированных систем показателей. В данном случае речь идет о других показателях.
Необходимо понять, какие ожидания сформированы в отношении производительности
приложений. Убедитесь, что в ходе переговоров получены ответы на следующие вопросы.
20

Какие сведения о производительности приложений доступны руководству сегодня?
Какие сведения желательно получать? Ответы на эти вопросы помогут в планировании
ролей (профилей и областей).

Как сведения о производительности приложений передаются руководству сегодня?
Каким образом желательно получать сведения? Ответы на эти вопросы помогут
решить, как следует предоставлять доступ к сведениям о производительности.
Например, нужна ли консоль управления с оператором только для чтения и доступ к
отчетам, относящимся к приложению, или будет достаточно веб-консоли?
Обеспечение соответствия нормативным требованиям
Выполнение нормативных требований является важнейшей задачей, с которой владельцы
организаций сталкиваются и в настоящем, и в будущем. Владельцы бизнес-процессов
обращаются к ИТ-службе за содействием в реализации планов компании по достижению и
соблюдению соответствия требованиям. Обязательно получите ответы на следующие
вопросы.

Применяются ли для бизнес-процессов законодательные требования? Каковы их
формулировки? (в случае положительного ответа) Эти данные помогут в планировании
служб ACS и планировании ролей.

Какой тип данных должна предоставить ИТ-служба руководству и за какие сроки? Это
поможет в планировании работы с отчетами и планировании политики хранения
данных.
Окупаемость затрат на ИТ-сферу
Владельцы бизнеса оплачивают ИТ-услуги (путем прямых платежей или косвенных
расходов), и как подобает рачительным хозяевам, они хотят знать, за что платят.
Статистику расходов поможет составить модуль создания отчетов Operations Manager,
однако нужно знать, какие данные представляют ценность для владельцев организации.
Обязательно рассмотрите следующие вопросы.

Какие ИТ-услуги руководство считает наиболее ценными? Ответ поможет в
планировании отчетов.

Имеют ли руководители представление об эффекте от инвестиций в ИТ-сферу в
данный момент? Это поможет составить различные отчеты, демонстрирующие услуги,
предоставляемые руководителям организации за пределами бизнес-приложений.
ИТ-требования
ИТ-требования лягут в основу топологии Operations Manager и его несущей
инфраструктуры. ИТ-требования формируются под действием двух главных факторов —
целевых показателей оптимизации и ИТ-среды, в которой будет работать Operations
Manager. Эти требования собираются у спонсоров, влиятельных представителей компании
и потребителей данных Operations Manager. Обсуждение следует вести в форме
свободных, неограниченных вопросов. Сначала спросите, как Operations Manager будет
21
применяться в среде, и для каких задач следует оптимизировать систему. Обязательно
получите ответы на следующие вопросы.
Целевые показатели оптимизации
Целевые показатели оптимизации — это проектные характеристики системы Operations
Manager. Примером могут служить следующие формулировки.

Доступность и возможность восстановления. Необходимо поддерживать доступность
Operations Manager с минимальным временем простоя. Эти требования помогают в
планировании высокого уровня доступности и средств резервного копирования и
восстановления.

Стоимость. Внедрение Operations Manager необходимо провести самым экономичным
образом. Представление о бюджетных ограничениях и умение действовать в их рамках
исключительно важно для успеха проекта.

Производительность. Например, Operations Manager должен передавать данные из
среды не позднее чем через 1 минуту, а доступ к консоли должен предоставляться не
позднее чем через 10 секунд после ее запуска. Представление этих требований
поможет в планировании оборудования.

Область действия. Operations Manager должен предоставлять единое представление
всей среды. Представление этих требований помогает спланировать количество
необходимых групп управления, а также связи между группами.

Администрирование. Администрирование Operations Manager должно быть доступно
только для определенных групп пользователей. Представление этих требований
поможет в планирование групп безопасности, ролей, системы доступа и возможно,
повлияет на количество реализуемых групп управления.

Расположение точек доступа. Данные Operations Manager должны быть доступны
только из интрасети компании или также внешним образом. Представление этих
требований поможет в планировании размещения консолей управления и вебконсолей.

Интеграция. Необходимо интегрировать Operations Manager в существующую систему
отслеживания технических проблем или другой корпоративный продукт для
наблюдения. Представление этих требования поможет спланировать размещение
Operations Manager и его компонентов в среде и функции, которые он будет выполнять.
Это также помогает определить, потребуются ли соединители сторонних
разработчиков или соединители собственной разработки.
Инвентаризация текущей среды
Точная и полная инвентаризация текущей среды дает двойное преимущество. Во-первых,
она сообщает, за какими объектами будет наблюдать Operations Manager, а во-вторых,
позволяет определить ограничения, в рамках которых будет работать Operations Manager.
Обязательно получите ответы на следующие вопросы.

Масштаб. Приблизительное количество устройств для отслеживания.
22

Необходимые пакеты управления. Приложения для отслеживания.

Типы устройств, поддерживающих приложения. В этот список входят компьютеры
Windows, сетевые устройства и компьютеры на базе UNIX или Linux.

Топология. Физическое и сетевое расположение отслеживаемых устройств.

Топология и распределение консолей. Физическое и сетевое расположение
операторов, использующих данные Operations Manager.

Необходимость использования сертификатов и сервера шлюза. Границы доверия
Active Directory в среде.

Имеющиеся продукты для управления и поддержки клиентов. Все прочие продукты,
применяемые для отслеживания, передачи предупреждений и составления отчетов.

Топология и планирование шлюзов. Брандмауэры и каналы глобальной сети,
определяющие границы сети.

Топология и планирование ролей. Границы ИТ-администрирования для отслеживаемых
устройств и приложений.

Топология и локализация. Языковые и геополитические ограничения, действующие в
среде.
Инвентаризация текущих процедур
Во всех средах так или иначе выполняются операции наблюдения и управления. Для этого
применяются различные методы и технологии разного уровня сложности и полноты.
Согласно модели оптимизации инфраструктуры все среды можно разделить на четыре
категории: базовые, стандартизированные, рационализированные и динамичные. См.
страницу http://go.microsoft.com/fwlink/?LinkId=92863 и статью Оценка оптимизации
инфраструктуры В этих источниках приводятся дополнительные сведения об этих четырех
категориях и средстве оценки, позволяющем получить представление о среде и процессах.
Для планирования использования возможностей Operations Manager 2007 необходимо
получить представление о процедурах, применяемых для управления средой в настоящее
время. Это поможет спланировать порядок обработки предупреждений и определить круг
пользователей, отвечающих за обработку предупреждений. Кроме того, это поможет
спланировать отправку уведомлений и определить круг пользователей, получающих
уведомления, а также спланировать порядок администрирования групп управления и
обеспечить защиту данных.
Далее перечислены основные вопросы, которые надо задать на этом этапе.

Как выполняется наблюдение в организации сейчас?

Как обрабатывается информация, предоставляемая процессом или системой
наблюдения?
Также получите ответы на следующие вопросы.

Кто обычно отвечает за устранение неполадок и обработку предупреждений,
создаваемых автоматизированными системами или службой технической поддержки?
23
Это поможет определить, кому необходим непосредственный доступ к консоли
управления, и какие данные должны выводиться на консоль.

Рассматривает ли служба поддержки проблемы с серверами, или они обычно
передаются в группу поддержки серверов?

Работает ли в компании сетевой операционный центр с операторами или другая
система наблюдения, управляемая операторами? В случае положительного ответа —
сколько людей там занято и сколько консолей постоянно используются? Это поможет
определить места размещения групп управления, чтобы они смогли получать
достаточную поддержку.

Где будут развертываться агенты (помимо информационных центров)? Сколько
понадобится таких точек и где они находятся в сети?

Какова статистика по доступной пропускной способности для передачи данных между
узлами, где находятся управляемые устройства. и узлами, где находятся серверы
управления?

Как выполняется регистрация событий безопасности?

Как выполняется наблюдение за рабочими станциями и клиентскими приложениями?

Отслеживание компьютеров и сетевых устройств на базе UNIX и Linux
Составление требований к проекту Operations
Manager 2007
Реализация проекта в соответствии с требованиями
В предыдущем разделе были выполнены следующие три задачи.

Сбор бизнес-требований, которые учитываются в планировании реализуемых функций
Operations Manager.

Сбор ИТ-требований, которые учитываются в планировании топологии групп
управления.

Анализ текущих средств отслеживания, применяемых в компании, с целью
планирования настройки Operations Manager.
В этом разделе рассматриваются действия, которые позволяют реализовать в проекте
собранные данные и знания. Для этого применяются рекомендации по выбору размера и
планированию емкости для ролей и компонентов сервера.
Проектирование групп управления
В любую конфигурацию Operations Manager 2007 входит по крайней мере одна группа
управления, и в некоторых случаях этого вполне достаточно, с учетом возможностей
масштабирования Operations Manager 2007. В зависимости от задач компании
24
дополнительные группы управления могут понадобиться на этапе реализации или
добавляться в дальнейшем. Процесс распределения служб Operations Manager по группам
управления называется секционированием.
В этом разделе рассматриваются общие условия, которые определяют необходимость
использования нескольких групп управления. Планирование состава отдельных групп
управления, в частности определение размера серверов и распределение ролей
Operations Manager по серверам в группе управления, рассматривается в разделе "Состав
групп управления".
Одна группа управления
Для планирования групп управления Operations Manager применяется такой же подход, как
и к планированию доменов Active Directory: начните работу с одной группой и добавляйте
их по мере необходимости. Рекомендуемые ограничения масштабируемости группы
управления Operations Manager 2007 R2:

3 000 агентов, передающих данные на сервер управления;

большинство требований в отношении масштабируемости, резервирования и
возможности аварийного восстановления можно выполнить в группе управления с
числом серверов управления от трех до пяти;

50 консолей управления, открытых одновременно;

1 500 агентов, передающих данные на сервер шлюза;

25 000 компьютеров отслеживания ошибок приложений (AEM), передающих данные на
сервер управления;

100 000 компьютеров AEM, передающих данные в группу управления;

2500 агентов коллективного наблюдения, передающих данные на сервер управления;

10000 агентов коллективного наблюдения, передающих в группу управления;

6 000 агентов (общее число) и компьютеров UNIX или Linux с 50 открытыми консолями

10 000 агентов (общее число) и компьютеров UNIX или Linux с 25 открытыми консолями

500 отслеживаемых компьютеров UNIX или Linux на выделенный сервер управления.

100 отслеживаемых компьютеров UNIX или Linux на выделенный сервер шлюза.

3 000 отслеживаемых URL-адресов на выделенный сервер управления.

12 000 отслеживаемых URL-адресов на выделенную группу управления.
Щелкните эту ссылку, чтобы посмотреть рекомендуемые ограничения для Operations
Manager 2007 SP1.
Рассматривая эти предельные значения в сочетании с функциями безопасностями,
доступными за счет применения ролей Operations Manager для управления доступом к
данным в консоли управления, можно заключить, что одной группы управления с учетом ее
широких возможностей масштабирования будет достаточно во многих ситуациях.
25
Несколько групп управления и секционирование
Несмотря на широкие возможности масштабирования группы управления, в ряде ситуаций,
описанных ниже, необходимо использование нескольких групп.

Разделение функций рабочей и подготовительной среды. В работе с Operations
Manager рекомендуется развернуть рабочую среду, используемую для отслеживания
рабочих приложений, и подготовительную среду, которая оказывает минимальное
воздействие на рабочую среду. Подготовительная группа управления применяется для
тестирования и настройки функций пакетов управления перед миграцией в рабочую
среду. Кроме того, в некоторых компаниях используется промежуточная среда для
серверов, где новые серверы размещаются в период эксплуатационного тестирования,
а затем переводятся в рабочую среду. Подготовительную группу управления можно
использовать для отслеживания промежуточной среды, чтобы обеспечить
работоспособность серверов перед развертыванием в рабочей среде.

Функции выделенных служб ACS. Если в рамках поставленных задач необходимо
собирать события журнала аудита Windows, будут реализованы службы ACS. Если
требования безопасности подразумевают управление и администрирование функций
ACS в особой административной группе, отдельной от администрирования остальной
рабочей среды, то может оказаться полезным реализовать группу управления,
занимающуюся исключительно поддержкой функций ACS.

Функции аварийного восстановления. В Operations Manager 2007 все операции с базой
данных OperationsManager записываются в журналы транзакций перед фиксацией в
базе данных. Эти журналы транзакций можно отправлять на другой сервер Microsoft
SQL Server 2005 с пакетом обновления 1 (SP1) и более поздней версии или Microsoft
SQL Server 2008 с пакетом обновления 1 (SP1) и фиксировать в копии базы данных
OperationsManager. Такой метод называется доставкой журналов. Целевая
(резервная) группа управления не обязательно должна быть целиком заполненной и
активной. Она может состоять только из корневого сервера управления и сервера SQL
Server 2005 с пакетом обновления 1 (SP1) и более поздней версии или SQL Server 2008
с пакетом обновления 1 (SP1). Когда необходимо выполнить отработку отказа, для
оставшихся серверов управления в исходной группе управления необходимо
изменение реестра и перезапуск для дальнейшей работы в качестве членов резервной
группы управления.

Увеличенная емкость. Operations Manager 2007 не имеет встроенных ограничений на
количество агентов, поддерживаемых одной группой управления. В зависимости от
используемого оборудования и нагрузки по отслеживанию (которая увеличивается по
мере развертывания дополнительных пакетов управления), приходящейся на группу
управления, для сохранения приемлемой производительности могут понадобиться
дополнительные группы управления.

Консолидация представлений. Если для отслеживания среды используется несколько
групп управления, необходим механизм, предоставляющий объединенное
представление данных наблюдения и данных о предупреждениях из всех групп. Для
этого можно развернуть дополнительную группу управления (которая может и не
26
выполнять собственных задач отслеживания), которая будет иметь доступ к данным во
всех остальных группах управления. В таком случае эти группы управления
называются подключенными. Группа управления, с помощью которой формируется
объединенное представление данных, называется локальной группой управления, а
остальные группы, передающие данные в локальную — подключенными группами
управления.

Установленные языки. Все сервера, где устанавливается роль сервера Operations
Manager, должны использовать одинаковый язык. Это значит, что нельзя установить
англоязычную версию Operations Manager 2007 на корневом сервере управления, а
затем развернуть консоль управления на японском языке. Если задачи наблюдения
необходимо выполнять на нескольких языках, понадобятся дополнительные группы
управления для каждого языка, доступного операторам.

Безопасность и администрирование. Секционирование групп управления для усиления
безопасности и упрощения администрирования весьма схоже с делегированием
административных полномочий подразделений или доменов Active Directory различным
административным группам. В компанию могут входить несколько ИТ-групп, каждая со
своей сферой ответственности. Ответственность отдельной группы может
распространяться на определенную территорию или бизнес-подразделение, например
дочернее подразделение в холдинге. Там, где применяется подобный вид полного
делегирования административных полномочий централизованной ИТ-группой, может
оказаться полезным реализовать структуры групп управления в каждом
подразделении. Их можно настроить в качестве подключенных групп управления для
локальной группы управления, которая располагается в информационном центре.
Анализ описанных случаев позволит получить ясное представление о необходимом
количестве групп управления в инфраструктуре Operations Manager. В следующем разделе
рассматривается распределение ролей сервера в группе управления и требования к
размеру таких систем.
Состав групп управления
На размещение серверных компонентов Operations Manager в группе управления
накладывается лишь небольшое число ограничений. Они могут устанавливаться на одном
сервере (за исключением роли сервера шлюза) или распределяться по нескольким
серверам в различных сочетаниях. Некоторые роли можно устанавливать в
отказоустойчивом сервере службы кластеров (ранее называвшейся MSCS) для
достижения высокого уровня доступности, и установить несколько серверов управления,
между которыми смогут переключаться агенты при отработке отказов. Следует выбрать
способ распределения серверных компонентов Operations Manager и типы используемых
серверов на основании ИТ-требований и задач по оптимизации.
Совместимость ролей сервера
Группа управления Operations Manager 2007 может выполнять большое количество
различных функций. Эти функции могут распределяться по отдельным серверам, и таким
27
образом каждому серверу назначается определенная роль. Не все функции и роли
серверов могут совмещаться. В следующей таблице приведены данные о совместимости и
зависимости ролей, а также указано, может ли роль устанавливаться в отказоустойчивом
кластере.
Роль сервера
Совместимость с
Требования
другими ролями
Может размещаться в
кворуме
отказоустойчивого
кластера
Рабочая база
данных
Да
SQL
Да
База данных служб
ACS
Да
SQL
Да
База хранилища
данных отчетов
Да
SQL
Да
База данных отчетов
Да
Выделенный
экземпляр служб
отчетов SQL Server,
не на контроллере
домена
Да
Корневой сервер
управления
Да
Не совместима с
ролью сервера
управления или
сервера шлюза
Да
Сервер управления
Да
Не совместима с
ролью корневого
сервера управления
Нет
Консоль
администратора
Да
Windows XP,
Windows Vista,
Windows Server 2003
и Windows
Server 2008
Н/Д
Сборщик ACS
Да
Может сочетаться с
ролью сервера
шлюза и базы
данных аудита
Нет
Сервер шлюза
Да
Может сочетаться
Нет
только со сборщиком
ACS, должна
28
Роль сервера
Совместимость с
Требования
другими ролями
Может размещаться в
кворуме
отказоустойчивого
кластера
входить в домен
Сервер веб-консоли
Да
Агент
Да
Н/Д
Автоматически
развертывается на
корневом сервере
управления и
сервере управления
в группе управления
Н/Д
Все приведенные здесь рекомендации основаны на следующих предположениях.

Показатели дисковой подсистемы рассчитаны для дисков, которые поддерживают 125
операций произвольного ввода-вывода в секунду на каждый диск. Многие диски
поддерживают более высокую интенсивность ввода-вывода, в результате чего
необходимое число дисков в конфигурации может быть меньше.

В группе управления, где в дополнение к корневому серверу управления развернуты
серверы управления, все агенты должны использовать в качестве основных и
вторичных серверов управления обычные серверы управления, а не корневые серверы
управления.

В рекомендациях по безагентному отслеживанию исключений предполагается, что в
среднем каждую неделю происходит два сбоя на компьютер, а средний размер CABфайла составляет 500 КБ.

В коллективное наблюдение за клиентами входят только готовые клиентские пакеты
управления, в том числе пакеты управления Windows Vista, Windows XP и компонент
информационных работников.

Между агентами и серверами обеспечивается связь на скорости 100 Мбит/с или выше.
Доступность
Задачу повышения доступности для баз данных корневого сервера управления, серверов
управления и серверов шлюза можно решить, реализовав резервирования в группе
управления.

База данных. Для всех баз данных, используемых в Operations Manager 2007,
необходима СУБД Microsoft SQL Server 2005 с пакетом обновления 1 (SP1) или более
поздней версии или Microsoft SQL Server 2008 с пакетом обновления 1 (SP1) или более
поздней версии, которая может устанавливаться в отказоустойчивой конфигурации
узла кворума MSCS.
29
Примечание
Дополнительные сведения о службах кластеров см. в справке Windows
Server 2003 и Windows Server 2008 в Интернете.

Корневой сервер управления. Служба доступа к данным System Center и служба
настройки управления System Center работают только на корневом сервере
управления, и они представляют собой единственную точку отказа в группе
управления. Учитывая важность роли корневого сервера управления, для обеспечения
высокого уровня доступности следует устанавливать корневой сервер управления в
собственном отказоустойчивом кластере из двух узлов. Полное описание
кластеризации корневого сервера управления см. в руководстве по развертыванию
Operations Manager 2007.

Серверы управления. В Operations Manager агенты из группы управления могут
передавать данные на любой сервер управления из этой группы. Поэтому доступность
нескольких серверов управления образует резервные каналы связи между агентами и
серверами. В таком случае рекомендуется развернуть кроме корневого еще один или
два сервера управления и использовать мастер назначения агентов и настройки их
переключения для назначения агентов серверам управления и исключения корневого
сервера управления из задач обработки агентов.

Серверы шлюза. Серверы шлюза служат средством связи между серверами
управления и агентами, которые лежат вне границы доверия Kerberos для серверов
управления. Агенты могут переключаться между серверами шлюза так же, как и между
серверами управления в случае, когда пропадает связь с основным сервером. Кроме
того, серверы шлюза можно настроить для резервного переключения между серверами
управления, чтобы реализовать полное резервирование маршрутов передачи данных
от агентов к серверам управления. Процедуры развертывании такой конфигурации см.
в руководстве по развертыванию Operations Manager 2007.
Стоимость
Чем сильнее распределены роли сервера в группе управления, тем больше ресурсов
понадобится для поддержки такой конфигурации. Сюда входит оборудование, среда,
лицензирование, затраты на эксплуатацию и обслуживание. Проектирование с
оптимизацией затрат приводит к варианту реализации с одним сервером или
минимальным распределением ролей, что в свою очередь снижает степень
резервирования и потенциально может понизить производительность.
Производительность
Если целью оптимизации является повышение производительность, сильнее
распределенная конфигурация с более современным оборудованием лучше выполняет
задачу. При этом стоимость будет расти соразмерно.
Распределение консоли и расположение точек доступа
Консоль управления обменивается данными непосредственно с корневым сервером
управления и с сервером отчетов (если установлен компонент для создания отчетов).
30
Планирование расположения корневого сервера управления и серверов баз данных
относительно консоли управления исключительно важно с точки зрения
производительности. Обязательно располагайте эти компоненты в сети максимально
близко друг к другу.
Рекомендуемое распределение компонентов и определение размеров
платформы
В таблицах ниже представлены рекомендации по распределению компонентов и подбору
размера платформы для Operations Manager 2007 R2. Щелкните эту ссылку, чтобы
посмотреть рекомендации по распределению компонентов и подбору размера платформы
для Operations Manager 2007 SP1. В этих таблицах сокращением БД обозначается сервер
базы данных SQL Server, ХД — хранилище данных, СО — сервер отчетов, КСУ — корневой
сервер управления, а СУ — сервер управления. Основы проектирования и планирования
служб ACS рассмотрены далее в этой статье.
Конфигурация с одним универсальным сервером
Число отслеживаемых устройств
Роли сервера и конфигурация
15–250 компьютеров Windows, 200
компьютеров UNIX или Linux
БД, ХД, СО, КСУ;
4-дисковый массив RAID 0+1, 8 ГБ ОЗУ,
четыре процессора
Небольшая конфигурация с несколькими серверами
Число отслеживаемых
Роли сервера и конфигурация Роли сервера и конфигурация
устройств
250–500 компьютеров
Windows, 500 компьютеров
UNIX или Linux
БД, ХД, СО;
КСУ;
4-дисковый массив
RAID 0+1, 4 ГБ ОЗУ, два
процессора
2-дисковый массив RAID 1,
4 ГБ ОЗУ, два процессора
Средняя конфигурация с несколькими серверами
Чтобы реализовать резервирование, можно развернуть несколько серверов управления,
каждый из которых обладает описанной минимальной конфигурацией. Чтобы обеспечить
высокий уровень доступности для серверов базы данных и корневых серверов управления,
их можно развернуть в кластере, где каждый узел обладает описанной минимальной
конфигурацией и подключением к внешнему общему диску для ресурсов кластера.
31
Число
Роль сервера и
Роль сервера и
Роль сервера и
Роль сервера и
отслеживаемых
конфигурация
конфигурация
конфигурация
конфигурация
БД;
СУ;
ХД, СО;
КСУ;
4-дисковый
массив
RAID 0+1, 4 ГБ
ОЗУ, два
процессора
2-дисковый
массив RAID 1,
4 ГБ ОЗУ, два
процессора
4-дисковый
массив
RAID 0+1 (для
данных), 2дисковый
массив RAID 1
(для журналов),
4 ГБ ОЗУ, два
процессора
2-дисковый
массив RAID 1,
8 ГБ ОЗУ, два
процессора
устройств
500–750
компьютеров
Windows, 500
компьютеров
UNIX или Linux
Крупная конфигурация с несколькими серверами
Чтобы реализовать резервирование, можно развернуть несколько серверов управления,
каждый из которых обладает описанной минимальной конфигурацией. Чтобы обеспечить
высокий уровень доступности для серверов базы данных и корневых серверов управления,
их можно развернуть в кластере, где каждый узел обладает описанной минимальной
конфигурацией и подключением к внешнему общему диску для ресурсов кластера.
Число
Роль
Роль сервера и
Роль
Роль
Роль
отслеживаем
сервера и
конфигурация
сервера и
сервера и
сервера и
ых устройств
конфигурац
конфигурац
конфигурац
конфигурац
ия
ия
ия
ия
750–1000
компьютеров
Windows,
UNIX или
Linux
БД;
ХД;
СО;
КСУ;
СУ;
8-дисковый
массив
RAID 0+1
(для
данных), 2дисковый
массив
RAID 1 (для
журналов),
8 ГБ ОЗУ,
два
процессора
4-дисковый массив
RAID 0+1 (для
данных), 2дисковый массив
RAID 1 (для
журналов), 8 ГБ
ОЗУ, два
процессора
Примечание. Для
удовлетворения
требований
хранилища данных
к дисковому
пространству
2-дисковый
массив
RAID 1,
4 ГБ ОЗУ,
два
процессора
2-дисковый
массив
RAID 1,
8 ГБ ОЗУ,
два
процессора
2-дисковый
массив
RAID 1,
4 ГБ ОЗУ,
четыре
процессора
32
Число
Роль
Роль сервера и
Роль
Роль
Роль
отслеживаем
сервера и
конфигурация
сервера и
сервера и
сервера и
ых устройств
конфигурац
конфигурац
конфигурац
конфигурац
ия
ия
ия
ия
можно
использовать
конфигурацию RAID
5 с аналогичной
производительност
ью.
Корпоративная конфигурация с несколькими серверами
Чтобы реализовать резервирование, можно развернуть несколько серверов управления,
каждый из которых обладает описанной минимальной конфигурацией. Чтобы обеспечить
высокий уровень доступности для серверов базы данных и корневых серверов управления,
их можно развернуть в кластере, где каждый узел обладает описанной минимальной
конфигурацией и подключением к внешнему общему диску для ресурсов кластера.
Число
Роль
Роль сервера и
Роль
Роль
Роль
отслеживаем
сервера и
конфигурация
сервера и
сервера и
сервера и
ых устройств
конфигурац
конфигурац
конфигурац
конфигурац
ия
ия
ия
ия
1 000–3 000
компьютеров
Windows, 500
компьютеров
UNIX или
Linux
БД;
ХД;
СО;
КСУ;
СУ;
8-дисковый
массив
RAID 0+1
(для
данных), 2дисковый
массив
RAID 1 (для
журналов),
8 ГБ ОЗУ,
два
процессора
8-дисковый массив
RAID 0+1 (для
данных), 2дисковый массив
RAID 1 (для
журналов), 8 ГБ
ОЗУ, два
процессора
2-дисковый
массив
RAID 1,
4 ГБ ОЗУ
4-дисковый
массив
RAID 0+1,
12 ГБ ОЗУ,
четыре 64разрядных
процессора
4-дисковый
массив
RAID 0+1,
8 ГБ ОЗУ,
четыре
процессора
3 000–6 000
компьютеров
Windows,
UNIX или
Linux
БД;
ХД;
СО;
КСУ;
СУ;
14дисковый
массив
RAID 0+1
14-дисковый
массив RAID 0+1
(для данных), 2дисковый массив
2-дисковый
массив
RAID 1,
4 ГБ ОЗУ,
4-дисковый
массив
RAID 0+1,
16 ГБ ОЗУ,
2-дисковый
массив
RAID 0+1,
8 ГБ ОЗУ,
четыре
процессора
33
Число
Роль
Роль сервера и
Роль
Роль
Роль
отслеживаем
сервера и
конфигурация
сервера и
сервера и
сервера и
ых устройств
конфигурац
конфигурац
конфигурац
конфигурац
ия
ия
ия
ия
четыре
процессора
четыре
процессора
(для
данных), 2дисковый
массив
RAID 1 (для
журналов),
8 ГБ ОЗУ,
четыре
процессора
RAID 1 (для
четыре
журналов), 12 ГБ
процессора
ОЗУ, четыре
двухъядерных
процессора Для
удовлетворения
требований
хранилища данных
к дисковому
пространству
можно
использовать
конфигурацию RAID
5 с аналогичной
производительност
ью.
Рекомендации по компонентам
В дополнение к данным рекомендациям по выбору размера учтите дополнительные
советы по планированию каждого из серверных компонентов Operations Manager.
Рекомендации по корневому серверу управления
В корневом сервере управления самыми важными ресурсами являются объем ОЗУ и
производительность процессора, поскольку многие операции, выполняемые корневым
сервером, требуют много памяти и значительно замедляются в случае интенсивного
использования файла подкачки. Нагрузка на корневой сервер управления определяется
следующими факторами.

Количество агентов в группе управления. Поскольку корневой сервер управления
должен рассчитывать конфигурацию для всех агентов в группе управления, то
увеличение количества агентов влечет увеличение требуемого объема памяти на
корневом сервере управления, независимо от объема рабочих данных, отправляемых
агентами.

Интенсивность изменения пространства экземпляров. Пространство экземпляров —
это данные, которые хранятся в Operations Manager для описания всех отслеживаемых
компьютеров, служб и приложений в группе управления. Если эти данные изменяются
часто, корневому серверу управления требуются дополнительные ресурсы для расчета
обновлений конфигурации для агентов, затронутых изменением. Интенсивность
34
изменения пространства экземпляров возрастает в результате импорта
дополнительных пакетов управления в группу управления. Добавление новых агентов в
группу управления также временно увеличивает интенсивность изменения
пространства экземпляров.

Количество одновременно работающих консолей управления и других клиентов SDK. К
другим клиентам SDK относится веб-консоль и многие средства сторонних
разработчиков, подключаемых к Operations Manager. Поскольку служба SDK
размещается на корневом сервере управления, каждое дополнительное подключение
расходует ресурсы памяти и процессора.
Далее представлены рекомендации по определению размера корневого сервера
управления.

Используйте 64-разрядное оборудование и операционные системы. 64-разрядное
оборудование позволяет легко расширять память за пределами 4 ГБ. Даже если
текущая конфигурация не требует памяти сверх 4 ГБ, применение 64-разрядного
оборудования обеспечивает запас для роста в случае увеличения требований в
будущем.

Сократите число агентов, передающих данные на корневой сервер управления, или
полностью исключите такое применение агентов. В группах управления с небольшим
числом агентов прямая передача данных от агентов обычно не вызывает проблем и
позволяет снизить общую стоимость оборудования, необходимого для работы
системы. Однако по мере увеличения числа агентов рекомендуется ограничить прямую
передачу данных от агентов на корневой сервер управления. Перенос рабочей
нагрузки агентов на другие серверы управления снижает требования к оборудованию
для корневого сервера управления и обычно приводит к повышению
производительности и надежности группы управления.

Подключение к базе данных OperationsManager и хранилищу данных с высокой
пропускной способностью. Корневой сервер управления часто обращается к базе
данных Operations Manager и хранилищу данных. Обычно такие подключения SQL
требуют повышенную пропускную способность и сильнее страдают от задержек в сети
по сравнению с соединениями между агентами и корневым сервером управления.
Поэтому обычно следует размещать корневой сервер управления, базу данных
OperationsManager и хранилище данных в одной локальной сети.
Рекомендации по базе данных Operations Manager
Как и в случае с другими базами данных, производительность базы данных Operations
Manager сильнее всего зависит от производительности дисковой подсистемы. Поскольку
все данные Operations Manager должны проходить через базу данных OperationsManager,
то чем быстрее работает диск, тем выше производительность. На производительность
также влияют показатели процессора и памяти. Нагрузка на базу данных
OperationsManager определяется следующими факторами.

Интенсивность сбора данных. Корневой сервер управления часто обращается к базе
данных Operations Manager и хранилищу данных. Обычно такие подключения SQL
35
требуют повышенную пропускную способность и сильнее страдают от задержек в сети
по сравнению с соединениями между агентами и корневым сервером управления.
Поэтому обычно следует размещать корневой сервер управления, базу данных
OperationsManager и хранилище данных в одной локальной сети.

Интенсивность изменения пространства экземпляров. Пространство экземпляров —
это данные, которые хранятся в Operations Manager для описания всех отслеживаемых
компьютеров, служб и приложений в группе управления. Обновление этих данных в
базе данных OperationsManager требует больше ресурсов, чем запись новых данных в
базу. Кроме того, когда данные в пространстве экземпляров изменяются, корневой
сервер управления выполняет дополнительные запросы к базе данных Operations
Manager, чтобы рассчитать изменения конфигурации и группы. Интенсивность
изменения пространства экземпляров возрастает в результате импорта
дополнительных пакетов управления в группу управления. Добавление новых агентов в
группу управления также временно увеличивает интенсивность изменения
пространства экземпляров.

Одновременно работающие консоли управления и другие клиенты SDK. Каждый
открытый экземпляр консоли управления считывает данные из базы данных
OperationsManager. Запрос этих данных может вызвать сильную нагрузку на диск,
процессор и память. Максимальную нагрузку на базу данных обычно создают консоли,
где выводится большой объем операционных данных в представлении "События",
представлении "Состояния", представлении "Предупреждения" и представлении
данных производительности. Чтобы обеспечить максимальную масштабируемость,
рекомендуется ограничить объем данных, выводимых в представлениях, и отображать
только необходимые данные.
Далее представлены рекомендации по определению размера для сервера базы данных
OperationsManager.

Выберите подходящую дисковую подсистему. Дисковая подсистема для базы данных
OperationsManager является самым важным компонентом с точки зрения общей
масштабируемости и производительности групп управления. Дисковый массив для
базы данных обычно имеет конфигурацию RAID 0+1 с необходимым числом дисков.
Конфигурация RAID 5, как правило, оказывается неудачным выбором для этого
компонента, поскольку она оптимизирует место в хранилище за счет
производительности. Поскольку в выборе дисковой подсистемы для базы данных
OperationsManager основным фактором является не емкость хранилища, а
производительность, то лучше подойдет конфигурация RAID 0+1. Если пропускная
способность одного диска покрывает потребности с учетом масштабирования,
подходящим выбором часто оказывается конфигурация RAID 1, обеспечивающая
отказоустойчивость без снижения производительности.

Размещение файлов данных и журналов транзакций. При менее масштабном
развертывании самым экономичным решением часто оказывается объединение
файлов данных и журналов транзакций SQL Server на одном физическом томе,
поскольку с журналом транзакций выполняется лишь небольшое число операций.
36
Однако с увеличением числа агентов будет разумно разместить файл данных и журнал
транзакций SQL Server на отдельных физических томах. Это позволит более
эффективно выполнять операции чтения и записи на томе журнала транзакций,
поскольку рабочая нагрузка будет по-прежнему состоять в основном из операций
последовательной записи. Один двухдисковый том RAID 1 может обрабатывать очень
большой объем операций последовательной записи, и этого достаточно практически во
всех случаях развертывания, даже весьма крупномасштабного.

Используйте 64-разрядное оборудование и операционные системы. Часто
производительность базы данных OperationsManager возрастает от увеличения объема
ОЗУ, и наращивание памяти может послужить экономичным способом снижения
интенсивности дисковых операций на сервере. Применение 64-разрядного
оборудования позволяет легко расширять память за пределами 4 ГБ. Даже если
текущая конфигурация не требует памяти сверх 4 ГБ, применение 64-разрядного
оборудования обеспечивает запас для роста в случае увеличения требований в
будущем.

Используйте контроллер диска, поддерживающий кэширование записи, с резервным
питанием от батарей. Тесты показали, что для рабочей нагрузки на базу данных
OperationsManager оптимально применение кэширования записи в контроллерах
дисков. При распределении кэша контроллеров диска между кэшированием чтения и
кэшированием записи рекомендуется отвести 100% кэша на кэширование записи. При
использовании контроллеров дисков с кэшированием записи в любой системе
управления базой данных важно обеспечить резервное питание от батарей, чтобы
исключить потерю данных в случае перебоев питания.
Рекомендации по хранилищу данных
В Operations Manager 2007 данные записываются в хранилище в режиме, приближенном к
реальному времени. Поэтому нагрузка на хранилище данных аналогична нагрузке на
компьютер с базой данных OperationsManager. Поскольку хранилище управляется SQL
Server, дисковая подсистема сильнее всего влияет на общую производительность. Другими
важными факторами являются объем памяти и ресурсы процессора. Службы отчетов
Operations Manager также создают нагрузку на сервер хранилища данных. Эта нагрузка
имеет несколько иную структуру. Нагрузка на хранилище данных определяется
следующими факторами.

Интенсивность вставки данных. Чтобы повысить эффективность работы с отчетами,
хранилище данных выполняет статистическую обработку данных и сохраняет ее
результаты вместе с ограниченным объемом необработанных данных. Выполнение
дополнительной работы означает, что сбор операционных данных в хранилище данных
может расходовать несколько больше ресурсов по сравнению с базой данных
OperationsManager. Эти дополнительные затраты обычно уравновешиваются
снижением затрат на обработку данных обнаружения в хранилище данных по
сравнению с обработкой в базе данных OperationsManager.

Число пользователей, одновременно работающих с отчетами. Поскольку часто в
отчетах составляются сводки по данным большого объема, каждый пользователь
37
работающий с отчетом, может создавать значительную нагрузку на систему. На общую
требуемую емкость влияют и количество одновременно выполняемых отчетов, и их
тип. Обычно отчеты, запрашивающие крупные диапазоны данных или большое
количество объектов, расходуют больше системных ресурсов.
Далее представлены рекомендации по определению размера для сервера хранилища
данных.

Выбор подходящей дисковой подсистемы. Поскольку хранилище данных стало
неотъемлемой частью потока данных в группе управления, очень важно выбрать
подходящую дисковую подсистему для хранилища данных. Как и в случае с базой
данных OperationsManager, самым лучшим выбором часто оказывается массив
RAID 0+1. Обычно для хранилища данных следует использовать такую же дисковую
подсистему, как и для базы данных OperationsManager.

Размещение файлов данных и журналов транзакций. Как и в случае с базой данных
OperationsManager, разделение данных и журналов транзакций SQL Server часто
оказывается правильным выбором при наращивании числа агентов. Если база данных
OperationsManager и хранилище данных находятся на одном физическом компьютере,
и нужно разделить данные и журналы транзакций, необходимо поместить журналы
транзакций для базы данных OperationsManager на собственном физическом томе,
отдельно от хранилища данных. В противном случае увеличение производительности
не будет заметно. Файлы данных для базы данных OperationsManager и хранилища
данных могут находиться на одном физическом томе при условии, что он обладает
достаточным размером.

Используйте 64-разрядное оборудование и операционные системы. Часто
производительность хранилища данных возрастает от увеличения объема ОЗУ, и
наращивание памяти может послужить экономичным способом снижения
интенсивности дисковых операций на сервере. Применение 64-разрядного
оборудования позволяет легко расширять память за пределами 4 ГБ. Даже если
текущая конфигурация не требует памяти сверх 4 ГБ, применение 64-разрядного
оборудования обеспечивает запас для роста в случае увеличения требований в
будущем.

Используйте выделенное серверное оборудование для хранилища данных. В
мелкомасштабном развертывании часто можно объединять базу данных
OperationsManager и хранилище данных на одном физическом компьютере, однако с
ростом числа агентов и увеличением объема поступающих операционных данных
разумно разделить базу и хранилище. Разделение хранилища данных и серверов
отчетов также позволит повысить производительность отчетов.

Используйте контроллер диска, поддерживающий кэширование записи, с резервным
питанием от батарей. Тесты показали, что для рабочей нагрузки на хранилище данных
оптимально применение кэширования записи в контроллерах дисков. При
распределении кэша контроллеров диска между кэшированием чтения и кэшированием
записи рекомендуется отвести 100% кэша на кэширование записи. При использовании
контроллеров дисков с кэшированием записи в любой системе управления базой
38
данных важно обеспечить резервное питание от батарей, чтобы исключить потерю
данных в случае перебоев питания.
Рекомендации по серверу управления
Самая большая часть нагрузки на сервер управления создается сбором операционных
данных и вставкой этих данных в базу данных OperationsManager и хранилище данных.
Важно заметить, что серверы управления выполняют эти операции непосредственно, без
участия корневого сервера управления. Большинство операций по упорядочиванию
данных выполняется в памяти серверов управления, не используя медленные диски, что
позволяет повысить производительность. Самым важным ресурсом для серверов
управления является процессор, однако тестирование показало, что как правило, для
серверов управления не нужно самое современное оборудование. Нагрузка на сервер
управления определяется следующими факторами.

Интенсивность сбора операционных данных. Поскольку сервер управления в основном
занимается сбором операционных данных, этот показатель имеет самое большое
влияние на общую загрузку сервера. Однако тестирование показало, что серверы
управления обычно могут поддерживать интенсивную обработку операционных
данных, сохраняя низкий и средний уровень загрузки. Главным фактором, влияющим
на интенсивность сбора операционных данных, является набор пакетов управления,
развернутых в группе управления.
Далее представлены рекомендации по определению размера для сервера управления.

Не устанавливайте на сервере управления оборудование избыточной мощности. В
большинстве случаев для работы, выполняемой сервером управления, достаточно
стандартного сервера общего назначения. В большинстве случаев для обработки
рабочей нагрузки должно быть достаточно рекомендаций по оборудованию,
приведенных в этом документе.

Сохраняйте соотношение числа агентов и серверов управления примерно 3,000 к 1.
Фактическая производительность сервера будет различаться в зависимости от объема
собираемых операционных данных, однако тестирования показалось, что каждый
сервер управления свободно поддерживает 2000 агентов с относительно высоким
объемом поступающих операционных данных. Соотношение 2000 агентов на сервер
управления служит рекомендацией, основанной на результатах тестирования, и не
является безусловным ограничением. В конкретной среде может оказаться, что сервер
управления успешно поддерживает большее или меньшее число агентов.

Чтобы повысить соотношение между компьютерами UNIX или Linux и серверами
управления (500:1), используйте выделенные серверы управления для
кроссплатформенного наблюдения.

Используйте минимальное количество серверов управления в группе управления в
целях резервирования. Главной причиной развертывания нескольких серверов
управления должно быть не масштабирование, а обеспечение резервирования и
возможности аварийного восстановления. Тестирование показало, что в большинстве
систем для этого достаточно от трех до пяти серверов управления.
39
Рекомендации по серверу шлюза
Серверы шлюза поддерживают связь между серверами управления и агентами,
расположенными по разные стороны границ доверия Kerberos. На сервере шлюза
применяется проверка подлинности на основе сертификатов для взаимной проверки с
сервером управления. Для этого используется одно соединение, а не несколько, как
необходимо для проверки подлинности между агентами и серверами управления. Это
упрощает управление проверкой подлинности на основе сертификатов для недоверенных
доменов. Нагрузка на сервер шлюза определяется следующими факторами.

Интенсивность сбора операционных данных. Главным фактором, определяющим
нагрузку на шлюз, является интенсивность сбора операционных данных. Этот
показатель зависит от количества агентов, передающих данные в шлюз, и от пакетов
управления, развернутых в группе управления.
Далее представлены рекомендации по определению размера для сервера шлюза.

Серверы шлюза удобны для контроля использования пропускной способности. С точки
зрения производительности шлюзы можно рекомендовать как средство оптимизации
использования пропускной способности в средах с низкой пропускной способностью,
поскольку они выполняют сжатие всех данных, передаваемых на сервер управления.

Поддерживайте соотношение агентов и серверов шлюза примерно 1,500 к 1.
Тестирование показало, что использование более 1000 агентов на шлюз может
негативно сказаться на возможности восстановления в случае продолжительного
(многочасового) отключения питания, в результате которого невозможна связь между
шлюзом и сервером управления. Если для передачи данных в шлюз нужны
дополнительные агенты, рекомендуется использовать несколько серверов шлюза.
Если на шлюз должно приходиться более 1,500 агентов, настоятельно рекомендуется
провести тестирование системы, чтобы проверить возможность быстрой разгрузки
очереди в шлюзе после продолжительной недоступности связи между шлюзом и
сервером управления, если в среде важным показателем является время
восстановления шлюза.

Используйте выделенный сервер управления в случае большого числа шлюзов и
подключенных к ним агентов. Подключение всех шлюзов к одному серверу управления,
к которому не подключаются никакие другие агенты, может ускорить восстановление в
случае продолжительного отсутствия связи.
Рекомендации по отслеживанию ошибок приложений
Сервер управления, применяемый для отслеживания ошибок приложений, получает
данные от клиента, создавшего отчет обо ошибках, и сохраняет его в общей папке. Если
это локальная общая папка, то процесс сохранения расходует ресурсы сервера
управления.
Далее представлены рекомендации по планированию отслеживания ошибок в
приложениях.

Для хранения файлов из общей папки может применяться локальный диск, устройство
хранения данных, подключаемое к сети (NAS) или сеть хранения данных SAN.
40

Диск, используемый для отслеживания ошибок приложений, должен быть отделен от
диска, где находится хранилище данных или база данных OperationsManager.

Если хранилище организовано распределенной файловой системе (DFS), то следует
отключить репликацию DFS.

Сервер шлюза не должен использоваться в качестве сборщика для отслеживания
ошибок приложений.
Число отслеживаемых устройств
Сервер управления для общей папки
отслеживания ошибок в приложениях
От 0 до 10000
2-дисковый массив RAID 1 емкостью 200 ГБ,
4 ГБ ОЗУ, два процессора
От 10000 до 25000
2-дисковый массив RAID 1 емкостью 500 ГБ,
8 ГБ ОЗУ, четыре процессора
Рекомендации по коллективному наблюдению за клиентами
Коллективное отслеживание работоспособности выполняется путем сбора данных о
событиях и производительности с большого количества компьютеров и объединения
данных по группам систем для составления отчетов и анализа. Например, собираются
данные о производительности памяти с отдельных клиентов Windows XP и Windows Vista,
работающих на оборудовании различного типа. В процессе коллективного отслеживания
работоспособности эти данные объединяются и составляются отчеты о
производительности памяти в отдельных группах систем, например с общей операционной
системой или с общим поставщиком оборудования. Это упрощает анализ общей
производительности по сравнению с поиском нужной информации в обширных списках
отчетов по производительности отдельных систем. Режим коллективного отслеживания
также позволяет передавать предупреждения и выполнять задачи наблюдения на
коллективном уровне, а не на уровне отдельных систем.
Коллективное наблюдение за клиентами поддерживается следующими пакетами
управления: пакет информационных работников, пакет клиентов Windows, Windows XP,
Windows Vista, протокол сетевых адресов и другие пакеты, предназначенные для работы с
клиентами.
Каждый клиент, отслеживаемый агентом, обычно периодически создает сводные события,
которые используются для расчета коллективного показателя работоспособности для
группы клиентов. Создание предупреждений для отдельных агентов отключено, и поэтому
агенты, работающие на клиентах, не будут создавать данные предупреждений.
В зависимости от количества развернутых пакетов управления и трафика агентов, каждый
сервер управления может управлять тремя-четырьмя тысячами клиентов, на которых
работают агенты.
41
Во время планирования развертывания клиентов коллективного отслеживания необходимо
утверждать агенты пакетами, не более 1000 агентов единовременно, чтобы обеспечить
возможность синхронизации агентов с самой последней конфигурацией.
В следующей таблице сокращением ХД обозначается хранилище данных, БД — база
данных OperationsManager, КСУ — корневой сервер управления, а ОПСУ2 — компьютер с
общей папкой на втором сервере управления.
Рекомендации для небольшой конфигурации.
Число отслеживаемых устройств
Роль сервера и конфигурация
От 0 до 2500
ХД, БД, ОПСУ2, КСУ;
2-дисковый массив RAID 1 емкостью 30 ГБ,
4 ГБ ОЗУ
Рекомендации для средней конфигурации.
Число отслеживаемых
Роль сервера и конфигурация Роль сервера и конфигурация
устройств
От 2500 до 5000
ХД, БД;
ОПСУ2, КСУ;
2-дисковый массив RAID 1
емкостью 50 ГБ, 4 ГБ ОЗУ
2-дисковый массив RAID 1,
4 ГБ ОЗУ
Рекомендации для крупной конфигурации.
Число отслеживаемых
Роль сервера и
Роль сервера и
Роль сервера и
устройств
конфигурация
конфигурация
конфигурация
От 5000 до 7500
ХД, БД;
ОПСУ2;
КСУ;
2-дисковый массив
2-дисковый массив
RAID 1 емкостью 100 RAID 1,
ГБ, 4 ГБ ОЗУ
4 ГБ ОЗУ
2-дисковый массив
RAID 1,
4 ГБ ОЗУ
Рекомендации для корпоративной конфигурации.
Число
Роль сервера и
Роль сервера и
Роль сервера и
Роль сервера и
отслеживаемых
конфигурация
конфигурация
конфигурация
конфигурация
ХД;
БД;
ОПСУ2;
КСУ;
2-дисковый
массив RAID 1
2-дисковый
массив RAID 1
2-дисковый
массив RAID 1,
2-дисковый
массив RAID 1,
устройств
От 7500 до 10000
42
Число
Роль сервера и
Роль сервера и
Роль сервера и
Роль сервера и
отслеживаемых
конфигурация
конфигурация
конфигурация
конфигурация
емкостью 300
ГБ, 4 ГБ ОЗУ
емкостью 300
ГБ, 4 ГБ ОЗУ
4 ГБ ОЗУ
4 ГБ ОЗУ
устройств
Проектирование служб ACS
В этом разделе приводятся общие рекомендации, позволяющие приступить к
планированию развертывания ACS.
Службы ACS не являются изолированным решением и могут размещаться только в
существующей группе управления, поскольку агент служб интегрируется с агентом
Operations Manager и устанавливается вместе с ним, а сборщик ACS может
устанавливаться только на сервере управления или сервере шлюза. Остальные
компоненты (база данных ACS модуль отчетов ACS) могут устанавливаться в одном
экземпляре SQL Server 2005 с другими компонентами базы данных Operations Manager и
компонентами создания отчетов. Однако по соображениям производительности, емкости и
безопасности разумно устанавливать такие компоненты на выделенном оборудовании.
Проектные решения
В ходе планирования развертывания ACS принимаются четыре фундаментальных
проектных решения. В процессе принятия этих решений учитывайте, что сервер сборщика
ACS и база данных ACS связаны по схеме "один к одному". В каждый момент времени
только один сборщик ACS может передавать данные в базу данных ACS, и для каждого
сборщика ACS требуется отдельная база данных ACS. В группе управления возможно
наличие нескольких пар "сборщик-база данных" ACS, однако отсутствуют готовые
процедуры для интеграция данных из нескольких баз данных ACS в единую базу данных.
Вначале надо решить, будет ли развертываться группа управления, применяемая
исключительно для поддержки служб ACS, или службы ACS будут развертываться в группе
управления, которая также выполняет функции отслеживания работоспособности и
передачи предупреждений. Далее представлены характеристики этих двух сценариев
развертывания ACS.

Службы ACS размещаются в рабочей группе управления.

Масштабируемое использование служб ACS. С учетом того, что службы ACS
собирают все события безопасности, происходящие в системах, где работают
серверы пересылки ACS, применение ACS может привести к созданию очень
большого объема данных. Если для ролей сборщика ACS и базы данных ACS не
применяется выделенное оборудование, обработка этих данных может
отрицательно сказаться на производительности группы управления, где
размещаются роли, особенно на уровне базы данных.
43


Не требуется отдельное администрирование и обеспечение безопасности.
Поскольку службы ACS размещаются в группе управления, то пользователи,
выполняющие администрирование группы управления, получают права
администратора в службах ACS. Если задачи бизнеса, аудита, нормативные
требования и ИТ-требования предусматривают размещение служб ACS вне
рабочей ИТ-среды, развертывание служб ACS в рабочей группе управления
невозможно.
Службы ACS размещаются в выделенной группе управления.

Необходимо отдельное администрирование и обеспечение безопасности. Если
имеется отдельная группа администрирования, отвечающая в компании за
управление аудитом и безопасностью, то рекомендуется размещать службы ACS в
выделенной группе управления, администрирование который выполняется группой
аудита и безопасности.
Затем необходимо решить, будет ли модуль отчетов ACS развертывается в одном
экземпляре служб отчетов SQL Server 2005 с компонентом создания отчетов Operations
Manager 2007. Далее представлены характеристики этих двух сценариев.

Модуль отчетов ACS интегрируется с компонентом создания отчетов Operations
Manager.

Общая консоль для всех отчетов. Если модуль отчетов ACS устанавливается
вместе с компонентом создания отчетов Operations Manager, доступ к отчетам ACS
выполняется через консоль управления Operations Manager.

Общая модель безопасности. Если компонент создания отчетов Operations
Manager 2007 устанавливается в службах отчетов SQL Server 2005, он
перезаписывает модель безопасности по умолчанию, заменяя ее ролевой моделью
безопасности Operations Manager. Модуль отчетов ACS совместим с этой моделью.
Все пользователи, которым назначена роль оператора отчетов, получают доступ к
отчетам ACS при условии, что они имеют необходимые разрешения в базе данных
ACS.
Примечание
Если в дальнейшем компонент создания отчетов Operations Manager
удаляется, необходимо вручную восстановить модель безопасности служб
отчетов SQL Server с помощью программы ResetSRS.exe, находящейся на
установочном носителе в каталоге SupportTools.

Модуль отчетов ACS устанавливается в выделенном экземпляре служб отчетов SQL
Server.

Отдельная консоль для отчетов служб ACS и Operations Manager. В случае
установки в отдельном экземпляре служб отчетов SQL Server доступ к отчетам ACS
выполняется через веб-сайт служб отчетов SQL Server, созданный во время
установки. Это обеспечивает повышенную гибкость в настройке структуры папок и
применении конструктора отчетов служб отчетов SQL Server.
44

Отдельная модель безопасности. Использование выделенного экземпляра служб
отчетов SQL Server дает возможность создавать роли безопасности по мере
необходимости для выполнения бизнес-требований и ИТ-требований по
управлению доступом к отчетам ACS. Учтите, что по-прежнему необходимо
предоставлять необходимые разрешения в базе данных ACS.
Следующим проектным решением является определение количества развертываемых пар
"сборщик-база данных" ACS для поддержки среды. Количественные показатели сбора
событий и вставки данных, поддерживаемых одной парой "сборщик-база данных" ACS, не
являются абсолютными. Эти показатели зависят от производительности подсистемы
хранения, к которой присоединен сервер базы данных. Например, решение SAN
начального уровня обычно поддерживает обработку не более 2500—3000 событий
безопасности в секунду. Независимо от этого показателя, сборщик ACS в реальных средах
продемонстрировал возможность поддерживать кратковременные всплески объемом до
20000 событий безопасности в секунду. Число событий безопасности, создаваемых за
секунду, определяется следующими факторами.

Конфигурация политики аудита. Чем строже политика аудита, тем большее число
событий безопасности создается на компьютерах, где действует аудит.

Если действует политика аудита по умолчанию (контроллер домена), то роль
компьютера, где включен сервер пересылки ACS, создает больше всего событий
безопасности. Далее по количеству создаваемых событий следуют рядовые серверы, а
рабочие станции создают меньше всего событий.
Роль компьютера
Приблизительное количество
неотфильтрованных событий безопасности,
создаваемых за секунду в условиях высокой
загрузки
Контроллер домена Windows Server 2003
40 событий в секунду
Рядовой сервер Windows Server 2003
2 события в секунду
Рабочая станция
0,2 события в секунду

С учетом данных из этой таблицы можно получить, что одна пара "сборщик-база
данных" ACS с оборудованием высокого класса может поддерживать до 150
контроллеров домена, 3000 рядовых серверов или 20000 рабочих станций (с
применением подходящего фильтра сборщика ACS).

Объем пользовательских операций в сети. Если в сети работают пользователи,
проводящие большое число транзакций (как это происходит, например, в Майкрософт),
то количество создаваемых событий будет выше. Если пользователи в сети выполняют
относительно небольшое количество транзакций, например в торговой палатке или на
складе, то число событий безопасности будет меньше.
45

Конфигурация фильтра сборщика ACS. Службы ACS собирают все события
безопасности из журнала событий безопасности на отслеживаемом компьютере. Из
собираемых событий интерес может представлять лишь некоторое подмножество.
Службы ACS поддерживают фильтрацию ненужных событий, чтобы обрабатывать в
сборщике и вставлять в базу данных ACS только нужные события. Расширенное
применение фильтрации позволяет сократить число обрабатываемых событий,
вставляемых в базу данных ACS.
Последним проектным решением является определение версии СУБД, используемой для
базы данных ACS — SQL Server 2005 или SQL Server 2008. Службы ACS поддерживают
SQL Server 2005 выпуска Standard Edition или Enterprise Edition и SQL Server 2008 выпуска
Standard Edition или Enterprise Edition. Выбор версии влияет на характеристики работы
системы в течение ежедневного периода обслуживания базы данных. В течение периода
обслуживания секции базы данных с отметками времени, лежащими вне графика хранения
данных (типичной продолжительностью хранения данных является 14 дней), удаляются из
базы данных. Если используется выпуск SQL Server Standard Edition, вставка событий
безопасности приостанавливается, и события помещаются очередь сборщика ACS до
завершения обслуживания. Если используется выпуск SQL Server Enterprise Edition,
вставка обработанных событий безопасности продолжается со скоростью примерно 30—
40% от обычной. По этой причине следует тщательно выбирать интервал времени для
ежедневного обслуживания базы данных, чтобы выполнять его в периоды минимальной
активности пользователей и приложений в сети.
Рекомендации по службам ACS
На общую производительность системы ACS сильнее всего влияет производительность
базы данных ACS и ее дисковой подсистемы. Это легко объясняется тем, что каждую
секунду вставляется несколько тысяч событий, а пиковые показатели достигают десятков
тысяч событий в секунду. Часто возникает ситуация, когда большое количество
отслеживаемых устройств, в том числе контроллеров домена, создают в базе данных ACS
более терабайта данных за срок в 14 дней. Далее представлены рекомендации по работе
со службами ACS.

Используйте 64-разрядное оборудование и операционные системы для сборщика и
SQL Server, а также высокопроизводительное решение SAN.

Разделяйте файлы данных базы данных и журналы транзакций.

Используйте выделенное оборудования для размещения служб ACS, если это
обеспечит преимущества.

Используйте строгие фильтры для сокращения числа побочных событий безопасности,
вставляемых в базу данных.

Тщательно планируйте политику аудита Windows, чтобы на отслеживаемых системах
регистрировались только содержательные события.

Включайте сервер пересылки ACS только на тех системах, где это необходимо.

Задавайте для журналов событий безопасности достаточно места, чтобы в случае
перебоев связи со сборщиком ACS не возникала ситуация с переполнением журнала
46
событий безопасности, когда новые события перезаписывают старые, что приводит к
потере данных.
Развертывание плана реализации Operations
Manager 2007
Разработка плана реализации
На этом этапе разработки необходимы следующие документы:

Список целей проекта реализации Operations Manager 2007

Сводная таблица производственных, нормативных и технологических требований

Полное описание текущей производственной среды

Полное описание текущих процессов отслеживания

Список реализуемых служб Operations Manager 2007 и компонентов, необходимых для
поддержки этих служб

Подробная схема планируемых групп управления и их размещения в среде

Подробный план интеграции Operations Manager с текущими процессами отслеживания

Описание аппаратного обеспечения в планируемых группах управления
В этом руководстве описывается процесс создания последнего необходимого документа —
плана реализации.
Тестирование в лаборатории
План реализации — это перечисление основных шагов, необходимых для перемещения
среды отслеживания из текущего (или "начального") состояния в итоговое ("требуемое
конечное") состояние. Единственный способ создания корректного плана заключается в
проведении тестирования. Цель тестирования, проводимого в рамках создания плана
реализации, заключается в проверке конфигурации и процедур, а не в подтверждении
масштабируемости, так как полное моделирование производственной среды и нагрузки в
лабораторных условиях экономически нецелесообразно.
Создание тестовой среды следует начать с определения наиболее важных компонентов
производственной среды, которые поддерживают среду мониторинга (например, Active
Directory и служба доменных имен DNS). Следует также определить компоненты, с
которым Operations Manager будет осуществлять взаимодействие (например, приложения,
серверы и рабочие станции).
Подготовьте аппаратное обеспечение для создания исходной тестовой среды. Так как
выполняется не полномасштабное тестирование, рекомендуется использовать Microsoft
Virtual Server для размещения этих компонентов в виде виртуальных машин.
Использование Virtual Server также позволяет быстро перезапускать тестовую среду после
прогона, возвращая ее в исходное состояние. Создайте в среде инфраструктуру наиболее
важных компонентов и компонентов начального состояния. Следите за там, чтобы тестовая
47
среда как можно более полно соответствовала производственной среде. Чем полнее будет
совпадение по конфигурации, службам и данным, там более точным будет последующее
тестирование.
Затем подготовьте аппаратное обеспечение, которое будет использоваться для поддержки
реализации групп управления и включите его в тестовую схему. Это позволяет
удостовериться в наличии и корректной работе всех компонентов. Затем составьте
набросок плана действий по развертыванию реализации Operations Manager. На этом
подготовительный этап завершен.
Теперь необходимо выполнить реализацию в тестовой среде, обновляя процедуры после
каждого выполненного шага. При этом могут возникать различные ошибки. Цель этого
процесса заключается в том, чтобы выявить максимальное количество ошибок,
препятствующих реализации, и разработать решения или указания для устранения таких
ошибок. Подобный процесс следует повторить несколько раз, каждый раз выполняя
следующий шаг. При необходимости можно выполнить перезапуск тестовой среды.
Если преобразование из начального состояния в конечное будет выполнено успешно, то
составленный план будет корректным и надежным.
48