Перенос БД System Center 2012 Orchestrator на другой сервер

imageРассмотрим ситуацию, когда все компоненты работающего экземпляра System Center 2012 Orchestrator (SCORCH) развернуты на одном виртуальном сервере под управлением Windows Server 2012 Standard с локальным экземпляром БД SQL Server 2012 Standard и возникла необходимость переместить базу данных SCORCH на отдельный кластеризованный экземпляр SQL Server. По мере эксплуатации сервера SCORCH стало очевидно что размер БД весьма мал и держать отдельный локальный экземпляр SQL Server на этом сервере несколько расточительно, особенно учитывая тот факт, что размер потребляемой оперативной памяти процессом SQL Server чуть ли не в 30 раз превышает размер файла единственной обслуживаемой этим процессом БД. В ходе обдумывания поставленной задачи стало понятно что в нашем случае для переноса БД воспользоваться инструкцией описанной в статье Migrate Orchestrator Between Environments не получится, так как она подразумевает перенос SQL Master Key с исходного SQL сервера на целевой, что в нашем случае невозможно, так как на этом экземпляре уже работает некоторое количество других БД по некоторым предположениям использующих уже имеющийся Master Key. Поэтому было решено отработать альтернативный сценарий переноса БД с использованием функций Экспорта/Импорта консоли Runbook Designer с проведением ряда дополнительных манипуляций для успешного решения поставленной задачи. 

Собственно весь процесс можно разделить на следующие этапы:

1. Экспорт всех Runbook в консоли Runbook Designer
2. Создание на целевом SQL сервере новой БД с помощью Data Store Configuration tool
3. Настройка прав и изменение размещения созданной БД
4. Перезагрузка нужных пакетов интеграции в консоли Deployment Manager
5. Импорт Runbook в консоли Runbook Designer
6. Восстановление работоспособности веб-консоли Orchestrator
7. Удаление локального экземпляра SQL Server на сервере SCORH

Экспорт всех Runbook в консоли Runbook Designer

Открываем консоль Runbook Designer или веб-консоль Orchestrator и останавливаем все запущенные Runbook-и

image_thumb

Выделив в дереве консоли корневой узел Runbooks вызываем пункт Export

image

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

image

Создание на целевом SQL сервере новой БД с помощью Data Store Configuration tool

После того как экспорт выполнен, закрываем все консоли и останавливаем службы относящиеся к SCORCH:

NET STOP "Orchestrator Management Service"

NET STOP "Orchestrator Runbook Server Monitor"

NET STOP "Orchestrator Runbook Service"

NET STOP "Orchestrator Remoting Service"

Базу данных Orchestrator в локальном экземпляре SQL Server на сервере SCORCH переводим в Offline и запускаем утилиту Data Store Configuration tool. На первой закладке указываем имя SQL сервера на котором мы хотим создать новую БД

image

На второй закладке выбираем вариант создания новой БД – Create a new data store и оставляем предложенное имя БД по умолчанию, если нет причин на его изменение.

image

Дожидаемся от утилиты сообщения о результате создания БД…

image

Настройка прав и изменение размещения созданной БД

Теперь на новом SQL сервере нам нужно добавить новый SQL-Login – доменную учетную запись, от имени которой работают службы SCORCH (в нашем случае это доменный пользователь KOMs-KOM-SCORCHSrv). После добавления логина нужно выдать этому логину SQL-роли уровня БД:

Microsoft.SystemCenter.Orchestrator.Admins
Microsoft.SystemCenter.Orchestrator.Operators
Microsoft.SystemCenter.Orchestrator.Runtime

ну и на всякий случай роль владельца БД Orchestrator – db_owner. Сделаем это в Server Management Studio выполнив следующий SQL-запрос:

USE [master]

CREATE LOGIN [KOMs-KOM-SCORCHSrv] FROM WINDOWS WITH DEFAULT_DATABASE=[Orchestrator]

GO

USE [Orchestrator]

CREATE USER [KOMs-KOM-SCORCHSrv] FOR LOGIN [KOMs-KOM-SCORCHSrv]

ALTER ROLE [Microsoft.SystemCenter.Orchestrator.Admins] ADD MEMBER [KOMs-KOM-SCORCHSrv]

ALTER ROLE [Microsoft.SystemCenter.Orchestrator.Operators] ADD MEMBER [KOMs-KOM-SCORCHSrv]

ALTER ROLE [Microsoft.SystemCenter.Orchestrator.Runtime] ADD MEMBER [KOMs-KOM-SCORCHSrv]

ALTER ROLE [db_owner] ADD MEMBER [KOMs-KOM-SCORCHSrv]

GO

 

Далее, при необходимости, перемещаем размещенные в расположении по умолчанию файлы БД на нужный нам диск:

ALTER DATABASE [Orchestrator] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

ALTER DATABASE [Orchestrator] SET OFFLINE;

ALTER DATABASE [Orchestrator] MODIFY FILE

(

   Name = Orchestrator,

   Filename = 'U:SQL1_SCORCHOrchestrator.mdf'

);

ALTER DATABASE  [Orchestrator] MODIFY FILE

(

   Name = Orchestrator_log,

   Filename = 'U:SQL1_SCORCHOrchestrator_log.LDF'

);

 

Теперь переносим файлы в новое месторасположение и выполняем запуск базы

ALTER DATABASE [Orchestrator] SET ONLINE;

ALTER DATABASE [Orchestrator] SET MULTI_USER;

 

Перезагрузка нужных пакетов интеграции в консоли Deployment Manager

После того как манипуляции с БД закончены можно запустить остановленные ранее службы SCORH:

NET START "Orchestrator Management Service"

NET START "Orchestrator Runbook Server Monitor"

NET START "Orchestrator Runbook Service"

NET START "Orchestrator Remoting Service"

Запустив консоль Runbook Designer получим сообщение о необходимости повторного ввода ключа продукта. Вводим ключ продукта, и убеждаемся в том что консоль успешно подключается к вновь созданной БД.

image

Перед тем как приступать к импорту Runbook, весьма желательно выполнить повторную регистрацию и развертывание на наш сервер SCORCH всех используемых пакетов интеграции в консоли Deployment Manager. Если этого не сделать то вполне возможна ситуация когда в дальнейшем (уже после успешного импорта Runbook) перестанут работать активности из специфических пакетов интеграции, например для SCOM. При проверке работоспособности таких активностей вы увидите то, что они попросту не исполняются и нет даже возможности открыть их свойства, - возникает ошибка "Unknown Activity Type"

image

Проблема описана в статье System Center Orchestrator Engineering Blog - KB: "Unknown" activity type displayed in the System Center 2012 Orchestrator Runbook Designer и, как я уже сказал, для её решения потребуется повторная загрузка и регистрация соответствующих пакетов интеграции в консоли Deployment Manager.

image

Импорт Runbook в консоли Runbook Designer

После повторного развертывания пакетов интеграции можно приступать к процедуре импорта в консоли Runbook Designer. Выделив в дереве консоли корневой узел Runbooks вызываем пункт Import

image

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

image

После успешного завершения импорта проверяем все Runbook-и, настройки подключения к внешним системам типа SCOM в меню Options и если всё в порядке запускаем остановленные в самом начале процедуры Runbook-и.

Примечание: Стоит помнить что при экспорте/импорте не будет перенесена история предыдущих запусков Runbook-ов и их аудит.

Восстановление работоспособности веб-консоли Orchestrator

При попытке доступа к веб-консоли Orchestrator мы получим ошибку, возникающую из-за того что веб-консоль отдельно хранит настройки подключения к БД, которые фактически конфигурируются лишь на этапе установки веб-компонент SCORCH. 

image

Для починки веб-консоли воспользуемся информацией из документа TechNet Library - How to Change the Orchestrator Database.

Чтобы изменить параметры базы данных для веб-службы, необходимо откорректировать файл Web.config в каталоге C:Program Files (x86)Microsoft System Center 2012OrchestratorWeb ServiceOrchestrator2012. Но для того чтобы параметры подключения к БД можно было редактировать их сначала необходимо расшифровать внутри этого файла командой:

C:WindowsMicrosoft.NETFrameworkv4.0.30319aspnet_regiis.exe -pdf "connectionStrings" "C:Program Files (x86)Microsoft System Center 2012OrchestratorWeb ServiceOrchestrator2012"

image

Теперь мы можем отредактировать строку подключения либо методом прямой правки файла web.config, либо с помощью оснастки IIS Manager открыв элемент Connection Strings для веб-приложения Orchestrator2012 в сайте Microsoft System Center 2012 Orchestrator Web Service

image

…выполним редактирование строки подключения OrchestratorContext поменяв значение параметра Data Source

image

Сохранив измененное значение строки подключения выполним обратную шифровку соответствующего раздела файла:

C:WindowsMicrosoft.NETFrameworkv4.0.30319aspnet_regiis.exe -pef "connectionStrings" "C:Program Files (x86)Microsoft System Center 2012OrchestratorWeb ServiceOrchestrator2012"

image

После этого веб-консоль должна запуститься без ошибок, однако на вкладке Runbooks будет пусто. Это связано с тем что нам необходимо восстановить разрешения на соответствующие папки через Runbook Designer

image

Как правило на этапе первоначальной установки SCORCH создается доменная группа администраторов Orchestrator. Собственно говоря этой группе нужно восстановить доступ (Full Controll) к корню Runbooks. После этого прежняя работоспособность веб-консоли должна быть восстановлена.

Кстати при изменении прав доступа на подкаталоги в структуре Runbooks возможна некоторая задержка отображения конечного результата в веб-консоли. Чтобы не ждать получасового таймаута кэша авторизации можно воспользоваться советом приведённым в заметке Orchestrator Runbooks not appearing on the web console и для БД Orchestrator выполнить SQL-запрос

USE [Orchestrator]

TRUNCATE TABLE [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache


Удаление локального экземпляра SQL Server на сервере SCORH

После того как мы убедились в работоспособности всех компонент SCORCH с фактически отключенным локальным экземпляром БД Orchestrator, - можно удалить локальный экземпляр SQL Server на сервере SCORCH. При этом надо помнить что для доступа к удалённому экземпляру БД нам потребуется сохранить клиентские компоненты SQL Server. В моём случае на сервере SCORCH в конечном итоге остался только пакет Microsoft SQL Server 2012 Native Client

image

Добавить комментарий