Search
Write a publication
Pull to refresh

Популярно про ИБМ мэйнфрэйм

Level of difficultyMedium

Многие считают что МФ это сервер и понимают МФ как «необычный», но все же сервер. Так считают и те кто не имел никаких дел с МФ и зачастую те кто работал/работают с МФ. Последние конечно знают и понимают что как минимум на одном МФ можно, и обычно так и есть, запускать несколько «серверов» (копий ОС) одновременно. Это принципиально не меняет отношения к МФ как серверу или нескольких серверов.

Но МФ это не сервер и не совокупность серверов. Сказав это я делаю следующее исключение. Есть такая конфигурация МФ называемая LinuxONE. Эта конфигурация предполагает выполнение только ОС Линукс. В логических разделах (LPAR) или на виртуальных машинах под zVM (система виртуальных машин на МФ существующая с начала 70-х). Возможны и комбинации того и другого одновременно.

В конфигурации LinuxONE да МФ выступает как совокупность серверов, как облако (Cloud). В этом случае применимы все подходы и закономерности используемые в построении ИТ инфраструктур на базе x86 серверах, или, скажем, Azure. С двумя исключениями: CPU и ввод‑вывод.

CPU на МФ обычно используются совместно (sharing) разными разделами (LPAR) или виртуальными машинами в одном LPAR. Конечно CPU можно закрепить (dedicate) за разделом или ВМ, но это снизит коэффициент использования таких CPU, если только нагрузка в таком разделе или ВМ не постоянно высока. Что в общем случае бывает очень редко.

Ввод‑вывод на МФ построен очень иначе чем на других платформах (впрочем МФ предоставляет и традиционные для х86 серверов интерфейсы ввода‑вывода FCP (Fibre Channel Protocol для SCSI устройств). МФ ввод‑вывод построен на концепции каналов ввода‑вывода. В первом приближении канал это сервер ввода‑вывода занимающийся только вводом‑выводом разгружая полностью CPU от этой функции. В конфигурациях МФ количество каналов варьируется от десятков до сотен и тысяч. Даже если количество CPU измеряется единицами то каналов ввода‑вывода может быть десятки. И это как правило оптоволокно (FICON Fibre Connection) с весьма высокой пропускной способностью. Ввод‑вывод МФ всегда был и остаётся их преимуществом.

При всем при этом LinuxONE не является главной фишкой МФ. Даже наоборот на мой взгляд LinuxONE это в некотором роде дискредитация самой идеи ИБМ МФ, которая заключается в симбиозе железа МФ с его основной ОС — z/OS да и с другими ОС МФ тоже.

Под симбиозом я здесь понимаю глубокий уровень сотрудничества между ОС z/OS и функциями МФ как компьютера, как процессора вычислений/обработки и обмена данными. Многие функции ОС вынесены в железо. Только z/OS из всех ОС МФ использует все возможности железа, которые фактически и созданы под z/OS. А другими ОС просто непонятны и не используются.

Раскрытие «загадки» МФ и z/OS я начну с примером из моей многолетней практики в ролях системного программиста/администратора, DBA, security, networking, и т. д.. После примеров я постараюсь обобщить то что показывают эти примеры и сделаю, скажем так, глобальные выводы.

Организация, где я проработал последним 25 лет, условно состоит, с точки зрения ИТ, из двух частей. Десять лет назад одна часть (бОльшая примерно 10 000 зарегистрированных пользователей) имела ERP класс приложение на МФ другая (2–2.5 пользователей) на Unix серверах в SAP/Oracle.

Было принято решение объединить обе части на МФ. На тот момент в пиковые часы загрузка МФ почти стабильно была 100%. Основываясь на этом я рекомендовал добавить мощности МФ. Как известно мощность МФ может меняться в довольно широком диапазоне без добавления каких либо ресурсов (не все ресурсы и не на все 100% используются как правило) и у нас такая возможность была.

Иначе говоря в каждом МФ как правило ресурсов процессора и памяти больше чем то что активировано для использования в каждом конкретном случае и, что важно, за что платит пользователь. Например, мы имеем МФ с одним CPU на 100 MIPS и платим за это х$$$. Этот МФ может превратиться в несколько кликов выполненых системщиком на HMC (Hardware Management Console) в МФ с тремя CPU и 2000 MIPS за которые, естественно, надо будет платить больше долларов получив в 20 раз мощнее CPU. Цифры условные но более менее реалистичные, касаются «младшего» семейства МФ уровня z14.

Ничего такого сделано не было. МФ остался с той же мощностью. Добавилось примерно 20% пользователей и их данные из SAP. SAP, до объединения, выполнялся на нескольких не мелких на то время Unix серверах. Все это объединилось на один МФ с 4 CPU (zBC12 2013 года выпуска model O04, 1000 MIPS), 32 GB RAM. На этом МФ выполнялась не только продакшн, но и все остальные копии этого приложения (Dev, QA, Training) и не только Базы Данных но и сервера приложений (типа но не в точности Web servers) для всех этих копий.

Сразу после объединения на МФ новые пользователи стали жаловаться на плохой респонс тайм. Загрузка в пиковые часы как и было до объединения доходила до 100%. Старые пользователи проблем с респонс тайм не отмечали.

Стало понятно что причина в том что новые пользователи использовали иной чем у старых интерфейс к DB2.

Обратились к WLM (Work Load Manager). WLM обязательная компонента z/OS, которая управляет приоритетами на основе полиси. Сразу замечу ничего подобного ни на каких других платформах нет. В WLM заключается, но это не единственная, фишка z/OS. Я расскажу больше про WLM в отдельной статье если заслужу право автора на Хабр‑е.

Интерфейс к DB2 новых пользователей в WLM полиси попадал в сервис класс с параметрами по умолчанию. Эти параметры были занижены. На ходу были изменены параметры этого сервис класса и проблема ушла. Те же 100% CPU, но уже никто не жалуется.

С тех пор это приложение проработало на этом МФ семь лет и было перенесено в Azure. Перенесено без проблем потому что оно было переписано вендором довольно давно один в один с сохранением структуры БД. Тем не менее процесс миграции занял два года.

Теперь, в Azure, это приложение размещается на 36 серверах. Каждый инстанс (Production, Dev, QA, Training) имеет свой набор серверов БД, Web servers, Batch/Print etc... Сравним с одним весьма скромным МФ до миграции.

Второй пример. Есть у нас ещё одно приложение на МФ в продакшн. Его сейчас мигрируют в Azure. Лет пять мигрируют не меньше. МФ этого приложения z14 ZR1 (capacity model A01, т. е. один CPU 100 MIPS). Этот МФ был DR сайт для первого приложения и мог быть в случае DR в несколько кликов превращен в модель Z03 с тремя CPU и 2000 MIPS.

Это приложение используется нескольким десятками пользователей, имеет небольшую БД (IDMS noSQL like Adabas). Написано в том числе на Cobol, на Ассемблер и ADS (Application Development System). Все эти компоненты до сих пор поддерживаются вендором фирмой Broadcom.

Как обычно все инстансы сидят на одном МФ. В двух LPAR (Dev/QA и Production) с памятью 1GB!!! каждый (больше и не надо, производительности более чем достаточно). Всего же на этом МФ 64 GB RAM (Это минимум возможного для МФ z14).

Перейдем к промежуточным выводам. Если типичным для ИТ архитектур на базе х86 является создание серверов или кластеров серверов под каждый сервис (Database, Application Server, Webserver, DNS, AD и т. д. и т. п.), то типичным для МФ является размещение на одном физическом МФ как можно больше сервисов и желательно разных приложений (ERP, EAS, etc...).

Такой подход может оказаться спорным и даже неприемлемым, но только с точки зрения практики использования х86 серверов и систем типа Linux и Windows.

Можно долго и подробно объяснять эту особенность МФ но чтобы закончить эту, надеюсь стартовую статью про МФ, ограничусь обобщённым утверждением что МФ и z/OS обладают исключительными возможностями управлять большими совокупностями разноплановых процессов так что достигаются любые целевые показатели (время выполнения, пропускная способность и т. п.) выполнения процессов с точки зрения пользователей. При этом имеется возможность эффективно использовать вычислительные ресурсы МФ так что при близкой и постоянной загрузке на уровнях 100% не вызывает деградации системы в целом.

В последующих статьях я намерен раскрыть частные аспекты устройства и работы МФ и z/OS что надеюсь позволит читателю самому разобраться в этом. Отвечу на любые вопросы в комментариях.

Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.