Управление рабочей нагрузкой

Одна из важнейших функций базовой управляющей программы z/OS связана с решением задачи эффективного динамического перераспределения системных ресурсов (процессорного времени, основной памяти, каналов и устройств) между всеми видами выполняемых в системе работ с учетом их важности. В состав выполняемых работ включаются пакетные задания, запускаемые процедуры STC и программы поддержки интерактивных пользовательских сеансов TSO, приложения и команды, запускаемые в рамках сеансов TSO/ISPF, команды и утилиты UNIX shell, транзакции CICS, DB2 и др. Иногда такую задачу называют "балансировкой рабочей нагрузки", поскольку в условиях постоянно меняющегося объема выполняемых в системе работ, с одной стороны, требуется поддерживать приемлемый или заданный уровень пропускной способности (или времени реакции), а с другой - обеспечить максимальную загрузку имеющихся ресурсов, не допуская при этом ситуаций, когда какого-либо ресурса недостает. Решение этой задачи возложено на менеджера управления рабочей нагрузкой WLM (WorkLoad Manager), который впервые был представлен в MVS SP V5. Возможности WLM распространяются на множество работ, выполняемых в том числе и в кластере Parallel Sysplex.

WLM реализует эффективную модель управления нагрузкой, получившую название "целевой режим" (goal mode) и основанную на выборе и описании ожидаемых целей функционирования для каждой из выполняемых работ [8]. Отметим, что одновременно вплоть до z/OS V1R2 поддерживался и так называемый "режим совместимости" (compatibility mode) - ныне не применяемая модель управления, ориентированная на низкоуровневые средства настройки и контроля использования ресурсов с помощью менеджера системных ресурсов SRM (System Resource Manager).

Рассмотрим основные принципы управления рабочей нагрузкой в целевом режиме WLM. Все выполняемые в системе работы делятся на непересекающиеся группы, называемые классами обслуживания (service class). Принадлежность конкретной работы к тому или иному классу определяется по ее атрибутам, таким как тип работы (пакетное задание, транзакция и т.п.), идентификатор пользователя, учетная информация, используемая подсистема (среда) выполнения и др.
Атрибуты каждого класса обслуживания назначаются системным администратором при настройке системы или устанавливаются по умолчанию. Таким образом, в каждом классе объединяются работы с идентичными характеристиками с точки зрения используемых ресурсов и требуемой производительности.

С каждым классом обслуживания ассоциируется определенная цель выполнения (goal) и показатель важности (importance). С помощью WLM могут быть определены три типа целей выполнения, условно обозначаемых как время отклика, избирательность и скорость выполнения.

Цель типа "время отклика" (response time) означает установку желаемой длительности выполнения работы, которая измеряется от момента запуска (ввода) запроса до получения результата. Эта цель обычно выбирается для коротких транзакций, поступающих от интерактивных пользователей, и может быть задана двумя способами. Первый способ заключается в установке среднего времени отклика: например, 0,5 с для всех работ данного класса обслуживания. Второй способ позволяет дополнительно указать долю работ, для которых необходимо обеспечить требуемое время реакции: например, 80% работ данного класса обслуживания должны быть выполнены не более чем за 0,5 с.

Цель "избирательность" (discretionary) устанавливается для работ, у которых нет жестких ограничений по длительности выполнения. В этом случае система может предоставлять таким работам ресурсы по принципу "разумной достаточности" - только в периоды невысокой общей нагрузки и когда другие работы достигли своих целей. Данная цель может быть назначена, например, для низкоприоритетных пакетных заданий, которым система лишь гарантирует завершение (рано или поздно).

Цель "скорость выполнения" (velocity) назначается для работ, для которых первые две цели неприемлемы. К этой категории относятся, например, длительные или "бесконечные" по времени выполнения работы, которые тем не менее нельзя отнести к низкоприоритетным. Скорость выполнения задается целым числом в диапазоне 1-99.

Чем выше уровень установленной скорости, тем больше вероятность получить необходимые ресурсы без предварительного ожидания.

Показатель важности класса обслуживания характеризует, насколько важно для работ данного класса достичь установленной цели. Данный показатель, принимающий целочисленные значения в диапазоне от 1 до 5, применяют в тех случаях, когда в системе возникает дефицит ресурсов и требуется "пожертвовать" какими-то работами (то есть заставить их ждать). При разрешении коллизий работы класса обслуживания с показателем важности 1 будут иметь преимущество перед работами всех остальных классов. Для классов, имеющих цель "избирательность", показатель важности не назначается.

Выполнение работ каждого класса обслуживания представляется в виде последовательности периодов (period), для каждого из которых могут быть заданы различные цели и показатели важности. Продолжительность периода определяется по условному количеству выделенных для периода ресурсов, измеряемому в так называемых единицах обслуживания (service units). Эта величина зависит от количества использованных процессорных квантов для выполняемых задач (TCB и SRB), числа запросов на доступ к памяти и ввод-вывод, а также типов используемых устройств и оборудования.

Каждые четыре секунды WLM производит сбор данных о производительности для каждого класса обслуживания. На основе полученных данных осуществляется корректировка текущего распределения ресурсов, с тем чтобы приблизить более приоритетные работы к установленной цели. Если несколько работ конкурируют за получение одного и того же ресурса, то WLM производит выбор путем их "взвешивания" на основе заданных целей и показателей важности. Менеджер управления рабочей нагрузкой принимает участие в реализации всех важнейших системных механизмов, включая:

управление созданием новых адресных пространств;
управление страничным обменом (предотвращение нехватки памяти, откачка страниц);
организацию свопинга (временное высвобождение ресурсов от низкоприоритетных работ);
блокировку приема пакетных, STC и TSU заданий при повышенной нагрузке (нехватка свободных страниц в страничных наборах или в центральной памяти, пробуксовка страниц и т.п.)
управление диспетчерскими приоритетами задач;
управление пакетными инициаторами, обеспечивающими выполнение пакетных заданий;
управление приоритетами при вводе-выводе;
управление распределением наборов данных по устройствам.

Еще одно важное понятие, используемое WLM, - стратегия обслуживания

(service policy), которая позволяет динамически изменять параметры (цели, периоды, показатели важности) для установленных классов обслуживания в течение рабочего дня или в зависимости от дня недели и иных критериев.

Настройка параметров WLM осуществляется системным программистом на основе специальной диалоговой программы, доступной в TSO/ISPF.

Ранее отмечалось, что в z/OS появился новый компонент для динамического управления ресурсами в режиме LPAR с учетом рабочей нагрузки - интеллектуальный менеджер ресурсов IRD (Intelligent Resource Director) [9]. IRD расширяет концепцию целевого режима управления рабочей нагрузкой, реализуемую WLM, путем предоставления ресурсов логических разделов LPAR, размещенных как на одном физическом сервере, так и в рамках сисплекса (так называемый кластер LPAR). Новые возможности IRD затрагивают решение следующих основных задач применительно к целевому режиму управления:

динамическое изменение доли процессорного времени (processor weight), выделяемого логическому разделу (LPAR CPU management);
динамическое переопределение канальных путей между LPAR для повышения эффективности ввода-вывода с учетом целевых критериев выполняемых работ (dynamic channel path management, DCM);
организация доступных всем LPAR дополнительных очередей на ввод-вывод с учетом целевых критериев выполняемых работ (channel subsystem priority queuing, CSSPQ).

При управлении ресурсами системы существенную роль играют еще два компонента z/OS: SMF и RMF.

Компонент SMF (System Management Facility) входит в состав базовой управляющей программы и предназначен для сбора и регистрации информации, касающейся функционирования z/OS и приложений. SMF работает в собственном адресном пространстве. Собранная информация накапливается в виде так называемых SMF-записей в специальных VSAM - наборах данных с именами SYS1.MANx (х - целое число). Различают два типа записей: с системной и пользовательской информацией. SMF-записи с системной информацией включают, например, сведения о конфигурации системы, активности страничного обмена, рабочей нагрузке и интенсивности использования различных ресурсов.

SMF-записи с пользовательской информацией содержат данные об использовании процессоров и устройств (в первую очередь DASD) для каждого шага задания и задания в целом, а также для пользовательских сеансов TSO. Собранная SMF информация используется различными компонентами z/OS, включая WLM, а также доступна пользователю непосредственно или с помощью рассматриваемого ниже компонента RMF. Настройка SMF осуществляется с помощью раздела SMFPRM реестра SYS1.PARMLIB.

Менеджер сбора данных о ресурсах RMF (Resource Measurement Facility) принадлежит к числу опциональных компонентов z/OS и содержит средства для сбора данных и формирования отчетов об использовании ресурсов и производительности системы. Отчеты, формируемые RMF, могут использоваться для анализа текущего состояния системы, выявления узких мест, а также выбора наиболее эффективной стратегии управления ресурсами и нагрузкой и планирования развития аппаратного обеспечения системы.

В состав RMF входят три программных монитора.

Монитор III - предназначен для сбора и анализа информации на коротком отрезке времени (сбор первичных данных с периодом 1 с, консолидация собранных данных с сохранением результатов - каждые 100 с). Позволяет получить сведения о значениях времени отклика и скорости выполнения работ, информацию о задержках, сказавшихся на производительности.
Монитор II - предназначен для сбора и анализа информации об использовании конкретного ресурса (например, процессоров, дискового тома, основной памяти) либо об активности и потребляемых ресурсах применительно к указанному адресному пространству или заданию в текущий момент времени. Может осуществляться непрерывный контроль состояния адресного пространства или задания.
Монитор I - предназначен для сбора и анализа информации о рабочей нагрузке и использовании ресурсов на длительном (указанном) отрезке времени (по умолчанию период сбора - 1 с, период консолидации - 30 мин). Значения временных периодов могут быть заданы пользователем. В остальном - то же, что и монитор III.

Для хранения собранной информации все три типа мониторов могут задействовать наборы данных SMF, а монитор III, кроме того, использует собственный набор данных VSAM. Использование RMF осуществляется через диалоговый интерфейс, доступный в TSO/ISPF, однако существует возможность запуска мониторов RMF в пакетном режиме с выводом отчетов в указанный набор данных. При этом можно получать сообщения о возникающих проблемах.

Для хранения собранной информации все три типа мониторов могут задействовать наборы данных SMF, а монитор III, кроме того, использует собственный набор данных VSAM. Использование RMF осуществляется через диалоговый интерфейс, доступный в TSO/ISPF, однако существует возможность запуска мониторов RMF в пакетном режиме с выводом отчетов в указанный набор данных. При этом можно получать сообщения о возникающих проблемах.

1)

Термин Bar можно перевести как <пробел>, <планка>, <барьер> - кому что нравится. Появились также термины <above the bar> и <below the bar> для обозначения областей виртуальной памяти, лежащих соответственно выше Bar-области (для доступа требуется 64-разрядный адрес) и ниже (достаточно 31-разрядного адреса).

Содержание раздела