· Настройка на уровне приложений (сценариев). Можно изучить сценарий задания и определить, можно ли его изменить для более эффективного управления пакетным заданием.
· Настройка на уровне баз данных. Базы данных можно проиндексировать, чтобы сценарии могли быстрее находить информацию. Диспетчер мощности должен проследить за выполняемыми запросами к базе данных, определить, какие данные запрашиваются чаще всего и проиндексировать базу данных таким образом, чтобы сценарий мог быстро находить требуемые данные.
· Настройка на аппаратном уровне. Предполагает добавление вычислительной мощности архитектуры:
· На сервере может быть установлен дополнительный процессор.
· В архитектуру может быть добавлен дополнительный сервер.
· На серверах может осуществляться балансировка нагрузки для более эффективного распределения транзакций. Диспетчер мощности может назначить некоторые пакетные задания серверам, которые технически не являются частью пакетной архитектуры для временного распределения нагрузки и повышения производительности.
Помните о том, что настройка на аппаратном уровне не является «простым решением», которое обязательно повысит производительность. Если узкие места присутствуют в других областях архитектуры, добавление вычислительной мощности может и не увеличить производительность системы.
Каждый из вышеперечисленных вариантов настройки может быть полезен для улучшения производительности пакетной обработки. Однако диспетчер мощности должен понимать, каким образом выбранные варианты настройки повлияют на другие области информационной среды, прежде чем внедрять эти изменения. Например, при балансировке нагрузки на серверы вряд ли стоит назначать запланированные задания серверу, преимущественно используемому работающими пользователями, так как это может оказать неблагоприятное воздействие на производительность системы. Поэтому не следует делать каких-либо изменений до подачи запроса на изменение (RFC) и его одобрения ответственными за управление изменениями. Процесс изменений предназначен для того, чтобы не допустить неблагоприятного воздействия изменений на информационную среду. (Дополнительные сведения см. в руководстве MOF Change Management Service Management Function).
Внедрение
После анализа показателей системы и журналов ошибок, если диспетчер мощности решит, что требуется внесение изменений в пакетную архитектуру, необходимо подать RFC ответственным за управление изменениями. Ответственные за управление изменениями должны убедиться в том, что в информационную среду не вносятся недопустимые изменения, и что внедрение изменений будет иметь минимальное воздействие на эту среду. Процесс управления изменениями также предполагает проверку выполнения записи изменений информационной среды в базу данных управления конфигурациями (CMDB), которая является центральным хранилищем, содержащим информацию и связи всех информационных компонентов (оборудования, программного обеспечения, процессов, процедур, документации, и т.д.). Как и в случае с CDB, эта база данных не обязательно представляет собой единое хранилище. CDB может фактически являться частью CMDB. (Дополнительные сведения см. в руководствах MOF Change Management и MOF Configuration Management Service Management Function).
При подаче RFC диспетчер мощности должен сообщить информацию о воздействии внедрения изменения на информационную среду. Эта информация должна быть получена путем тестирования новых компонентов (например, пакетных заданий) и определения их воздействия на существующую архитектуру. Предоставление полных материалов по анализу воздействия при подаче RFC помогает ускорить процесс обзора изменений. Ответственные за управление изменениями оценивают RFC и либо утверждают, либо отклоняют его. При отклонении RFC должно быть представлено описание причины отклонения. Утвержденные RFC должны быть внедрены до следующего запланированного пакетного сеанса. При внедрении изменений диспетчер мощности должен помнить о необходимости добавления новой информации в журнал пакета.
Ответственные за управление изменениями указывают диспетчеру мощности, когда следует внедрять изменения так, чтобы свести к минимуму воздействие на операционные системы. После внедрения изменения диспетчер мощности должен протестировать изменение или проследить за работой измененных компонентов во время следующего пакетного сеанса, чтобы убедиться в эффективности внедрения. При возникновении ошибок следует отменить изменение и восстановить первоначальное состояние среды. Ответственные за управление изменениями должны быть уведомлены о результатах, успешных или неуспешных. (Дополнительные сведения о внедрении изменений см. в руководстве MOF Release Management Service Management Function).
Управление событиями
Управление событиями представляет собой мониторинг успехов и отказов пакетного процесса. Этот раздел сосредоточен на действиях, которые следует предпринять при возникновении ошибок обработки. Управление событиями обычно входит в функциональные возможности инструмента планирования.
Мониторинг событий позволяет убедиться в том, что рабочие системы постоянно функционируют в соответствии с определенными уровнями сервиса. Инструмент планирования заданий принимает события и затем направляет уведомления на соответствующие компоненты для дальнейшей обработки (например, электронные сообщения от приложений, оборудования, и т.д). Также он обеспечивает запись событий, произошедших в архитектуре системы.
Дата добавления: 2015-11-04; просмотров: 14 | Нарушение авторских прав
| <== предыдущая лекция | | | следующая лекция ==> |