Журналы, контроль выполнения и проверка результата
Назначение раздела
В данном разделе описано, как администратор контролирует выполнение задания миграции, анализирует журналы и подтверждает успешный перенос конфигурации на резервную площадку.
1. Переход в раздел Журналы
После выполнения операций Generate Config и Run администратор открывает раздел Журналы.
На предоставленных экранах раздел отображается как Журналы.
В верхней части страницы доступны основные действия:
Просмотр;
Удалить;
обновление списка.
В верхней таблице отображается список записей журнала с колонками:
ID;
Date/Time;
Job Name.
Ниже располагается область детального просмотра Log View (ID: ...), в которой отображается содержимое выбранной записи.
В таблице детального просмотра используются колонки:
№;
Log Entry.
Место для скриншотаСкриншот 16.
Раздел Журналы в XRM Director со списком записей и областью Log View.
2. Какие записи должен увидеть администратор
В типовом сценарии после выполнения задания должны появиться как минимум две записи:
журнал генерации конфигурации (Generate Config);
журнал выполнения миграции (Run).
Если используется задание DailyBackupJob, администратор должен увидеть записи, относящиеся именно к этому заданию.
На предоставленном примере в списке отображаются две записи для DailyBackupJob:
запись с ID = 1;
запись с ID = 2.
Обе записи содержат дату и время выполнения и позволяют открыть подробный журнал в нижней части страницы.
3. Анализ журнала Generate Config
Журнал генерации конфигурации подтверждает, что XRM Director смог:
подключиться к основному брокеру;
считать конфигурацию выбранных сервис-пулов;
сохранить необходимые параметры для дальнейшего переноса.
В демонстрационном сценарии из журнала должно быть видно, что система считала конфигурацию пула testpool и других связанных объектов.
На предоставленном примере журнал генерации открывается для записи Log View (ID: 1).
В начале журнала отображаются характерные строки:
Job submitted to Generate. JobID: 1;
Trying to get data from broker for 'testpool' plan name.
Далее в журнале последовательно отображаются данные, считанные из конфигурации сервис-пула, включая:
идентификатор и имя сервис-пула;
параметры пула;
группы;
транспорты;
назначенные сервисы;
assignables и другие связанные сущности.
Что полезно проверить в журнале
наличие записи о целевых сервис-пулах;
отсутствие ошибок чтения конфигурации;
наличие параметров сервис-пула;
наличие связанных объектов: транспортов, групп, пользователей, authenticators.
Место для скриншота
Скриншот 17. Детальный журнал операции Generate Config для записи ID: 1.
4. Анализ журнала Run
Журнал выполнения Run подтверждает фактический перенос конфигурации на резервную площадку.
Из него администратор должен увидеть, что система:
считала ранее сформированный план;
подключилась к резервному брокеру;
начала создание или воспроизведение объектов;
перенесла конфигурацию сервис-пулов.
На предоставленном примере журнал выполнения открывается для записи Log View (ID: 2).
В начале журнала отображаются характерные строки:
Job submitted to run. JobID: 1;
Trying to read saved data from 'plandata/DailyBackupJob.plandata' config file;
Trying to send 'testpool' data to secondary broker.
Далее в журнале отображаются пошаговые действия по воспроизведению конфигурации на резервной площадке, например:
Creating authenticators;
создание группы adm;
создание пользователей authenticator users;
последующее создание и привязка связанных объектов.
Какие объекты обычно отражаются в журнале
authenticators;
группы;
пользователи;
сервисы;
сервис-пулы;
связанные параметры и атрибуты конфигурации.
Место для скриншота
Скриншот 18. Детальный журнал операции Run для записи ID: 2.
5. Как открыть запись журнала
Для просмотра содержимого конкретной записи администратор должен:
выбрать нужную строку в верхней таблице журнала;
отметить ее чекбоксом;
нажать кнопку Просмотр.
После этого в нижней части страницы в блоке Log View отобразится содержимое выбранной записи.
Если запись не выбрана, нижняя область Log View может отображать пустое состояние No data.
6. Проверка результата на резервном брокере
После анализа журналов необходимо убедиться в фактическом результате миграции.
Для этого:
вернитесь в раздел управления брокерами;
выберите резервный брокер;
нажмите Управление;
откройте интерфейс резервной площадки;
перейдите в раздел сервис-пулов.
Что должен увидеть администратор
Если перенос выполнен успешно, на резервной площадке должны появиться сервис-пулы, которых до миграции там не было.
В демонстрационном сценарии это:
testpool;
test2pool.
Оба должны находиться в статусе Active.
Место для скриншота
Скриншот 19. Резервная площадка после успешной миграции.
7. Что считается подтверждением успешной миграции
Администратор может считать миграцию успешной, если одновременно выполнены следующие условия:
в журналах нет критических ошибок;
операция Generate Config завершилась успешно;
операция Run завершилась успешно;
на резервном брокере появились ожидаемые сервис-пулы;
сервис-пулы активны;
ключевые элементы конфигурации воспроизведены корректно.
К таким элементам могут относиться:
родительский сервис;
группа пулов;
состояния объектов;
связанные учетные записи и группы доступа.
8. Практический контроль после переноса
После успешной миграции рекомендуется дополнительно проверить:
соответствие имени и состава сервис-пулов основной площадке;
статус Active для перенесенных объектов;
доступность связанных сущностей;
отсутствие дублирующих или конфликтующих записей на резервной площадке.
Даже если операция Run завершилась без явной ошибки, администратор должен всегда подтверждать результат непосредственно на резервной площадке.
9. Результат этапа
После завершения контроля выполнения администратор должен иметь документально подтвержденный результат:
план был сгенерирован;
миграция была выполнена;
журналы подтверждают ход выполнения;
резервная площадка содержит требуемую конфигурацию.
