Перевод серверов СЭД на Linux и Postgres на практике

Привет, Хабр! Это вторая серия кейса по переводу на Linux и Postgres серверов системы электронного документооборота ТЕЗИС в компании ITMS (но можно читать ее как отдельную статью). Речь идет о крупном проекте — 2000 пользователей, БД на 700 Гб. Раньше ITMS было подразделением глобальной компании, после 2022 года произошла локализация бизнеса, из-за этого встал вопрос перехода на российское ПО. СЭД ТЕЗИС — кроссплатформенный продукт на Java, поэтому переписывать систему не понадобилось. Сложность заключалась в сжатых сроках, большом объеме данных и том факте, что параллельно с заменой ОС и СУБД развивалась СЭД и перестраивалось связанное с ней ПО. В прошлой серии мы подробно рассказали о выборе ОС и СУБД, определении зон ответственности и совместимости версий. Сегодня — о том, как происходила замена.

Подготовка к замене ОС и СУБД

Первое, что мы сделали перед сменой ОС и миграцией СУБД — вместе с заказчиком пришли к пониманию, что имеем и какие существуют риски.

• Проблемы могли создать некоторые библиотеки и свыше 20 интеграций с различными системами, которые могли работать в новой среде не так, как ожидалось. Было важно понимать, насколько глубоко у ITMS механизмы работы СЭД завязаны на продукты Microsoft, а также как под Linux будет работать стороннее ПО. При замене ОС, СУБД и библиотек мы совместно решили вопросы совместимости и вписались в существующие ограничения, в том числе со стороны ИБ.

• В отдельных случаях может потребоваться замена для аппаратных сетевых устройств (серверные платформы, балансировщики, сетевые экраны, маршрутизаторы и мобильные устройства). Также может встать вопрос о сохранении облачной инфраструктуры. В нашем случае эти вопросы решал провайдер.

• Перед стартом работ важно распределить ответственность по технической поддержке. На стороне облачного провайдера был необходимый минимум поддержки серверной ОС, мониторинг ресурсов, аудит безопасности. Команда ТЕЗИС отвечала за поддержку СЭД, деплоймент, масштабирование, помощь в мониторинге, тюнинг производительности, разбор инцидентов. Также заказчик рассчитывал на поддержку PostgresPro на контуре прода (команде PostgresPro теплый привет, было приятно встретить знакомые лица;)

• Потребовалось проработать вопрос обслуживания систем, чтобы процедура не сильно отличалась от существовавшей. Команды поддержки со стороны заказчика и со стороны ТЕЗИС остались прежними, наши сотрудники после графического интерфейса Windows полностью погрузились в шелл Linux.

• На случай сбоя в процессе миграции мы подготовили бэкап СУБД. В дальнейшем при нормальной работе планировалось использовать платформу резервного копирования облачного провайдера.

• Заказчик отметил сопутствующие вопросы, которые планировал решить заменой ОС: проблемы производительности Windows-серверов, обрывы соединений, ошибки приложения в браузере, зависания, уязвимость файлов перед шифровальщиками.

• При переходе на новую ОС и платформу виртуализации следовало учитывать планы по расширению бизнеса.

Тестирование совместимости и производительности

Работы требовалось провести на проде и на двух тестовых контурах. Начали с тестовых стендов. На одном поменяли ОС, на другом проводили миграцию СЭД. Работы проводили отдельно, чтобы не закопаться в проблемах. При этом оценивали совместимость платных и бесплатных версий ОС, библиотек и СУБД — об этом подробно было в прошлой серии.

Так как при внедрении новых ОС вводились новые журналируемые файловые системы, то потребовалось по-новому рассчитать необходимые объемы. На тестовом стенде опробовали сжатие и дедупликацию файлов в хранилище на файловой системе BTRFS. Экономия составила 11%, потерь производительности не выявили, но в продуктив данную файловую систему решили не внедрять. Надежность Ext4 и опыт работы с этой файловой системой имели большее значение, чем небольшой выигрыш в сжатии и сложность поддержки у BTRFS. Для Ext4 также провели тестирование производительности СУБД.

Планирование работ

План работ помог собрать команду, обозначить зоны ответственности и распределить задачи. При проектировании новой системы следует помнить, что любое изменение влияет на существующие процессы, порядок работы конкретных людей и стоимость работ.

1. Сперва мы зафиксировали цель и критерии ее достижения.

2. Уточнили границы задачи, разбили на подзадачи.

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

4. Продумали планы аварийного восстановления на случай неудачной установки и на случай форс-мажора при нормальном использовании обновленной системы в будущем.

5. Непрерывно проводили мониторинг производительности системы, до начала работ и после окончания наладки фиксировали ключевые метрики (например, время открытия страницы и карточки и время выполнения запроса в БД).

6. Актуализировали составленные в ходе работ на тестовом контуре чек-лист и инструкцию для данного вида работ.

7. Убедились в достижимости поставленных целей на продуктиве и надежности новой системы.

8. Выполнили операции по инструкции и чек-листу на проде.

9. Сдали работу, указав в заключении значения ключевых метрик с пройденным чек-листом.

10. Внесли улучшения в процесс благодаря полученному опыту.

Работы на тесте и проде

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

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

Копирование файлового хранилища со старого сервера приложения оказалось непростой задачей, так как оно занимало около 1 Тб. Плюс к этому, особенность СЭД ТЕЗИС состоит в том, что файлы никогда не изменяются, в системе на каждый день создается каталог, и туда добавляются новые файлы. Сперва мы сделали тестовое копирование, чтобы понять, на какую скорость можем рассчитывать, и на основе этого составили график копирования. Каждую ночь запускали процедуру, чтобы избежать дополнительной нагрузки при работе прод сервера днем. При этом оставалась некая дельта, которую мы копировали уже в момент переключения со старого сервера на новый.

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

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

После финального переключения сначала мы провели смоук-тест, затем заказчик выполнил проверку на своей стороне.

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

Правила работ по замене ОС

В данном проекте мы выработали правила, которым следовали при построении плана работ. Если совсем коротко, то важно минимальное количество изменений. Если подробнее, то при замене серверной ОС в работающей бизнес-критикал системе важно следующее:

Скрытый текст

1. Налаженные бизнес-процессы не должны прерываться.

2. Существующие облачные решения должны остаться облачными.

3. Хранение и обработка данных должны соответствовать 152-ФЗ.

4. Форматы файлов, документов и календарей и их кодировка должны остаться такими же или совместимыми. Сортировка данных должна соответствовать языку.

5. Документы в облаке должны оставаться документами в облаке, при этом облачная платформа и ПО могут быть заменены.

6. Прикладное ПО, используемое в процессах, должно остаться или должно быть переведено на Linux (например, конвертеры, средства распознавания текста).

7. Периферийные устройства (потоковые сканеры, сканеры штрих-кодов, принтеры) по возможности должны остаться прежними.

8. Существующие интеграции сервисов должны остаться рабочими на серверах с новой ОС.

9. Замена ОС должна минимально влиять на способ подключения пользователя к рабочему столу или командной оболочке и периферии.

10. Привычный способ доступа к файлам должен остаться либо должен быть заменен на аналогичный (доступ к сетевым папкам, копирование путем перетаскивания, управление буфером обмена, редактирование файлов, конфигурация прав доступа через атрибуты файла и т.д.).

11. Сквозная авторизация и единая учетная запись пользователя должна сохраниться.

12. Технические учетные записи, используемые в интеграциях, должны остаться.

13. Замена ОС не должна сломать выполнение назначенных заданий и пользовательских сценариев, в том числе программных роботов. Следует заложить возможность написания несложных альтернатив.

14. Замена ОС не должна потребовать дополнительных трат на лицензии антивирусного ПО, резервного копирования, криптографии и прочего.

15. Замена ОС не должна потребовать закупки новых лицензий сопутствующего софта или интеграций из-за смены операционной системы (например, VipNet).

16. Замена ОС не должна серьезно влиять на настройки смежных систем, таких как системы мониторинга, аудита, резервного копирования. Смежные системы должны иметь возможность настройки.

17. Замена ОС не должна потребовать изменений в способе внешнего подключения к сети предприятия.

18. Уровень информационной безопасности ИТ-систем не должен снижаться.

19. Отказоустойчивость подсистем с конкретными показателями доступности RPO/RTO не должны ухудшаться.

20. Переиспользование текущего оборудования в случае установки новой ОС может быть затрудненным, что потребует временно увеличить количество машин.

21. Уровенькомпетенций персонала, обслуживающего сеть предприятия, должен остаться прежним или может требовать небольшого повышения.

22. Уровень компетенций персонала, обслуживающего серверное оборудование предприятия, потребует повышения.

23. Уровень компетенций персонала, обслуживающего пользовательские ПК, может потребовать повышения (в случае замены ОС на рабочих станциях).

24. Для персонала, оказывающего поддержку ПО пользовательских ПК, потребуется повышение квалификации до уровня опытного пользователя и администратора (в случае замены ОС на рабочих станциях).

25. Для существенной доли пользователей персональных компьютеров потребуется повышение квалификации до уровня пользователя (в случае замены ОС на рабочих станциях).

26. Перед началом работ потребуется составить сетевые схемы с протоколами и портами взаимодействия систем во всех контурах. Для моделирования проектируемых частей системы нужно использовать заглушки (эмуляцию прослушиваемых портов).

27. Потребуются обновленные инструкции для администраторов и пользователей.

28. Если планируется подключать к работе облачного провайдера и сотрудников аутсорсинга, то уточнить возможность поддержки выбранного ПО и ОС этими сторонами в долгосрочной перспективе.

Интеграция с 1С

Дополнительной сложностью было то, что параллельно с заменой ОС и СУБД «на лету» нужно было интегрировать СЭД ТЕЗИС с новой системой управления предприятием. Раньше в ITMS использовался SAP, но заказчик перешел на 1С. Обычно производственные системы внедряют годами, но тут нужно было успеть за полгода. В СЭД ТЕЗИС требовалось поменять большое количество процессов, связанных с еще не запущенной, а только реализуемой системой. Для интеграции использовали сервисную шину Datareon. Интеграционный модуль спроектировали так, чтобы распознавался формат пакета данных для обмена, и логика обмена пакетами была бы настраиваемой.

Разработка нового API-хранилища скан-образов первичной документации

Глобальное API-хранилище скан-образов первичной документации (например, счетов, актов, накладных и т.п.) — еще один ресурс, который заказчик заменил. После локализации компании к нему могли в любой момент закрыть доступ. Альтернативное решение представляет собой локальное хранилище на арендованных мощностях с Linux.

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

В новое хранилище дополнительно выгрузили архив документов размером около 1,5 ТБ из глобального хранилища, объединив два разных логических пула в один, с которым стало удобнее работать.

Миграция СУБД

В чем проблема заменить СУБД? В случае СЭД ТЕЗИС вопрос звучит в разрезе кроссплатформенной трехзвенной системы, которая поддерживает и старую СУБД и новую без изменения в модели данных. Обычно здесь кроются корневые причины в пользу убеждения «ничего не менять». В нашем случае изначально перенос СУБД не планировался, заказчика устраивала работа MS SQL. Но оставался риск, что в будущем ITMS не сможет продлить лицензии, и все данные компании окажутся под угрозой.

Система строится начиная с базы данных. Она получает модель данных со структурой и связями. Обычно при миграции БД используется подход, при котором берется новая операционная система, и в нее устанавливается СУБД. Однако в нашем случае правильно было спроектировать структуру новой СУБД, и затем к ней подобрать подходящую версию ОС, поскольку на этот выбор влияет совместимость Postgres и дистрибутива Linux. Разработчик СУБД всегда рассматривает ее как самостоятельный продукт. Операционная система с драйверами, библиотеками и антивирусом получает доступ к сети и внешним клиентам. Через клиентов могут появляться новые виды связей в виде REST API. Каждый такой слой требует обслуживания:

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

В общем случае при выборе ОС для СЭД следует учитывать:

1. Какая СУБД планируется на контуре прода.

2. Какая СУБД будет использоваться на остальных контурах.

3. Какие ОС допустимо использовать (импортозамещение: Astra Linux, РедОС, Альт, РОСА).

4. Какие версии из выбранных СУБД поддерживаются СЭД.

5. Какие из отмеченных СУБД совместимы с выбранными ОС.

6. Какие опции ОС могут блокировать использование ОС или СУБД (защищенный режим и т.д.).

7. Какие опции интеграций могут блокировать использование ОС (КриптоПро и т.д.).

8. Возврат к СЭД — поддержит ли СЭД выбранный вариант СУБД?

9. Учесть требование по поддержке СУБД вендором в течение 5 лет — это частое требование скорее всего будет невыполнимо.

В декабре 2022 при выборе новой ОС при миграции с Windows на проекте ITMS была выбрана Astra. Но тогда еще не знали о том, что при выборе ОС нужно отталкиваться от СУБД. Особенностью отечественных ОС является несовместимость ванильных версий Postgres с ОС. Некоторые версии Postgres встроены в дистрибутив и такой Postgres сопровождается модифицированными версиями общих библиотек. Эти библиотеки конфликтуют с ванильными.

Как было упомянуто выше, заказчик планировал использовать на проде PostgrePro. Команда разработки PostgrePro поставляет библиотеки, которые не конфликтуют с библиотеками операционных систем. Но так как это платный продукт с поядерным лицензированием, и платить за лицензии остальных контуров не хотелось, то для остальных контуров хотели использовать ванильный Postgres. Оказалось, что в декабре 2022 в Astra были PostgreSQL-astra 11 и 14. В итоге спустились до PostgreSQL-astra версии 11, поскольку ТЕЗИС на тот момент еще не прошел тестирование на совместимость с Postgres 14. К счастью, в течение 2023 года и ТЕЗИС прошел сертификацию, и репозиторий Astra пополнился недостающими версиями Postgres.

На тестовом контуре ITMS использовалась СУБД MS SQL на Windows Server совместно с приложением ТЕЗИС на Astra Linux 1.7. В качестве будущего тестового контура развернули отдельный сервер с Astra Linux, на котором подняли СУБД PostgreSQL. СУБД продуктива была на отдельном сервере на Windows, ее тоже планировали переносить на новый сервер с Linux.

Миграция СУБД

В первую очередь мы получили дампы БД прода и теста заказчика и проверили работоспособность системы на новой БД. Логика СЭД ТЕЗИС реализована на Java в самом приложении, а БД используется в основном для хранения данных, поэтому с работоспособностью проблем не было, основная сложность заключалась в объеме БД и ограниченном времени на миграцию. Требовалось перенести базу размером 700 Гб за два выходных дня, чтобы с началом рабочей недели пользователи смогли спокойно использовать систему. У нас уже был опыт миграции и готовые инструменты — скрипт, выполняющий конвертацию данных из MS SQL в PostgreSQL. Первичные внутренние тесты показали миграцию тестовой базы в 110 Гб за два дня — а прод база была почти в 7 раз больше.

С производительностью миграции работали в двух направлениях:

• Уменьшение объема базы данных на 130 Гб за счет очистки таблиц, хранящих различную историческую информацию о работе с системой

• Оптимизация работы скрипта миграции

В итоге миграция тестовой БД сократилась до двух часов.

После этого схожим образом на внутренних мощностях мы мигрировали прод БД, начав с 69 часов и завершив процесс на значении в 21 час. Результаты тестов радовали, но оставался риск, связанный с инфраструктурой ITMS. Как миграция отработает на мощностях заказчика, мы не знали. Опираясь на выводы, сделанные в процессе внутренних тестов, очистки и оптимизации, были подготовлены планы миграции тестовой и прод БД заказчика в инфраструктуре заказчика.

План выглядел следующим образом:

• Запросить открыть новые сетевые правила под приложение и новую СУБД.

• Установить СЭД ТЕЗИС с правками для работы с PostgreSQL возле текущей системы.

• Подготовить сервера через pg_hba.conf.

• Запустить службы приложения с PG, запустить все скрипты, если система запущена и выполнен логин, считать подготовку завершенной.

• Остановить обе службы — текущее и дополнительное приложение.

• Запустить миграцию БД с MS SQL на PostgreSQL.

• Запустить приложение для взаимодействия с PostgreSQL на мигрированной СУБД PostgreSQL.

Мы продумали порядок действий на случай сбоя — снести то, что мигрировали, собрать данные для анализа и планировать отдельную дата-миграцию. Но миграция прошла успешно. Мы обновили основной тестовый сервер сборкой PostgreSQL, переключили систему на мигрированную базу, передали заказчику и завершили работы.

В итоге миграция в рамках прод мощностей заняла 13 часов вместо запланированных 21 часа. Мы предполагаем, что такая разница связана с различиями в мощностях между нашими внутренними стендами и прод стендом заказчика. Объем БД сократился более чем в 3 раза.

Результаты

Как и требовалось заказчику, мы перевели всю инфраструктуру СЭД ТЕЗИС с серверов MS на Astra Linux до окончания срока действия лицензий и улучшили ситуацию с производительностью. Все это — параллельно с расширением функциональности СЭД ТЕЗИС, обновлением ее версии, а также переходом на 1С вместо SAP и локализацией API-хранилища скан-образов.

В таблице — наглядные результаты замеров производительности.

Важно отметить, что вдобавок к замене ОС и СУБД на повышение скорости могли повлиять и другие факторы, включая оптимизацию за счет обновления версии СЭД. Однако результат очевиден — производительность подросла, запросы стали выполняться быстрее, пользователям стало комфортнее.

Что и говорить, работа была стрессовая, пару раз нескольким участникам команды хотелось уволиться, но это был крутой вызов. Мы набили шишек, сделали выводы и подняли планку. Теперь даже на «тихих» проектах у нас ведутся подробные карточки со связями, чтобы изменения в инфраструктуре не остались незамеченными. А теперь представьте, что будет, когда кто-то захочет такую же миграцию? Контакты в профиле😊