Главная System Center, Новое Архитектура SCSM 2010
  • Архитектура SCSM 2010

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

    Как я уже много раз писал, SCSM 2010 является потомком OpsMgr, поэтому архитектура этих продуктов очень похожи, хотя и имеются некоторые различия, связанные с тем, что SCSM построен на базе следующего поколения OpsMgr.


    Группа управления

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

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

    Основным отличием от OpsMgr при рассмотрении SCSM является тот факт, что SCSM имеет специальную группу управления – отчетную (Data Warehouse). Эта группа управления настраивается при установке сервер управления хранилища данных (Data Warehouse Management Server), и может взаимодействовать с одной или несколькими другими группами управления SCSM. Это полезно, когда вам нужно получать отчетные данные из изолированных групп управления. Естественно, вы можете иметь и несколько отчетных  групп управления, если вам это необходимо. Еще одно замечание – отчетная группа управления опциональна, т.е. её может на быть вовсе. В этом случае вам будут недоступны отчеты, но все остальные компоненты SCSM будут работать.

    Компоненты SCSM 2010

    SCSM 2010 может состоять из следующих компонентов:

    # Компонент Количество Примечание
    1 Основной сервер управления (management server) Один на группу управления Обязательный компонент
    2 Дополнительный сервер управления 0 и более Необязательный компонент
    3 Операционная база данных (ServiceManager) Одна на группу управления Обязательный компонент
    4 Консоль управления Одна и более  
    5 Портал самообслуживания Один или более Необязательный компонент
    6 Сервер управления хранилища данных (Data Warehouse Management Server) Один Необязательный компонент
    7 База данных хранилища данных (DWDataMart) Один Необязательный компонент
    8 База данных настройки хранилища данных (DWStageAndConfig) и база данных промежуточных данных (DWRepository) Один Необязательный компонент
    9 Сервер службы отчетности (SQL Reporting Services) Один Необязательный компонент

    При этом компоненты 1-5 относятся к основной группе управления (которых может быть несколько, как я уже писал выше), а компоненты 6-9 к отчетной группе управления.

    Серверы управления (management servers)

    Первый сервер в группе управления, на который устанавливается SCSM, является основным сервером управления. Основной сервер управления отвечает за:

    • Подключение консолей управления в рамках данной группы
    • Запуск рабочих процессов (workflow) в рамках данных группы

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

    На каждом сервере управления работают следующие службы (в скобках указано системное имя службы):

    • System Center Data Access Service (OMSDK). Отвечает за взаимодействие с клиентами: консолями управления, порталом самообслуживания и приложениями, использующими SCSM SDK.
    • System Center Management (HealthService). Отвечает за запуск и выполнение внутренних процессов системы.
    • System Center Management Configuration (OMCFG). Отвечает за управление всеми процессами в системе, в том числе расписаниями, событиями и т.д. Как метко выразился Трэвис, он отвечает за то ЧТО делать, КОГДА делать и КАК делать. Эта служба является “дирижёром” для всех компонентов SCSM.

    Все события, происходящие в SCSM, записываются в журнал ОС Applications And Serices Logs\Operations Manager. Опять же, не стоит удивляться – сказывается родственная связь с OpsMgr. Если у вас есть подозрение, что ваш SCSM работает “как-то не так”, этот лог - первое, что необходимо изучать.

    Сервер управления может работать под управлением Windows Server 2008 R2 или Windows Server 2008 (Standard или Enterprise) только x64 версии (указанные здесь и далее данные актуальны на момент написания статьи, текущие поддерживаемые системы вы всегда можете посмотреть на странице TechNET).

    Отказоустойчивость серверов управления

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

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

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

    Операционная база данных (ServiceManager)

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

    Операционная база данных может работать под управлением Microsoft SQL Server 2008 SP1, SP2 и SQL Server 2008 R2 только x64 версии. Обратите внимание, что использование SQL 2008 без сервисных пакетов не поддерживается. 

    Для обеспечения отказоустойчивости вы можете использовать любые средства Microsoft SQL Server, в том числе кластеризацияю, log-shipping, mirroring.

    Консоль управления

    Консоль управления служит для полноценной работы в SCSM. Консоль управления может работать под управлением ОС Windows XP SP3 и выше (в том числе Windows Server 2003). Консоль управления устанавливается на компьютеры пользователей, которым необходимо активно работать с элементами SCSM: создавать их, редактировать и пр. Для сотрудников, которые участвуют в голосовании или только создают простые заявки (т.е. конечные пользователи), вполне подходит веб-портал самообслуживания.

    С компьютера, на котором установлена консоль управления, можно подключаться к разным группам управлениям. При этом формы, которые передаются на локальный компьютер в виде сборок (библиотек, dll), будут храниться отдельно для каждой группы управления. При этом следует стараться, чтобы уровень обновлений (CU) для SCSM во всех группах управления совпадали. Если добиться этого не получается, необходимо стремиться, чтобы консоль управления имела наибольшее обновление из всех групп управления. При этом подключение консоли SCSM без SP1 к группам управления с SP1 (и наоборот) не поддерживается. К примеру, если у вас есть две группы управления, в одной используется SCSM SP1 CU1, а в другой SCSM SP1 CU2, то необходимо все консоли управления обновить до SCSM SP1 CU2.

    Портал самообслуживания

    Портал самообслуживания работает под управлением IIS 7 (Windows Server 2008) или IIS 7.5 (Windows Server 2008 R2) и представляет собой обычное ASP.NET-приложение.

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

    Сервер управления хранилища данных

    Сервер управления хранилища данных (далее СУХД, data warehouse management server) служит для выгрузки данных из основных серверов управления и преобразования её в вид, более подходящий для построения отчетов. Я не опечатался, написав множественное число для серверов управления – как я уже писал ранее, один СУХД может обслуживать несколько групп управления. Это позволяет использовать единую базу отчетности для нескольких изолированных групп. При этом в отчете мы можем определить к какой группе управления относятся те или иные данные (в отчетах, предоставленных по умолчанию, имя группы не выводится).

    На СУХД выполняется те же три службы, что и на основном сервере управления.

    Для того, чтобы начать передачу данных из основной группу в группу отчетности, необходимо выполнить регистрацию (register) основной группы управления. Это можно сделать как из консоли, так и с помощью PowerShell.

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

    1. Передача и обработка пакетов управления из основной группы в отчетную (MpSyncJob)
    2. Извлечение данных (Extract_%MAINGROUPNAME% и Extract_%DWGROUPNAME%)
    3. Загрузка данных (Load.Common)
    4. Трансформация данных (Transform.Common)

    Последние три задачи объединены в один процесс, которые называется ETL (по первым буквам Extract-Transfrom-Load). Объяснения принципов работы ETL и вообще принципов работы хранилища данных выходит далеко за рамки этой статьи, я постараюсь написать отдельный пост про Data Warehouse.

    Базы данных хранилища данных

    База данных хранилища данных (DWDataMart) является окончательной отчетной базой данных. Именно её вы будете использовать для построения отчетов. Данная БД может находится на выделенном SQL-сервере, что может быть полезно, если у вас большой объем отчетных данных и вы активно пользуетесь отчетами. Схема этой БД документирована.

    База данных настройки хранилища данных (DWStageAndConfig) и база данных промежуточных данных (DWRepository) являются служебными база данных. При этом обе эти базы данных должны располагаться на одном SQL-сервер. Это обязательное условие.

    Все БД хранилища данных работают под управлением Microsoft SQL Server 2008 SP1, SP2 или SQL Server 2008 R2 только x64 версии. Обратите внимание, что использование SQL 2008 без сервисных пакетов не поддерживается.

    Для обеспечения отказоустойчивости вы можете использовать любые средства Microsoft SQL Server, в том числе кластеризацияю, log-shipping, mirroring, однако для этих БД 100% отказоустойчивость не критична.

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

    Сервер службы отчетности (SQL Reporting Services)

    Сервер отчетности использует MSSQL Reporting Services версии 2008 SP1, SP2 или 2008 R2, при этом поддерживается только х64 версия. Отчеты, расположенные на сервер служб отчетности загружаются из пакетов управления (с помощью задачи MpSyncJob) или же могут создавать на сервере напрямую.

    Взаимодействие компонентов SCSM

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

    image

    Обозначения:

    • SM MS – основной сервер управления
    • SM MS Secondary – дополнительный сервер управления
    • SM DB – сервер основной базы данных
    • SSP – Веб-портал самообслуживание
    • DW MS – сервер управления хранилища данных
    • DW DB – серверы баз данных хранилища данных

    Думаю пояснений данная схема не требует, но обратите внимание, что веб-портал требует соединения как с основным сервером управления, так и с базой данных. Также обратите внимание, что СУХД должен иметь доступ к Reporting Services, чтобы загружать в него отчеты.

    Совмещение компонентов SCSM

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

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

    Кол-во пользо-вателей Схема Пояснение
    0 - 200 image Тестовые стенды или очень небольшие компании.
    Предлагается использовать один физический сервер (Microsoft н-р рекомендует Dual Quad-core 2.66 GHz CPU с 16Гб RAM), на котором расположены все компоненты SCSM, кроме сервера управления хранилищем данных, который расположен на виртуальном сервере на этом же физическом компьютере.
    По опыту могу сказать, что комфортная работа в такой конфигурации возможна, только если у вас хорошая дисковая подсистема (т.е. несколько дисков SAS\SCSI 15000к).
    200 - 1000 image Небольшие компании.
    Сервера баз данных расположены на том же сервере, что и соответствующий им компонент.
    Такая схема позволяет разгрузить основной сервер от обработки отчетной информации. Сервера могут быть как физическими, так и виртуальными. Самым узким местом в любом случае (но особенно в случае виртуализации) будет дисковая подсистема.
    500-5000 image Небольшие и средние компании. Выделенный сервер баз данных для всех БД. Такая схема позволяет организовать работу баз данных на кластере, при этом мы может расположить БД на разных дисковых массивах, что позволяет сэкономить и добиться хорошей производительности. В этом случае основной сервер управления и сервер управления хранилищем данных могут быть виртуальными, а вот сервер БД лучше делать физическим.
    5000 - 10000 image Средние компании.
    При таком количестве пользователей необходимо разносить базы данных на разные сервера, чтобы обработка отчетных данных не сказывалась на производительности основного сервера БД.
    10000 и более

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

    Необходимо понимать, что деление по количеству пользователей весьма условно. Нагрузка на компоненты SCSM сильно зависит от того, какие из возможностей SCSM вы будете включать в работе. К примеру, 1000 пользователей с одним включенным коннектором Active Directory создадут меньшую нагрузку, чем 500 пользователей с включенным коннектором AD, SCCM и OpsMgr, т.к. два последних коннектора передают большое количество подробных данных о компьютерах (аппаратную инвентаризацию, алерты и пр.).

    Виртуализация

    В последнее время виртуализация пользуется большим успехом, оно и не удивительно – экономия, удобство использования и прочие прелести делают её привлекательной как для администраторов, так и для ИТ-бизнеса. Но, как и всё остальное, виртуализация имеет и обратную сторону медали. При неправильном подходе она может не только не принести дивидендов, но и ухудшить ситуацию.

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

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

    Для примера могу сказать, что одна из наших тестовых лабораторий работает в одной виртуальной машине с 4мя виртуальными процессорами, 8Гб RAM и 3мя дисками, расположенными на разных дисковых массивах. На этом сервере установлен SQL. В БД загружены данные о 4500 пользователях и почти 8000 компьютерах (правда без синхронизации с SCCM, т.е. данные о компонентах этих компьютеров не доступны), плюс около 500 запросов. На этом сервере постоянно ведут разработку 2 человека, плюс подключено 5 консолей управления, и при этом скорость отклика просто отличная.

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

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

    • 20000 пользователей, при этом у каждого пользователя есть конфигурационная единица, содержащая 10-12 элементов. Другими словами – в базе содержится информация о 20000 пользователях, 20000 компьютерах и 10-12 компонентах этих компьютеров, таких как память, процессор диск и пр.
    • 5000 инцидентов в неделю, срок хранения – 3 месяца, итого 60000 инцидентов
    • 1000 запросов на изменения, срок хранения – 3 месяца, итого 12000 запросов

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

    Максимально протестированное число пользователей – 50000, при этом необходимо добавлять 8Гб памяти на сервер управления и сервер БД (на котором расположена только основная БД) на каждые 10000 пользователей свыше 20000. Т.е. для 30000 необходимо 16Гб, для 40000 – 24Гб и т.д.

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

    Дополнительные серверы управления рекомендуется вводить из расчета 10-12 консолей на одно ядро сервера. Т.е. скажем 2х процессорный 4х ядерный сервер “потянет” до 100 консолей одновременно.

    Заключение

    В данной статье я постарался изложить из каких компонентов состоит SCSM и как они взаимодействуют друг с другом. Надеюсь, эта статья поможет вам понять, как построить стабильную систему на базе SCSM.

    Антон Гриценко ака FreemanRU

    Оригинал статьи: Архитектура SCSM 2010

Комментарии

  1. Спасибо за статью. Неплохо бы почитать про условия лицензирования SCSM в связке с SCOM и SCCM.

  2. Такая статья пока что не может быть написана, потому что даже сам MSFT не может объяснить толком, как его лицензировать в определенных случаях. А так — читайте PUR, там всё подробнои рассписано про обычные случае.

Опубликовать

Я не робот.