Сейчас для многих организаций стоит вопрос перевода серверов с корпоративными системами (СЭД, ERP, CRM и так далее) на российские ОС и СУБД. Казалось бы, в чем может быть проблема? Существует много российских дистрибутивов Linux, а также продуктов на базе Postgres. Среди российского ПО есть выбор кроссплатформенных продуктов, которые не зависят от иностранных технологий. Однако при реализации проекта может возникнуть много сложностей.
В этой статье мы делимся историей перевода серверов крупного заказчика с Windows на Linux. Это красивый флэшбэк, из которого можно узнать про этапы подготовки к миграции, подводные камни и секреты успеха (шутка, ведь секретами никто не делится).
Рассказ будет в нескольких частях. Сначала вы узнаете о выборе ОС и СУБД с учетом реалий заказчика, потом — непосредственно о переходе на новую ОС и миграции СУБД.
Коротко о проекте
Для начала — немного контекста о системе, которую переводили, и о заказчике. СЭД ТЕЗИС — кроссплатформенное веб-приложение от компании «Хоулмонт», написанное на языке Java, предназначенное для автоматизации документооборота, управления поручениями и ведения канцелярии. За счет встроенных инструментов разработки (в том числе Low Code) можно расширять функциональность системы практически без ограничений. Как раз такой проект-расширение у нашего заказчика – группы компаний ITMS, о котором сегодня пойдет речь. После локализации компании встал вопрос перехода на ПО, доступное в России.
Мы внедряли СЭД ТЕЗИС еще в 2020 году – до локализации. Тогда в компании использовали Windows Server 2016 и MS SQL Server 2016 (SP2). На момент перехода в СЭД работало около 2 000 пользователей, объем базы данных насчитывал около 700 Гб.
Если интересно узнать про кейс подробнее.
Зачем переходить на Linux и Postgres
Госорганам и близким к ним заказчикам импортозамещение ОС, СУБД, офисного пакета, систем виртуализации и т.д. нужно выполнить к 2025 году. ITMS не относится к госсектору, поэтому требования законодательства не вынуждали переходить на российское ПО. Тем не менее в компании еще в 2021 году самостоятельно решили перевести серверное окружение на Linux. Основные аргументы заключались в том, что системы на Linux проще масштабировать и модифицировать, к тому же лучшие DevOps-практики — контейнеры и конвейеры — целесообразно использовать именно в Linux.
В 2022 году, как мы уже упоминали, произошла локализация бизнеса ITMS. Как следствие, был потерян доступ к корпоративным лицензиям MS Windows Server, MS SQL, RedHat и SUSE. Легально купить или продлить иностранное ПО стало невозможно. Поэтому заказчик начал обсуждать с нами перевод серверов СЭД ТЕЗИС на российский дистрибутив Linux, а также запланировал миграцию СУБД и замену критически значимого ПО, участвующего в бизнес-процессах.
Как преодолеть сомнения при замене ОС и СУБД
При замене ОС и СУБД у коммерческих компаний возникает большое количество вопросов и сомнений:
1. Критичные компоненты бизнеса завязаны на текущую СУБД.
2. Прикладной софт заточен под определенные СУБД и ОС.
3. Под прикладную часть подобрано оборудование и выстроена инфраструктура.
4. Для обслуживания инфраструктуры подобран штат квалифицированных работников.
5. Если часть инфраструктуры и процессов находится на аутсорсе, то налажены связи с обслуживающей организацией.
6. Расписаны все регламенты по ИТ-безопасности.
Словом, если все работает, то зачем что-то менять. Однако на самом деле эти вопросы решаемы, а в результате заказчик получит дополнительные преимущества. Разберем все вопросы по порядку.
1. Критичные компоненты бизнеса завязаны на текущую СУБД.
Замена СУБД выполняется в последний момент, но продумать план миграции и все внешние связи с базой данных следует в самом начале. Главное при проектировании — не отталкиваться от ОС, а сначала выбирать СУБД. Непосредственно миграция выполняется с сохранением модели данных, минимизацией времени простоя системы, подготовкой откатов на случай сбоя и мониторингом производительности новой СУБД.
2. Прикладной софт заточен под определенные СУБД и ОС.
СЭД ТЕЗИС поддерживает различные ОС и СУБД, но для отдельных приложений практически невозможно найти готовый аналог, поэтому придется перестраивать бизнес-процессы или переписывать все с нуля. Затраты окупятся за счет получения более гибкой инфраструктуры.
3. Под прикладную часть подобрано оборудование и выстроена инфраструктура.
В отдельных случаях замена ОС и СУБД может потребовать изменений в инфраструктуре. Но у нас все изменения происходили ради апгрейда, при желании заказчик мог бы остаться на прежнем оборудовании. В случае облачных решений иногда удается совместить два переезда, чтобы получить более выгодные условия обслуживания.
4. Для обслуживания инфраструктуры подобран штат квалифицированных работников.
Есть риск, что некоторые специалисты из-за отказа от Windows окажутся невостребованными. Но про спецов SQL так не скажешь. Поддерживать Postgres они вполне смогут, плюс их заинтересуют новые задачи. Например, в нашем случае был внедрен мониторинг с Zabbix и Grafana, а также открыта возможность масштабировать инфраструктуру при росте нагрузки.
5. Если часть инфраструктуры и процессов находится на аутсорсе, то налажены все связи с обслуживающей организацией.
В условиях конкуренции на рынке облачных ИТ-услуг достаточно иметь хорошо документированные процессы и системы, чтобы при необходимости можно было передать инфраструктуру на обслуживание в новую организацию. Это и произошло в нашем случае, причем документацию мы составили в процессе работы, используя удобное сочетание форматов markdown и drawio.
6. Расписаны все регламенты по ИТ-безопасности.
Если у безопасников нет цели задушить бизнес, то в любой серьезной задаче будет найдено устраивающее всех решение.
В целом наш подход — сегодня делать работу лучше, чем вчера. Поэтому на выражение «работает — не трогай» мы смотрим сквозь свою призму. Мы не будем трогать до момента регламентных работ, чтобы в нужное время подкрутить и оно заработало еще лучше. Если во внедрении новых технологий видны явные перспективы, если есть понимание, что своими руками можно творить и достигать новых высот, то нужно решиться на изменения.
Выбор ОС и СУБД: как всегда и как надо
Существует два подхода к взаимодействию заказчика и вендора. В одном случае заказчик ждет, что вендор сделает все сам, а потом удивляется, потому что ожидал другого результата. Второй вариант — работать сообща. При этом очень важно обратиться к вендору на старте проекта, а не когда ОС уже закуплена и развернута на новых виртуальных машинах, а потом оказывается, что нет подходящей версии PostgreSQL.
Еще одно распространенное ожидание — что вендор должен знать все варианты совместимости ПО со всеми известными СУБД, ОС, антивирусами и т.д. Но на практике нет такой возможности, так как версии библиотек и ядер очень быстро меняются. То, что было проверено в прошлом месяце, сегодня может измениться. Отсюда следует, что имеет смысл проводить тестирование совместимости на конкретных сочетаниях СУБД, ОС и оборудовании.
Как в нашем случае происходил выбор ОС и СУБД:
1. Заказчик собрал команду проекта.
В команду вошло 19 человек, в том числе со стороны заказчика — руководитель проекта, аналитик, инфраструктурный менеджер и инфраструктурный инженер, с нашей стороны — руководитель проекта, DevOps, техлид, инженеры поддержки. Заказчик назначил куратора проекта и ответственных за вопросы сети, инфраструктуры хранения данных, балансировки нагрузки и катастрофоустойчивости, резервного копирования и восстановления, инфраструктуры СУБД, платформы виртуализации, виртуальных и физических серверов, мониторинга производительности и доступности, разработки ПО, ИТ-безопасности, а также проконсультировался у юристов.
2. Заказчик определился с количеством контуров.
В нашем случае был один продуктив и два тестовых контура.
3. Куратор запросил рекомендацию по лучшей ОС для совместимости с текущей СЭД с учетом пожеланий по количеству и составу контуров.
Изначально ITMS рассчитывала на лицензионные ОС из внутреннего корпоративного стандарта: RHEL или SLES. Заказчику была важна понятная и доступная техническая поддержка, поэтому альтернативой рассматривалась Ubuntu Pro. Когда стало ясно, что указанные ОС становятся недоступными, сфокусировались на российских производителях. В первую очередь, заказчик определился с СУБД — для прода исходя из опыта использования в проектах с высокой нагрузкой была выбрана PostgreSQL 13.12, а для теста решили взять версию, входящую в дистрибутив ОС. Далее у нас запросили список ОС, с которыми мы рекомендуем работать. СЭД ТЕЗИС поддерживает широкий спектр серверных ОС (Windows Server, Ubuntu, Debian, OpenSUSE, RedHat, российские дистрибутивы на базе Linux). Из российских дистрибутивов на клиентских проектах есть опыт использования Астра Линукс, РедОС, Альт и Роса. Чаще всего встречается Астра, на втором месте — РедОС, поэтому мы порекомендовали выбирать из этих вариантов, и заказчик остановился на первом.
Сначала на проде развернули Astra Linux 1.7 SE, на тестовых серверах — Astra Linux 2.12 CE. Однако мы столкнулись с багом в ядре ОС на проде, причем на тестовом сервере он не воспроизводился. Поддержка Astra Linux вовремя отреагировала, провела анализ отличий между версиями и подсказала вариант решения проблемы на проде — обновить версию ядра. Мы провели апгрейд до 1.7.4, и вопрос решился.
4. Проведена проверка совместимости ОС и СУБД.
Планировалось на тестовом стенде использовать СУБД из пакетов ОС, а не платную версию. Мы проверили, какие версии Postgres доступны — на момент выбора в дистрибутиве Астры были версии 11 и 14, а ТЕЗИС поддерживала все версии до 13. Это могло стать проблемой, но пока шла работа по переводу ОС, команда Астры добавила в дистрибутив недостающие версии Postgres. В итоге на продуктив установили PostgresPro 13.12, на тест — PostgreSQL-astra 13.12.
Итог
Какие выводы по этапу выбора ОС и СУБД для серверов с корпоративной системой можно сделать:
Переход на Линукс дает много преимуществ. Линукс более стабилен, требует меньшего числа перезагрузок из-за обновлений, работа процессора и файловая система в нем более эффективная. Выбор российского дистрибутива позволяет дополнительно обеспечить технологическую независимость и исключить риск прерывания бизнес-процессов из-за потери доступа к лицензиям. Сейчас на рынке существует множество российских дистрибутивов Линукс, из которых можно выбирать оптимальный, а также СУБД российского производства.
Процесс замены ОС и СУБД непростой. Может возникнуть соблазн ничего не менять, но все вопросы решаемы, а результат того стоит.
Этап выбора ОС и СУБД очень важен. Самое главное — понимать, что это совместная задача заказчика и производителей всех используемых решений, от ОС и СУБД до корпоративной системы.
Спасибо за внимание! В следующей статье расскажем непосредственно про сам процесс переноса и миграции.
P.S. Также приглашаем поделиться в комментариях — а как вы или ваши заказчики выбирали ОС и СУБД для миграции корпоративных систем?
