четверг, 2 октября 2014 г.

Почему вы должны хотеть мейнфрейм zEnterprise EC12 и z/OS для работы ваших Java-приложений

Что такое мейнфрейм


Обычно когда люди слышат слово "мейнфрейм", им представляется нечто такое древнее, ужасное, занимающее целый машинный зал, а то и не один, связанное с тысячами устройств и управляемое с помощью старого-доброго терминала 3270. На самом деле конечно же все уже давно не так, современные мейнфреймы корпорации IBM представляют собой одно- (Business Class Model, BC12) или двустворчатый (Enterprise Class Model, EC12) шкаф, чуть выше человеческого роста, внешне похожий на этакий высокотехнологичный холодильник, набитый сверху-донизу различным оборудованием.


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

Возникает вполне закономерный вопрос: в принципе благодаря горизонтальной масштабируемости можно работать и на россыпи x86-серверов, так зачем чем же нужны мейнфреймы. Для ответа на него следует заметить, что с помощью информационных технологий мы решаем множество абсолютно непохожих друг на друга задач. Такие корпорации как Google, Facebook, ВКонтакте, часто рассматриваемые как эталон высоких нагрузок, обрабатывают миллионы запросов в секунду, но при этом имеют полное право не выполнить некоторые из них по причине аппаратного или программного сбоя. Ничего страшного не случится, в крайнем случае пользователь просто повторит действие. Аналогичным образом данные компании могут потерять часть данных, это хуже, но данные не являются критичными и легко восстанавливаются. Например, когда вы ставите "лайк" в Facebook, то это вовсе не значит, что он тут же становится видим всем пользователям данной социальной сети.

Абсолютно другое дело - приложения, обрабатывающие пользовательские транзакции. При переводе денег из банка в банк невозможно допустить ситуацию, когда они спишутся с одного счета, но не попадут на другой. Аналогично невозможно допустить потери даже части пользовательских данных о финансовых транзакциях. Требования к согласованности данных и надежности информационных систем для того же Google и, например, Федерального резерва абсолютно несопоставимы друг с другом. Данная статья призвана рассказать о том, каким же образом мейнфреймы IBM обеспечивают высочайшую надежность и производительность, и как воспользоваться данными уникальными механизмами из ваших программ на языке Java.


Заглянем под капот



Процессоры

Для обеспечения максимально возможной производительности мейнфрейм zEnterprise EC12 снабжается специальными 6-ти ядерными процессорами, выпускаемыми по технологии 32 нм. и работающими на тактовой частоте 5.5 Ghz. На момент выпуска машины, а возможно и сейчас, это была самая быстрая модель процессора в мире. Топовая модель мейнфрейма может иметь на борту 20 процессоров, что составляет 120 ядер. Часть ядер используется для резервирования, работы канальной подсистемы ввода-вывода и специального использования, а 101 ядро доступно для использования в приложениях. Каждое из этих ядер можно настроить следующим образом:

  • как процессор общего назначения (CP);

  • исключительно для Java- и XML-приложений (zAAP);

  • исключительно для работы информационных систем, например СУБД DB2 (zIIP);

  • исключительно для запуска специальной версии Linux (IFL);

  • для работы аппаратной подсистемы кластеризации (ICF);

  • опционально, как дополнительный процессор для работы канальной подсистемы ввода-вывода (SAP).

О процессорах для Java-приложений я немного расскажу подробнее ниже.

Распределение числа зарезервированных и доступных к использованию ядер в зависимости от модели мейнфрейма представлено в таблице:


Скорость роста тактовой частоты процессоров от поколения к поколению можно увидеть на графике:


Процессоры zEnterprise EC12 имеют три уровня кэш-памяти и один, четвертый, уровень реализован на отдельных микросхемах. Объемы каждого уровня следующие:

  • L1: 64 Кб инструкций, 96 Кб данных на ядро;
  • L2: 1 Мб инструкций, 1 Мб данных на ядро;
  • L3: 48 Мб на процессор;
  • L4: 384 Мб на группу из шести процессоров.

В названиях System z и zEnterprise буква 'z' обозначает 'zero-downtime', т.е. полное отсутствие простоев. Одна из основных решаемых мейнфреймами задач - обеспечение высокой доступности и надежности работы приложений. Поэтому все системы мейнфрейма резервируются, включая даже сервисные элементы - специальные ноутбуки. Процессоры тоже резервируются, каждая модель мейнфрейма имеет по два резервных процессора, при этом важным является тот факт, что переключение процессора в случае выявления системой неисправности происходит на лету, без прерывания исполняемой программы. Данная возможность реализуется исключительно мейнфреймами и ее наличие вполне понятно: в мире существует множество областей, в которых ошибка вычисления может дорого стоить в прямом смысле этого слова.

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

Оперативная память

Каждый мейнфрейм zEnterprise EC12 имеет на борту больше установленной памяти нежели заказано. Часть установленной памяти используется для реализации Redundant Array of Independent Memory (RAIM). Для приложений, работающих на мейнфрейме, доступно до 3 Tб оперативной памяти, при этом одному логическому серверу в составе машины (LPAR) доступно до 1 Тб ОЗУ.

Планки оперативной памяти вместе с группами процессоров и портами ввода-вывода помещаются в специальный модуль, называемый "книгой" (book).


Каждая книга имеет точки подключения системы охлаждения в том числе при необходимости и водяной. Распределение объема доступной ОЗУ по книгам в зависимости от модели мейнфрейма приведено в таблице:


Внутренняя инфраструктура ввода-вывода

Внутренняя инфраструктура ввода-вывода в машине представлена двумя вариантами: InfiniBand I/O, впервые представленной в машинах серии z10 и поддерживающей 6 Гб/с InfiniBand I/O interconnect и PCI Express Generation 2 (PCIe Gen2), используемой ранее в машинах серии z196 и z114, поддерживающей 8 Гб/с PCIe I/O interconnect. Только последняя инфраструктура доступна на новых машинах.

Мы рассмотрели основные внутренние системы мейнфрейма. С некоторыми другими аппаратными возможностями познакомимся уже применительно к вопросу обеспечения работы Java-приложений на данной платформе.


Место для Java


Корпорация IBM считает виртуальную машину JVM и язык программирования Java одним из своих стратегических приоритетов. Инвестиции в данную инфраструктуру огромны. Чего стоит один только сервер приложений IBM WebSphere AS - один из лучших Java EE-совместимых серверов приложений в мире. Так же код на языке Java поддерживается такими продуктами как WebSphere MQ и Integration Bus, адаптеры для Java имеют координаторы транзакций IBM с долгой историей: CICS и IMS TM. Так же на языке Java можно писать хранимые процедуры для реляционной СУБД DB2.

Корпорация заинтересована в стабильной надежной и быстрой работе Java-приложений на мейнфрейме и прилагает к этому множество усилий. Давайте рассмотрим какие возможности мейнфрейма уникальны для исполнения Java-кода.

Настраиваемые наборы процессоров

В последние годы на рынке программного обеспечения наметилась тенденция лицензирования по ядрам. Чем больше процессорных ядер в вашей машине, тем больше лицензий на программное обеспечение вам нужно купить, тем оно дороже. По данной схеме лицензируются СУБД, сервера приложений, различное ПО промежуточного уровня (брокеры сообщений, ESB, BPM и т.д.), а так же корпоративное ПО (CRM, ERP, АБС и т.д.) При этом объективно Java является довольно тяжелой нагрузкой, что связано и со сборкой мусора, и с необходимостью в JIT-компиляции, и с поздним связыванием. Поэтому можно зарезервировать часть имеющихся на борту мейнфрейма ядер под работу исключительно с данным типом нагрузки. Такие зарезервированные ядра или, в терминах мейнфреймщиков, "процессоры" называются zEnteprise Application Assist Processor (zAAP). По аппаратной составляющей это - обычный процессор zEnterprise, часть команд которого отключается в настройках. Сам по себе такой процессор стоит гораздо дешевле обычного, т.н. Generic центрального процессора zEnterprise. Но основная выгода даже не в этом. Данный процессор не участвует в расчете лицензий на программное обеспечение. Таким образом использование zAAP позволяет существенно сэкономить.

При этом zAAP не может исполнять некоторые действия, такие как управление операциями ввода-вывода или работа JNI. Поэтому операционная система z/OS при выполнении диспетчеризации TCB (в мире распределенных систем используется термин "поток") может лениво переводить их с общего центрального процессора (GP) на zAAP и обратно. Если диспетчер видит, что выполняется Java-код, запущенный на GP, то он при выделении следующего кванта времени данному TCB перенесет его на ядро, сконфигурированное как zAAP. Аналогично, если диспетчер понимает, что выполняется JNI, то он при выделении следующего кванта времени запустит соответствующий TCB на GP, а не на zAAP. Естественно, такие переносы занимают время на перестройку кэша и TLB, но в целом оно не настолько критично по сравнению с выигрышем на стоимости лицензий.

Важный момент: использовать процессоры zAAP можно только под операционной системой z/OS, допускается не более двух zAAP на один GP.

Помимо выполнения Java-кода, процессоры zAAP могут использоваться и при работе с XML.

Аппаратная транзакционная память

Мейнфрейм zEnterprise EC12 - первый сервер общего назначения от IBM, содержащий реализацию технологии транзакционной памяти, впервые использованной для того, чтобы сделать суперкомпьютер IBM Blue Gene/Q-based Sequoia, расположенный в Lawrence Livermore National Lab, самым быстрым в мире (по состоянию на октябрь 2014-го года данный суперкомпьютер занимает третью строчку в списке ТОП-500). В мейнфрейме zEnterprise EC12 IBM улучшила данную технологию, адаптировав ее для ускорения выполнения конкурентных операций над общим набором данных, например для параллельного проведения различных финансовых операций по одному и тому же набору счетов.

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

Транзакция начинается специальной командой процессора TBEGIN, а заканчивается командой TEND. Если за время выполнения транзакции какой-то из задействованных ею участков памяти был изменен другим процессором, то транзакция откатывается и восстанавливается состояние регистров общего назначения и оперативной памяти, которое было до ее начала. Затем управление передается блоку transaction failure handler, который решает повторить ли выполнение транзакции или наложить традиционную блокировку (coarse-locking), чтобы гарантировать выполнение нужного кода.


Цель описанного выше zEnterprise EC12 Transactional Execution (TX) facility - избежать необходимости в coarse-grained-locking с целью обеспечить безопасное, свободное от блокировок (lock-free), конкурентное исполнение критических секций. Рассмотрим пример использования TX при работе нескольких читателей и писателя. В классической реализации, использующей блокировки, все читатели ждут освобождения критической секции, соответственно они могут читать область памяти исключительно по одному, друг за другом. В реализации с использованием TX, т.н. lock-elision, читатели работают параллельно до тех пор, пока писатель не изменит общую область памяти.


zEnteprise EC12 Transaction Execution facility включает в себя множество функций обеспечивающих широкое поле оптимизаций, таких как lock-elision, примитивы compare-and-swap (CAS) над несколькими словами (multi-word) и спекулятивные оптимизации.

В IBM Java7 SR3 с включенной опцией -Xaggressive становится доступной реализация многопоточной очереди ConcurentLinkedQueue (CLQ), использующая TX. CLQ - это потокобезопасная реализация очереди, работающей по принципу "первый пришел - первый ушел (FIFO)". Стандартные реализации методов CLQ.offer() и CLQ.poll() основаны на свободных от блокировок алгоритмах и используют циклы и атомарные CAS-операции, т.е. стандартные примитивы, применяемые для построения множества конкурентных алгоритмов. IBM JVM компилирует данные алгоритмы в сотни машинных инструкций. При использовании TX, реализации методов CLQ.offer() и CLQ.poll() заменяются на описанные выше последовательности инструкций, обеспечивающие работу транзакций. Это существенно повышает эффективность алгоритмов из-за того, что сокращается исполняемый набор машинных инструкций и уменьшается необходимость в доступе к данным. Повышение эффективности в два раза подтверждается микробенчмарком.


В последней версии IBM JVM для z/OS - IBM Java7R1 аналогичным образом доработано поведение класса HashTable, эффективность повысилась более чем в 5 раз.


Аппаратная поддержка сжатия данных

Знаете ли вы, что каждый день в мире создается более 2000 петабайт данных? Цифровая вселенная увеличится более чем в 300 раз за время между 2005-м и 2020-м годами, со 130 до 40 000 экзабайт.

В последней версии IBM JVM для z/OS - IBM Java7R1 для работы класса, обеспечивающего поточное сжатие данных, - java.util.zip.GZIPOutputStream - используется специальная карточка - zEDC Express I/O Adapter. Задействование данной карточки позволяет снизить использование процессора на 91% по сравнению с программно реализованным сжатием. Среднее время сжатия снижается на 74%, а уровень сжатия повышается примерно в 5 раз.


zEDC I/O Adapter может использоваться через стандартные API: Java и zlib.

Специальные команды процессора

Начиная с поколения z196, в процессоры машин было добавлено более 70 новых машинных инструкций, часть которых используется для ускорения работы Java. JIT-компилятор использует их при генерации кода. Подробная информация о работе процессора является конфиденциальной, но ознакомиться с системой команд, поддерживаемыми типами данных и некоторыми особенностями можно, изучив документ z/Architecture. Principles of Operation.

Работа с упакованными десятичными числами

В мире финансовых вычислений для обеспечения точности округления и ускорения операций используется формат данных под названием "упакованные десятичные числа" или по-английски Packet Decimal. Данный формат реализован в zEnteprise EC12 аппаратно. Версия IBM Java7R1 предлагает библиотеку для работы c packed decimal. Данная библиотека решает следующие задачи:

  • маршалинг и демаршалинг: трансформация примитивных типов в байтовые массивы, поддерживается как big-, так и little-endian;

  • операции над packed decimal (PD): арифметические, сравнения, проверки ошибок (проверяет, является ли PD-операнд верно сформированным) и специальные: сдвиги и перемещения;

  • конвертация типов: преобразование из Packed Decimal (PD), External Decimal (ED) и Unicode Decimal (UD) в примитивные типы (int, long) и обратно, преобразование между разными десятичными типами (PD, ED, UD) и преобразование десятичных типов в Java-объекты: BigDecimal и BigInteger.


Библиотека является платформенно- и JVM-независимой. Работает непосредственно с массивами байт и не требует создания деревьев Java-объектов, а так же позволяет JIT сгенерировать максимально эффективный для платформы код.

Multi-tenant JVM

В версии IBM Java7R1 в качестве технологического превью доступна такая опция, как multi-tenancy. Включается данная опция с помощью аргумента командной строки, передаваемого при запуске JVM: -Xmt.


Суть данной опции в следующем: в системе стартует единая JVM в виде демона javad. У данной JVM настраивается размер кучи, количество потоков, использование ввода-вывода, CPU. Каждый последующий запуск java создает не отдельную JVM, а лишь небольшую прокси к демону javad.


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

Выводы


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

Сама по себе огромная вычислительная мощь мейнфрейма (101 ядро!) позволяет делать вещи, недоступные на других системах. Например, возможно разместить СУБД, критические для бизнеса приложения и веб-портал, работающий под управлением IBM WebSphere AS, на одной машине, что совместно с применением технологии общей памяти и гиперсокетов позволяет гарантировать минимальное время отклика всего комплекса и его соответствие самому жесткому SLA. Из взаимодействия приложений убирается самая медленная и нестабильная часть - компьютерная сеть.

Использование аппаратной транзакционной памяти (Hardware transactional memory) открывает новую веху в разработке многопоточных приложений. Ученые и энтузиасты долгое время уже занимаются изучением программной транзакционной памяти, накоплены определенные знания, алгоритмы, есть реализации библиотек, в частности под Clojure. Теперь все данные возможности доступны на уровне самой машины, что существенно увеличивает производительность многопоточных приложений. Данное утверждение подтверждено результатами тестов, приведенными в статье.

В целом можно отметить, что слухи о смерти "танцующего динозавра" слишком преувеличены. Уникальная серия, которая недавно отметила свои 50 лет лидерства в серверном мире, продолжает шествие по планете. Мейнфрейм от IBM предлагает высокопроизводительную, надежную, максимально зарезервированную среду исполнения приложений и для нашего любимого языка программирования. Не COBOL'ом единым!


Из графика видно, что за последние 10 лет производительность Java на мейнфреймах выросла в 12 раз.

На последок уместно привести высказывание одного из основателей корпорации IBM, сделанное задолго до появления не только персональных компьютеров, но и средних ЭВМ:

"Развитие вычислительной техники полностью повторит развитие транспорта. Когда-нибудь появятся персональные ЭВМ, как появились персональные автомобили, и для них будет существовать целая сеть мастерских, "дорог" и "заправок". Это будет лучшее средство решения индивидуальных проблем. Наверняка будут средние ЭВМ, роль которых будет аналогична автобусам - решать проблемы небольшой группы потребителей. Решение особых задач потребует быстрых и сверхдорогих компьютеров - их место подобно авиации. Но для решения масштабных задач всегда будут использоваться железные дороги - поезд гарантированно перевезет сотни и тысячи людей на огромные расстояния за очень умеренные деньги. Да, железным дорогам требуется прокладка рельсов, строительство вокзалов, подготовка машинистов и прочее, но в целом ряде случае альтернативы им нет и никогда не будет. Это место наших машин - мейнфреймов.”

Если у вас появились вопросы о работе мейнфрейма, о работе Java на нем, может быть вы - представитель партнера IBM и хотите протестировать или обеспечить работу вашего приложения на zEnterprise, то могу предложить несколько каналов связи. Во-первых, вы можете писать в комментарии, во-вторых, обратиться ко мне по электронной почте pavel.samolysov@ru.ibm.com, в-третьих, позвонить по телефону +7-495-775-88-00 ext. 4353. Всегда буду рад вам помочь.

Материалы


Данная статья во многом основана на презентации Marcel Mitran, Chief Architect IBM JVM on System z под названием A Survey of Java Performance on zEnteprise EC12. Так же использовались следующие ресурсы:


Понравилось сообщение - подпишитесь на блог

15 комментариев:

Роман Комаров комментирует...

Какова цена вопроса?

Pavel Samolisov комментирует...

Цену вопроса обсуждать не имею возможности, но вот здесь пишут, что 896 интеловских ядер (16 32-х ядерных + 8 48-ми ядерных HP Superdome) на 5 лет стоили $180 million, а данная нагрузка, запущенная на 41-м мейнфреймовском ядре под z/OS, обошлась в $111 million 5-ти летнего TCA (т.е. посчитано и железо, и софт и скорее всего еще и место в дата-центре, электроэнергия и зарплата администраторов.

Артем Абих комментирует...

Крутая штуковина, и цена не менее крутая)

Unknown комментирует...

Павел, оставляешь только удобные комментарии?
Может приведешь примеры успешных внедрений в РФ и их примерную архитектуру, какое ПО и на чем оно написано? Хочется примеров демонстрирующих "Абсолютно другое дело - приложения, обрабатывающие пользовательские транзакции. При переводе денег из банка в банк невозможно допустить ситуацию, когда они спишутся с одного счета, но не попадут на другой. Аналогично невозможно допустить потери даже части пользовательских данных о финансовых транзакциях. Требования к согласованности данных и надежности информационных систем для того же Google и, например, Федерального резерва абсолютно несопоставимы друг с другом"
Я немного наслышан об одном внедрении, упоминаемом например здесь http://www.connect.ru/article.asp?id=8343, дак на сколько мне известно в нутрях у него Oracle DB, который доступен на zos только в старой версии, со всеми вытекающими.

Pavel Samolisov комментирует...

Коллеги, мы работаем и с Банком России и с другими заказчиками, использующими нашу технику и ПО. Помимо Oracle DB существует и СУБД DB2 z/OS, реляционная СУБД от IBM, использующая всю мощь платформы zEnterprise и z/OS. Есть успешные проекты миграции приложений на нашу СУБД в том числе и для России, надеюсь скоро появятся соответствующие пресс-релизы. Впрочем, статья объясняет преимущества использования Java на z/OS, давайте придерживаться этой темы обсуждения.

З.Ы. Я пропускаю все комментарии, не содержащие оскорблений и ненормативной лексики. Данный ваш комментарий был первым в моем блоге, насколько я помню, поэтому заход с фразы "оставляешь только удобные комментарии" смотрится несколько странно.

В любом случае благодарю вас за обратную связь.

Pavel Samolisov комментирует...

Уважаемый Unknown, я предлагаю не обсуждать в моем блоге конкретных клиентов IBM.

Вы оставили комментарий следующего содержания:

Очень странно, так как это был не первый комментарий, а как минимум второй. На второй раз я не стал расписывать более подробно, но раз все таки диалог идет, то могу в кратце повторить мысль из него.
Тезис был в том, что краеугольным камнем некой абстрактной системы, занимающейся обработкой финансовых транзакций является СУБД, а никак не Java. Дальше понимаем, что нам нужна полноценная энтерпрайз СУБД, с блекджеком и ... нормальным суппоротом. Смотрим какие игроки у нас имеются:
1. Весьма популярная на территории СНГ - Oracle либо старая версия, либо вместо zOs ставим zLinux. В общем смысла особого нет, т.к. за эти же деньги купят exadata.
2. MS SQL - без вариантов.
3. DB2, вроде бы наш вариант, но есть нюанс, LUW версия слегка не тоже самое, что версия для zOs. А сколько можно найти специалистов по DB2 for zOs? К сожалению очень немного...

А просто некое абстрактное Java приложение без привязки к необходимости честного ACID, работы с СУБД и т.д., то непонятен профит от мейнфрейма и возвращаемся к опции про россыпь из x86.

Pavel Samolisov комментирует...

Если я вас правильно понял, то основная претензия к DB2 z/OS - малое количество специалистов. Это действительно так, но давайте посмотрим с другой стороны. Много ли на локальном рынке специалистов по той же Exadata? Есть ли в России люди, работающие с Exalogic, кто-то вообще его видел? Рынок мейнфреймов, как впрочем и машин баз данных, - это не рынок широкого потребления. С одной стороны на нем мало специалистов, с другой - мало работодателей. Работодателям и специалистам приходится учиться работать в условиях высокой лояльности друг к другу.

Если вообще говорить о мейнфреймах, то это абсолютно иной тренд в IT, противоположный популярному "каждые пять лет появляется новый оператор Java/C#, нужно выбросить весь код и переписать заново, все переписать!" Мейнфреймы - это 50 лет эволюции при сохранении обратной совместимости. Это десятки лет возврата инвестиций в ПО. За это время сменились поколения специалистов, а в наших реалиях встречаются семьи, где отец работал с ЕС ЭВМ, а сын продолжает работать с zEnterprise. По сути мэйнфреймы позволяют превратить IT в действительно инженерную дисциплину, в которой методики накапливаются десятками лет аналогично машиностроению и прочим областям промышленности. Уверен, что специалистов по мейнфреймам в России все же больше, чем по той же Exadata, не в обиду последней будет сказано.

Если же вернуться к вопросу, то корпорация IBM естественно помогает и партнерам, и заказчикам как с миграцией приложений, так и с обучением. Я пока знаком не с большим количеством специалистов по DB2 z/OS, но те, кого я знаю, переходили с Oracle DB. Могу поспрашивать сколько времени занял у них такой переход.

db2man комментирует...

Я понимаю когда нужно построить высококритичную-высокопроизводительную БД-платформу федерального масштаба (берем DB2/zOS, делаем сисплекс-даташаринг и радуемся), но покупать System z под java-нагрузки ??? Цена масштабирования этих самых java-нагрузок (активациия zIIP-zAAP и памяти) будет мягко говоря неадекватной.
Ну в общем повторюсь, как в том комментарии, который Вы, видимо, не пропустили - сия идея есть забивание гвоздей золотым микроскопом.

Pavel Samolisov комментирует...

Не очень понимаю, с кем я разговариваю, вы - db2man или Unknown?

Что касается накладных расходов на использование Java на мейнфрейме и конкретно на переключение zIIP/zAAP, могу ли я вас попросить привести источник осведомленности? Вы знаете о том, что данное переключение стоит дорого из собственного опыта и выполнения каких-то тестов, или это утверждение из той же оперы, что и "Java тормозит"?

db2man комментирует...

Я не Unknown :) Оставлял комментарий пару месяцев назад, когда вышел пост.

Пойнт был не про performance, а про price/performance. Больше java-нагрузка - больше дорогих zIIP/zAAP нужно активировать (а с учетом обязательности 1 CP на каждые 2 zIIP/zAAP еще дороже) и массовый java-деплоймент под z/OS быстро становится экономически неэффективным.

Pavel Samolisov комментирует...

zIIP и zAAP стоят гораздо дешевле CP + экономия на стоимости лицензий. На мой взгляд, это как раз и есть пример экономии от использовании Java на мейнфрейме. Магии не бывает, поступающую нагрузку нужно каким-то образом обрабатывать, если не на Java, то на COBOL, C, C++, HASM и т.д., которые исполняются на более дорогих во всех отношениях CP. Можно предположить, что приложение на COBOL или C++ само по себе будет потреблять меньше процессора, чем решающее эту же задачу приложение на Java. В некоторых случаях это действительно так, в других - разница не столь очевидна.

db2man комментирует...

> zIIP и zAAP стоят гораздо дешевле CP +

Если верить этому (взято с http://tech-news.com/publib/pl2827.html) :

"ZAAP and ZIIP specialty engines add $100,000 to price plus $1,662 per month maintenance."

то даже страшно представить сколько стоит 1 CP :)

> + экономия на стоимости лицензий. На мой взгляд, это как раз и есть пример экономии от использовании Java на мейнфрейме.

Смотря с чем сравнивать. PVU-лицензии на WAS для машины IBM POWER S824 (24 ядра POWER8) выйдут в 92400$ в листе. Т.е меньше стоимости ОДНОГО zIIP/zAAP ;-)

Pavel Samolisov комментирует...

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

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

db2man комментирует...

> Публикации бывают разными, к тому же там написано "engineS", а не один engine.

"engineS" относится к тому что их два типа (zIIP и zAAP на выбор). Про IFL там же написано в единственном числе :)

> это не официальные цены IBM.

Это понятно. По "листу" никто никогда ничего не покупает. Просто грубая оценка "масштаба бедствия" :)




Pavel Samolisov комментирует...

Дело не в "по листу" или "не по листу". Дело в том, что вы ссылаетесь на публикацию в непонятном техническом блоге, а не на официальную информацию IBM.

Отправить комментарий

Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!