Как мы портировали программно-аппаратное решение из SPARC Solaris в AMD64 Linux и виртуализировали все это

Эта статья для тех, кто все еще сильно любит древние Unix, но уже понимает, что срочно нужно мигрировать на Linux...
image

Началась эта история с того, что наш уважаемый заказчик решил уменьшить риски эксплуатации оборудования 10-ти летнего возраста, сэкономить на лицензиях и перейти с Unix на Linux, а заодно и виртуализировать это программно-аппаратное решение. Не то, чтобы заказчик не любил Solaris и Unix, просто сама возможность виртуализировать серверное приложение, жестко привязанное к специфической на сегодняшний день архитектуре SPARC и «седеющей» операционной системе Solaris, выглядела для заказчика очень привлекательной. Отдельным пунктом стоял вопрос замены специализированной карты с PCI интерфейсом на доступное «виртуализированное» решение. Мы решили взяться за такую интересную задачу.

До того, как мы увидели исходники мы плохо представляли себе, с чем имеем дело. Позже, познакомившись с задачей поближе, мы увидели, что UNIX демон представляет собой:

  1. «привязанный» к системным вызовам ядра Solaris, но гибко настраиваемый, многопоточный Web сервер (демон) с внешним Web API
  2. код, привязанный к Си-шному API специализированной карты в слоте PCI
  3. Unix — вызовы IPC к программе PGP
  4. код, привязанный к дюжине специализированных Unix библиотек

И вот этот код и программно-аппаратное решение нужно было «виртуализировать» и заставить работать в Linux.

image

Отступление от темы
Сейчас уже понимаю, что портирование этого проекта было крайне рискованное занятие…

Задачу «в лоб» не решить, поэтому мы решили разбить задачу на части.

Отдельно хотелось сказать, что код демона оказался 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-сервер мы заменили и он проходил отдельные тесты.

image

Следующая проблема — решить как «виртуализировать» специализированную карту расширения с PCI интерфейсом? Схожее по функциональности оборудование имелось на рынке, но это также аппаратное решение, хотя и с интерфейсом USB. Так как используемый заказчиком гипервизор позволял подключать USB оборудование в виртуальную систему, мы пришли к решению, в котором аппаратное решение с USB интерфейсом подключалось в виртуальную среду и становилось доступно в Linux нашему приложению. Все это потребовало значительной переработки связанной с PCI — картой кода, написания нового кода для работы с USB оборудованием и последующего тестирования.

image

Третья проблема была — 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 сервис.

image

Благодаря стандарту C++11 (а на подходе C++17), Boost, CMake и современным гипервизорам техническое задание, казавшееся поначалу невыполнимым, оказалось вполне себе исполнимым и даже увлекательным.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 35

    0

    "Началась эта история с того, что наш уважаемый заказчик решил уменьшить риски эксплуатации оборудования 10-ти летнего возраста, сэкономить на лицензиях и перейти с Unix на Linux, а заодно и виртуализировать это программно-аппаратное решение. Заказано — сделано."


    Отдельно благодарен за "Compaq в обозе".

      0
      Лично я был в шоке когда их HP купил. Compaq был тогда корпоративным стандартом.
      0
      Ничё не понимаю :)

      А просто нельзя было на SPARC-сервера поставить линукс?
      Не поддерживается осью или что?
        0
        Все наоборот. «Железу» 10 лет, включая специализированное оборудование. Варианты: новое «железо» SPARC и Solaris Unix — это если без перекомпиляции проекта. Но гораздо сложнее привезти новое специализированное оборудование для таких SPARC-ов. Оказалось выгоднее переписать и виртуаизировать.
        0
        и нам пришлось переписать IPC на вызовы библиотеки gpgme, в результате повысилась надежность, демон прекрасно заработал с родными «C-шными» вызовами и стал корректно обрабатывать ошибки в нештатных ситуациях.

        И ваш код автоматически перелецензировался под GPL-2, т.к. у gpgme насколько я помню
        именно эта лицензия. Где можно скачать исходники вашей программы? :)

          +1
          Так GPL вроде требует раскрытия для пользователя, а не неопределенного круга лиц, не?

          з.ы. проверять я это, конечно, не буду. Во всяком случае в ближайшее время.
            +3
            Для начала можно почитать LGPL для gpgme.
            0
            Вообще-то, SPARC-серверы прекрасно продолжают производиться ораклом и архитектура успешно развивается. И с совместимостью с софтом двадцатилетней давности всё в полном порядке, в отличие от. И уж точно для любого вменяемого заказчика не выглядит привлекательной идея полностью переписать потроха работающей легаси-системы, которая окупилась уже сто раз и просто продолжает приносить прибыль с нулевыми затратами.
              +2
              Заказчик захотел перейти на open source. Его право. Наверное подсчитали еще и затраты.
                0
                Solaris как и бы и так давно open source, и для SPARC и для x86
                  +2
                  Там история запутанная: открыли исходники в Sun, закрыли в Oracle, последняя открытая версия вышла больше 8 лет назад, в 2009 году. Сравните с выпусками хотя бы RHEL, тем более Ubuntu.
                    0

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

                      0
                      Да, OpenIndiana для энтузиастов, а не промышленности.
                  0
                  Мне кажется Red Hat, всё таки не совсем open source.
                    0
                    Мне кажется Red Hat, всё таки не совсем open source.


                    Проверяли? Там из не-свободного пакет только с логотипами.
                  0
                  Затраты на эксплуатацию заказчики считать умеют. Со стороны другим многого не видно.
                  Насчет «полностью переписать» — ответ неверный, около 25 — 30%.
                  0
                  ничего себе костыль…
                    0
                    ScTL — мог бы стать «костылем». Но нет, пришлось переписать часть кода проекта и благодаря Boost процесс удалось ускорить.
                    +1
                    Спасибо, очень интересно.
                    Хотя, признаться, перенос с Ubuntu на RHEL, путём статической компиляции несколько огорчил… После преодоления стольких препятствий…
                      0
                      Угу, странно и не понятно почему так. Неужели поставить Centos в виртуалку или докер контейнер, и разрабатывать там — это очень сложно?
                        0
                        На новой Ubuntu на шустром i7 а 8 потоков нам удобно (пере-)собирать, на виртуалках только тестируем, там и количество ядер может быть меньше и отлаживать не нужно.
                      0
                      Ну мы далеко не все линковали статически, только Boost. Остальное — «из коробки», пакетами :-)
                        0
                        Я думал gpgme — там различия в API сильно гуляют от 12.1 до 12.3 — я пытался как-то mod_gnutls загнуть хотя-бы под EL6, но утонул в зависимостях.
                        А если только boost, который даже не core, можно было собрать тот, что вам нужен в /usr/local и линковать динамически с ним…
                          0
                          1. 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)

                          Успехов!
                        0
                        Сколько заняло времени?
                          0
                          Смотря как учитывать, ко всему серверу понадобилась отдельная новая утилита, документация… Но дольше всего проходили согласования с заказчиком :-)
                          0
                          И как вам std::async?
                            0
                            std::async нам нормально, так мы отделили длительные по времени операции (от минут до часа) от синхронных (миллисекунды).
                            0
                            «седеющей» операционной системе Solaris,
                            она не «седеющая», а неплохо развиваемая в последнее время точно: каждый месяц регулярно выходят сотни багфиксов на Oracle Solaris. Правда они доступны только в платной подписке, но факт, что она развивается — это да.
                              0
                              Я не несу отсебятину, вот наглядный график популярности ОС для суперкомпьютеров:
                              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_category
                                0
                                Solaris никогда не ориентировалась на super-компьютеры,end-юзеров — она достаточно популярна среди enterprise-решений, особенно при использовании не x86 архитектуры. Да, среди СНГ она не так популярна, чем в Европе или США.

                                Ну и спор был именно о том, что она не седеющая, как вам кажется. В моём понимании, седеющая, эта та, которая мало развивается, мало используется и с каждым годом эти показатели падают. Но если она не популярна среди end-юзеров, то это не значит, что она не популярна в своё сегменте :) Только когда используешь её годами, понимаешь кучу преимуществ её перед linux, windows, freebsd. Solaris, если и можно сравнивать с Linux, то только с RedHat Enterprise (обе используются в корпоративном сегменте :). Так вот, много ли используют RHEL? Может она тоже седеющая?

                                ПС. Да и ссылки на wikipedia в последнее время вообще не аргумент. :)
                                  0
                                  Можно спорить о деталях до бесконечности, некоторые это любят больше работы :-) И никакие доводы не подействуют. Моя последняя попытка ниже.
                                  Лично мне (как автору статьи) любой Unix/Linux приятнее «Виндоузов». С Solaris именно пока приходится работать, а возраст и современный market share и подсказали нужное слово («седеющая») в отношении Solaris.
                                  И Вы совершенно правы, «седеющая, эта та, которая мало развивается, мало используется и с каждым годом эти показатели падают». Википедия не аргумент? Ок. Опросите сами знакомых ребят с Wall street, на какие ОСи они переводят свои low latency приложения? Поищите вакансии с нужными словами, сравните с другими ОС. Задайте вопрос знакомым в Microsoft и Oracle. Ну и опубликуйте свои изыскания в сводной статистике в отдельной статье :-) Очень интересно будет почитать.
                                    –1
                                    Если вы вдруг не знаете, почему wikipedia не аргумент, то я вам расскажу: вся фишка в том, что там любой может поправить статью, её промодерируют обычные юзера, для которых Solaris — не больше чем просто слово. Раньше, лет этак 10 назад wiki была достаточно весомым аргументом, но сейчас уже нет. Это раз
                                    Второе, причём тут wall street? Solaris уж точно не претендует на роль low latency ОС (она используется там, где важна в первую очередь именно стабильность; скорость тоже важна, но уже на втором плане). И да, многие НОРМАЛЬНЫЕ банки, НОРМАЛЬНЫЕ операторы связи используют именно Solaris, хотя бы потому, что она прошла разные этапы/типы сертификации(в том числе и по безопасности, например, PCI DSS), есть саппорт.

                                    И третье: открыто вам никто на улице кричать не будет, что я использую Solaris, а просто берут и используют. Точно так же можно сказать, что Oracle DB тоже седеющая, её практически не предоставляет ни один хостер для сайтов-визиток. Нельзя сравнивать круглое с мелким.

                                    Вам указали на то, что она не «седеющая», причём с аргументами, так возьмите и просто исправьте в статье этот момент, нежели доказывать обратное и переводить тему в другое русло.
                                +1
                                Ну вот и конец истории с Solaris Unix в Oracle: http://www.opennet.ru/opennews/art.shtml?num=47128
                                  0
                                  Sic transit gloria mundi

                                Only users with full accounts can post comments. Log in, please.