В связи с тем, что иностранные компании прекратили поддержку многих продуктов и в т.ч. MS SQL в России, появилась задача быстрой миграции систем 1С на PostgrеSQL. Также одной из предпосылок перехода стал рост компании и потребность подключения большего количества пользователей к системам 1С для ведения учета. Из-за ухода западных вендоров с рынка, покупка лицензий для расширения мощности серверов стала невозможна.
В качестве пилотного проекта была выбрана информационная система с объемом хранения данных 300 гигабайт, которая обеспечивает работу около 300 активных пользователей в среднем. Система, которую мы переносили, была сильно кастомизирована. Ряд авторских доработок существенно изменил типовой функционал, который был реализован на базе платформы 1С: УПП. Эти факторы существенно осложняли работу на проекте.
При миграции систем из среды Windows в Linux можно разбить на две большие части. Это миграция сервисов 1С и миграция систем СУБД.
На первом этапе было решено переносить СУБД с MS SQL на PostgrеSQL. Всего требовалось мигрировать с MSSQL на PostgreSQL 17 систем 1С. Выбрали как самую приоритетную для целей миграции систему MDM с объемом данных около 300 ГБ и до 300 пользователей на момент начала работ.
Первая проблема, с которой столкнулись это длительный этап выгрузки базы данных в файл универсального бэкапа DT. База данных порядка 300 ГБ выгружалась порядка 22 часов. Далее при тестировании загрузки полученного файла универсального архива в СУБД PostgreSQL обнаружились ошибки связанные с невозможностью загрузки в PostgreSQL текстовых полей больших размеров, более 512 МБ. Так проблемы подготовки системы к тестированию в среде PostgreSQL появились до того, как само тестирование в среде PostgreSQL стало возможно.
Для решения задачи длительной выгрузки в универсальном формате мы обратились к возможностям современных релизов платформы версий 8.3.23 и более новых в части нового функционала Автономного сервера. Функционал автономного сервера при определенных настройках позволяет создавать копию базы, при этом исходная база и целевая копия могут располагаться в СУБД разных видов. Создание копии базы данных средствами автономного сервера поддерживает многопоточность и повышает скорость, по нашей оценке, до 10 раз. Рекомендуем использовать для размещения сервиса миграции отдельный сервер, что позволяет хорошо распараллелить и распределить нагрузку по серверам, участвующим в миграции. Забегая вперед, отмечу, что достигнутая скорость миграции данных обеспечила прерывание работы системы на несколько часов, выделенных в ночь, вместо остановки системы на более чем 1 сутки в период, согласованный с заказчиком.
Решение задачи невозможности загрузки данных в базу PostgreSQL «как было» в базе MSSQL было организовано после анализа ошибки, выделения объектов 1С к анализу и выбору метода обработки скриптами MSSQL. База, мигрировавшая в PostgreSQL, эксплуатировалась, и развивалась более 10 лет, что как видим привело к некоторым сюрпризам. В частности оказалось, что благодаря загрузкам из внешних источников, подготовленных пользователями, в базу попали не запланированные для хранения данные. MSSQL позволил сохранить в двух справочниках, трех реквизитах 7 текстовых значений объемом от нескольких сотен мегабайт до > 1 гигабайта. Запросом напрямую к данным хранимым в МSSQL мы нашли проблемные записи и скорректировали их, сократив размер до приемлемого.
Выполнив работы по 2 пунктам проблем, нам удалось развернуть проблемную систему в тестовой среде для проверки работоспособности системы 1С в СУБД PostgreSQL.
Основная проблема работоспособности с нашей точки зрения после миграции на PostgreSQL это проблемы деградации производительности. Оценку возможной деградации производительности мы проводили, используя несколько подходов:
Для реализации исполнения п.1 мы использовали 1С:Тест центр и данные доработанных регистров подсистемы сбора статистики замеров Apdex. Так же были реализованы доработки в 1С:Тест центре для обеспечения подготовки данных регистров Apdex к массовому тесту. Методом масс теста было организация нагрузки на систему при работе большого количества пользователей при проведении документов. План включения пользователей в тест и порядок проведения документов строился на истории работы с документами, хранимыми в регистрах замеров и истории работы с объектами учета. Для «драматизации» нагрузки были опционально использованы методы уменьшения интервалом между операциями проведения и увеличения количества повторов проведения документов. С учетом специфики нашей системы и опыта подобных тестов мы использовали тройное проведение документов вместо одного проведения по данным статистики при работе в реальных условиях, что позволило в некоторой степени сблизить реальную нагрузку рабочей базы и тестовой, в тестовых условиях.
Реализация п.п. 2 и 3 заключалась только организационные решениях и технического интереса не представляла. Полученные данные по результаты операций и оценочные данные для контроля сопоставлялись с Apdex статистикой как для проведенных операций в тестах, так и с историческими показателями.
По итогам проведенных испытаний был сформирован план работ и мероприятий, связанных с доработкой 1С Конфигурации системы и оптимизации, перераспределение параметров настроек PostgreSQL. В частности, мы выяснили, что основная проблема связана с авторскими доработками, проектировавшимися в среде Windows+MSSQL не прошедшими из-за отсутствующего бюджетирования на оптимизацию и рефакторинг систем после периодов промышленной эксплуатации. Часть доработок реализованных в момент внедрения системы и отсутствия больших объемов нельзя было протестировать на объемах данных соответствующим 10 летней базе с десятками и сотнями млн. записей в объектах учета. На период эксплуатации системы в MSSQL уже появились нарекания к оперативности интерфейса, PostgreSQL проявил по части объектов проблемы более ярко. В т.ч. по двум журналам документов со сложным запросом с соединениями с историей статусов, историй ответственных по этапам бизнес-процессов, и подобным связям в MSSQL отклик интерфейса достигал нескольких секунд, в PostgreSQL требовалось несколько часов на открытие двух проблемных списков документов. Это фатальный для эксплуатации результат, который требовал решения в первую очередь. Задачу решили, используя кеширующие регистры. Регистры обновлялись при изменении ключевых показателей, выводимых с большими задержками ранее. Таким образом мы повысили отзывчивость списков документов на порядок по сравнению с MSSQL и еще более значимо по сравнению с PostgreSQL. Забегая вперед, скажу, что такой фатальный с точки зрения быстродействия результат проявляется не для всех систем и как правило для авторской реализации под MSSQL. Типовые решения в общем не страдают фатальной деградацией производительности.
После решения проблемы со списками документов мы смогли передать в массовое тестирование для специалистов со стороны Заказчика, наших тестировщиков и параллельно запустить масс тест проведение. По итогам проведены незначительные оптимизации 4 отчетов из NNN, алгоритмов проведения 6 документов из NNN в массово использующихся системе. По результатам Apdex мы повысили быстродействие системы по операциям проведения документов от нескольких процентов до нескольких раз. Т.е. в общем после миграции в СУБД PostgreSQL пользователи получили более комфортную и отзывчивую рабочую среду.
После подтверждения от тестовой группы Заказчика, что их устраивают результаты работы системы в среде PostgreSQL и достижения внутренних целей, поставленных по итогам тестирования мы согласовали дату миграции на ночь в начале рабочей недели и провели миграцию системы с MSSQL на PostgreSQL. Т.е. на данном этапе сервер 1С не мигрирует, то для пользователей эта операция прошла прозрачно, только с прерыванием доступа в систему, на несколько часов.
Вывод: быстрая миграция системы 1С на PostgreSQL позволила компании успешно справиться с проблемой прекращения поддержки MS SQL и достичь целей по увеличению производительности и масштабируемости системы. В результате, компания получила устойчивую и эффективную систему управления данными, которая полностью соответствует требованиям и обеспечивает оптимальное функционирование бизнес-процессов.
Общество с ограниченной ответственностью «РГ-Софт Проект Консалтинг» (ООО «РГ-Софт Проект Консалтинг»)
Веб-студия SeoLand: Создание и продвижение сайтов
