Куда и как мигрировать с зарубежных Enterprise Linux систем

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

В июне 2024 году завершается поддержка одной из наиболее популярных серверных операционных систем на базе Linux — Red Hat Enterprise Linux 7 (и его производных, например CentOS 7). Вместе с тем, Red Hat еще в 2022 году официально прекратил техническую поддержку клиентов в нашей стране. Российскому бизнесу необходима альтернатива, способная заменить зарубежные RHEL-совместимые операционные системы с сохранением производительности и поддержки действующего программного обеспечения.

Операционная система «МСВСфера» 9 – одна из немногих отечественных разработок, способных уже сегодня закрыть потребности бизнеса в части серверных ОС. «МСВСфера» более 10 лет применяется в крупных коммерческих и государственных организациях, обеспечивая стабильную и безопасную работу их ИТ-инфраструктуры.

Новый виток развития для ОС «МСВСфера» начался в июне 2023 года, когда в экосистеме «Инферит» появилось отдельное направление «Инферит ОС». Инвестиции и присоединение к команде разработчиков с опытом участия в создании и развитии таких проектов, как AlmaLinux OS, CloudLinux OS, ASPLinux, RFRemix (Russian Fedora) и Black Cat Linux, дали операционной системе «МСВСфера» мощный импульс к развитию. Результатом работы стал выпуск современной, 9-й версии дистрибутива.

Перед командой «Инферит ОС» стояла амбициозная задача — предоставить пользователям альтернативу зарубежным операционным системам уровня Enterprise Linux, совместимую с существующими корпоративными сервисами и приложениями, и обеспечить инструмент для миграции на нее.

Для крупных серверных инфраструктур переход на новую версию операционной системы – процесс непростой, сопряженный с рисками и вынужденными простоями. О том, как инструмент «Мигратор» решает эти проблемы посредством автоматизации, мы поговорили с руководителем проекта Александром Швецовым.

Насколько остро стоит проблема перехода с иностранных систем, у которых заканчивается жизненный цикл, на отечественные системы? С какими основными сложностями сталкиваются компании при таком переходе?

Тема перехода действительно актуальна. Рассмотрим CentOS – на этой платформе работают тысячи систем по всей стране. И вот сейчас, когда закончится этап поддержки CentOS 7, все эти системы окажутся в подвешенном состоянии. Обновлений безопасности больше не будет, найденные уязвимости – не исправят, а программу расширенного жизненного цикла купить невозможно. Значит, риски для бизнеса резко возрастают. И CentOS тут не уникален, примерно так же ситуация обстоит с другими дистрибутивами, которые базируются на Red Hat.

Если говорить о коммерческих дистрибутивах LINUX, то в условиях, когда невозможно приобрести техническую поддержку или поддержку расширенного жизненного цикла, и при этом необходимо переходить с систем, у которых заканчивается жизненный цикл, многие компании начинают рассматривать не просто переход на следующую более новую версию ОС, но переход на более новую версию российской ОС. Это дает бизнесу возможность приобретать техническую поддержку и налаживать прямой диалог с разработчиком, работая на системе, совместимой с отечественным оборудованием.

Но здесь встает вопрос: как перевести свой парк на новую версию либо вообще другой дистрибутив ОС. Тут можно пойти несколькими путями, в частности – переустанавливать систему на каждом сервере и настраивать его заново с простоем во время работ, или же воспользоваться средствами автоматизации перехода. Не все ОС поддерживают автоматизированные средства миграции, из российских мы – одни из немногих. При этом мы, возможно, единственные на рынке РФ, у кого есть инструмент перехода на следующую мажорную версию не только внутри своей ОС, но и с других RHEL – совместимых (RedHat, CentOS, AlmaLinux, OracleLinux, ROSA)

Расскажите подробнее, как работает «Мигратор»?

Для начала разберемся в том, что «Мигратор» из себя представляет. Можно сказать, что он состоит из двух частей: утилиты миграции и скрипта с инструкциями. Утилита является универсальной для всех, а скрипт может потребовать доработки, это зависит от пакетной базы сервера.

Если предельно упростить принцип работы «Мигратора», то можно сказать, что утилита, согласно программе, заложенной в скрипте миграции, скачивает из репозиториев пакеты следующей версии ОС (или другого дистрибутива) и заменяет ими пакеты старой версии. По такому же принципу обновляются и приложения, не входящие в дистрибутив ОС «МСВСфера». Если у клиента установлены какие-то специфические пакеты, ему необходимо отредактировать скрипт миграции, указав там эти пакеты и репозиторий, в котором они содержатся.

Можно все перенести одним нажатием кнопки?

И да, и нет. Если у вас огромное количество серверов с одинаковой пакетной базой и вы качественно протестировали скрипт, то разница в миграции одного сервера или многих не велика. Программа работает, обновляя пакеты, затем перезагружает систему и — вуаля! — у вас новая версия ОС. Разумеется, каждый сервер обновляется отдельно, и на это ему требуется время, но при этом он в процессе обновления может даже выполнять полезную деятельность, уходя в даунтайм лишь для перезагрузки. Зато системный администратор тратит время не пропорционально количеству серверов благодаря автоматизации процесса. То есть, утрированно, один раз нажмет на кнопку для запуска миграции, а затем проверит работоспособность серверов – уже после ее завершения.

Если же у вас обширный зоопарк разных конфигураций, то потребуется либо доработка скрипта под каждый случай (и, соответственно, тестирование его на множестве серверов), либо дополнительные средства управления средами, когда вы мигрируете какую-то базовую конфигурацию, а потом уже «допиливаете» серверы, устанавливая на них дополнительные приложения вручную или сторонними средствами автоматизации. Здесь уже целесообразность использования «Мигратора» зависит от того, есть ли возможность сформировать типовые группы и их размер. На больших объемах, как правило, можно получить существенную экономию, на малых — не всегда.

Как измерить полезный эффект от «Мигратора»?

Хороший вопрос. Мерить можно по-разному, я бы выделил три единицы измерения: время, деньги и ошибки.

Начнем с ошибок: если типовая операция (а миграция парка схожих серверов — это типовая операция) проводится автоматизированно, а не вручную, риск ошибок существенно снижается. Разумеется, при условии, что до этого операция (в нашем случае — скрипт миграции) была хорошо протестирована. Иначе ошибка будет, наоборот, масштабирована.

Время можно разделить на машинное и человеческое. Машинное — это время работы сервера, человеческое — системного администратора. Как я говорил выше, экономия человеческого времени колоссальная за счет того, что нужно запустить операцию и проконтролировать конечный результат, а не повторять большой набор действий многократно. Основные затраты здесь приходятся на разработку и тестирование скрипта. С точки зрения сервера также можно сэкономить время. Как минимум на даунтайме: сервер продолжает выполнять полезную работу в процессе миграции, отключаясь лишь на время финальной перезагрузки. Может также быть экономия и на установке специфических пакетов, но это индивидуально.

Представляя себе временные затраты, можно конвертировать их в деньги: умножаете время, затрачиваемое системным администратором, на его зарплату, время простоя сервера — на стоимость его аренды и потерь из-за невыполнения бизнес-функций, умножаете на количество — и ужасаетесь, если ваш парк достаточно большой. Далее попробуйте предположить что хотя бы 5% ручных операций были сделаны с ошибкой, и вы обнаружили ее только когда сервер обвалится в самый критический момент. В целом, это крайне упрощенная формула для примерного расчета.

Нужно учитывать еще и специфику компании: критичность сбоев, общую автоматизированность инфраструктуры, количество и уровень экспертизы системных администраторов. «Мигратор», при всех своих преимуществах — не серебряная пуля, каждая компания должна сама оценивать экономический эффект от его применения.

Кто занимается написанием скрипта миграции — команда заказчика, специалисты «Инферит ОС», или нужно обращаться в компанию заказной разработки? Сколько времени в среднем может занять доработка скрипта миграции под нужды конкретного заказчика? И, конечно, сколько это может стоить, если реально оценить в деньгах? От чего это зависит?

Начнем с простого: мы поставляем «Мигратор» уже в комплекте со скриптом, который в общем случае позволяет мигрировать с RHEL-совместимой системы на ОС «МСВСфера». Для ряда пользователей это вообще не потребует каких-то доработок. Те же, кто нуждаются в доработке скрипта, могут сделать это своими силами (скрипт представляет собой json файл), либо обратиться к нашим партнерам, которые сделают им проект под ключ. Стоимость и сроки доработки, как всегда, будут зависеть от многих факторов, таких как объем доработок, сложность и прочее. Не берусь оценивать сферический проект в вакууме.

Для тех, кто рассматривает миграцию, я бы порекомендовал самый простой вариант: скачать утилиту и скрипт, поднять на тестовом сервере типовой образ своей системы и сделать миграцию. Вы сразу увидите, где возникли ошибки, и сможете приблизительно оценить масштабы. Таким образом, входной порог в тестирование миграции на ОС «МСВСфера» крайне низок.

Скачать утилиту “Мигратор” можно по ссылке, а ознакомиться с документацией здесь.