Уходим от ручной наладки компьютеров в филиалах, предоставив управление конфигурациями Configuration Manager 2012 R2. В статье будет рассказано о СУБД MS SQL Server, планировании сайтов и их настройках, а также о необходимых требованиях, достоинствах и недостатках.

 

Введение

Наличие System Center Configuration Manager предполагает автоматизацию многих процессов и более удобное централизованное управление конфигурациями компьютеров. И в первую очередь это касается главного офиса компании. В филиалах, особенно с медленными каналами, подготовка машин часто ещё происходит по старинке – с помощью образов на носителях. А имея в главном офисе уже полностью настроенный Configuration Manager 2012 R2 - Primary Site (Первичный сайт), - было решено облегчить труд сотрудникам техподдержки отдалённых объектов (уйти от использования продуктов Acronis TrueImage, GLPI+OCS Inventory, Remote Administrator) и прийти к единым корпоративным программным решениям, а именно: инвентаризация компьютеров, автоматическая установка ОС, ПО, драйверов, проверка на соответствие параметров и другое.     

Задача: в сжатые сроки оборудовать рабочие места сотрудников филиала компьютерами из новой партии. Для этого вынести из локального окружения СУБД и вместо MS SQL Server 2008 установить версию 2012 года, предоставить возможность использования функционала MS SCCM 2012 R2 в территориально отдалённых объектах.   

 

Планирование

По рекомендациям Microsoft СУБД MS SQL Server можно держать вместе с SCCM на одной машине при количестве клиентских компьютеров примерно в 1000 единиц. В нашем случае это количество меньше раза в 2, но если посмотреть вперёд, то несколько филиалов увеличат значение до 800 единиц. Также в дальнейшем предполагается подключить систему мониторинга MS SCOM 2012, поэтому создание выделенного сервера для базы данных весьма выгодное решение.

SCCM имеет возможность предоставить свой функционал отдалённым объектам в 2х случаях [http://technet.microsoft.com/ru-ru/library/gg712681.aspx , http://technet.microsoft.com/ru-ru/library/bb693570.aspx]:

  • удалённая Distribution Point (DP, Точка распространения);
  • Secondary Site (Вторичный сайт).

С одной стороны, оба варианта подходят, но с другой – имеют существенные отличия. Чтобы сделать правильный выбор, давайте рассмотрим достоинства и недостатки каждого из них. И главное, что здесь нужно принимать во внимание - это объём сетевого трафика.

Подсчёт количества трафика можно осуществить с помощью готовой Excel-таблички [http://1drv.ms/1qV0Tdt], но нужно понимать, что это примерное представление, которое помогает узнать пределы “от” и “до”. Основные действия SCCM, по которым производятся расчёты, - это: сканирование программной части для обновлений; инвентаризация программной и аппаратной части; запросы на политики и другое. В этой таблице нужно в поле Number of Clients (Количество клиентов) ввести количество пользовательских компьютеров. Ячейка Regular (Регулярно) отображает постоянно передаваемые данные, а поле Worst Case (Худший вариант), показывает объём трафика, когда все клиенты начнут передавать информацию после полной инвентаризации, запросов политик и так далее.

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

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

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

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

Итак, в нашем случае больше подходит работа со вторичным сайтом, потому как пропускная способность каналов передачи данных составляет 2 Мбитс. А после того, как мы определились с иерархией, в соответствии с требованиями [http://technet.microsoft.com/ru-ru/library/c1e93ef9-761f-4f60-8372-df9bf5009be0#BKMK_SupConfigClientsperSite], необходимо подобрать соответствующее оборудование.

 

Работа над SQL Server

Перейдём к практике. Первым делом проверим в локальной CУБД значения нескольких параметров Service Broker [http://technet.microsoft.com/ru-ru/library/ms166049%28v=sql.105%29.aspx], необходимых для SCCM, это:

  • is_trustworthy_on – говорит о надёжности БД;
  • is_broker_enabled – включена ли служба Service Broker;
  • is_honor_broker_priority – показывает, учитываются ли приоритеты в базе данных.

Каждое из них должно быть равным 1, что обозначает включенность, запущенность. Определить их состояния можно с помощью запроса на выборку из системной таблицы sys.databases, который будет выглядеть следующим образом:

select name, collation_name, is_trustworthy_on, is_broker_enabled, is_honor_broker_priority_on

from sys.databases

where name = 'СМ_DD'

Рисунок 1. Результат работы запроса на выборку.

Перед тем, как начинать переносить базу данных, необходимо остановить службы SCCM. Сделать это можно в командной строке, запустив команду preinst /stopsite (preinst находится в каталоге Program FilesMicrosoft Configuration ManagerinX64).

Теперь сделаем резервную копию БД Configuration Manager. Для этого воспользуемся консолью Microsoft SQL Server Management Studio, в ней находим CM_DD, на которой жмём правкой кнопкой мыши и выбираем Tasks (Задачи)->Back Up(Бэкап). В появившемся окне из выпадающего списка останавливаемся на Full (Полный бэкап) и указываем путь для сохранения.

Следующим шагом будет настройка нового SQL-сервера после его инсталляции. Сначала проверяем, что версия СУБД [http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SupConfigSQLDBconfig] подходит для SCCM 2012 R2, при необходимости устанавливаем требуемое обновление. Затем обращаем внимание на значение параметра Server Collation, которое должно соответствовать SQL_Latin1_General_CP1_CI_AS. Это можно увидеть в свойствах SQL-сервера, в консоли Management Studio.

Затем смотрим, включён ли CRL (Common Language Runtime), который предоставляет интеграцию MS SQL Server с платформой .Net Framework. Это означает, что можно работать с триггерами, функциями, хранимыми процедурами на любом языке web-программирования, включая и MS Visual C#, MS Visual Basic. Убедиться нам нужно в том, что параметр run_value=1, запустив для этого запрос:

sp_configure 'clr enabled'

Ещё обязательно на новом сервере БД добавить в группу локальных администраторов доменную учетную запись сервера SCCM для полного его доступа.

Настало время перенести и подключить БД Configuration Manager (файл CM_DD.bak) на новый сервер баз данных. Открываем консоль Microsoft SQL Server Management Studio 2012, жмём правой кнопкой на Databases (Базы данных), выбираем Restore Database (Восстановление базы данных) и указываем путь к бэкапу. Затем останавливаем уже старую СУБД, при этом в оперативной памяти освободится примерно 500 Мб.    

Если сейчас запустить Configuration Manager, то он выдаст ошибку о невозможности подключиться к базе данных. И это естественно, потому как он ещё не знает о существовании новой СУБД и обращается к локальной MS SQL Server 2008. Чтобы прописать путь к БД выделенного сервера, необходимо открыть консоль Configuration Manager Setup (Пуск->Microsoft System Center 2012->Configuration Manager), в первом окне мастера выбрать Perform site maintenance or reset this site (Выполнить обслуживание или сброс сайта), во втором - Modify SQL Server configuration (Изменить конфигурацию SQL-сервера), а в следующем – должны быть заполнены поля FQDN, Instance name (если используется), Database name (Имя базы данных). Для тех, кто впервые делает такой перенос баз данных, ждёт сюрприз: сервер SCCM определил БД, пытается подключиться и ничего не получается, при этом операционная система не зависает. Проверка служб SQL Server (SQL Server, SQL Server Reporting Services, SQL Server Agent, SQL Server Browser), портов, IP-адресов и путей результата не даёт, в логе SCCM (ConfigMgrSetup.log) можно увидеть сообщение о настройке Service Broker (см. рис. 2). 

          

Рисунок 2. Сообщение о настройке Service Broker.

Исходя из этого, нужно проверить конфигурацию SQL-сервера. Нам поможет запрос на выборку (см. листинг 1), результат которого покажет, что is_broker_enabled установлен в 0, потому как Service Broker по умолчанию в прикрепленных или восстановленных базах данных выключен. Если ещё какой-то из этих 3х параметров имеет такое же состояние, то нужно инвертировать значение 0. Сделать это можно, с помощью другого запроса:

USE master;

GO

ALTER DATABASE CM_DD SET ENABLE_BROKER ON

GO

USE master;

GO

ALTER DATABASE CM_DD SET TRUSTWORTHY ON

GO

USE master;

GO

ALTER DATABASE CM_DD SET HONOR_BROKER_PRIORITY ON

GO

а на выходе должны получить (см. рис. 1). После этого снова запускаем Configuration Manager и наблюдаем как он “взлетает”. Чтобы полностью быть уверенным в правильности конфигураций по миграции БД, в SCCM заходим в раздел Administration->Overview->Site Configuration->Servers and Site System Role и видим, что автоматически уже создан Site System Server, содержащий всего 3 роли (Component server, Site database server, Site system). На этом первый этап нашей работы завершился.

 

Продолжение следует...