IT-компании

Мэйнфрейм IBM: как он работает и почему выживает

Мэйнфреймовые компьютеры часто рассматриваются как древние машины — практически динозавры. Но мэйнфреймы, специально созданные для обработки огромных объемов данных, по-прежнему чрезвычайно актуальны и сегодня. Если они динозавры, то это Ти-рексы, а настольные и серверные компьютеры – жалкие млекопитающие, которых можно растоптать ногами.

По оценкам, сегодня используется 10 000 мэйнфреймов. Ими пользуются почти исключительно крупнейшие компании мира, включая две трети компаний из списка Fortune 500, 45 из 50 крупнейших банков мира, восемь из 10 крупнейших страховых компаний, семь из 10 крупнейших мировых розничных торговцев и восемь из 10 крупнейших телекоммуникационных компаний. И большинство этих мэйнфреймов поставляются IBM.

В этом пояснении мы рассмотрим мэйнфреймовый компьютер IBM — что это такое, как он работает и почему он все еще работает более 50 лет.

Подготовка к

Мэйнфреймы произошли непосредственно от технологии первых компьютеров в 1950-х годах. Однако вместо того, чтобы быть оптимизированными для использования на недорогих настольных компьютерах или серверах, они эволюционировали для обработки больших объемов данных, таких как массовая обработка данных и финансовые транзакции большого объема.

Вакуумные трубки, память на магнитном сердечнике, накопитель на магнитном барабане, ленточные накопители и перфокарты легли в основу IBM 701 в 1952 году, IBM 704 в 1954 году и IBM 1401 в 1959 году. Примитивные по сегодняшним стандартам, эти машины обеспечивали функции научных вычислений и обработки данных, которые в противном случае пришлось бы выполнять вручную или на механических калькуляторах. Для этих машин был готовый рынок, и IBM продавала их так быстро, как только могла их производить.

В первые годы развития вычислительной техники у IBM было много конкурентов, включая Univac, Rand, Sperry, Amdahl, GE, RCA, NEC, Fujitsu, Hitachi, Unisys, Honeywell, Burroughs и CDC. В то время на все эти другие компании вместе взятые приходилось около 20 процентов рынка мэйнфреймов, а IBM претендовала на остальное. Сегодня IBM – единственный производитель мэйнфреймов, который имеет значение и который ведет масштабный бизнес любого рода. Его фактическими конкурентами в настоящее время являются облако и кластеры, но, как мы увидим, переход на эти платформы не всегда рентабелен, и они не способны обеспечить надежность мэйнфрейма.

По любым стандартам мэйнфреймы огромны. Современный мэйнфрейм может иметь до 240 серверных процессоров, 40 ТБ оперативной памяти с исправлением ошибок и много петабайт избыточного вторичного хранилища на основе флэш-памяти. Они предназначены для обработки больших объемов критически важных данных при сохранении времени безотказной работы на уровне 99,999% — это чуть более пяти минут простоев в год. Банк среднего размера может использовать мэйнфрейм для запуска 50 или более отдельных финансовых приложений и вспомогательных процессов и нанимать тысячи сотрудников службы поддержки для обеспечения бесперебойной работы.

Большинство мэйнфреймов обрабатывают финансовые транзакции большого объема, которые включают в себя такие вещи, как покупки по кредитной карте в кассе, снятие средств в банкомате или покупки акций в Интернете.

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

  • Получение информации о дебетовой учетной записи пользователя
  • Проверка идентификатора пользователя и PIN-кода
  • Проверка наличия средств
  • Списание суммы транзакции со счета пользователя
  • Зачисление средств на счет продавца

Все это должно происходить за считанные секунды, и банки должны обеспечить быстрое реагирование даже во время массовых мероприятий, таких как праздничные дни покупок. Мэйнфреймы разрабатываются с нуля, чтобы обеспечить как резервирование, так и высокую пропускную способность для этих целей. Высокоскоростная обработка бесполезна, если обработка останавливается в рабочее время, а надежная обработка бесполезна, если людям приходится ждать обработки транзакции несколько минут.

Когда вы обрабатываете финансовую транзакцию, это означает, что вы зарабатываете деньги. Если вы обрабатываете много транзакций, вам нужно потратить много денег на резервирование, чтобы все работало бесперебойно. Когда детали неизбежно выходят из строя, шоу должно продолжаться. Вот тут-то и вступает в дело встроенная в мэйнфреймы избыточная обработка.

Оперативная память, процессоры и диски имеют возможность горячей замены, поэтому в случае сбоя компонента его можно извлечь и заменить, не требуя отключения питания мэйнфрейма. Фактически мэйнфреймы разделены на независимые разделы, каждый с отдельной оперативной памятью, хранилищем, процессорами и даже разными операционными системами, что позволяет приложениям работать непрерывно, в то время как определенные разделы получают техническое обслуживание в виде исправлений операционной системы, аппаратных исправлений и обновлений.

В то время как серверы на базе Intel могут поддерживать память с кодом исправления ошибок (ECC), которая может исправлять неисправные биты памяти в ОЗУ, процессоры Telum могут исправлять неисправные биты ОЗУ и многое другое. Память может обнаруживать и восстанавливать отказавшие аппаратные каналы памяти, неисправные чипы памяти DIMM и сбои в работе процессора.

Сотрудник IBM Кристиан Якоби объяснил мне этот процесс:

Когда мы обнаруживаем ошибку в обработке в ядре центрального процессора, ядро может пройти прозрачное восстановление. Это полный сброс ядра — почти как мини-перезагрузка ядра, но состояние программы, расположение программы и все содержимое регистра восстанавливаются. Итак, после восстановления мы продолжаем работать там, где мы были [запущены] в программе. Это полностью прозрачно для программных уровней. Это “восстановление ядра”. Если ядро проходит через слишком много перезапусков, содержимое ядра может быть перемещено в запасное ядро. Это “пересадка мозга”.

Центральный процессор мэйнфрейма может восстанавливать поврежденные биты памяти, каналы памяти, микросхемы памяти и процессоры, причем все это прозрачно для операционной системы и программного обеспечения.

Динамически реконфигурируемое разделение системы

Эквивалентные отдельные блоки мэйнфрейма, или логические разделы (LPAR), могут быть созданы с помощью контроллеров ввода-вывода, разрешений мэйнфрейма и настраиваемых пользователем процессоров. Каждый LPAR может запускать отдельный изолированный экземпляр Z / OS, операционной системы мэйнфрейма.

Эти экземпляры можно использовать для разработки, тестирования или запуска отдельных приложений. LPAR также могут запускать разные операционные системы, такие как Linux, и у них совершенно разные аппаратные ресурсы. Если один из разделов выходит из строя или его приходится выводить из строя для обслуживания, другие разделы остаются незатронутыми. LPAR также разделяются по разрешениям; например, одна группа пользователей может иметь доступ к LPAR тестового региона, но не к производственному LPAR.

IBM использует эффективный протокол с низкой задержкой, называемый “parallel sysplex”, чтобы разные мэйнфреймы (или разные LPAR на одном мэйнфрейме) были “связаны” друг с другом для распределения рабочей нагрузки, обмена данными или восстановления / отработки отказа. Для достижения почти линейного ускорения под нагрузкой можно параллельно сгруппировать до 32 процессоров, а процессорам можно назначить либо производительность, либо избыточность. Методы блокировки данных и организации очередей используются для поддержания целостности данных во время обработки, а внедрение параллельного системного комплекса в ОС требует целостного подхода ко всему стеку ОС.

Возможность динамического добавления и удаления мощностей означает, что мэйнфреймы могут реагировать на всплески рабочей нагрузки. Джейкоби сказал, что группы поддержки мэйнфреймов IBM наблюдали колебания в обработке, необходимой для устранения дефицита в цепочке поставок во время пандемии.

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

Последнее поколение процессоров серии Z, на которых построены мэйнфреймы, называется Telum. Современный чип с тактовой частотой 5,2 ГГц построен по 7-нм технологическому процессу Samsung и оптимизирован для работы в одном потоке.

Что отличает Telum от других высокопроизводительных процессоров Intel и AMD? Короче говоря, в нем больше всего: более высокая тактовая частота, больше кэша, более специализированное аппаратное обеспечение внутри процессора и больше каналов PCI для передачи данных.

Современные процессоры мэйнфреймов IBM основаны на усовершенствованной версии архитектуры POWER, которую IBM разрабатывает более 30 лет. Текущий процессор Telum является мощным. Каждое ядро является двусторонним многопоточным, имеет 256 КБ кэша L1 и 32 МБ кэша L2 и поддерживает выполнение суперскалярных команд. Telum имеет восемь ядер на чип, два чипа на сокет и четыре разъема на выдвижной ящик; четыре выдвижных ящика составляют систему. Полностью загруженный мэйнфрейм может поддерживать 250 ядер, 190 из которых управляются пользователем. Ввод-вывод обрабатывается двумя контроллерами PCI Express 4.0.

Организация процессора мэйнфрейма.
IBM

Новая конструкция кэша Telum оптимизирована для разнородной производительности одного процессора благодаря новой и уникальной стратегии управления кэшем. Каждое ядро имеет свой собственный кэш L2 объемом 32 МБ. Когда строка кэша удаляется из кэша L2, она перемещается в другой кэш L2 и помечается как строка кэша L3.

Это означает, что восемь кэшей L2 могут быть объединены в виртуальный общий кэш L3 объемом 256 МБ, доступный любому из восьми ядер. Сравните это с чипом AMD Zen 3, где каждое из восьми ядер имеет 512 КБ кэша L2 и в общей сложности 32 МБ кэша L3.

Когда строка кэша удаляется из виртуального кэша L3, эта строка может найти в системе кэш другого ядра, создавая таким образом виртуальный кэш L4. Объединение кэшей L2 в системе дает впечатляющий объем виртуального кэша L4 объемом 8192 МБ. IBM заявляет о повышении общей производительности на сокет более чем на 40 процентов по сравнению с предыдущей конструкцией процессора z15.

“Управление кэшем – это пример нового дизайна и инвестиций”, – сказал мне Джейкоби. “В целом это чрезвычайно успешно и прошло более гладко, чем ожидалось. Мы всегда знали, что когда каждое ядро выполняет одно и то же действие, оно использует один и тот же кэш. Но в реальной работе все происходит иначе. Каждый процессор использует кэш немного по-другому. Когда мы испытывали реальные рабочие нагрузки, мы были рады видеть, что это полностью подтверждается нашими измерениями для L3 и L4. Производительность Z16 стала новым уровнем, на котором можно учиться и развиваться ”.

В Telum также встроен аппаратный ускоритель искусственного интеллекта. Естественно, эта часть предназначена для решения крупных корпоративных задач обработки данных, таких как быстрая обработка дел о мошенничестве с кредитными картами. Сто двадцать восемь процессорных блоков объединены в массив и поддерживаются матричными математическими функциями с плавающей запятой. Функции искусственного интеллекта поддерживают как обработку логического вывода, так и машинное обучение. (или тренинг).

Эти встроенные функции искусственного интеллекта тесно связаны с кэшем L2 для предварительной выборки данных и обратной записи с низкой задержкой. Система управления виртуальным кэшем L3 и L4 помогает процессорам искусственного интеллекта масштабироваться почти линейно для нескольких процессоров в ящике мэйнфрейма, позволяя предприятию обрабатывать десятки тысяч транзакций вывода в секунду.

Дополнительные функции мэйнфрейма с аппаратным ускорением включают:

  • Аппаратная поддержка zEDC для сжатия без потерь при минимальной загрузке процессора. Класс Java Deflater обеспечивает пропускную способность в 15 раз по сравнению с предыдущей реализацией Z.
  • Встроенный ускоритель для Z Sort, обеспечивающий аппаратное ускорение сортировки. Тесты базы данных DB2 показывают сокращение затраченного времени на 12 процентов при снижении загрузки процессора на 40 процентов.
  • Повсеместное шифрование, аппаратно-ускоренная реализация широко используемого AES (Advanced Encryption Standard). Он может шифровать корпоративные данные, затрачивая всего 3 процента дополнительной нагрузки на процессор. Это называется повсеместным шифрованием, потому что оно может шифровать все и вся на вашем мэйнфрейме как часть любого рабочего процесса. Аппаратное ускорение также доступно для алгоритмов SHA, DES, GHASH и CRC32.

Вторичное хранилище на мэйнфреймах имеет огромный объем, что крайне важно для компаний, обрабатывающих огромные объемы данных, критичных ко времени. Вы не подключаете диски к мэйнфрейму; вы подключаете массивы хранения. Одним из таких массивов является платформа виртуального хранилища Hitachi G1500. Он может быть оснащен вращающимися дисками, твердотельными накопителями или NVME, его емкость составляет 6,7 петабайт, а пропускная способность – 48 Гбит/с. Для сравнения, один быстрый NVMe-накопитель выдает максимальную скорость около 7 Гбит /с. Эти массивы могут быть сконфигурированы в различных конфигурациях RAID для обеспечения избыточности, и типичный мэйнфрейм будет иметь несколько массивов хранения на LPAR с отдельными массивами хранения для резервных копий.

Несколько выделенных контроллеров ввода-вывода и поддержка процессором шины PCIe 5.0 обеспечивают высокую пропускную способность мэйнфрейма. Основное хранилище находится на массивах SSD или NVME.

Чтобы максимально использовать специализированный процессор, вам нужна специализированная операционная система. Z / OS — произносится как “zee / zed oh ess”, в зависимости от вашего местоположения — это операционная система мэйнфрейма. 64-разрядная операционная система была разработана IBM для семейства мэйнфреймов Z/Architecture и совместима со старой ОС мэйнфреймов MVS. Он был выпущен в 2000 году и обратно совместим со старыми 24-разрядными и 31-разрядными приложениями. Лицензированный и арендованный у IBM, Z / OS является собственностью с закрытым исходным кодом (компания также предлагает персональную версию Z / OS для использования на настольных ПК).

Операционная система изначально поддерживает приложения, скомпилированные на COBOL, C, C ++, Fortran и PL / 1, а также Java-приложения на серверах приложений Java. Как обсуждалось ранее, Z / OS может быть разделена на отдельные логические разделы, каждый с отдельным оборудованием, разрешениями, рабочими нагрузками и даже разными операционными системами. Red Hat Linux является поддерживаемой гостевой ОС.

Z / OS обеспечивает систему безопасности, реализованную с помощью Security Server, средства контроля доступа к ресурсам (RACF) и повсеместного шифрования. Security Server контролирует доступ пользователей и ограничивает функции, которые может выполнять авторизованный пользователь. RACF контролирует доступ ко всем защищенным ресурсам Z / OS.

Сюда входит доступ к приложениям, файлам данных, API и аппаратным устройствам. Повсеместное шифрование обеспечивает возможность шифрования любого файла данных с помощью надежного шифрования AES, а зашифрованные файлы прозрачно расшифровываются и повторно шифруются при обращении. Шифрование выполняется аппаратно с минимальной нагрузкой на центральный процессор. Пользователь, имеющий доступ к файлу, но не имеющий доступа к расшифровке, увидит только случайные байты зашифрованного файла.

В системе, в которой может быть 1000 человек вспомогательного персонала, никто не должен знать или выполнять всю операционную систему целиком. Поддержка мэйнфреймов часто распределена между многими отделами, включая корпоративное хранилище, разрешения и доступ, криптографию, повседневные системные операции, поддержку прикладного программного обеспечения, тестирование приложений, развертывание приложений, аппаратную поддержку и отчетность.

Файлы

Файлы на мэйнфрейме называются наборами данных. Ссылка на каждый файл осуществляется через его полный путь, который состоит максимум из восьми “уточняющих параметров”, каждый из которых состоит максимум из восьми символов. Квалификаторы могут содержать цифры, буквы и символы @, # и $.

Вот пример полного пути к набору данных:

TEST1.AREA1.GHCC.AMUST#.T345.INPUT.ACC$.FILEAA

На уровне байтов все символы представлены в расширенном двоично-десятичном коде обмена, или EBCDIC, 8-битной кодировке символов, альтернативной ASCII. При сортировке EBCDIC строчные буквы помещаются перед прописными буквами, а буквы – перед цифрами, в точности противоположно ASCII.

Z / OS также поддерживает файловую систему ZFS и предоставляет файловую систему для программ UNIX или Linux для запуска под управлением Z / OS.

Хотя Z / OS включает в себя систему X Windows, приложения не имеют понятия о растровых окнах. Все отображение осуществляется с помощью символьных экранов с использованием эмулируемых терминалов 3270. Это древний и вошедший в поговорку “зеленый экран”. Приложения Z / OS с экранным вводом-выводом обычно кодируются в 24 строки по 80 столбцам.

Z / OS развивалась отдельным эволюционным путем от UNIX и Linux. Вы можете увидеть удобный список сходств и различий между двумя системами здесь.

Традиционными продуктами мэйнфрейма являются программы COBOL, файлы данных и JCL, или язык управления заданиями. Большинство компаний используют большие программы COBOL, разработанные десятилетиями, и программы выполняются, а данные обрабатываются в неинтерактивных заданиях. Концепция пакетных компьютерных заданий восходит к 50-60-м годам и предшествует эпохе интерактивных миникомпьютеров с разделением времени. Базовое задание состоит из компьютерного кода, который должен выполняться, входных данных, подлежащих обработке, понимания того, как обрабатывать выходные данные, и команд задания, которые передают этапы обработки операционной системе Z / OS. Большие объемы данных могут быть обработаны очень эффективно в неинтерактивных пакетах. Ниже приведены некоторые примеры кода JCL и COBOL.

Язык управления заданиями

JCL был впервые представлен в середине 1960-х годов, и с тех пор его синтаксис практически не изменился. Для неподготовленного глаза это похоже на чтение иероглифов, но он очень мощный и остается предпочтительным методом запуска приложений.

Для каждого задания, отправляемого для запуска в Z / OS, язык управления заданиями определяет, какие программы запускать, где искать входные данные, как обрабатывать входные данные и куда помещать выходные данные. JCL не имеет значений по умолчанию, поэтому все должно быть записано в последовательных операторах управления заданиями. JCL изначально вводился на перфокартах. Он сохраняет формат из 80 столбцов.

Вот простой пример JCL:

//EXAMPLE JOB 1
//MYEXAMPLE EXEC PGM=SORT
//INFILE DD DISP=SHR,DSN=ZOSPROF.TEST.DATA
//OUTFILE DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD *
SORT FIELDS=(1,3,CH,A)

Каждая инструкция JCL DD (определение данных) используется для связывания набора данных (файла) z / OS с именем ddname, которое распознается программой как входное или выходное значение.

При отправке на выполнение EXAMPLE – это имя задания, которое система связывает с этой рабочей нагрузкой. MYEXAMPLE – это имя шага, которое предписывает системе выполнить SORT программу. В инструкции DD INFILE указывается ddname. INFILE ddname кодируется в SORT программе как программный ввод. Имя набора данных (DSN) в этой инструкции DD является ZOSPROF.TEST.DATA. Это путь к папке, а также имя файла. Набор данных может быть передан (DISP=SHR) другим системным процессам. Содержимое данных ZOSPROF.TEST. является SORT вводом программы. OUTFILE Ddname – это SORT выходные данные программы.

SYSOUT=* указывает, как отправлять системные выходные сообщения в область вывода на печать подсистемы ввода заданий (JES). Также возможно отправлять выходные данные в набор данных. SYSIN DD * – это оператор ввода, который указывает, что за ним следуют инструкции data или control. В данном случае это инструкция сортировки, указывающая SORT программе, какие поля SORTIN записей данных должны быть отсортированы.

Для всех заданий требуются инструкции JCL трех основных типов: JOBEXEC и DD. Задание определяет конкретную рабочую нагрузку для z / OS для обработки. Поскольку JCL изначально разрабатывался для перфокарт, детали кодирования инструкций JCL могут быть сложными. Однако общие концепции довольно просты, и большинство заданий можно запускать с использованием очень небольшого подмножества этих управляющих инструкций.

COBOL

COBOL – ранний компьютерный язык, разработанный в 1959 году. Как и другие компьютерные языки его поколения, он является императивным, процедурным и ориентированным на строку. Он был разработан как самодокументируемый, с синтаксисом, похожим на английский, что, к сожалению, делает его чрезвычайно подробным. Его ранняя популярность среди деловых и финансовых кругов привела к появлению огромных специализированных баз кода, которые по сей день активно используются.

Хотя код на COBOL может показаться подробным и громоздким по сравнению с другими популярными языками, запуск этого языка не является медленным. IBM продолжает выпускать обновления для компилятора IBM Enterprise COBOL для Z / OS. Версия 6 этого компилятора предоставляет дополнительные аппаратные оптимизации для архитектуры Telum и расширения для доступа к JSON и XML и обеспечения совместимости Java / COBOL. Благодаря этой поддержке приложения COBOL могут лучше взаимодействовать с современными веб-ориентированными сервисами и приложениями. Также существует инфраструктура для запуска программ COBOL в облачных приложениях.

* Комментарии начинаются с * в столбце 7
* Программы на COBOL имеют структуру раздела, абзаца, предложения, инструкций.

PROGRAM-ID. SORTEXAMPLE.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INPUT ASSIGN TO INFILE.
SELECT OUTPUT ASSIGN TO OUTFILE.
SELECT WORK ASSIGN TO WORKFILE.

DATA DIVISION.
FILE SECTION.
FD INPUT.
*DEFINE THE INPUT FIELDS
01 INPUT-EMPLOYEE.
*DEFINE THE STORAGE AND TYPE OF EMPLOYEE-ID-INPUT FIELD,
*NUMBER DATA OF 5 DIGITS
05 EMPLOYEE-ID-INPUT PIC 9(5).
*DEFINE THE STORAGE AND TYPE OF EMPLOYEE -LAST-NAME FIELD,
*ALPHANUMERIC DATA WITH 25 CHARACTERS
05 EMPLOYEE-LAST-NAME PIC A(25).
*USE THE SAME INPUT FIELDS FOR OUTPUT FIELDS
FD OUTPUT.
01 EMPLOYEE-OUT.
05 EMPLOYEE-ID-OUTPUT PIC 9(5).
05 EMPLOYEE -FIRST-NAME PIC A(25).
*USE THE SAME INPUT FIELDS FOR TEMP WORKING DATA
SD WORK.
01 WORK-EMPLOYEE.
05 EMPLOYEE-ID-WORK PIC 9(5).
05 EMPLOYEE-NAME-WORK PIC A(25).

*USE EMPLOYEE-ID-OUTPUT AS THE SORTING KEY, SORT IN ASCENDING ORDER
PROCEDURE DIVISION.
SORT WORK ON ASCENDING KEY EMPLOYEE-ID-OUTPUT
USING INPUT GIVING OUTPUT.
DISPLAY 'Finished Sorting'.
STOP RUN.

В этом примере JCL будет запущена примерная программа COBOL после ее компиляции. Обратите внимание, что JCL часто ссылается на конфигурации системы, настроенные для организации, которые не являются переносимыми.

//SAMPLE JOB(TESTJCL,XXXXXX),CLASS = A,MSGCLASS = C
//STEP1 EXEC PGM = SORTEXAMPLE
//IN DD DSN = INPUT-FILE-NAME,DISP = SHR
//OUT DD DSN = OUTPUT-FILE-NAME,DISP = SHR
//WRK DD DSN = &&TEMP

SORTEXAMPLE это очень маленький пример обработки данных COBOL. Типичное банковское приложение может быть предназначено для обработки активных кредитов. Для такой программы вам понадобятся файлы входных данных для активных клиентов, типов кредитов, ежемесячных платежей по кредитам и процентных ставок. Вы могли бы создать выходные данные для оставшегося основного баланса, отсрочки платежа, уведомлений о просрочках, обновлений для компаний, осуществляющих мониторинг кредитоспособности, и многого другого.

Код для приложения такого типа может легко превышать миллион строк кода. Вам понадобятся бизнес-аналитики для понимания и поддержки бизнес-логики, а разработчики – для внедрения изменений в виде кода. Вам понадобятся системные разработчики, чтобы понимать файлы данных и разрешения и управлять ими; они должны знать, как приложение взаимодействует с другими системами и как JCL настроен для выполнения пакетных заданий. И вам понадобится менеджер приложений или владелец, чтобы решить, как и когда вносить изменения в приложение.

CICS

Мэйнфреймы также управляют серверами приложений как частью программного стека. Серверы приложений – это своего рода универсальные курорты для запуска вашего прикладного кода, и они предоставляют множество функций для кода. Например, если вам нужны данные, ваш запрос находится на высоком уровне. Это эквивалентно вызову официанта, чтобы он принял ваш заказ. Написание кода в контейнере сервера приложений помогает сосредоточить усилия разработчиков на бизнес-логике приложения, а не на деталях системного уровня, которые необходимы для пакетной обработки.

CICS предоставляет следующие функции:

  • Обработка входящих и исходящих веб-сообщений.
  • Управление очередями входных данных, когда требуется порядок транзакций.
  • Преобразование форматов входных данных, таких как JSON и XML, во входные данные собственного приложения.
  • Обеспечение функций безопасности, включая аутентификацию, авторизацию и шифрование.
  • Запуск нескольких языков на одном сервере для повышения производительности и сокращения накладных расходов.
  • Предоставление общего CICS LINK API с общей памятью для высокопроизводительной связи между приложениями.
  • Обеспечение атомарного разделения обработки в случае сбоя частей транзакции и необходимости отката.

CICS может обрабатывать данные в режиме реального времени, поступающие из веб-и мобильных приложений, а также банкоматов, и обеспечивает время безотказной работы на 99,999% и обладает высокой масштабируемостью в периоды пиковых транзакций, таких как праздничные дни для покупок и дни после банковских каникул.

Владение мэйнфреймами сопряжено с трудностями. Ими пользуются только крупнейшие компании, поскольку они дороги в владении и эксплуатации — их стоимость составляет от 250 000 до 4 000 000 долларов, и каждый из них изготавливается по индивидуальному заказу. Им требуется большой штат технической поддержки, который может исчисляться сотнями или тысячами. Персонал технической поддержки, имеющий опыт работы с COBOL, JCL, системами хранения данных на мэйнфреймах, обслуживания оборудования, эксплуатации мэйнфреймов и приложений, выбывает из рабочей силы. Язык COBOL больше широко не преподается, и лишь немногие университеты имеют в своей учебной программе практические темы по мэйнфреймам.

Многим приложениям для мэйнфреймов уже несколько десятилетий, и хотя COBOL работает эффективно, программное обеспечение должно развиваться, чтобы соответствовать меняющимся потребностям клиентов. Поддержка приложений “dusty deck” требует больших усилий, а старые банки и страховые компании находятся в невыгодном конкурентном положении по сравнению с проворными молодыми финтех-компаниями.

Тем не менее, люди десятилетиями предсказывали смерть мэйнфреймов, и они продолжают выживать, потому что заполняют важную нишу обработки финансовых транзакций большого объема, критически важных для бизнеса. Мэйнфреймы IBM имеют “привязку” к конечному потребителю. Компании из списка Fortune 500 десятилетиями используют одни и те же кодовые базы COBOL. Первоначальные разработчики давно перешли на другую работу или даже умерли от старости, и переписывание десятков миллионов строк критически важного кода – очень сложное и дорогостоящее занятие.

Многие компании пытались преобразовать его, но потерпели неудачу. Но преобразование кода – это всего лишь часть общего процесса миграции. Вам также необходимо преобразовать свои данные, разработать новые процессы и процедуры для новых приложений, обучить процессам и процедуры новых сотрудников, провести стресс-тестирование всех систем, а затем выполнить сокращение для запуска в производство.

Все это должно происходить по определенному графику и бюджету. Это эквивалентно пересадке сердца, когда ваши шансы выжить составляют менее 50 процентов. Такого рода миграция занимает у компаний годы и сопряжена с трудностями. Многие компании потратили десятки или сотни миллионов долларов на попытки обновить системы такого рода и потерпели неудачу. Более безопасный вариант – просто продолжать оплачивать лицензионные сборы за аппаратное обеспечение мэйнфрейма, операционную систему и приложения и содержать персонал для сотен или тысяч сотрудников службы поддержки.

Тем не менее, альтернативы мэйнфрейму существуют. FIS Global, крупный поставщик банковского программного обеспечения для мэйнфреймов, предоставляет путь миграции с мэйнфрейма на свою современную банковскую платформу FIS. Компания спроектировала стек облачных компонентов для выполнения тех же функций, что и ее продукты для мэйнфреймов, а также переписала свои приложения для мэйнфреймов COBOL на Java и перенесла данные из плоских файлов в реляционные базы данных. Код Java выполняется на сервере приложений JBOSS, который развернут в контейнере Docker. Управление контейнером осуществляется на облачных серверах с помощью Kubernetes container manager, который работает на Linux или Windows на облачном сервере. События реального времени управляются с помощью Apache Kafka.

Связь осуществляется с помощью событий Kafka или служб обмена сообщениями Java, а новые экземпляры сервера могут быть развернуты за считанные секунды в облаках AWS или Azure, чтобы обеспечить дополнительную пропускную способность, которая необходима для обработки большого объема. FIS Global может предоставлять те же функциональные возможности, что и приложения для мэйнфреймов, но его система состоит из компонентов commodity cloud и очень масштабируема. Инвестиции в переход на эту архитектуру довольно высоки, и плавный переход ни в коем случае не гарантирован, но как только компания перейдет на современную банковскую платформу, ежегодные эксплуатационные расходы, предположительно, будут ниже.

/ Увеличьте программный стек этой современной банковской платформы.
FIS

FIS Global поддерживает полный банковский набор продуктов для мэйнфрейма, и в нем работают команды аналитиков и разработчиков, которые разработали и преобразовали бизнес-логику с COBOL на Java и преобразовали данные из плоских файлов в схемы реляционных баз данных. Его инженеры создали контейнеры Java и database, а компания разработала дорожную карту для переноса клиентских данных и сервисов с мэйнфрейма в облако.

Так почему же банки не пользуются возможностью отказаться от своих мэйнфреймов и перейти в облако? Риски и стоимость конвертации. Как правило, банки не склонны к риску. Они часто отстают в освоении новых технологий и делают это только под давлением конкуренции или регулирующих органов.

Стоимость миграции многих десятков критически важных приложений может легко составить сотни миллионов долларов и занять три или более лет. В течение этого времени миграции трудно добавлять новые функции или реагировать на конкуренцию. Помимо рисков и затрат, существует проблема найма сотен высокоспециализированных технических консультантов, которые контролировали бы работу по миграции. Если вы не можете найти этих людей, значит, у вас есть узкое место в плане проекта.

Мэйнфрейм продолжает адаптироваться

Бизнес-модель IBM позволяет ей инвестировать в инфраструктуру мэйнфреймов. Telum, новейший процессор для мэйнфреймов, был усовершенствован в управлении кэшем и внедрении встроенной обработки с помощью искусственного интеллекта, что привело к увеличению производительности. Мэйнфрейм COBOL был расширен до поддержки JSON и XML для обеспечения веб-разработки, а также получил значительную оптимизацию для архитектуры процессора Telum.

IBM также адаптируется к изменениям в отрасли и внедряет свою стратегию гибридного облака на мэйнфреймы. Это включает использование Red Hat Linux для DevOps и Red Hat для наборов инструментов Linux. Red Hat поддерживает Node.js Python, Docker и Kubernetes на мэйнфрейме. Другие последние функции Z / OS включают в себя возможность извлекать образы Linux с открытым исходным кодом, управлять ими и запускать их в контейнерах.

Таким образом, несмотря на то, что программисты COBOL и обслуживающий персонал мэйнфреймов выбывают из рабочей силы, IBM продолжает модернизировать инфраструктуру мэйнфреймов и программный стек. И хотя мэйнфрейм продолжает сталкиваться с проблемами, связанными с облаком, ему удалось адаптироваться и выжить.

admin
Author: admin