Перевод больших баз 1С 8.3 на Linux с СУБД Tantor: опыт миграции 1С:ERP и 1С:Документооборот

Подробно рассказываем о нашем опыте перевода больших баз 1С:ERP и 1С:Документооборот с Windows на ОС Linux с использованием СУБД Tantor. Делимся технологией переноса данных, особенностями настройки, выявленными проблемами и практическими рекомендациями, которые помогут пройти этот процесс максимально гладко и без сбоев. Статья будет полезна ИТ-специалистам, которые планируют или уже начали перенос 1С на Linux.

Проект миграции 1С на Linux: информация о заказчике, параметры систем

СПб ГУП "Пассажиравтотранс" – крупнейший оператор автобусных перевозок в Санкт-Петербурге, входящий в перечень объектов критической информационной инфраструктуры. В соответствии с федеральным законодательством такие организации обязаны использовать отечественное программное обеспечение и операционные системы. Поэтому перед специалистами "СофтБаланс" была поставлена задача миграции двух ключевых баз данных – "1С:ERP Управление предприятием" и "1С:Документооборот" – на российское ПО.

Характеристики систем, используемых на предприятии:

• Размер базы – примерно 1ТБ;

• 700-750 пользователей в системе (500 активных);

• Работа в системе ведется 24/7;

• Максимальный размер технологического окна – 2-3 часа.

В ключевые алгоритмы конфигурации изменения практически не вносились: были сохранены типовые механизмы расчета себестоимости и взаиморасчетов. Единственное исключение – незначительная доработка в блоке распределения расходов.

При этом общий объем доработанного функционала в системе сопоставим с размером самой 1С:ERP.

1С:Документооборот 2.1.34

• Размер базы примерно 300 ГБ;

• Основная специфика – активное использование ЭЦП;

• Работа в системе также ведётся 24/7.

Этапы проекта миграции баз 1С на Linux

Проект длился примерно полгода: работы начались в январе, а закончились в июне 2025. Подготовку к миграции клиент начал ещё в 2023 году. В 2024 году "Пассажиравтотранс" самостоятельно осуществили закупку оборудования и перевод клиентских станций на Astra Linux.

Постепенный перевод клиентских ПК на новое программное обеспечение позволил в достаточно спокойном режиме (без авралов) устранить платформенно зависимый клиентский код. Адаптация кода выполнялась в рамках сопровождения и в основном касалась работы с MS Excel. Если у кого-то из пользователей функционал переставал работать, то его всегда мог подменить пользователь со "старым" ПО.

К январю 2025 все клиентские ПК были переведены на Linux, и команда "СофтБаланс" приступила к работам по миграции серверов 1С и баз данных.

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

• Открытия форм,

• Проведения документов,

• Некоторых действий в формах.

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

С позиции трудозатрат встраивание замеров в код обошлось довольно дешево – примерно одна неделя работы младшего разработчика.

Задачи перед миграцией баз данных

Перед началом миграции были сформулированы ключевые задачи:

• Сохранить производительность для пользователей – время выполнения операций на новом контуре должно быть сопоставимо с прежним;

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

• Уложиться в разумные сроки и трудозатраты при разработке обработок для нагрузочного тестирования.

Сценарий нагрузочного тестирования

За основу сценария для нагрузочного тестирования мы взяли идею имитации реальной пользовательской работы и собрали логи действий, дающих в совокупности 80-90% нагрузки на систему, за рабочий день, в часы наиболее интенсивной работы:

• Открытие и закрытие форм;

• Запись документов и справочников;

• Формирование отчетов;

• Формирование стандартных бухгалтерских отчетов;

• Формирование печатных форм.

Недостающие логи (например, имитация ошибок записи и проведения) сгенерировали самостоятельно.

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

В результате в логах были собраны действия со 100-150 объектами каждого типа. Для воспроизведения логов была написана одна универсальная обработка, что позволило существенно сократить этап подготовки к нагрузочному тесту.

Для проведения теста:

• Выбрали 500 пользователей, чьи действия планировали воспроизводить;

• Клонировали их учетные записи со всеми настройками;

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

Таким образом нагрузочный тест был максимально приближен к реальной ежедневной работе пользователей.

Проблемы, выявленные при нагрузочном тестировании

Первое нагрузочное тестирование выявило, что большинство действий стали выполняться почти вдвое медленнее. Ключевая причина – "старый" режим RLS.

Так, форма списка справочника "Сотрудники" открывалась в среднем 50 секунд, максимум – до 30 минут. При этом 30 минут – это время выполнения запроса к базе данных. После перехода на новый режим RLS время открытия формы "Сотрудники" сократилось примерно до 8 секунд: значительно лучше, но всё ещё недостаточно быстро. Поскольку форма нужна была абсолютно всем пользователям и входила в список ключевых, пришлось пересмотреть архитектуру хранения данных, чтобы уложиться в целевое время. Это была самая трудозатратная оптимизация за весь проект.

Дополнительно было выявлено ухудшение скорости выполнения операций в типовом зарплатно-кадровом блоке. Так документы стали проводится в среднем на 1-2 секунды медленнее. А у некоторых отчетов и динамических списков скорость формирования/открытия увеличилась в 1,5 раза. 

Скорость ухудшилась именно на формировании запросов, на исполнении кода замедления не были выявлены. Основные причины:

• "Старый" режим RLS;

• Пользовательские настройки динамических списков и отчетов;

• Соединения с виртуальной таблицей "СрезПоследних" в запросах;

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

• Архитектура, приводящая к неоптимальным запросам.

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

Результаты нагрузочного тестирования

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

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

В рамках финального нагрузочного теста показатель Apdex составил 0,984, что немного лучше, чем до перехода (0,978), и близко к значению в рабочей базе после перехода (0,96).

После миграции зарегистрировано менее десяти инцидентов от пользователей, что подтверждает успешность и релевантность проведенного тестирования.

Технология миграции базы 1С:ERP на Linux

Сам процесс миграции базы 1С:ERP происходил следующим образом:

1. Для переноса базы размером около 1 ТБ использовали выгрузку (из развернутой копии) и загрузку через dt-файлы. Процесс занимал примерно 8 часов.

1. Попытка использовать утилиту администрирования автономного сервера (Ibcmd) оказалась неудачной из-за потерь данных: база уменьшалась с 1 ТБ до 350 ГБ, что делало этот способ неприемлемым.

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

3. После переноса базы между серверами в ней, по данным логов, были многопоточно восстановлены документы и справочники. Технологическое окно для переноса данных составило около 2 часов.

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

Специфика миграции базы 1С:Документооборот на Linux – проблемы после перехода и перенос томов хранения

Перенос базы "1С:Документооборот" проходил проще: выгрузка и загрузка через dt-файлы занимали около 2 часов, а допустимое технологическое окно составляло примерно 4-5 часов.

Основные проблемы, с которыми столкнулись после перехода – это ошибки в коде типовой конфигурации:

• Некорректные обращения к шрифтам в коде.

• Некорректный регистр символов в путях к файлам.

• Ошибки при вызове команд ImageMagick для вставки отметки ЭП в документы.

Дополнительно перестала работать вставка отметки ЭП в pdf-файлы с помощью ImageMagick, переключились на вставку средствами 1С.

Главная рекомендация: обязательно проводите функциональное тестирование, не полагайтесь только на пользователей – тестируйте вместе с ними.

Отдельно остановимся на процессе переноса томов хранения:

• Важно помнить, что это длительный процесс. Если учет ведётся давно, а объемы томов значительны, то перенос вместе с актуализацией может занять несколько дней – зачастую больше времени, чем сама миграция базы. Также необходимо учитывать, что в зависимости от размеров технологического окна, пользователи некоторое время после миграции могут не иметь доступа к актуальным файлам.

• Ограничение на длину имени файла – 255 байт. Один символ может занимать до 4 байт, поэтому длинные имена могут превысить лимит. Если в системе много присоединенных файлов, особенно если пути хранятся не в одном справочнике, стоит заранее продумать вопрос ограничения длины имени и автоматическую обрезку.

Что ожидать после перехода

• То, что работало медленно, может начать работать еще медленнее. "Плохие" запросы лучше выполняться не станут. А те, что вытягивал MSSQL, может не вытянуть PostgreSQL.

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

• После перехода могут некорректно работать сортировки в печатных формах, отчетах и табличных частях документов – такие ошибки часто не выявляются на этапе функционального тестирования. Заложите время на исправление этих ошибок после миграции. Для устранения проблемы достаточно будет упорядочить выборки в запросах.

Как подготовиться к переходу на Linux

1. Ревизия и анализ текущей системы:

   1. Проведите ревизию интеграций и используемого стороннего ПО – большинство проблем для миграции будет связано именно с ними.

   2. Встройте замеры производительности, если их нет. Хотя бы базовые: время открытия форм, записи документов и справочников. Это даст понимание общей картины работы системы и потенциальных "узких мест".

   3. Запросите у пользователей информацию о медленных операциях с обязательной фиксацией на видео. То, что понимают пользователи и технические специалисты под операцией, может сильно различаться.

   4. Если сейчас у вас есть какие-то особенности по управлению учетными записями пользователей – возможно, потребуется искать новые решения.

2. Оптимизация кода и пересмотр архитектуры:

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

   2. Если система активно развивается и дорабатывается, то со временем код "замусоривается", а архитектура перестает соответствовать нуждам учета. С этим помогает только периодическая ревизия и рефакторинг. При наличии возможности стоит систематически планировать такие работы, хотя бы для наиболее часто модифицируемого функционала. Принцип "работает – не трогай" - некорректный.

   3. Если до сих пор работаете на "старом" режиме RLS – запланируйте переход. Для понимания трудозатрат -  150 нетиповых ролей 4 разработчика доработали и протестировали менее, чем за 4 рабочих дня.

3. Организационные и технические моменты:

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

   2. Для проведения тестирования нужны оборудование и лицензии – это вопрос потребует решения.

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

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

Не бойтесь перехода – нерешаемых задач нет. Даже если наш опыт для вас не применим, сейчас существует большое количество различных технических решений. Какое-то из них обязательно вам подойдет. Если тщательно подойти к вопросу и продумать все необходимое, миграция может быть "комфортной", без аврального устранения проблем после перехода.

Узнайте больше о том, как перевести ваши базы 1С на отечественное ПО с минимальными рисками и без простоев. Отправьте запрос – и наши специалисты свяжутся с вами.