Личные впечатления об использования Linux-а на мэйнфреймах. Не отчет, а просто заметки и приглашение к дальнейшему обсуждению темы. Первый личный опыт использования
Linux на мэйнфреймах архитектуры IBM S/390 приходится на конец 90-х
(точнее не помню). Дистрибутив был скачан с рекомендованного IBM сайта www.marist.edu.
С некоторым трудом на его основе была сделана пробная система, она
успешно грузилась и, кроме ядра и необходимых сетевых компонент,
практически ничего в ней не запускалось. Установка системы
сопровождалась активным использованием недокументированных команд и
личных указаний разработчиков, которыми они активно делились. Было
понятно, что это «пробный шар», и поэтому особых требований к качеству
программного продукта в тот момент не предъявлялось. Мой оптимизм в
отношении будущего Linux на платформе S/390 базировался на следующих
простых соображениях: - в
S/390 намного меньше внешних устройств, которые нужно обеспечивать, и
они довольно консервативны, поэтому проще написать надежные драйвера
внешних устройств («ахиллесова пята» многих ранних реализаций Linux и
постоянный источник ошибок для всех систем);
- S/390,
как любая зрелая серверная платформа, имеет развитые средства
мультипрограммирования и защиты адресных пространств, поэтому есть шанс
сделать надежное защищенное ядро, может быть, даже более стабильное,
чем для Intel.
Так
что оставалось ждать результатов усилий всех тех энтузиастов, которые
подключились к разработке Linux на S/390. Да и IBM недвусмысленно
заявил о финансовой поддержке данного проекта. На новый уровень мои изыскания вышли с выпуском версий TurboLinux 6.2 и SUSE 7 для S/390. Они базировались на версии ядра 2.2.х и выглядели уже как нормальные качественные продукты. В состав дистрибутива SUSE входило 3 CD-ROMа с программами, как серверными, так и клиентскими, претендуя таким образом на некую универсальную платформу, а TurboLinux,
позиционировав свой продукт как серверный, ограничил свой дистрибутив
одним диском, собрав на него в основном серверные компоненты. Личные
впечатления остались противоречивыми. С одной стороны, стало понятно, что Linux на S/390 все-таки работать может, и это было в тот момент самым главным. Поднимались WWW-сервера, формировались и передавались страницы, выполнялись PHP-скрипты,
в общем, я и мои коллеги были полны энтузиазма и перед нами открывались
широкие перспективы применения мэйнфреймов на новом поле – в качестве
сверхмощных Unix/Linux серверов. С другой стороны огорчали определенные «накладки» и недоработки, совсем не свойственные уже хорошо доведенным «родным» операционным системам – например, тот же SUSE
просто замедлялся в разах, если дать ему много оперативной памяти.
Именно МНОГО, а не мало – из-за ошибок в механизме управления реальной
памятью в этом случае возникали большие накладные расходы на
обслуживание таблиц, своппинг и прочее. Кроме того,
IBM заявил, что не будет открывать исходные коды для целого ряда
применяемых в Linux драйверов устройств – они будут распространяться на
условиях OCO –лицензий (object code only).
Из-за этого для сопровождения Linux со стороны IBM применяется довольно
своеобразная процедура, основанная на программных «потоках» (streams),
так что прежде чем скачивать свежие драйвера от IBM приходилось иногда
поднимать версию целого ряда компонент, чтобы «дотянуть» систему до
указанного IBM-ом «потока». Все это, конечно,
раздражало, но я был уверен, что это своего рода «болезни роста», в той
или иной мере свойственные любой новорожденной операционной системе.
Кроме того, развитие Linux шло полным ходом, и была надежда что в самом ближайшем будущем все изменится к лучшему. Эту надежду питали, в частности, заявления все новых и
новых производителей Linux-дистрибутивов о выходе их вариантов систем
для S/390 и анонсы производителей прикладных систем (как IBM со своими DB2 и Lotus, так и других, известных на рынке – Oracle,
Software AG и проч.) о переносе своих продуктов в новую среду. Стало
понятно, что на наших глазах завершается «подростковый» период Linux на
платформе S/390, и он вот-вот превратится в полноценную промышленную
систему. Будущее виделось многообещающим, и я с коллегами с нетерпением
ждали появления новых продуктов. Будущее настало очень быстро. В конце 2003 года я начал активные изыскания в области новых версий Linux-систем на S/390 имея в своем распоряжении три дистрибутива: · Red Hat 7.2 для S/390; · Debian 3.0r1 для S/390; · SUSE Linux Enterprise Server 8 for S/390. Каждый
из них был вполне развит, и я прекратил поиск и закачку других
дистрибутивов – их общее количество к тому моменту приблизилось к
десятку. Рискну дать их очень поверхностную и субъективную
характеристику. Red Hat 7.2 для S/390: - фирма имеет давний опыт по сопровождению Linux-дистрибутивов, ее продукты широко распространены и прилично документированы; - S/390-вариант похож на Intel
по своей структуре, поэтому можно воспользоваться книгами и знаниями
людей, у которых уже есть опыт применения этой системы (по мнению
многих из них, кстати, именно 7.2 наиболее стабильная рекомендованная
серверная версия); - IBM включил этот дистрибутив в список рекомендованных, поэтому дает свои изменения привязанными к версиям данного (и других рекомендованных) дистрибутива; - и
сам дистрибутив, и изменения к нему выложены на сайте поставщика в
свободном доступе – в виде «файлового мешка». Его надо качать и
устанавливать через FTP. Debian 3.0r1 для S/390: - поддерживается таким мощным коллективом, как GNU-сообщество; - полностью аналогичен версии
на всех других платформах, не отстает практически ни на день (это
уникально. Остальные распространители выпускают свои версии на S/390
позже версий для Intel, и они имеют значительно больше различий в своих диалектах); - имеет самую развитую систему сопровождения и внесения изменений – программы jigdo и apt. Правильное применение этих компонент позволяет с минимальными потерями времени на администрирование и соединение с Интернет поддерживать систему в актуальном и непротиворечивом состоянии; - достаточно
консервативен, по скорости выпуска новых версий отстает от конкурентов
(по отзывам разработчиков – из-за более тщательного тестирования.
Может, так оно и есть, кто знает…); - НЕ
входит в список рекомендованных IBM дистрибутивов, и вообще нелюбим
IBM-ом до колик в животе. Эти чувства, очевидно, взаимны – GNU-сообщество обвиняет IBM в отходе от Linux-принципов из-за OCO-лицензирования части драйверов. По этой причине IBM-драйвера работают, разумеется, в Debian,
но в состав поставки не входят, качать их надо самостоятельно, и
устанавливать – тоже. В свете IBM-технологии «потоков» это зачастую
становится нетривиальным процессом; - по
вышеупомянутой причине этот дистрибутив нелюбим также и другими
производителями ПО – зачастую их процедуры установки настроены только
на рекомендованные дистрибутивы. Это «лечится» ручным вмешательством в
процесс установки, и то не всегда. - по
субъективному мнению – самый гибкий и интересный дистрибутив, но
требует более высокой квалификации администратора, нежели для работы с
конкурентными продуктами. Практически вся настройка осуществляется
через текстовые файлы, поэтому надо понимать, что, где и когда делаешь; - самый большой по объему и функциональному наполнению – 7-8 компакт дисков, абсолютный чемпион в данной категории. SUSE Linux Enterprise Server 8 for S/390: - выпускается
опытным европейским поставщиком Linux, является самым распространенным
на платформе S/390 в мире (его доля больше, чем доля всех остальных,
вместе взятых) и самым распространенным на других платформах в Европе
(хотя тут его доля не так велика, RedHat наступает на пятки); - Linux-лаборатория IBM располагается в том же маленьком немецком городе, что и штаб-квартира SUSE,
к работе привлечены одни и те же люди, поэтому данный дистрибутив
является «самым IBM-овским» и, разумеется, входит в состав
рекомендуемых; - по вышеупомянутым причинам он же и является самым коммерческим – закрыт не только сам дистрибутив (скачать нельзя), но и абсолютно все изменения; - этот дистрибутив наиболее полно документирован – redbook-и IBM тоже пишутся на его основе (понятно почему); - имеется официальный представитель SUSE
в России – не помню, кто, но можно узнать. Все, как положено –
российская фирма, рублевый счет и т.д. Но он просто подключают вас к их
англоязычному сервису, своих технических специалистов для платформы
S/390 у них нет; - имеет
самый дружелюбный интерфейс, наиболее свежие версии продуктов и
достаточно хорошо наполнен функционально – комплект из 3 дисков с
программами; - исключительно прост в установке и настройке. Итак, все эти дистрибутивы были установлены и настроены практически одновременно. Все они базировались на разных версиях ядра
2.4, были стабильны в работе и включали в себя достаточно продуктов,
чтобы попробовать сделать что-то полезное. Раньше не хватало
коммерческих прикладных систем – теперь они появились. Я имел некоторое
отношение к работам, связанным с тестированием TAMINO XML Server от Software AG. В прикладных системах я ничего не понимаю, поэтому обсуждать их не могу, но в процессе испытаний выявилось много интересного о самой ОС Linux. Установка TAMINO
сопровождалась большим количеством подготовительных действий –
трансляцией и установкой дополнительных продуктов, настройкой разного
рода компонент WWW-сервера Apache,
выполнением и модификацией всяких установочных скриптов, наполнением и
обслуживанием тестовой базы данных и проч., и производились эти
действия на очень неслабых ЭВМ – IBM 9672-R16 (примерно 117 MIPS) и z800 (примерно 170 MIPS, на этих машинах в настоящее время работают в OS/390 несколько сотен пользователей с очень хорошим временем реакции как на процессорных, так и на информационных задачах). При этом аналогичные действия выполнялись на платформе Intel, как в среде Win32, так и в Linux, поэтому я мог сравнить ощущения. Поскольку испытания шли долго, и в них была заинтересованность как со стороны IBM, так и Software AG,
то у нас была возможность консультироваться с их специалистами в том
объеме, какой мы считали необходимым. Некоторые из этих специалистов
имели доступ к вычислительной установке, и могли проводить настройку
любой требуемой глубины – вплоть до изменения аппаратного конфигуратора
S/390. Да и нас поучили на куче семинаров, посвященных Linux-у.
Особенно запомнился недельный IBM-овский семинар с привлечением
французских специалистов, где мы работали с IBM 9672-Z67,
развернутой в Монпелье. Почему я так подробно об этом говорю? Чтобы
вызвать доверие к итоговому неутешительному выводу – Linux на платформе
S/390 работает страшно медленно. Вот об этом и надо рассказать подробнее. Во-первых, что такое «медленно» и когда это происходит? По моим замерам трансляция исходных кодов Apache шла медленнее в 3 раза, нежели на Intel 2,4 ГГц. Примерно такая же пропорция сохранялась
на всех процессорных приложениях. А таких приложений немало. Ну ладно,
трансляция нового пакета перед установкой – разовая процедура, в
стабильных версиях применяемая достаточно редко (хотя для разработчиков
– обычное дело, но их можно вытолкнуть на другую, более дешевую
платформу). Но вот выполнение парсинга XML-документов – основная постоянная нагрузка для XML-сервера. Похожая по типу работа осуществляется при формировании интерактивных страниц на основе содержимого SQL-баз
– то есть то, чем занимаются практически все хостинговые сервера.
Информационные задачи (такие, где основная работа связана с выполнением
операций ввода-вывода) выполнялись в целом неплохо, но не быстрее, чем
на современных Intel-серверах. В
этом случае утешает то, что у S/390 более высокая пропускная
способность – пусть запросы на ввод-вывод выполняются не очень быстро,
зато параллельно и их может быть много. Но процессоров-то в ЭВМ не так
много, и они страшно дорогие! Во-вторых,
почему это происходит? Как мне кажется, причина более-менее понятна.
Линейная вычислительная скорость IBM-овского процессора невысока, и
таковой никогда не была. Например, процессор на z800
работает с тактовой частотой 900 МГц. Другое дело, что инструкции,
которые он выполняет с такой скоростью – другие, иногда они существенно
более высокоуровневые, нежели на Intel. Взять хотя бы инструкцию «ПЕРЕКОДИРОВАТЬ» (TR) либо «ПЕРЕКОДИРОВАТЬ И ПРОВЕРИТЬ» (TRT)! На Intel
для этого нужна была бы целая подпрограмма, а здесь – один такт.
Символьные преобразования – вообще сильная сторона IBM S/390, и в
парсинге это можно было бы применить. Но в том то и дело, что Linux
такие команды практически не использует – он ведь портирован, причем
портирован с минимальными изменениями. И кроме этой возможности, не
использует еще ряд других – например, быстрое переключение адресных
пространств с использованием управляющих регистров, особенности
функционирования канальной системы ввода-вывода, обмен информацией
между адресными пространствами с помощью адресных регистров и т.д.
Понятно, что для того, чтобы все это использовать, нужно было бы
перерабатывать транслятор и некоторые алгоритмы ядра – но это значило
бы полный отказ от идеологии Linux и выбор курса IBM-ом на создание
собственного «IBM Unix». Идти на
это IBM не хочет. Поэтому в ближайшее время ожидать кардинального
улучшения скоростных характеристик Linux не приходится. Кроме того, все
конкуренты Linux на платформе S/390 написаны на ассемблере, они
отлаживались многие годы и полностью используют упомянутые выше
архитектурные особенности. Linux написан на Си, разработчики намеренно
изолируют его от каких бы то ни было особенностей оборудования, а
значит, и от его, оборудования, потенциальных преимуществ, и его
зрелость как серверной системы еще очень далеко впереди. Вообще имеется ли смысл использовать Linux и когда?
Безусловно, имеется. Просто надо хорошо отдавать себе отчет в силе и
слабости Linux. Выбирать Linux в качестве платформы для консолидации
серверов имеет смысл только тогда, когда степень загрузки процессора
каждым из этих серверов невелика - примерно около 10%, и пик нагрузки этих серверов не приходится на одно и то же время. Другой удачный пример – своего рода frond-end сервер для группы систем архитектуры S/390. Тогда Linux будет работать в качестве системы для «WWW-FireWall-Proxy-сервера» и связной компоненты в прикладную среду обработки данных OS/390 или VM (в случае применения DB2 для этого можно использовать DB2 Connect). Сам
Linux будет жить в своей виртуальной машине (или логической партиции),
а OS/390 – в своей. Связь между ними можно обеспечить очень быструю –
например, с помощью HiperSocket-плат либо средствами ОС VM.
Ведь даже относительная «медлительность» ОС Linux не перечеркивает его
бесспорные достоинства – бесплатность, функциональность, наличие
подготовленных к работе с Linux администраторов и высокую пропускную
способность аппаратной платформы S/390. Просто надо иметь мощные
многопроцессорные машины, тогда и время реакции приложений можно будет
очень существенно улучшить как за счет распараллеливания, так и за счет
более редкой смены контекста – очень затратной в Linux операции. Что могло бы кардинально улучшить перспективы Linux на платформе S/390?
Я думаю, что есть два решающих фактора – цена процессора и его
быстродействие. Если IBM сможет создать быстрые процессоры архитектуры
S/390, которые при этом стоили бы на порядок дешевле, чем они стоят
сейчас - это бы решило многие проблемы с применением Linux данной платформе. А как бы шикарно на таких процессорах работали бы VM и OS/390!
Именно поэтому я не ожидаю в ближайшем будущем революционных изменений
в этом отношении. Так что будем пока работать с тем, что есть и вносить
свой вклад в развитие идеи свободно распространяемого программного
обеспечения – самой красивой и романтичной идеи в нашей работе. Беда
только, что романтика не всегда уживается с прозой жизни. |
