www-03.ibm.com/systems/z/os/linux/getstarted.html
Самые популярные дистрибутивы — SUSE и RedHat, специальные сборки под процессор мейнфрейма, обычно именуются s390. Выше Евгений Хабаров хорошо расписал этот момент.
Очень важно, что мы и хотим донести до аудитории — мы не нашли кейс, нам принесли реальное бизнес-приложение, решающее реальную бизнес-задачу — банковскую платежную систему. Данная система до этого разрабатывалась исключительно на Oracle и Linux. С нашей помощью была осуществлена миграция данной системы на z/OS + DB2, после чего были проведены сравнительные испытания, результатом которых мы и делимся.
Все данные телеметрии, собранные при проведении тестов у нас имеются (больше сотни страниц), есть все необходимые графики. По понятным причинам мы не можем выложить это в публичный доступ. Если вам или кому-нибудь другому данная информация действительно интересна, то прошу написать мне личное сообщение, в котором указать, какую компанию вы представляете, после чего можем встретиться в нашем офисе и пообщаться.
Коллеги, кто действительно заинтересовался темой, приходите на семинар 26 и 27 марта z13 Technical Enablement Roadshow, где мы расскажем про новый мейнфрейм. Семинар будет исключительно технический, приедут коллеги из Монпелье, Франция. В кулуарах можно будет обсудить и Linux vs z/OS, а так же другие темы.
Следует обратить внимание на время выполнения многостороннего взаимозачета без учета работы с СУБД, т.е. время выполнения только расчетной части. На z/OS данное время оказалось на 25% меньше, чем на Linux. Это веский аргумент в пику имеющемуся среди специалистов по информационным технологиям убеждению, что Java плохо работает на z/OS и что не следует использовать данную операционную систему для запуска Java-приложений.
Если вы имеете ввиду, что IBM добавляет какие-то закладки в свою JDK на Linux, чтобы та тормозила, то уверен, что такого нет. Верить в такие закладки — это все равно, что верить в слив данных Интелом в АНБ о том, какой код выполняется на их процессорах и что он делает.
Конечно коллеги, разрабатывающие Java для z/OS по максимуму используют возможности аппаратуры. Я как-то писал об этом в личном блоге большую статью. По сути быстрая Java — это одно из конкурентных преимуществ платформы, а не «узкое место».
MS-DOS — это однозадачная операционная система, речь же идет о коммуникации двух одновременно работающих приложений (у каждого свое адресное пространство, в мире мейнфреймов именно этот термин обычно и используется).
Всеми данными, которыми можно было поделиться мы поделились. Начинать публиковать планы выполнения запросов нам никто не позволит, да и если честно, не думаю, что это так важно, т.к. очень специфичная для конкретного приложения информация. А вот архитектурно значимые вещи: выбор операционной системы, СУБД, топологии развертывания и их влияние на работу приложения определенного класса — OLTP — продемонстрированы. Первый комментатор правильно отметил, что использование родной для платформы операционной системы вместе с таковой же СУБД очевидно даст лучшие результаты по производительности, это всем понятный факт. Но вот настолько лучшие, думаю, для многих оказалось сюрпризом. Можно конечно от этого отмахнуться и списать на «вы все врети», но это какой-то не инженерный подход.
Я с вами согласен, но на принятие решение о выборе конфигурации влияет множество факторов, не только скорость работы. Тестирование — процесс не бесплатный, а довольно затратный. Тестируется не просто сферический конь в вакууме, а конфигурация, которая может удовлетворить заказчика. Заказчик естественно выбирает исходя из имеющихся лучших практик. В мире линукс такой лучшей практикой является разнесение компонентов стека по разным образам операционной системы.
Для меня, как технического специалиста, архитектора, безусловно интересны все варианты, но к сожалению возможности не безграничны. Сам был бы рад и надеюсь мы еще сможем протестировать и DB2 + Linux vs DB2 + z/OS, и другие варианты, ну и конечно же поделиться ими с сообществом.
Лет пять назад, если мне не изменяет память, я точно так же хейтил Microsoft и тролил их евангелистов, ну как тролил, искренне считал, что искрометно тролю. Потом вырос.
Я понимаю, что данная статья задевает чувства многих людей, которые искренне любят Линукс и открытые исходники, но числа есть числа, с другой стороны — только невнятные предположения. При этом ненавидеть IBM линукс-сообществу наверное не стоит, корпорация вкладывает миллиарды долларов в развитие данной операционной системы.
Я согласен, данное сравнение было бы интересно, но мы — авторы статьи — занимаемся мейнфреймами, может быть коллеги, занимающиеся распределенными системами, порадуют читателей таким материалом.
Как единственный пока представитель нашей небольшой z-команды на Хабре постараюсь ответить на все комментарии.
Во-первых, отвечу на претензии вида «разное железо». В тестах использовалось два идентичных по параметрам мейнфрейма, количество ресурсов, выделямых на каждый вариант развертывания приложения, определялось организаторами тестирования. Как видите в варианте с Oracle'ом памяти выделено даже больше, совокупное число процессоров было одинаковым.
Во-вторых, отвечу на претензии вида «разные названия ПО». Если честно претензия непонятна, естественно СУБД использовались разные, от разных производителей. Сервер приложений был одним и тем же — WebSphere Application Server 8.5.5, просто версия под распределенные системы называется «Network Deployment», а версия для z/OS — «for z/OS». Тестировалось одно и то же прикладное решение, основанное на платформе Java EE.
В-третьих, хотя пассаж про «прослойку zLinux» уже прокомментировали, немного дополню. И Linux, и z/OS работали под управлением аппаратно-микропрограммного гипервизова Processor Resource and System Manager (PR/SM). Никакой дополнительной виртуализации для Linux не использовалось.
Самое существенное высказанное замечание — в случае z/OS использовалась ее сила — colocation, а в случае Linux — СУБД и сервер приложений были разнесены на разные LPAR'ы и взаимодействовали по сети (в тесте использовалась реальная сеть 10 Gb). Возможно сравнение с вариантом «все подсистемы в рамках одного образа Linux» было бы интереснее с технической точки зрения, но это был бы синтетический тест. Почему-то на практике специалисты по Linux так решения для промышленной эксплуатации не разворачивают. Они стараются разносить СУБД, сервер приложений, а был бы еще и MQ, то и его, по разным образам операционной системы. Почему они так делают я сказать не могу.
По поводу сравнения разных дистрибутивов Linux. Дело не в дистрибутиве, а в том, что при любом дистрибутиве Linux остается Linux'ом со всеми его плюсами и минусами. z/OS как проприентарная (я все же употребил это страшное слово!) система адресно затачивается под железо. Упрекать за это — все равно, что причитать: «ага, ваш боксер победил, потому что тренировался, а наш — нет!» Linux же разрабатывается сообществом как кроссплатформенное решение. В этом его сила, и… слабость. В данной статье эта слабость наглядно продемонстрирована.
Мы описали это в статье: «Многосторонний взаимозачет выполняется в один поток (т.е. он в принципе не масштабируется, так написано приложение). Время его проведения в кластерном режиме увеличивается из-за необходимости пересылки блокировок DB2 в CF при выполнении массовых операций DML.»
Фаза 2 не является критической, в том смысле что она выполняется несколько раз в сутки и ее при необходимости можно повторить, это — одна транзакция. Однако мы тестировали восстановление после сбоев и на этой фазе и при падении любого компонента системы (WAS, MQ, DB2) платежи продолжали обрабатываться.
Мне не понятно, почему вы сделали вывод, что при обработке карточек все было бы плачевнее, срочные платежи системой обрабатываются на кластере с расстоянием 70 км. в среднем всего на 7,6% медленнее.
У нас не было возможности протестировать на большем расстоянии. По данным нашей интерполяции на 100 км работать будет, но конечно результаты реального теста были бы нагляднее. Для расстояний 500 — 1000 — далее везде требуется асинхронная репликация.
Все платежи считываются из входной очереди и проходят по «конвейеру», но часть платежей (несрочные) могут накапливаться и реально обрабатываются несколько раз в сутки на фазе два (взаимозачет), а часть платежей должны быть обработаны как можно быстрее (срочные), при этом заказчиком задан жесткий SLA на максимальное время обработки таких платежей. Да собственно это все описано в статье.
Самые популярные дистрибутивы — SUSE и RedHat, специальные сборки под процессор мейнфрейма, обычно именуются s390. Выше Евгений Хабаров хорошо расписал этот момент.
Все данные телеметрии, собранные при проведении тестов у нас имеются (больше сотни страниц), есть все необходимые графики. По понятным причинам мы не можем выложить это в публичный доступ. Если вам или кому-нибудь другому данная информация действительно интересна, то прошу написать мне личное сообщение, в котором указать, какую компанию вы представляете, после чего можем встретиться в нашем офисе и пообщаться.
Следует обратить внимание на время выполнения многостороннего взаимозачета без учета работы с СУБД, т.е. время выполнения только расчетной части. На z/OS данное время оказалось на 25% меньше, чем на Linux. Это веский аргумент в пику имеющемуся среди специалистов по информационным технологиям убеждению, что Java плохо работает на z/OS и что не следует использовать данную операционную систему для запуска Java-приложений.
Конечно коллеги, разрабатывающие Java для z/OS по максимуму используют возможности аппаратуры. Я как-то писал об этом в личном блоге большую статью. По сути быстрая Java — это одно из конкурентных преимуществ платформы, а не «узкое место».
Для меня, как технического специалиста, архитектора, безусловно интересны все варианты, но к сожалению возможности не безграничны. Сам был бы рад и надеюсь мы еще сможем протестировать и DB2 + Linux vs DB2 + z/OS, и другие варианты, ну и конечно же поделиться ими с сообществом.
Я понимаю, что данная статья задевает чувства многих людей, которые искренне любят Линукс и открытые исходники, но числа есть числа, с другой стороны — только невнятные предположения. При этом ненавидеть IBM линукс-сообществу наверное не стоит, корпорация вкладывает миллиарды долларов в развитие данной операционной системы.
Во-первых, отвечу на претензии вида «разное железо». В тестах использовалось два идентичных по параметрам мейнфрейма, количество ресурсов, выделямых на каждый вариант развертывания приложения, определялось организаторами тестирования. Как видите в варианте с Oracle'ом памяти выделено даже больше, совокупное число процессоров было одинаковым.
Во-вторых, отвечу на претензии вида «разные названия ПО». Если честно претензия непонятна, естественно СУБД использовались разные, от разных производителей. Сервер приложений был одним и тем же — WebSphere Application Server 8.5.5, просто версия под распределенные системы называется «Network Deployment», а версия для z/OS — «for z/OS». Тестировалось одно и то же прикладное решение, основанное на платформе Java EE.
В-третьих, хотя пассаж про «прослойку zLinux» уже прокомментировали, немного дополню. И Linux, и z/OS работали под управлением аппаратно-микропрограммного гипервизова Processor Resource and System Manager (PR/SM). Никакой дополнительной виртуализации для Linux не использовалось.
Самое существенное высказанное замечание — в случае z/OS использовалась ее сила — colocation, а в случае Linux — СУБД и сервер приложений были разнесены на разные LPAR'ы и взаимодействовали по сети (в тесте использовалась реальная сеть 10 Gb). Возможно сравнение с вариантом «все подсистемы в рамках одного образа Linux» было бы интереснее с технической точки зрения, но это был бы синтетический тест. Почему-то на практике специалисты по Linux так решения для промышленной эксплуатации не разворачивают. Они стараются разносить СУБД, сервер приложений, а был бы еще и MQ, то и его, по разным образам операционной системы. Почему они так делают я сказать не могу.
По поводу сравнения разных дистрибутивов Linux. Дело не в дистрибутиве, а в том, что при любом дистрибутиве Linux остается Linux'ом со всеми его плюсами и минусами. z/OS как проприентарная (я все же употребил это страшное слово!) система адресно затачивается под железо. Упрекать за это — все равно, что причитать: «ага, ваш боксер победил, потому что тренировался, а наш — нет!» Linux же разрабатывается сообществом как кроссплатформенное решение. В этом его сила, и… слабость. В данной статье эта слабость наглядно продемонстрирована.
Мне не понятно, почему вы сделали вывод, что при обработке карточек все было бы плачевнее, срочные платежи системой обрабатываются на кластере с расстоянием 70 км. в среднем всего на 7,6% медленнее.
Все платежи считываются из входной очереди и проходят по «конвейеру», но часть платежей (несрочные) могут накапливаться и реально обрабатываются несколько раз в сутки на фазе два (взаимозачет), а часть платежей должны быть обработаны как можно быстрее (срочные), при этом заказчиком задан жесткий SLA на максимальное время обработки таких платежей. Да собственно это все описано в статье.