Если спросить администратора любой системы на х86 сервере в чем их система и как измеряет выполненную работу, то в ответ услышишь "А зачем это надо? Выполняется и хорошо. Чего еще?". Может я ошибаюсь, поправьте в комментариях.

Здесь я хочу рассказать о измерении выполненой работы в z/OS, зачем это делается и какие из этого могут быть финансовые последствия (нет не штрафы и пени, а скорее наоборот).

Вот фрагмент протокола выполнения пакетного задания:

17.25.40 JOB18531  IEF403I SIVBRGE0 - STARTED
17.25.41 JOB18531  -                                      -----TIMINGS (MINS.)------                          -----PAGING COUNTS----
17.25.41 JOB18531  -STEPNAME PROCSTEP    RC   EXCP   CONN       TCB       SRB  CLOCK          SERV  WORKLOAD  PAGE  SWAP   VIO SWAPS
17.25.41 JOB18531  -STEP1    D1          00      5      3       .00       .00     .0            12  BATCH        0     0     0     0
17.26.18 JOB18531  -DBRGET   GO          00    684    192       .09       .00     .6         31555  BATCH        0     0     0     0
17.26.18 JOB18531  -STEP2    D1          00      5      3       .00       .00     .0            11  BATCH        0     0     0     0
17.32.40 JOB18531  -DBRGET   GO          00   2221    591       .43       .04    6.3        149929  BATCH        0     0     0     0
17.32.40 JOB18531  IEF404I SIVBRGE0 - ENDED

Если присмотреться то можно почти все понять без особых объяснений. И все таки. В задании SIVBRGE0 выполнялись два шага (STEP1, and STEP2). В каждом шаге выполнялась процедура с двумя исполняемыми шагами D1, и GO. Т.е. проще говоря исполнялись два шага процедуры с двумя исполняемыми шагами.

И мы видим столбцы RC - код возврата, 0 это очень хорошо, EXCP - количество выполненных операций I/O, CONN - какие то коннекции, наверное к базе данных, не важно пока, TCB - время выполнения в состоянии задача, SRB - в состоянии Service Request Block , CLOCK - wall clock.

Сдвинем картинку вправо и увидим столбец SERV, и WORKLOAD. Paging Counts нас сегодня не интересует.

SERV это количество сервисных единиц (Service Units, SU) затраченных на выполнение шага задания. WORKLOAD название первого уровня иерархии (Workload) в WLM полиси на котором "живут" другие элементы полиси как то Service Classes. В данном случае workload это пакетное задание (BATCH).

Вернемся к SU, Что это? Это интегрированный показатель используемых ресурсов МФ, он включает и время CPU и ввод-вывод и память. Естественно просто складывать время и ... что там в вводе-выводе, не понятно, память в мега-, гига- байтах измеряется не возможно. Но ИБМ (z/OS) умеет измерять и скадывать нескладываемое используя коэффициенты разные для каждого ресурса. Измерение в SUs используется давно, на основании опыта создания многих поколений МФ, знаний о МФ, измерений, исследований.

Равно как ИБМ (z/OS) умеет измерять количество SU использованых, в данном случае пакетным заданием, а в общем случае любой активности в z/OS, ИБМ также умеет измерять производительность конкретной конфигурации МФ. Но уже не в SU, а в миллионах SU или MSU. МФ на котором выполнялось задание, протокол которого приведен выше, это z14, ZR1, capacity model A01 и его производительность 11 MSU.

Это как электростанции и потребители электричества.

Ну и что с этим делать спросите вы. Первое это то что цены на лицензии ПО (z/OS, DB2, CICS, ! Cobol и другое ПО называемое Сlassic) зависят напрямую от MSUs вашего МФ, точнее его capacity model, их сотни и их можно менять как вверх так и вниз ничего не изменяя в самом железе. Чем это вам не облако? Для этого правда надо быть на саппорте в ИБМ. Ниже я пиведу больше информацию про цены и настройке производительности МФ под нужды пользователя, которые к сожалению пока недоступно в России.

Другое применение (доступное в Росси при наличии МФ и z/OS) способности измерять SU мы находим в WLM (я в предыдущей статье привел некоторую информацию о WLM здесь приведу дополнение для лучшего понимания WLM).

Каждая активность будь то пакетное задание, адресные пространств DB2 (их несколько на каждую инстранс DB2), DB2 threads запущенные из TSO или CICS, DB2 enclaves (enclave это транзакция, которая может охватывать несколько диспетчируемых единиц в одном или нескольких адресных пространствах, WLM различает и управляет enclave как единым целым), запущенные удаленным клиентом, адресные прстранства CICS, WebSphere enclaves процессы в Unix System Services, и тд. и т.п. всё отслеживается системой и доступно WLM. Что еще важно это то что квалификационные признаки активностей, например, юзер аккаунт, его сетевые координаты тоже доступны и используются WLM. Посмотрим для чего.

WLM на основе квалификационных параметров и квалификационных правил назначает активностям классы сервисов (Service Class). Связь их один-к-одному. Сервис класс состоит из периодов. Их может быть от одного до нескольких. Каждый период кроме последнего имеет продолжительность. Продолжительность задается... в SUs. Это работает следущим образом. Стартует активность, WLM назначает ей параметры выполнения первого периода в сервис классе. Идет выполнение активности с параметрами первого периода сервис класса. И вот активность использовала назначенные периоду SUs. WLM переключает активность на параметры следущего периода, с более низкими важностью и другими параметрами периода, но может быть и наоборот, более высокими. Правил на этот счет нет. Последний период не имеет продолжительности и активность выполняется до своего завершения в последнем периде. Активность может завершиться на любом периоде. Т.е. в течении жизни активности она может иметь разные параметры выполнения (выражаемые в итоге в приоритете диспетчирования) в разное время жизни.

Отчеты WLM содержат гистограммы нахождений активностей на разных периодах сервис классов и используются для настройки продолжительностей периодов.

Как видим измерение использованых работами/активностями ресурсов применяется на Мф в самом широчайшем смысле от просто учета до управления процессами работ и активностей.

Дополнения об управлении производительностью МФ.

Ручное управление или Capacity Backup Upgrade (CBU).

При покупке МФ оговаривается конфигурация, которую хочет использовать покупатель. Это включает количество и типы CPU (их несколько), уровень производительности тех CPU на каких будет выполняться z/OS. Последнее выражется в т.н. capacity model в формате LNN, где L - буква от A до Z, NN - число, количество CPU для z/OS. Уровней capacity model сотни, Собственно 26 помножить на количество CPU. А также размер памяти для LPARs доступный для пользователя (у нас на МФ 128 Gb, но использовать мы можем до 64 GB. Мы купили тольуо 64. Но могли бы увеличить до 128 по необходимости. На самом сейчас используется только 2 GB. Да 2. Остальные раньше использовались для DR другого МФ).

Именно эта оговоренная при покупке конфигурация и будет встроена в предоставленном МФ. На самом деле в МФ будет такая конфигурация (их немного) какую делают на заводе.

В процессе установки МФ на нем конфигурируется служба т.н. Call-home. Т.е. связь через инет в ИБМ Control and Support Center (Outbound Connectivity). Это нужно для того чтобы ИБМ получала все сигналы от МФ по поводу поломок и для другого ниже описанного. Call-home не обязателен, МФ работает и без этого. Но никто вам не позвонит и не скажется что у вас не так с МФ и вы не сможете делать описаное ниже и еще многое другое (см. CoD ниже).

В процессе использования пользователь может захотеть добавить "дровишек" к конфигурации. Это оформляется как Purchase Order, обсчитывается, выставляется счет, оплачивается. В итоге ИБМ создает некий Record и сообщает пользователю Order number. Системный программист пользователя заходит на Hardware Management Console (HMC), выбирает нужный МФ, переходит в "Single Object Operation" для этого МФ, выбирает "Perform model conversion" и далее в "Receive, and Active" for "Permanent Upgrade". HMC запрашивает Order number, вводим, Ок, ждем несколько минут, Done, можем приступать к использованию новой конфигурации. Большей, или ......меньшей. Мы переходили однажды и на меньшую, это экономило деньги.

Есть еще Temporary Upgrade это когда можно на до 10 дней увеличивать мощность МФ. Рекорды для таких апгрейдов закупаются заранее нужным количеством и могут использоваться например для ежегодных DR test или чего угодно еще (годовых отчетов). Эти рекорды могут активироваться системщиком когда угодно. Использованные рекорды из списка удаляются и так пока все не использованы. Их можно докупать по мере надобности. У нас такие рекорды использывались для DR test и изменяли capacity model с А01 (один CPU на наименьшей скорости) до z03 (три CPU на максимальной скорости).

Capacity on demand (перевод из Redbook)

Расширенные возможности предоставления ресурсов по требованию (CoD) предоставляют клиентам большую гибкость в управлении и администрировании временных потребностей в ресурсах. z14 ZR1 поддерживает тот же архитектурный подход к предложениям CoD, что и z13 (временным или постоянным). В z14 ZR1 может быть доступно одно или несколько гибких определений конфигурации для решения различных временных задач, и несколько конфигураций ресурсов могут быть активны одновременно. Можно создать до 200 промежуточных записей (конфигураций - zVlad909) для обработки различных сценариев. До восьми таких записей можно установить на сервере в любое время. После установки записей их можно активировать вручную, или z/OS Capacity Provisioning Manager может автоматически запустить активацию при достижении пороговых значений политики Workload Manager (WLM). Доступны токены, которые можно приобрести для On/Off CoD до или после выполнения рабочей нагрузки (предоплата или постоплата).

Дополнение к CoD от себя (без перевода). Довольно замысловатое объяснение я нашел. С рекламным уклоном. Простыми словами это работает следущим образом. Идет работа, все Ок. Ок это значит удается удержимать Performance Indexes (PI) в желаемом диапозоне (PI это отношение цели управления к достигнутому результату управления. Идеально должен быть равен 1. Меньше единицы, скажем так, "перелет" (over achieved), Больше единицы "недолет" (under achieved)). И вдруг WLM обнаруживает что ему не хватает производительности МФ чтобы удержать PI. Используя "записи" из предыдущего объяснения WLM повышает производительность МФ. Может повышать несколько раз, но не больше раза в 4 часа (так было раньше как сейчас не знаю). Если оказывается что нагрузка упала то делается понижение производительности используя другие "записи".

Расчет в долларах ведется на основании отчета по использованию предоставляемого в ИБМ ежемесячно отчета, который создается пользователем на основе данных собранных системой и обработанных программой ИБМ, на основании этого отчета ИБМ выставляет инвойс (счет) на оплату. Как можно заметить это своего рода Pay as You Go, по фактическому использованию ресурсов пусть даже вашего МФ, но за программное обеспечение.

Вот фрагмент нашего отчета в ИБМ за май. Это не для CoD, но он показывает что наш МФ имеет 125 MSU, в пике было до 15 MSU, всего за месяц потребили 204 MSU и показано какое ПО мы использовали. Здесь нет CICS котороый у нас есть, но его ни разу не запускали в мае.