После настройки системы на мониторинг определенных уровней пороговых значений, важно, чтобы операции мониторинга выполнял квалифицированный персонал. Диспетчер мощности, неспособный определить и диагностировать проблемы системы, не сможет исправить ошибки. Важно, чтобы диспетчер мощности был достаточно опытным, и чтобы была доступна документация, которая бы помогала в выявлении и исправлении проблем. Если возможно, полезно было бы настроить инструмент планирования на автоматическое создание билета сервиса в случае ошибки или предупреждения. Это позволяет обеспечить точное определение проблемы и максимально сократить время на ее разрешение.
Обработка запросов по требованию
Запросы по требованию обычно представляют собой неповторяющиеся пользовательские запросы на запуск пакетного задания вручную. Рисунок 7 иллюстрирует процесс обработки запросов по требованию.
Рисунок 7. Процесс обработки запроса по требованию
Все подаваемые запросы по требованию должны пройти процесс, показанный на рисунке 7. Все запросы должны подаваться в формате схемы пакета, что облегчает просмотр и утверждение запросов. Диспетчер мощности начинает процесс с изучения поданного запроса на наличие всей требуемой информации. При отсутствии требуемой информации запрос отклоняется, и владельцу запроса направляется уведомление с объяснением; владелец может повторно подавать запросы в любое время.
Принятые запросы по требованию должны сначала быть выполнены в тестовом окружении и профиле пакетного задания, при этом должен быть получен набор показателей, описывающих производительность выполнения задания. Профиль должен быть сохранен на случай повторной подачи запроса. При неудачном тестировании нужно попытаться определить причину отказа и возвратить владельцу запрос вместе с объяснением. Обычно ошибки возникают по причине неполноты или неточностей при кодировании сценариев пакетного задания.
На основании профиля диспетчер мощности решает, когда задание должно быть выполнено, принимая во внимание требования задания к ресурсам и доступные требования пакетной архитектуры к ресурсам. Диспетчер мощности должен сообщить владельцу, когда задание будет выполнено, и передать ему результаты задания после выполнения сеанса. Печать, архивация и публикация отчетов выполняется в соответствии с запросом пользователя и выполнением сценария. Архивированные отчеты должны храниться в базе данных вне пакетной архитектуры.
Изменение расписаний
Изменения в расписании могут быть как запланированными, так и незапланированными. Незапланированные изменения происходят по причине ошибок обработки или предупреждений системы. Запланированные изменения вносятся в ответ на анализ оптимизации системы. Запланированные изменения назначенных пакетных сеансов отслеживаются с использованием процесса управления изменениями, так как изменения в рабочих сеансах требуют подачи RFC. Это обеспечивает внесение только допустимых изменений и обеспечивает надлежащий уровень контроля и учета повседневных операций процесса планирования заданий. (Дополнительные сведения см. в руководстве MOF Change Management Service Management Function). Рисунок 8 иллюстрирует процесс изменения пакетного расписания.
Рисунок 8. Процесс изменения пакетного расписания
Изменения в назначенных пакетных сеансах обычно относятся к одной из двух категорий:
· Изменения в расписании пакетного сеанса:
· Изменение времени запуска/остановки пакетного сеанса.
· Изменение в пакетных заданиях, относящихся к сеансу.
· Изменение приоритета пакетного задания.
· Изменение времени запуска/остановки пакетного задания.
· Изменения в пакетном задании:
· Добавление задания.
· Удаление задания.
· Изменение задания.
Любые изменения в пакетных заданиях влияют на производительность обработки пакетного сеанса и должны быть протестированы и утверждены до внедрения в пакетной среде. Эти изменения должны сопровождаться утвержденным RFC. Добавляемые или изменяемые пакетные задания должны проходить тестирование в тестовом окружении и, как и в случае с запросами по требованию, должен быть разработан профиль нового задания. Подлежащие сбору параметры профиля включают:
· Использование дисков
· Использование памяти
· Использование сети
· Использование процессора
· Время, требуемое для выполнения задания
Профиль задания можно экстраполировать с целью оценки требований к ресурсам и времени в случае изменения задания. Например, если профиль основан на задании, содержащем 1000 записей, диспетчер мощности может экстраполировать результаты профиля и определить, сколько времени займет выполнение такого же задания, состоящего из 3000 записей, и какими будут показатели использования ресурсов. После этого диспетчер мощности сможет определить, окажет ли изменение входных параметров (т.е. количества записей) неблагоприятное влияние на выполнение этого задания или других заданий. Другими словами, будет ли измененное задание препятствовать доступу других заданий к требуемым ресурсам или наличию у них достаточного количества времени для завершения выполнения? Это очень полезно при ограниченности ресурсов тестирования.
Дата добавления: 2015-11-04; просмотров: 13 | Нарушение авторских прав
| <== предыдущая лекция | | | следующая лекция ==> |