Сейчас для многих организаций стоит вопрос перевода серверов с корпоративными системами (СЭД, 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. Также приглашаем поделиться в комментариях — а как вы или ваши заказчики выбирали ОС и СУБД для миграции корпоративных систем?
Комментарии (27)
Solopov
31.07.2024 12:38Только дошел до самого интересного: на тесте postgres, на проде postgrespro и ожидал историй про отличия и как потом перешли на единый стек.
А тут сразу итог в виде воды....
Rapekas
31.07.2024 12:38+1С точки зрения разработчика, интегратора и техподдержки разумно иметь одинаковый стек во всех контурах. Но не всегда это оправдано. Продукт пишется на ванильном постгресе и архитектура приложения в ITMS использует фичи PgPro, но не явно. То есть, на проде используется pg_repack для перестроения таблиц, а оптимизация плана запроса в про-версии дает выигрыш в производительности. Но эти фичи не так критичны, и таким образом остается обратная совместимость с другими версиями постгрес (ванильная и астра) в контурах разработки, тестирования и предпрода, которые менее требовательны к нагрузке.
Использование про-версии на проде защищает клиента от рисков, связанных с самой СУБД. То же самое касается ОС. К слову, из-за расхождения версий ядер ОС между контурами мы однажды столкнулись с проблемой, когда на тесте она не воспроизводилась, а на проде была. Ситуацию быстро решила команда Астры.
В таком подходе удается сохранить то, что важно для клиента. Для бизнеса важен баланс между совместимостью сред, оптимальными расходами, минимальными рисками возникновения инцидентов из-за разного окружения и возможностью быстро получать профессиональную помощь от первого лица.
9241304
31.07.2024 12:38Процесс замены ОС и СУБД непростой. Может возникнуть соблазн ничего не менять, но все вопросы решаемы, а результат того стоит.
Я только знаю, что это стоит денег. Если цель в том, что их нужно периодически пилить, то можно не заморачивался так глубоко.
Если имелся ввиду какой-то другой результат, то зачем же было сразу лезть в винду, когда был такой прекрасный линукс? Предыдущие разработчики были дураками? Так может они и в других частях системы так же накодили?
Rapekas
31.07.2024 12:38СЭД на Windows + MS SQL разворачивали исходя из устоявшихся технологий и компетенций на стороне заказчика. Когда мы приходим со своим решением, то сложно сходу изменить сложившиеся устои, и как правило приходится работать с тем, что есть.
9241304
31.07.2024 12:38Да каждый первый программист приходит с таким решением: взять всё и переписать. И ведь речь в данном случае идёт не о легаси, а просто о желании. Так и не понятно, почему все эти затраты "того стоят"? )
Rapekas
31.07.2024 12:38У нас нет цели доказать, что замена ОС и СУБД оправдана с точки зрения денег. Мы начали рассказывать историю, когда заказчик сам задался вопросом - а не станет ли лучше, если окружение сменится на линуксовое. Для конечного пользователя ничего не поменяется, а серверная часть станет другой. Большинство наших клиентов использует линукс с самого начала, и поэтому у нас было наблюдение, что с подобными решениями всегда проще. Система более предсказуемая и проще в обслуживании.
Взять тот же способ подключения. На нетерминальной винде только 2 RDP подключения, одно из которых как правило резервирует сторона заказчика. Сразу двоим сотрудникам невозможно подключиться. Один сеанс тратится на элементарные операции посмотреть лог, например. С учетом сложных схем подключения, скорость, стабильность соединения и возможности прямого чтения или управления в итоге вырождаются в недоразумение.
SSH позволяет все делать одним туннелем и использовать скилы сразу несколько человек. В такой схеме можно использовать средства автоматизации, например Ansible, и подключать системы мониторинга, недоступные на винде. Как дальнейший этап развития, это способ создания конвейеров для поставки сборок на сервер (Docker или традиционный деплоймент).
Сокращение Time to market может быть оправданием затрат на перенос платформы.
9241304
31.07.2024 12:38У нас нет цели доказать, что замена ОС и СУБД оправдана с точки зрения денег. Мы начали рассказывать историю, когда заказчик сам задался вопросом - а не станет ли лучше, если окружение сменится на линуксовое.
Просто пил чай и подумал, а не станет ли лучше? И фиг с ними деньгами. Это точно про бизнес?
Для конечного пользователя ничего не поменяется, а серверная часть станет другой
Это как дать юзеру либру вместо мс офиса и сказать, что ничего не поменяется. Поменяется. И риск, что поменяется в худшую сторону, есть. Потому мало кто решается на такое
И систему ещё не переписали, но вывод уже есть, потому что "ну вы ж знаете этот линукс" ))
Насчёт предсказуемости и простоты в обслуживании весьма спорно, тема отдельного холивара. Особенно учитывая выбор поставщика решения
PS. По RDP можно подключаться троим и более, как легально, так и нелегально. И оба способа стоят меньше, чем переписывание системы. Нелегальный так и вовсе бесплатен
Rapekas
31.07.2024 12:38Это как дать юзеру либру вместо мс офиса и сказать, что ничего не поменяется. Поменяется. И риск, что поменяется в худшую сторону, есть. Потому мало кто решается на такое
И систему ещё не переписали, но вывод уже есть, потому что "ну вы ж знаете этот линукс" ))
Поделитесь примерами из вашей практики. Из вашего сообщения видно, что вы прочитали статью невнимательно. Речь идет о кроссплатформенном серверном веб-приложении. Изначально это приложение способно работать практически в любых средах, где есть Java. Соответственно сравнение Java-приложения c либрой здесь неуместно. Статья написана не только для аудитории интересующихся айтишников, но и для тех, кто имеет отношение к руководству проектами, как со стороны разработки, так и со стороны бизнеса.
9241304
31.07.2024 12:38Статья написана не только для аудитории интересующихся айтишников, но и для тех, кто имеет отношение к руководству проектами, как со стороны разработки, так и со стороны бизнеса.
"не столько", вы хотели сказать )
теперь стало яснее. из чего всё-таки вывод, что изначальные разработчики были не очень умны (как я и предполагал сразу), либо исполняли прямой приказ руководства.
пример есть. но не вижу смысла обсуждать прямой приказ заказчика, в котором он потребовал линуксовые "устоявшиеся практики" на винде, а сделать всё нативно для винды не захотел, потому что не понравилось название языка программирования.
Year
31.07.2024 12:38Из статьи сложилось мнение, что заказчик выбирал не конкретный линукс и постгрес, а продукты с реально работающим саппортом, как бы сами продукты не назывались.
Более того, из текста понятно, что это не было прихотью, и на этапе миграции саппорт действительно понадобился.
А вот в выводах необходимость саппорта не отмечена
Rapekas
31.07.2024 12:38+1Спасибо, вы подсветили один из важнейших критериев выбора. Качественная поддержка продукта (ОС и СУБД в контуре прода) и серверного окружения для заказчика всегда являлась обязательным условием. Поэтому мы помогали найти ОС и СУБД российского производства с проверенной поддержкой.
В выводы мы не включили пункт о поддержке, чтобы не выделять кого-то из вендоров. Индустрия быстро развивается, и мы упомянули о том, что поначалу в дистрибутиве Астры не хватало некоторых версий постгреса. Всего через несколько месяцев ситуация выровнялась, видно что работа ведется.
vvmtutby
31.07.2024 12:38Не совсем понятно, почему Вы беспокоитесь о перезагрузках серверов или СУБД: обе СУБД способны работать в кластере. Соответственно, перезагружать узлы можно когда угодно.
Или cluster -а нет?
ildarz
Вот казалось бы, простое правило - если вы, к примеру, менеджер и пишете статью на хабр, пишите о том, в чем разбираетесь, не трогайте технические детали. Но нет, обязательно надо вставить какой-нибудь фейспалм типа
Rapekas
Добрый день. Мы имели ввиду следующее: если у кроссплатформенного приложения есть выбор, на какой платформе размещаться, то по нашему опыту лучше использовать линукс
ildarz
Это в среднем по больнице безусловно понятная позиция по самым разным причинам, но в контексте конкретно перевода корп. систем типа ЭДО с MS SQL на Postgres читать то, что я процитировал выше, несколько забавно, по крайней мере с моей колокольни. У вас вообще сколько было кейсов, когда вот эту замену в корп. софте делали именно по означенными причинам? Не тех, что "MS SQL дорого, Оракл еще дороже и вообще они все теперь недружественные, поэтому все-таки придется грызть кактус", а именно потому что работа процессора и файловой системы там эффективная, и вообще этот ваш MS SQL постоянно перезагружать надо? :)
Rapekas
В статье не сказано о необходимости перезагружать MS SQL. Требовать перезапуск и СУБД, и ОС могут ожидающие установки обновления. Об этом и сказано в выводах. Ни слова не было про дорого и недружественно. Заказчик сам пришел к выводу, что замена ОС даст преимущества.
С переходом на линукс решился вопрос с мониторингом веб-приложения СЭД, появилась прозрачность в вопросе производительности. Упростились интеграции продукта с внешними сервисами заказчика. Стало возможным заменить дополнительное ПО, которое раньше не представлялось возможным интегрировать без костылей. А уже в процессе перехода на линукс возникли известные обстоятельства, которые заставили отказаться от MS SQL.
Spyman
А что собственно с этими тезисами не так?
Linux умеет даже ядро подменять на лету, только иксы перезагрузить, если они нужны. Так что про перезагрузки вроде верно, винда даже в серверном варианте всё таки иногда требует перезагрузить себя.
То, что работа процессора более эффективна конечно спорный момент, но с другой стороны в винде с невырезанной телеметрией и прочим мусором можно считать что тоже верно.
Про файловые системы тоже спорно, но тот же ext4 вроде как быстрее в создании файлов и каталогов, а так-же лучше работает с фрагментацией. Т.е. с натяжкой можно считать что тоже верно. Тем более что мир linux куда проще в натягивании своих файловых систем которые конкретно в вашем сценарии будут производительнее. Zfs какой нибудь.
Wolfen113
Я не знаю как это работает но, когда стала переходить на линукс. Первое что заметила, это что диски под ним будто работают шустрее и практически не кряхтят. Даже когда я монтирую ntfs. На винде у этих дисков такой скрежет и тормоза, что кажется вот вот рассыпятся.
9241304
Обои! Обои же!!!! НЕСКУЧНЫЕ
Sleuthhound
Качество системы бессмысленно оценивать по критерию сколько дней/лет она проживет без перезагрузки, времена Novell NetWare когда серваки по 10 лет без рестарта работали закончились.
Качественная система должна переживать перезагрузки без проблем, хоть 2 раза в день ее ребути - она должна стоять и работать.
ildarz
Применительно к обсуждаемой предметной области с ними не так примерно всё, начиная с того, что это вообще не те параметры, на основании которых заказчиком делается выбор (см. мой коммент выше). А сравнения сферических винды и линукса в вакууме - холивар, который интересен только первые лет 20 работы в ИТ, и то не всем. :)