Началась эта история с того, что наш уважаемый заказчик решил уменьшить риски эксплуатации оборудования 10-ти летнего возраста, сэкономить на лицензиях и перейти с Unix на Linux, а заодно и виртуализировать это программно-аппаратное решение. Не то, чтобы заказчик не любил Solaris и Unix, просто сама возможность виртуализировать серверное приложение, жестко привязанное к специфической на сегодняшний день архитектуре SPARC и «седеющей» операционной системе Solaris, выглядела для заказчика очень привлекательной. Отдельным пунктом стоял вопрос замены специализированной карты с PCI интерфейсом на доступное «виртуализированное» решение. Мы решили взяться за такую интересную задачу.
До того, как мы увидели исходники мы плохо представляли себе, с чем имеем дело. Позже, познакомившись с задачей поближе, мы увидели, что UNIX демон представляет собой:
- «привязанный» к системным вызовам ядра Solaris, но гибко настраиваемый, многопоточный Web сервер (демон) с внешним Web API
- код, привязанный к Си-шному API специализированной карты в слоте PCI
- Unix — вызовы IPC к программе PGP
- код, привязанный к дюжине специализированных Unix библиотек
И вот этот код и программно-аппаратное решение нужно было «виртуализировать» и заставить работать в Linux.
Задачу «в лоб» не решить, поэтому мы решили разбить задачу на части.
Отдельно хотелось сказать, что код демона оказался endian — нейтральный, что несколько упростило задачу.
В процессе поиска оптимального пути портирования этого кода мы исследовали техническое руководство IBM по портированию Solaris — приложения в Linux.
Первое, что хотелось выяснить, это насколько трудоемко окажется портировать вызовы ядра Solaris в относительно POSIX — совместимый Linux? Solaris, являясь POSIX сертифицированной ОС, имеет в своем ядре весьма специфические функции работы с потоками. Естественно, есть и те, что не имеют аналогов в ядре Linux:
- thr_suspend();
- thr_continue();
Функционал демона не только полностью полагался на эти, но также и на другие функции ядра Solaris: thr_keycreate(), thr_self(), thr_getspecific() и другие. В руководстве IBM прямо говорилось о том, что такой код при портировании в Linux придется переписать. А это значило, что тысячи строк многопоточного низкоуровневого кода «C с классами» нужно было проанализировать и переписать. Неужели нет другого пути? И нам показалось, что мы его нашло! В поиске рабочего «костыля» для портирования кода для Solaris «как есть» в Linux мы наткнулись на старый проект Compaq Solaris-compatible Thread Library (ScTL). Ура, у нас есть «прослойка», которая ляжет между портированным демоном и ядром Linux! Но не тут то было…
Сначала этот проект не хотел собираться, так как изначально почившая в обозе компания Compaq задумывала проект для Tru64 UNIX, потом портировала проект в Linux Intel x86 и другие платформы. Методом проб и ошибок после исправлений исходников ScTL нам удалось собрать требуемые нам библиотеки для нового ядра Linux на AMD64. Демон на Linux увидел «родные» для него и специфичные для Solaris функции и даже делал вид, что может работать, но все этим и закончилось. В процессе работы с ScTL возникали исключения времени исполнения в самом коде ScTL и демон «падал». Разбираться в таком коде 13-ти летней «свежести» времени не было, мы стали искать альтернативу. Выбор оказался очевиден, хотелось максимальной совместимости с C++11 и STL, поэтому решили остановиться на std::thread и не связываться со стандартом POSIX для потоков напрямую. Поскольку демон был web-сервером, нам крайне желательно было перейти с низкоуровневых сокетов на Boost::Asio. Сравнивая решения мы решили использовать относительно простой, но уже пригодный к использованию в сторонних проектах (лицензия MIT) проект на GitHub. В прикладных классах для обеспечения асинхронности из C++11 нам пригодились std::async и, конечно, лямбды. Итак, web-сервер мы заменили и он проходил отдельные тесты.
Следующая проблема — решить как «виртуализировать» специализированную карту расширения с PCI интерфейсом? Схожее по функциональности оборудование имелось на рынке, но это также аппаратное решение, хотя и с интерфейсом USB. Так как используемый заказчиком гипервизор позволял подключать USB оборудование в виртуальную систему, мы пришли к решению, в котором аппаратное решение с USB интерфейсом подключалось в виртуальную среду и становилось доступно в Linux нашему приложению. Все это потребовало значительной переработки связанной с PCI — картой кода, написания нового кода для работы с USB оборудованием и последующего тестирования.
Третья проблема была — PGP. Ее свободный аналог GnuPG не хотел работать в Linux по требуемому сценарию как в Solaris и нам пришлось переписать IPC на вызовы библиотеки gpgme, в результате повысилась надежность, демон прекрасно заработал с родными «C-шными» вызовами и стал корректно обрабатывать ошибки в нештатных ситуациях.
Оставалась четвертая проблема — зависимость от Unix библиотек. Но после решения предыдущих задач эти библиотеки не казались такой уж большой проблемы. Мы построили таблицу соответствия пакетов Linux (аналоги) пакетам из Solaris, затем выяснили, какие пакеты содержат в себе нужные нам библиотеки и для каких целей и как их хочет использовать наш демон. В итоге нашлись все требуемые свободные аналоги, сборка и тесты показали, что Unix-подобие ОС Linux позволяет упростить портирование кодовой базы.
В заключение хочется рассказать о двух моментах: используемая нами система сборки и целевые дистрибутивы Linux. В оригинале с кодом для Solaris нам достался Makefile. Он был неплохим решением 20 лет назад, но нам хотелось гибкости при сборке и CMake дал нам то, что мы искали: настраивать работу с Boost, линковать с разными версиями библиотек, учитывать изменения в ABI у g++. Сейчас CMake позволяет нам удобным образом генерировать файлы для Debug и Release сборок. С целевыми дистрибутивами ситуация обстояла так, что Заказчик хотел использовать Red Hat Enterprise Linux, у нас же на предприятии использовался Ubuntu. Дело закончилось статической компиляцией Release сборки с минимальными зависимостями (привет любителям .Net и Java), хотя размер исполняемого файла несколько «подрос».
В итоге мы портировали Solaris демон в Linux, но при этом мы выбросили практически весь системный код, «вросший корнями» в Solaris UNIX, написали новый код для «виртуализации» PCI карты в подобное по функционалу USB устройство и сделали отдельные места в коде более надежными. Что немаловажно, наш новый демон для Linux читает файлы конфигурации, скопированные из Solaris и корректно настраивает свою работу по ним, сохраняя 100% совместимость со спецификацией API как Web сервис.
Благодаря стандарту C++11 (а на подходе C++17), Boost, CMake и современным гипервизорам техническое задание, казавшееся поначалу невыполнимым, оказалось вполне себе исполнимым и даже увлекательным.
Комментарии (33)
Prometheus
30.03.2017 23:15Ничё не понимаю :)
А просто нельзя было на SPARC-сервера поставить линукс?
Не поддерживается осью или что?
halpro
31.03.2017 00:24Все наоборот. «Железу» 10 лет, включая специализированное оборудование. Варианты: новое «железо» SPARC и Solaris Unix — это если без перекомпиляции проекта. Но гораздо сложнее привезти новое специализированное оборудование для таких SPARC-ов. Оказалось выгоднее переписать и виртуаизировать.
apro
30.03.2017 23:18и нам пришлось переписать IPC на вызовы библиотеки gpgme, в результате повысилась надежность, демон прекрасно заработал с родными «C-шными» вызовами и стал корректно обрабатывать ошибки в нештатных ситуациях.
И ваш код автоматически перелецензировался под GPL-2, т.к. у gpgme насколько я помню
именно эта лицензия. Где можно скачать исходники вашей программы? :)
alex4321
30.03.2017 23:47+1Так GPL вроде требует раскрытия для пользователя, а не неопределенного круга лиц, не?
з.ы. проверять я это, конечно, не буду. Во всяком случае в ближайшее время.
zxweed
31.03.2017 00:02Вообще-то, SPARC-серверы прекрасно продолжают производиться ораклом и архитектура успешно развивается. И с совместимостью с софтом двадцатилетней давности всё в полном порядке, в отличие от. И уж точно для любого вменяемого заказчика не выглядит привлекательной идея полностью переписать потроха работающей легаси-системы, которая окупилась уже сто раз и просто продолжает приносить прибыль с нулевыми затратами.
halpro
31.03.2017 00:13+2Заказчик захотел перейти на open source. Его право. Наверное подсчитали еще и затраты.
zxweed
31.03.2017 00:18Solaris как и бы и так давно open source, и для SPARC и для x86
halpro
31.03.2017 00:28+2Там история запутанная: открыли исходники в Sun, закрыли в Oracle, последняя открытая версия вышла больше 8 лет назад, в 2009 году. Сравните с выпусками хотя бы RHEL, тем более Ubuntu.
caban
31.03.2017 07:59Мне кажется Red Hat, всё таки не совсем open source.
sHaggY_caT
31.03.2017 15:26Мне кажется Red Hat, всё таки не совсем open source.
Проверяли? Там из не-свободного пакет только с логотипами.
halpro
31.03.2017 00:36Затраты на эксплуатацию заказчики считать умеют. Со стороны другим многого не видно.
Насчет «полностью переписать» — ответ неверный, около 25 — 30%.
xtotec
31.03.2017 01:00+1Спасибо, очень интересно.
Хотя, признаться, перенос с Ubuntu на RHEL, путём статической компиляции несколько огорчил… После преодоления стольких препятствий…sHaggY_caT
31.03.2017 04:40Угу, странно и не понятно почему так. Неужели поставить Centos в виртуалку или докер контейнер, и разрабатывать там — это очень сложно?
halpro
31.03.2017 23:17На новой Ubuntu на шустром i7 а 8 потоков нам удобно (пере-)собирать, на виртуалках только тестируем, там и количество ядер может быть меньше и отлаживать не нужно.
halpro
31.03.2017 01:01Ну мы далеко не все линковали статически, только Boost. Остальное — «из коробки», пакетами :-)
xtotec
02.04.2017 01:25Я думал gpgme — там различия в API сильно гуляют от 12.1 до 12.3 — я пытался как-то mod_gnutls загнуть хотя-бы под EL6, но утонул в зависимостях.
А если только boost, который даже не core, можно было собрать тот, что вам нужен в /usr/local и линковать динамически с ним…halpro
03.04.2017 14:011. https://github.com/rjhansen/gpgme-example/blob/master/src/gpgme-example.cc
… и подобные исходники. Насчет зависимостей — не понял, GnuPG 2 по умолчанию в RHEL7, для разработки одного хэдера хватит (ниже о Debian):
$sudo apt-get install gnupg2
$sudo apt-get install libgpgme11-dev
2. Boost у нас потребовал этого (CMake):
#boost libraries:
find_package(Threads REQUIRED)
find_package(Boost 1.58.0 COMPONENTS regex system thread coroutine context filesystem date_time REQUIRED)
set(Boost_USE_MULTITHREADED ON)
Успехов!
skeletor
31.03.2017 23:26«седеющей» операционной системе Solaris,
она не «седеющая», а неплохо развиваемая в последнее время точно: каждый месяц регулярно выходят сотни багфиксов на Oracle Solaris. Правда они доступны только в платной подписке, но факт, что она развивается — это да.
halpro
31.03.2017 23:32Я не несу отсебятину, вот наглядный график популярности ОС для суперкомпьютеров:
https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#/media/File:Operating_systems_used_on_top_500_supercomputers.svg
Насчет «седения» — не нужно обижаться, возраст Solaris большой, популярность его падает, Linux быстро растет, факты: https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Market_share_by_categoryskeletor
01.04.2017 18:13Solaris никогда не ориентировалась на super-компьютеры,end-юзеров — она достаточно популярна среди enterprise-решений, особенно при использовании не x86 архитектуры. Да, среди СНГ она не так популярна, чем в Европе или США.
Ну и спор был именно о том, что она не седеющая, как вам кажется. В моём понимании, седеющая, эта та, которая мало развивается, мало используется и с каждым годом эти показатели падают. Но если она не популярна среди end-юзеров, то это не значит, что она не популярна в своё сегменте :) Только когда используешь её годами, понимаешь кучу преимуществ её перед linux, windows, freebsd. Solaris, если и можно сравнивать с Linux, то только с RedHat Enterprise (обе используются в корпоративном сегменте :). Так вот, много ли используют RHEL? Может она тоже седеющая?
ПС. Да и ссылки на wikipedia в последнее время вообще не аргумент. :)halpro
03.04.2017 14:14Можно спорить о деталях до бесконечности, некоторые это любят больше работы :-) И никакие доводы не подействуют. Моя последняя попытка ниже.
Лично мне (как автору статьи) любой Unix/Linux приятнее «Виндоузов». С Solaris именно пока приходится работать, а возраст и современный market share и подсказали нужное слово («седеющая») в отношении Solaris.
И Вы совершенно правы, «седеющая, эта та, которая мало развивается, мало используется и с каждым годом эти показатели падают». Википедия не аргумент? Ок. Опросите сами знакомых ребят с Wall street, на какие ОСи они переводят свои low latency приложения? Поищите вакансии с нужными словами, сравните с другими ОС. Задайте вопрос знакомым в Microsoft и Oracle. Ну и опубликуйте свои изыскания в сводной статистике в отдельной статье :-) Очень интересно будет почитать.skeletor
03.04.2017 15:06-1Если вы вдруг не знаете, почему wikipedia не аргумент, то я вам расскажу: вся фишка в том, что там любой может поправить статью, её промодерируют обычные юзера, для которых Solaris — не больше чем просто слово. Раньше, лет этак 10 назад wiki была достаточно весомым аргументом, но сейчас уже нет. Это раз
Второе, причём тут wall street? Solaris уж точно не претендует на роль low latency ОС (она используется там, где важна в первую очередь именно стабильность; скорость тоже важна, но уже на втором плане). И да, многие НОРМАЛЬНЫЕ банки, НОРМАЛЬНЫЕ операторы связи используют именно Solaris, хотя бы потому, что она прошла разные этапы/типы сертификации(в том числе и по безопасности, например, PCI DSS), есть саппорт.
И третье: открыто вам никто на улице кричать не будет, что я использую Solaris, а просто берут и используют. Точно так же можно сказать, что Oracle DB тоже седеющая, её практически не предоставляет ни один хостер для сайтов-визиток. Нельзя сравнивать круглое с мелким.
Вам указали на то, что она не «седеющая», причём с аргументами, так возьмите и просто исправьте в статье этот момент, нежели доказывать обратное и переводить тему в другое русло.
Shtucer
"Началась эта история с того, что наш уважаемый заказчик решил уменьшить риски эксплуатации оборудования 10-ти летнего возраста, сэкономить на лицензиях и перейти с Unix на Linux, а заодно и виртуализировать это программно-аппаратное решение. Заказано — сделано."
Отдельно благодарен за "Compaq в обозе".
halpro
Лично я был в шоке когда их HP купил. Compaq был тогда корпоративным стандартом.