Рассмотрим ситуацию, когда все компоненты работающего экземпляра 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-и
Выделив в дереве консоли корневой узел Runbooks вызываем пункт Export
В открывшемся диалоговом окне указываем путь к файлу в который будут выгружены все Runbook, задаём пароль для шифрования файла отмечаем все дополнительные опции
Создание на целевом 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 сервера на котором мы хотим создать новую БД
На второй закладке выбираем вариант создания новой БД – Create a new data store и оставляем предложенное имя БД по умолчанию, если нет причин на его изменение.
Дожидаемся от утилиты сообщения о результате создания БД…
Настройка прав и изменение размещения созданной БД
Теперь на новом 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 получим сообщение о необходимости повторного ввода ключа продукта. Вводим ключ продукта, и убеждаемся в том что консоль успешно подключается к вновь созданной БД.
Перед тем как приступать к импорту Runbook, весьма желательно выполнить повторную регистрацию и развертывание на наш сервер SCORCH всех используемых пакетов интеграции в консоли Deployment Manager. Если этого не сделать то вполне возможна ситуация когда в дальнейшем (уже после успешного импорта Runbook) перестанут работать активности из специфических пакетов интеграции, например для SCOM. При проверке работоспособности таких активностей вы увидите то, что они попросту не исполняются и нет даже возможности открыть их свойства, - возникает ошибка "Unknown Activity Type"
Проблема описана в статье KB: "Unknown" activity type displayed in the System Center 2012 Orchestrator Runbook Designer и, как я уже сказал, для её решения потребуется повторная загрузка и регистрация соответствующих пакетов интеграции в консоли Deployment Manager.
Импорт Runbook в консоли Runbook Designer
После повторного развертывания пакетов интеграции можно приступать к процедуре импорта в консоли Runbook Designer. Выделив в дереве консоли корневой узел Runbooks вызываем пункт Import
В открывшемся диалоговом окне указываем пусть к файлу который был экспортирован на первом этапе, пароль который использовался при экспорте и включаем соответственно все дополнительные опции.
После успешного завершения импорта проверяем все Runbook-и, настройки подключения к внешним системам типа SCOM в меню Options и если всё в порядке запускаем остановленные в самом начале процедуры Runbook-и.
Примечание: Стоит помнить что при экспорте/импорте не будет перенесена история предыдущих запусков Runbook-ов и их аудит.
Восстановление работоспособности веб-консоли Orchestrator
При попытке доступа к веб-консоли Orchestrator мы получим ошибку, возникающую из-за того что веб-консоль отдельно хранит настройки подключения к БД, которые фактически конфигурируются лишь на этапе установки веб-компонент SCORCH.
Для починки веб-консоли воспользуемся информацией из документа 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"
Теперь мы можем отредактировать строку подключения либо методом прямой правки файла web.config, либо с помощью оснастки IIS Manager открыв элемент Connection Strings для веб-приложения Orchestrator2012 в сайте Microsoft System Center 2012 Orchestrator Web Service…
…выполним редактирование строки подключения OrchestratorContext поменяв значение параметра Data Source
Сохранив измененное значение строки подключения выполним обратную шифровку соответствующего раздела файла:
C:WindowsMicrosoft.NETFrameworkv4.0.30319aspnet_regiis.exe -pef "connectionStrings" "C:Program Files (x86)Microsoft System Center 2012OrchestratorWeb ServiceOrchestrator2012"
После этого веб-консоль должна запуститься без ошибок, однако на вкладке Runbooks будет пусто. Это связано с тем что нам необходимо восстановить разрешения на соответствующие папки через Runbook Designer
Как правило на этапе первоначальной установки 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
Обратная ссылка: System Center 2012 R2 Configuration Manager — перенос баз данных сервера Primary Site (с учётом SSRS и WSUS) между экземплярами SQL Server | Блог IT-KB /