До выхода SCSM 2012 (да простит меня Алексей, но я пока что буду писать именно так )) ) осталось совсем немного времени, и сегодня уже известно практически всё о новой версии – доступна SCSM 2012 RC в которой реализованы все функции, которые будут в окончательной версии. Поэтому эта статья начинает цикл статей о SCSM 2012.

Данная статья во многом основана на моей старой статье об архитектуре SCSM 2010. Это было сделано сознательно, хотя в начале я хотел сделать просто сравнение с предыдущей версией, но всё-таки желание избавить читателей от необходимости прыгать между двумя статья пересилило.

31.03.2012. ВНИМАНИЕ! Обновлена информация по поддерживаемым ОС для консолей!

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

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

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

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

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

SCSM 2012 может состоять из следующих компонентов (“жирным” выделены новые, по сравнению с SCSM 2010, компоненты):

#	Компонент	Количество	Примечание
1	Основной сервер управления (management server)	Один на группу управления	Обязательный компонент
2	Дополнительный сервер управления	Один и более	Необязательный компонент
3	Операционная база данных (ServiceManager)	Одна на группу управления	Обязательный компонент
4	Консоль управления	Одна и более
5	Портал самообслуживания на базе Sharepoint 2010	Один или более	Необязательный компонент
6	Сервер веб-содержимого	Один или более	Обязательный при использовании портала самообслуживания
7	Сервер управления хранилища данных (Data Warehouse Management Server)	Один	Необязательный компонент
8	База данных хранилища данных (DWDataMart)	Один	Необязательный компонент
9	База данных хранилища данных для SCCM (CMDWDataMart)	Один	Необязательный компонент
10	База данных хранилища данных для OpsMgr (OMDWDataMart)	Один	Необязательный компонент
11	База данных настройки хранилища данных (DWStageAndConfig) и база данных промежуточных данных (DWRepository)	Один	Необязательный компонент
12	Сервер службы отчетности (SQL Reporting Services)	Один	Необязательный компонент
13	SQL Analysis Services	Один	Необязательный компонент
14	База данных Analysis Services (DWASDataBase)	Один	Необязательный компонент

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

По сравнению с прошлой версией, в SCSM 2012 появился полноценный портал самообслуживания, реализованный на базе Sharepoint 2010, а также кубы данных на базе SQL Analysis Services. Оба этих новшества снимают с администратора огромный объем работы по настройке системы, а также предоставляют ему возможность гибкой настройки системы для конечных пользователей.

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

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

• Подключение консолей управления в рамках данной группы управления
• Запуск рабочих процессов (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 SP1 (указанные здесь и далее данные актуальны на момент написания статьи, текущие поддерживаемые системы вы всегда можете посмотреть на странице TechNET). Обратите внимание, что установка SP1 обязательна, в нем содержатся важные для SCSM 2012 обновления.

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

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

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

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

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

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

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

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

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

Консоль управления служит для полноценной работы в SCSM. Консоль управления может работать под управлением ОС Windows Vista SP2 и выше для клиентских ОС и Windows Server 2008 и выше для серверных ОС (ОБНОВЛЕНО 31.03.2012. Поддержки Windows Server 2003 НЕ БУДЕТ). Обратите внимание, что Windows XP и Windows Serrver 2003 не поддерживаются (вне зависимости от уровня SP). Консоль управления устанавливается на компьютеры пользователей, которым необходимо активно работать с элементами SCSM: создавать их, редактировать и пр. Для сотрудников, которые участвуют в голосовании или только создают простые заявки (т.е. конечные пользователи), вполне подходит веб-портал самообслуживания.

Для полноценной работы с консолью на компьютере должны быть установлены:

• Windows PowerShell 1.0 или Windows PowerShell 2.0
• ADO.NET Data Services Update for .NET Framework 3.5 SP1 для Windows Server 2008 R2 и Windows 7
• Microsoft Analysis Management Objects (AMOs)
• Microsoft .NET Framework 3.5 with SP1

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

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

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

Портал самообслуживания может работать под управлением Sharepoint 2010 редакций Foundation, Server (Enterprise или Standard) и SharePoint 2010 for Internet Sites Enterprise.

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

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

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

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

Сервер веб-содержимого

Сервер веб-содержимого представляет собой сайт IIS, в котором расположены компоненты Silverlight для отображения на портале самообслуживания, а также служба WCF (Windows Communication Foundation) для доступна к данным. Эту служба используется для доступа к данным SCSM из портала самообслуживания (эта служба примечательна еще и тем, что ровно такая же служба реализует доступ по SDK, и тем кто интересует “начинкой” OpsMgr или SCSM будет интересно её изучить). Кроме этого сервер веб-содержимого кэширует данные, получаемые из БД SCSM.

Сервер веб-содержимого можно установить на Windows Server 2008 R2 Standard или Enterprise. Можно установить любое количество серверов веб-содержимого, использовать NLB для балансировки нагрузки.

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

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

Кроме этого, теперь поддерживается регистрация в качестве источников данных не только групп управления SCSM, но и БД SCCM и групп управления OpsMgr. Это позволяет использовать SCSM в качестве единой точки отчетности CMDB. Из SCCM передаются данные конфигурации, данные по обновлениям ПО и энергопотреблению, из OpsMgr – данные по конфигурационным единицам.

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

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

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

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

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

В связи с появлением OLAP-кубов в SCSM 2012 добавились задачи по синхронизации данных между отчетной БД и БД кубов, которые носят имена Process.SystemCenter%ИМЯ_КУБА%Cube:

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

База данных хранилища данных (DWDataMart) является окончательной отчетной базой данных для данных, полученных из Service Manager. Именно её вы будете использовать для построения отчетов. Данная БД может находится на выделенном SQL-сервере, что может быть полезно, если у вас большой объем отчетных данных и вы активно пользуетесь отчетами. SCSM 2012 также поддерживает получение отчетных данных из SCCM и OpsMgr, которые хранятся в базах данных CMDWDataMart  и OMDWDataMart  соответственно. При этом не важно, сколько источников данных для SCSM, SCCM или OpsMgr  у вас будет – все данные будут распределятся в соответствующие базы данных. Схема этих БД документирована (с 2010 версии больших отличий нет, когда будет ссылка на схему 2012 я поправлю линк).

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

База данных настройки хранилища данных (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) или же могут создаваться на сервере напрямую.

Кубы OLAP для SCSM 2012

В SCSM 2012 появился новый компонент: кубы данных (OLAP). Эти кубы работаю на базе SQL Analysis Services и позволяют строить отчеты и заниматься анализом данных в нескольких измерениях с помощью привычных средств: Excel, Sharepoint или любой другой инструмент, умеющий работать с OLAP-кубами SQL Analysis Services.

OLAP-кубы описываются в пакете управления, и затем уже загружаются в SQL Analysis Services. “Из коробки“ доступны следующие кубы:

• Куб обновления программного обеспечения (данные из SCCM)
• Куб рабочих элементов Service Manager
• Куб элементов конфигурации Service Manager
• Куб управления питанием (данные из SCCM, один из самых “ценных” кубов в условиях России ;) )
• Куб управления действиями и изменениями
• Кубы библиотеки каталога услуг Service Manager

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

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

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

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

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

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

Официальный Sizer (инструмент для расчета необходимого аппаратного обеспечения) будет доступен немного позже, поэтому сейчас лишь несколько рекомендаций:

• Не стоит совмещать Analisys Services с другими компонентами. Причина тому серьезная нагрузка на сервера в момент расчета кубов (правда этот расчет запускает по умолчанию раз в сутки в 03:00)
• Выделяйте на отдельный сервер базы данных DWDataMart, если у вас большой объем данных (от 5000 пользователей\компьютеров)

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

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

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

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

Кроме этого, выбором в пользу виртуализации является лицензионная модель System Center, которая позволяет назначать лицензии управления на хост-серверы.

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

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

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

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

Заключение

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