Многие считают что МФ это сервер и понимают МФ как «необычный», но все же сервер. Так считают и те кто не имел никаких дел с МФ и зачастую те кто работал/работают с МФ. Последние конечно знают и понимают что как минимум на одном МФ можно, и обычно так и есть, запускать несколько «серверов» (копий ОС) одновременно. Это принципиально не меняет отношения к МФ как серверу или нескольких серверов.
Но МФ это не сервер и не совокупность серверов. Сказав это я делаю следующее исключение. Есть такая конфигурация МФ называемая 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 что надеюсь позволит читателю самому разобраться в этом. Отвечу на любые вопросы в комментариях.