Размер базы данных и производительность
Размер базы данных является ключом для понимания производительности System Center — Orchestrator. Функционирование серверов Runbook, серверов Management и веб-компонентов полностью зависит от базы данных Orchestrator. Проблемы с развертываниями Orchestrator могут возникать из неполного понимания типов данных в базе данных и способах их управления.
Поскольку Runbook Designer взаимодействует с базой данных Orchestrator (через сервер Management), низкая производительность базы данных будет тормозить эти связи.
Интерфейс оператора Orchestrator основан на двух компонентах: Консоль оркестрации и веб-служба. Консоль Orchestration — это приложение на платформе Silverlight, которое использует веб-службу для подключения к базе данных Orchestrator. Веб-служба — это приложение IIS, которое подключается к базе данных. Таким образом, веб-служба и консоль оркестрации зависят от производительности базы данных Orchestrator.
Кроме того, хотя Консоль Orchestration зависит от веб-службы, она также имеет уникальную логику для своей работы как пользовательского интерфейса и собственные характеристики производительности.
Данные конфигурации и данные журнала
На высоком уровне база данных Orchestrator содержит два типа данных:
Данные конфигурации
Инфраструктура Orchestrator содержит данные конфигурации. Эти данные не являются проблемой в контексте роста базы данных, так как требования к хранилищу для этого типа данных невелики.
Данные журнала
Orchestrator создает различные типы данных журнала, все из которых можно просматривать и управлять ими в конструкторе Runbook. Требования к хранилищу для этих данных могут отличаться по размеру и могут быть большими.
В следующей таблице перечислены типы данных, которые могут храниться в базе данных Orchestrator. Orchestrator также хранит данные в отдельных файлах журнала (за пределами базы данных) для аудита и трассировки. Дополнительные сведения обо всех типах данных журнала см. в разделе Orchestrator Logs.
| Тип данных журнала | Расположение в Runbook Designer | Управляется функцией очистки журнала? |
|---|---|---|
| Журналы "Runbook" | Вкладки Журнал и История журнала | Да |
| События активности (платформы) | ВкладкаСобытия | Нет |
| История аудита | ВкладкаЖурнал аудита | Нет |
Код платформы и код домена
Действия Runbook Orchestrator содержат два разных типа кода:
Код платформы
Это общий код, общий для большинства действий и используется для выполнения распространенных задач, выполняемых действиями Orchestrator. Код платформы создает общие опубликованные данные.
Код домена
Выполняет различные задачи, специфичные для каждой активности, которые обычно не связаны с самой платформой Orchestrator. Возможно, существует значительное различие между кодом платформы и кодом домена.
Журнальные данные, которые создает данное действие, могут содержать элементы с одним или несколькими значениями. Каждое действие создает одну запись с одним значением данных. Код домена может создавать несколько записей данных с несколькими значениями. Поэтому код домена отвечает за определение процедуры, выполняемой действием с общими опубликованными данными, которые оно получило от предшествующих действий.
По существу, модули Runbook в Orchestrator предназначены для передачи данных между дискретными элементами кода домена. Кроме того, код домена может опционально генерировать данные, публикуемые для конкретной активности.
Все модули Runbook выполняют подобные функции: они запускают действия, которые состоят из кода домена и кода платформы; организуют цикличность рабочих процессов и создают ветвление. Ветвление возникает, когда модуль Runbook вызывает другие модули Runbook для выполнения определенной задачи. При первом вызове модуля Runbook он состоит из одного потока. Когда этот поток обнаруживает активность Runbook, ссылки которой требуют ветвления, создаются дополнительные потоки — по одному для каждой ветви. Каждый поток принимает на вход общие опубликованные данные от активности, которая создала ветвь. Эти данные сопоставляются с предшествующими действиям в модуле Runbook для обновления общих опубликованных данных, на которые подписываются действия.
Код домена может влиять на производительность базы данных в большей степени, чем многопоточность, создаваемая ветвлением. Это объясняется тем, что код домена потенциально может генерировать большие объемы данных, публикуемой для конкретной деятельности.
Параметры ведения журнала
С помощью вкладки Ведение журнала в окне Свойства для модуля Runbook можно настроить необязательное сохранение записей журнала. Термин ведение журнала по умолчанию означает следующее: ни один из двух параметров опубликованных данных не выбран, а для каждого действия генерируется 524 байта данных. Опции журналирования предусматривают две категории общедоступных опубликованных данных.
Общие опубликованные данные
Набор элементов данных, общих для всех действий. Для получения списка см. Параметры журнала Runbook.
Этот параметр ведения журнала для каждого действия создает 6082 байта данных.
Опубликованные данные, относящиеся к действиям
Набор данных, специфичных для определенного действия, которые при необходимости создаются кодом домена.
Этот параметр ведения журнала генерирует 6082 байта в дополнение к байтам, записываемым определенными действиями.
Совет
Этот параметр выбирается главным образом для целей отладки. Не устанавливайте этот флажок, чтобы ограничить рост размеров журнала.
Установка параметров ведения журнала может существенно повлиять на производительность и усилить разрастание базы данных. Рассмотрим сценарий, когда одно и то же действие Runbook выполняется дважды: сначала с ведением журнала данных на уровне, используемом по умолчанию (при отсутствии выбранных параметров опубликованных данных), а затем при выборе общих параметров опубликованных данных. На выполнение кода домена должно быть затрачено одинаковое количество времени. Однако на выполнение кода платформы потребуется больше времени, поскольку он должен поддерживать ведение журнала опубликованных данных, общий объем которого в 12 раз больше, чем при ведении журнала только на уровне по умолчанию.
Очистка журналов
Параметры по умолчанию, указанные для функции Очистка журналов в Конструкторе Runbook, настроены для обеспечения оптимального взаимодействия с пользователем при развертывании оркестратора из коробки. Изменение этих значений может изменить характеристики производительности среды и должно быть реализовано постепенно и высокоуровнево, чтобы можно было оценить эффект изменения.
Дополнительные сведения об автоматической и ручной очистке журналов см. в разделе "Очистка журналов Runbook".
Создание тестов производительности
Чтобы создать простую рабочую книгу для проверки роста ведения журнала, можно использовать стандартное действие Compare Values для создания эталонов среды Orchestrator.
Следующая процедура создает рунбук, который запускает действие Сравнить значения 10 000 раз. Сравнение значений — это простое действие, код домена которого является минимальным. Этот модуль Runbook можно вызывать при различных обстоятельствах, чтобы охарактеризовать общую производительность заданной среды выполнения Orchestrator.
Создание модуля Runbook, который можно использовать для тестирования среды Orchestrator
Создайте новый модуль Runbook.
Добавьте действие Compare Values из палитры стандартных действий. Дважды щелкните по активности, чтобы ее настроить.
Выберите вкладку "Общие " и настройте это действие для сравнения строк (значение по умолчанию).
Выберите вкладку "Сведения" , введите значение STRING в поле "Тест " и нажмите кнопку "Пустая".
Нажмите кнопку "Готово ", чтобы сохранить обновления для действия.
Щелкните правой кнопкой мыши действие и выберите Цикл.
Установите флажок "Включить" и введите число 0 (ноль) для задержки между попытками.
Выберите вкладку "Выход ".
Измените условие выхода по умолчанию. Выберите "Сравнить значения", установите флажок "Показать распространенные опубликованные данные" и выберите "Цикл: количество попыток". Нажмите кнопку "ОК ", чтобы сохранить это изменение.
Выберите значение из обновленного условия выхода и введите число 10000 (десять тысяч). Нажмите кнопку "ОК ", чтобы сохранить это изменение.
Нажмите кнопку "Готово ", чтобы сохранить эти обновления.
Нажмите кнопку "Войти" , чтобы сохранить изменения в базе данных Orchestrator.
Данный модуль Runbook может использоваться для экспериментов с разными конфигурациями Orchestrator. Например, можно создать тестовые модули Runbook для определения производительности четырех серверов Runbook, развернутых в разных центрах обработки данных.
| Центр обработки данных | Конфигурация ведения журнала | Время работы кода платформы (в миллисекундах) | Миллисекунд на активность | Коэффициент масштабирования |
|---|---|---|---|---|
| Расположение 1 | журналирование по умолчанию | 819 | 82 | 1,0 (эталон) |
| Расположение 1 | Ведение журнала общих опубликованных данных | 2012 | 201 | 2.5 |
| Расположение 2 | ведение журнала по умолчанию | 1229 | 123 | 1.5 |
| Расположение 2 | Ведение журнала общих опубликованных данных | 3686 | 369 | 4,5 |
| Расположение 3 | ведение журнала по умолчанию | 2457 | 426 | 3.0 |
| Расположение 3 | Ведение журнала общих опубликованных данных | 4422 | 442 | 5,4 |
| Расположение 4 | ведение журнала по умолчанию | 1474 | 147 | 1.8 |
| Расположение 4 | Ведение журнала общих опубликованных данных | 2654 | 265 | 3.2 |
Обратите внимание на значительное снижение производительности платформы, вызванное ведением журнала общих опубликованных данных. Наихудший сценарий, по-видимому, заключается в журналировании общих опубликованных данных на Местоположении 2. На первый взгляд, здесь все ясно и выводы очевидны.
Однако следует отметить, что эти данные отражают издержки кода платформы, а не кода домена. Время выполнения кода домена может занимать больше времени. Например, действие Создание ВМ из шаблона в пакете интеграции диспетчера виртуальных машин может работать несколько минут, пока будет создана ВМ. Расширяя предыдущий пример, рассмотрим затраты на код платформы в процессе runbook, который занимает 1 минуту (1 минута = 60 000 миллисекунд) вне зависимости от расположения.
| Центр обработки данных | Конфигурация ведения журнала | Время работы кода платформы (в миллисекундах) | Код домена — % | % Код платформы |
|---|---|---|---|---|
| Расположение 1 | ведение журнала по умолчанию | 819 | 98,6 % | 1,4 % |
| Расположение 1 | Ведение журнала общих опубликованных данных | 2012 | 96,7 % | 3,3 % |
| Расположение 2 | ведение журнала по умолчанию | 1229 | 98,0 % | 2,0 % |
| Расположение 2 | Ведение журнала общих опубликованных данных | 3686 | 93,9 % | 6,1 % |
| Расположение 3 | ведение журнала по умолчанию | 2457 | 95,9 % | 4,1 % |
| Расположение 3 | Ведение журнала общих опубликованных данных | 4422 | 92,6 % | 7,4 % |
| Расположение 4 | ведение журнала по умолчанию | 1474 | 97,5 % | 2,5 % |
| Расположение 4 | Ведение журнала общих опубликованных данных | 2654 | 95,6 % | 4,4 % |
Из этих данных начинает вырисовываться более четкая картина. Сценарий, в котором журналирование общих опубликованных данных включено в Расположении 2, продолжает оставаться наименее эффективным вариантом. Однако код платформы и ведение журнала занимают всего 6% от общего времени выполнения. Хотя это и существенная цифра, в лучшем случае — 1,4 %. Фактически, время, затрачиваемое в примере кодом домена, намного превышает время выполнения кода платформы. Чтобы понять это, если вы смогли полностью исключить затраты на код платформы, вы увидите только улучшения производительности модуля Runbook в диапазоне от 1,4% до 7,4%.
Большинство реальных сценариев будут отличаться. Поведение действия может варьироваться в зависимости от того, что должен делать код домена. Например, действие Клонирование виртуальной машины из шаблона может занять одну минуту для клонирования виртуальной машины из шаблона сервера A, но пять минут для клонирования виртуальной машины из шаблона сервера B. Кроме того, серверы Runbook могут находиться в разных сетях с различными характеристиками производительности, что потенциально влияет как на производительность доменного кода, так и на производительность ведения журнала данных Orchestrator.
Определение роста базы данных
Для определения стратегии роста файла базы данных администратор базы данных Orchestrator может использовать следующие рекомендации:
Как правило, файлы базы данных не будут увеличиваться при каждом вызове модуля Runbook. Файлы разрастаются, когда содержащиеся в них данные достигают настроенного администратором базы данных определенного верхнего предела, при котором файл должен расшириться.
Каждое действие runbook должно учитываться по отдельности, особенно когда циклические функции могут привести к многократному выполнению одного действия.
Чтобы определить хранилище, необходимое для каждого вызова модуля Runbook, умножьте количество действий в runbook на количество байтов, добавленных в базу данных в соответствии с выбранным уровнем ведения журнала. Это такие значения:
524 байта
Конфигурация ведения журнала по умолчанию.
6082 байта
Уровень ведения журнала общих опубликованных данных.
6082 байта + данные, записываемые действием
Уровень ведения журнала данных, публикуемых в зависимости от активности.
По умолчанию Orchestrator очищает все журналы, кроме 500 новых журналов, для каждого модуля Runbook ночью в 02:00. Для определения объема пространства, необходимого для всех вызовов модуля Runbook, умножьте объем пространства, необходимого для каждого вызова модуля Runbook, на 500. При изменении параметра «Очистка журнала» следует соответственно умножить данные каждого вызова на расчетное число вызовов в день, неделю или месяц.
В следующей таблице показаны оценки роста и производительности для конфигураций уровней ведения журнала.
| Уровень логирования | Коэффициент роста базы данных | Коэффициент производительности | Рекомендуется для производства. |
|---|---|---|---|
| По умолчанию. | 1 | 1 | Да |
| Общие опубликованные данные | 11,6x | 2,5x | Ограниченное использование с планированием |
| Публикуемые данные, специфичные для определенных действий | Больше чем 11,6x | Больше чем в 2,5 раза | Нет |
Примеры
Пример 1
В следующей таблице описываются рекомендации по размеру базы данных для развертывания Orchestrator.
| Название runbook | Число действий | Уровень логирования | Число вызовов в день |
|---|---|---|---|
| Runbook 1 | 50 | По умолчанию. | 100 |
| Runbook 2 | 25 | По умолчанию. | 50 |
| Runbook 3 | 12 | Общие опубликованные данные | 24 |
| Runbook 4 | 8 | Общие опубликованные данные | 500 |
Используя описанные выше параметры базы данных, можно оценить требования к пространству хранения для модулей Runbook.
| Имя ранбука | Байтов на вызов | Объем хранилища в МБ Очистка журнала по умолчанию (500 вызовов) |
Количество вызовов за месяц | Объем хранилища в МБ Один месяц (Нет очистки журнала по умолчанию) |
% объема хранилища БД через 30 дней |
|---|---|---|---|---|---|
| Runbook 1 | 26 200 | 12.5 | 3,000 | 74,5 % | 9% |
| Runbook 2 | 13 100 | 6,2 | 1500 | 18.7 | 2% |
| Runbook 3 | 72 984 | 34,8 | 720 | 50,1 | %6 |
| Runbook 4 | 48 656 | 23,2 | 15 000 | 696,0 | 83 % |
| Всего: 76,7 МБ | Всего: 839,3 МБ |
Этот пример ясно иллюстрирует важность принятия взвешенных решений по ведению журнала данных. Runbook 4 содержит только восемь действий, но при настройке на уровне ведения журнала общих опубликованных данных он потребляет большую часть хранилища в базе данных из-за высокой частоты вызова. На основе этих результатов можно уменьшить уровень ведения журнала Runbook 4 до конфигурации ведения журнала по умолчанию.
Пример 2
В следующей таблице описываются рекомендации по размеру базы данных для другого развертывания Orchestrator.
| Имя руководства по операциям | Число действий | Уровень логирования | Число вызовов в день |
|---|---|---|---|
| Runbook 1 | 50 | По умолчанию. | 100 |
| Runbook 2 | 25 | По умолчанию. | 50 |
| Runbook 3 | 12 | Общие опубликованные данные | 24 |
| Runbook 4 | 8 | По умолчанию. | 500 |
После пересчета параметров хранилища для обновленной конфигурации результаты существенно отличаются от предыдущих.
| Имя runbook | Байтов на вызов | Объем хранилища в МБ Очистка журнала по умолчанию (500 вызовов) |
Число вызовов в месяц | Объем хранилища в МБ Один месяц (Нет очистки журнала по умолчанию) |
% объема хранилища БД через 30 дней |
|---|---|---|---|---|---|
| Runbook 1 | 26 200 | 12.5 | 3,000 | 74,5 % | 37 % |
| Runbook 2 | 13 100 | 6,2 | 1500 | 18.7 | 9% |
| Runbook 3 | 72 984 | 34,8 | 720 | 50,1 | 25% |
| Runbook 4 | 4192 | 2.0 | 15 000 | 60,0 | 29 % |
| Всего: 55,5 МБ | Всего: 203,3 МБ |
Хотя в конфигурации ведения журнала по умолчанию мало изменений (500 записей журнала на runbook), требования к хранилищу на 30 дней изменились значительно. Очевидно, что затраты на хранение при использовании ведения журнала общих опубликованных данных для Runbook 4 следует тщательно учитывать, так как это изменение приводит к сокращению требований к хранилищу баз данных на 76 % в течение 30 дней.
Итоги
При управлении размерами и производительностью баз данных придерживайтесь следующих рекомендаций:
Включайте ведение журнала общих опубликованных данных только при необходимости.
Помните, что время выполнения действия определяет объем журнальных данных. Небольшой модуль Runbook с несколькими действиями выполняется несколько раз, что может привести к большему ведению журнала данных, чем более крупный модуль Runbook, выполняющий меньшее количество раз.
Не включайте ведение журнала опубликованных данных, связанных с конкретными действиями, в производственных средах. Их следует использовать только для целей отладки.
Исследуйте, сколько времени модули Runbook тратят на выполнение кода домена по сравнению с выполнением кода платформы.
Оцените издержки кода платформы с помощью методик, описанных в этом документе. Используйте эти данные как ссылочные материалы при анализе возможностей повышения производительности модулей Runbook.
Определите возможности для улучшений, проведя нормализованные сравнения измерений.