Меня зовут Александр Леонов. Я руководитель центра экспертизы 1С в компании Magnit Tech. Мои команды занимаются исследованиями в сфере 1С, а также импортозамещением 1С-систем на open-source технологии. Сегодня я хочу поговорить о переводе систем 1С на базу данных Postgres и поделиться накопленным опытом.
Magnit Tech — это крупная компания с 29 000 магазинов, 360 000 сотрудников и 64 информационными системами, построенными на основе 1С. Более трети этих систем уже работают на Postgres, а более 60% баз данных имеют размер свыше одного терабайта. Учитывая такие масштабы, переход на Postgres требует тщательного планирования и стратегического подхода.
Чтобы эффективно осуществить переход, до его начала нужно организовать обучение, выбрать программное обеспечение, внедрить систему мониторинга, организовать резервное копирование, настроить отказоустойчивость, а также подготовить инструменты.
Этап 1. Обучение
Никакую новую технологию вы не внедрите без экспертизы. Первая базовая вещь — вы должны обучить ваших Unix-администраторов. Они должны уметь настраивать Linux-машины, должны уметь их администрировать, мониторить.
Самая база — это подготовка к сертификациям LPIC-1 и LPIC-2, которые нужно обязательно пройти. И далее развивать эту экспертизу. Нам в этом плане очень везет — у нас отличная команда специалистов.
Но речь не только о Unix-администраторах, но и о DBA. Обучение DBA также нужно проводить, если у вас его еще не было.
Что касается Postgres — огромное спасибо коллегам из Postgres Pro. Они подготовили потрясающее обучение в большой градации: можно выбрать любой курс на свой вкус. Но мы базово рекомендуем DBA1 и QPT.
Также не забывайте, что ваши 1С-разработчики прекрасно умеют работать с MS SQL: у них огромная экспертиза в этой области. Они умеют снимать планы запросов, подключаться к базам, могут даже работать в Profiler, разбираются в Extended Events… Но вот в Postgres такой экспертизы у них, скорее всего, нет.
Это тоже нужно подтягивать: отправлять их на курсы, проверять, как они усвоили материал. Об этом тоже нужно позаботиться, чтобы они были готовы к работе с новой технологией.
Этап 2. Выбор ПО
Следующий важный шаг — это выбор программного обеспечения и платформы. В первую очередь, речь об операционной системе. Если вы работаете в госсекторе, выбор, конечно, ограничен. Мы использовали CentOS, но сейчас переходим на Debian.
Что касается СУБД, может показаться, что с PostgreSQL особого выбора нет, но это не так. Для работы с 1С доступны такие решения, как PostgreSQL от самой 1С, а также Postgres Pro, Tantor, Pangolin и Jatoba. Все они имеют сертификацию и отлично работают с 1С.
Каждый из этих продуктов уникален и решает свои специфические задачи, поэтому их обязательно стоит рассматривать. Если у вас возникают ошибки или проблемы, важно изучать опыт коллег — возможно, они уже нашли решение.
Пока мы остановились на PostgreSQL от 1С, но ежегодно пересматриваем свою стратегию, учитывая изменения на рынке.
Этап 3. Мониторинг
В рамках мониторинга также необходимо тщательно продумать, как вы будете отслеживать работу ваших систем, как они функционируют, и каким образом вы будете реагировать на возможные проблемы.
Существует стандартное решение для PostgreSQL — связка Grafana и Prometheus. С их помощью вы можете использовать готовые дашборды в Grafana, которые уже предварительно настроены, что обеспечивает наглядность и простоту восприятия данных.
Однако есть и альтернативные варианты. Например, Zabbix. Также существуют инструменты, которые предоставляют не только возможности мониторинга, но и функционал для диагностики проблем (troubleshooting). Среди них:
-
Tantor (платформа для управления базами данных),
-
Sage от T-Bank (отличное решение для PostgreSQL),
-
Kintsugi от Platform V.
Обязательно обратите внимание на эти инструменты — они могут значительно упростить вашу работу.
В настоящее время мы используем Grafana + Prometheus, на некоторых системах дополнительно задействован Zabbix.
Этап 4. Надежность
Вы должны обеспечить надежность для ваших систем. Здесь можно выделить два этапа. Первый — это резервное копирование. Его также необходимо тщательно продумать: как именно вы будете выполнять бэкапы. Поскольку Postgres — это открытое программное обеспечение, вокруг него сформировалось большое сообщество, которое разработало множество утилит для решения различных задач. Для резервного копирования также существует множество инструментов.
Мы используем связку PgBackrest и NetWorker. Такой выбор обусловлен тем, что у нас есть значительная экспертиза, в том числе среди администраторов баз данных (DBA). Наши специалисты обладают высокой квалификацией, активно участвуют в сообществе и делятся своими знаниями. У нас сформированы стандарты работы с Postgres, поэтому мы придерживаемся именно этого подхода.
Также крайне важно учитывать отказоустойчивость. В этом вопросе 1С рекомендует стандартную сборку: HaProxy плюс Patroni. Мы же используем комбинацию Virtual IP и VIP Manager.
Полезная ссылка: //infostart.ru/1c/articles/2122530/
Этап 5. Инструменты
Следующий аспект — инструменты. Здесь мы столкнулись с определенными сложностями при переходе на Postgres.
Мы внедрили технологию, но не учли, что многие сотрудники ранее работали напрямую с СУБД. У администраторов 1С был обширный функционал: они писали собственные скрипты для работы с MS SQL, использовали специализированные запросы для извлечения данных, а также триггеры, которые завершали активные сеансы при чрезмерном потреблении ресурсов.
Об этом не стоит забывать. Часть функционала придется адаптировать под Postgres, а что-то, возможно, окажется ненужным. Но это требует отдельного анализа.
В MS SQL логирование по умолчанию предоставляет детальную информацию: можно посмотреть, какие запросы выполнялись месяц назад, их статистику, частоту вызова и потребление ресурсов. В Postgres из коробки такой возможности нет — приходится использовать плагины и дополнительные библиотеки для расширения возможностей.
Также важно учитывать разработчиков, которые привыкли работать с СУБД (пусть и не всегда напрямую). Для них необходимо готовить тестовые базы. Мы создаем их путем снятия логической копии с ноды. У нас трехзвенная архитектура (три сервера в кластере), поэтому мы можем выполнять резервное копирование с пассивной ноды без заметного влияния на работу. Однако в процессе перевода мы столкнулись с системами, которые не требуют репликации на три сервера, и пользователи быстро замечают, когда мы начинаем делать копии. Поэтому сейчас мы изучаем возможность использования снапшотов.
Database Lab разработал отличный инструмент на основе ZFS, который позволяет мгновенно создавать базы любого размера (3 ТБ, 4 ТБ, 20 ТБ — не имеет значения), при этом они занимают минимум места (20–30 МБ, хранятся только изменения). Сейчас мы тестируем эту систему, и она уже прошла первоначальную проверку. Планируем запустить пилотный проект. Рекомендую обратить внимание на этот инструмент — он отлично подходит для разработчиков и подготовки тестовых баз.
Также стоит подумать об обезличивании данных в базах для разработки. Если у вас уже есть инструменты для обезличивания в MS SQL, их придется адаптировать. Postgres тоже предоставляет плагины и утилиты для этой задачи.
Кроме того, важно настроить сбор статистики и логирование. Отладка запросов в Postgres работает иначе, чем в MS SQL. Также необходимо продумать разграничение прав: разработчики не должны иметь полный доступ к СУБД. Лучше вообще ограничить их доступ к базам, чтобы они анализировали планы запросов на уровне сервера приложений. Тем более, что консоль запросов с сайта ИТС позволяет получать план запроса через техжурнал: выполнил запрос — сразу видишь его план. Это отличный подход, и важно разделять права именно таким образом.
Далее о логировании. Можно использовать pg_stat_statements для сбора расширенной статистики. Некоторые опасаются включать этот модуль, полагая, что он значительно увеличит нагрузку. Мы провели тестирование и выяснили, что нагрузка возрастает незначительно: в пиковых сценариях — на 5–10% CPU.
Полезная ссылка: https://habr.com/ru/articles/696274/
Полезная ссылка: //infostart.ru/1c/articles/2102149/
Как обеспечить стабильность системы
При любых изменениях в архитектуре необходим системный подход к тестированию. Мы используем три вида тестов. Первый — это стандартный тест Гилёва, который вам всем хорошо знаком. Вам показывают цифру, и вы сразу понимаете, что она означает. Далее у нас есть нагрузочный тест, разработанный нашей командой. Он позволяет четко выявить, где возникают просадки: в СУБД или на сервере приложений.
Третий вид тестирования максимально приближен к реальным условиям — это тестирование в ERP. Мы создаем цепочки документов и замеряем, сколько таких цепочек формируется за определенный промежуток времени. Это реальный тест, которому доверяют абсолютно все. Мы применяем эти подходы при любых изменениях: обновляем версию Postgres — запускаем тесты, меняем версию операционной системы — снова проверяем.
Такой подход к тестированию обязателен. Вы должны быть уверены, что после изменений система останется стабильной и не будет просадок в производительности.
Postgres позволяет расширять функциональность не только за счет плагинов и утилит. Есть возможность создавать собственные функции и методы, причем не только на SQL, но и на таких языках, как Perl или Python. В нашем случае мы использовали Python для сбора расширенной статистики по активным запросам.
Мы дополняем стандартные данные Postgres информацией с операционной системы: сколько CPU потребляет запрос, какой объем оперативной памяти использует, какова скорость чтения и записи на диск в момент выполнения этого запроса. Наши администраторы привыкли видеть подобную статистику в MS SQL, и для них важно иметь такую же возможность в PostgreSQL.
Кастомизация модулей и ядра PostgreSQL – добро или зло?
Здесь открывается огромное поле для обсуждения. Насколько вообще оправдана такая глубокая кастомизация? Речь идет о модификации модулей или даже ядра PostgreSQL. Мы проводили исследования в этом направлении. В целом мы пришли к выводу, что это не так сложно. У Postgres Pro даже есть специальное обучение, которое объясняет, как правильно вносить изменения и адаптировать Postgres под свои нужды.
Однако такой подход требует глубокого понимания задачи. Вы должны быть уверены, что это действительно необходимо и что проблема не решается на уровне платформы 1С. В исключительных случаях такой вариант возможен, но мы пока не сталкивались с ситуациями, где это было бы оправдано — все решается на уровне платформы. Тем не менее это запасной вариант, который стоит иметь в виду.
Полезная ссылка: //infostart.ru/1c/articles/1814630/
Первичный анализ ИС
После того как мы подготовили всю нашу инфраструктуру и сотрудников для внедрения новой технологии, нам необходим пилотный проект. Нужно выбрать подходящую информационную систему для перевода и провести ее детальный анализ.
Мы разделяем анализ на две части. Анализ инфраструктуры помогает понять, какие требования предъявляются к ней и какие работы потребуются при переводе системы. Анализ работ определяет, как именно будет проходить миграция и какие дополнительные задачи могут возникнуть.
Анализ инфраструктуры
-
Свободное место на дисках — обязательно должно быть не менее 30% свободного пространства. Это best practice, неоднократно подтвержденный на практике. Postgres не любит нехватку места, поэтому перед миграцией убедитесь в наличии запаса. Если у вас уже сейчас возникают подобные проблемы на MS SQL, сначала увеличьте дисковое пространство и только потом планируйте перевод.
-
Архитектурные долги — если у вас критичная система, но всего один сервер, необходимо предусмотреть резервирование. Добавьте как минимум еще пару серверов.
-
Текущая нагрузка — если сервер работает на пределе (100% загрузки CPU, памяти или дисков), сначала устраните эти проблемы: либо оптимизируйте нагрузку, либо добавьте ресурсов. Только после этого можно приступать к миграции.
После выполнения этих условий можно сделать вывод о том, возможна ли миграция 1:1. Например, можно развернуть аналогичный сервер под Postgres и перенести данные на него либо, если позволяет временное окно, перенастроить существующий сервер.
Анализ работ
-
Объем данных и время миграции — если база большая, а технологическое окно слишком мало, потребуется механизм синхронизации изменений, происходящих во время переноса. В 1С для этого используются планы обмена, но если изменений много, этого может быть недостаточно. В таком случае нужно продумать многопоточную миграцию для ускорения процесса.
-
Крупные таблицы — если в базе есть таблицы с большим объемом данных, стоит проанализировать их содержимое. Например, там могут храниться файлы, которые лучше вынести за пределы СУБД. Современные платформы позволяют делать это незаметно для пользователей, например, перенося файлы в S3-хранилище (лицензия Corp) или через БСП (хранение в файловой системе).
-
Ограничения Postgres — максимальный размер одного поля не должен превышать 1 ГБ. Если у вас хранятся большие объекты (например, видео или отчеты), это вызовет ошибки при миграции.
-
Кастомные объекты — иногда администраторы баз данных добавляют индексы или другие объекты вручную, без уведомления разработчиков. При миграции на Postgres эти объекты могут быть потеряны, что приведет к проблемам с производительностью. Для аудита таких изменений мы разработали специальную обработку, которая помогает выявить кастомные индексы и перенести их на уровне платформы.
-
Прямые интеграции — в старых системах (например, на 1С 7.7) часто использовались прямые подключения к базе данных (через ODBC, OLAP-кубы, BI-системы). При миграции такие интеграции могут быть неочевидны, особенно если они не задокументированы. Необходимо выявить все внешние подключения и перевести их на стандартные API или другие методы взаимодействия.
-
Проблемы производительности — если на MS SQL уже есть узкие места, не стоит надеяться, что на Postgres они исчезнут. Скорее всего, проблемы останутся или даже усугубятся, поэтому их нужно решать до миграции.
Чек-лист и инструменты
Чтобы ничего не упустить, мы подготовили чек-лист для анализа и выложили его на GitHub. Там же доступна обработка для аудита кастомных индексов и других нестандартных объектов.
Полезная ссылка: https://github.com/magnit-tech/cfg-1c-analysis-checklist-pg
Тестовая миграция, целевые показатели
После этого необходимо определиться с дальнейшими шагами. Первый этап — тестовая миграция. Вам потребуется подготовить тестовую зону для выполнения проверок. Для миграции существует несколько инструментов. В первую очередь стоит отметить утилиту ibcmd с командой replicate. Это инструмент автономного сервера, который эффективно выгружает и загружает данные. Он работает в многопоточном режиме как при выгрузке, так и при загрузке. Показывает отличные результаты, однако есть нюанс: на сервере, где запускается эта утилита, нагрузка на CPU может достигать критических значений. Поэтому на важных серверах ее использование не рекомендуется. Будьте осторожны. Что касается выгрузки и загрузки через DT, то мы успешно переносили базы данных объемом до 900 ГБ без серьезных проблем. Главное — не забыть выделить дополнительное место во временных каталогах сервера приложений.
Если после миграции вы не укладываетесь в технологическое окно, необходимо продумать стратегию обмена данными. Как синхронизировать изменения, которые произошли в исходной базе за время миграции? Стандартный подход следующий: вы создаете слепок (бэкап) базы SQL, начинаете мигрировать с этой копии, а с момента создания слепка фиксируете все изменения в продуктивной базе MSSQL.
После завершения миграции тестовой базы (этого быстрого слепка) на PostgreSQL вы применяете зафиксированные изменения из продуктивной MSSQL на новую PostgreSQL-базу. Затем выполняете переключение. Для пользователей этот процесс может быть практически незаметным — перезагрузка занимает около 5 минут, и система продолжает работать в штатном режиме.
Мы исследовали рынок в поисках инструментов для миграции. Проблема актуальна не только для нас или пользователей 1С — аналогичные задачи решают те, кто переходит с Oracle или других СУБД. Существуют альтернативные инструменты для выгрузки и обмена данными, но мы оценили трудозатраты на их настройку для миграции 1С-систем и пока отказались от их использования.
Возможно, мы вернемся к этому вопросу при работе с крупными монолитными системами 1С, но пока такие решения кажутся избыточно трудоемкими. Например, обмены через сторонние инструменты не всегда надежны. В этом плане ibcmd от 1С обеспечивает гарантированную миграцию без сюрпризов.
После миграции важно настроить мониторинг. Необходимо определить критические точки, где падение производительности может негативно сказаться на бизнесе. Для этого подходит APDEX, но также важен тех.журнал. APDEX не покрывает все сценарии — это сложно и не всегда целесообразно, а вот статистика тех.журнала позволяет сохранить историю изменений и оперативно анализировать проблемы.
Тестовый сервер должен быть сопоставим по мощности с продуктивным (либо с тестовым MSSQL-сервером). Сервер приложений желательно использовать тот же или аналогичный.
Тестирование
После подготовки базы наступает этап тестирования. Идеально, если у вас уже есть нагрузочные тесты. Их можно запустить на MSSQL и PostgreSQL, сравнить результаты, выявить просадки и детально изучить причины. В сомнительных случаях мы разрабатываем специализированные нагрузочные тесты, особенно для highload-участков.
Сценарные (дымовые) тесты тоже полезны, но только на полных копиях базы. Например, у нас есть системы, где такие тесты выполняются именно на копиях продуктивных данных. Это помогает выявлять узкие места.
Наш ключевой инструмент — автотестирование на уровне запросов. Мы собираем логи MSSQL, преобразуем их в формат PostgreSQL и выполняем аналогичные запросы в обеих СУБД. Сравниваем время выполнения и анализируем расхождения. Инструмент доступен для скачивания — можете использовать его и участвовать в развитии.
Полезная ссылка: https://github.com/magnit-tech/one-s-questions-ms-on-postgres
Ручное тестирование тоже остается важным инструментом. Например, можно привлечь пользователей для замеров времени выполнения операций (формирование отчетов, проведение документов) на MSSQL и PostgreSQL.
Мигрируем
После тестов и устранения проблем составляем план миграции. Расписываем роли, этапы, временные рамки. Если команда распределенная, важно четко обозначить зоны ответственности. Также готовим скрипты для автоматизации и план отката.
Варианты отката могут быть разными: от простого переключения обратно на MSSQL до полного восстановления данных через ibcmd. В одном из проектов мы ежедневно синхронизировали PostgreSQL с MSSQL, поддерживая актуальность резервной копии.
Перед миграцией отключаем автовакуум и реплики, настраиваем параметры для ускорения загрузки. После миграции возвращаем стандартные настройки и выравниваем их с тестовым окружением, чтобы избежать спецэффектов из-за расхождений в конфигурации.
После перехода пользователи часто связывают любые проблемы с миграцией, даже если их нет. Тех.журнал здесь незаменим: он позволяет показать, что задержки были и раньше (например, сравнить метрики за последние 2 месяца).
После миграции основной базы переносим тестовые окружения и базы разработчиков. В процессе эксплуатации постепенно донастраиваем PostgreSQL (память, воркеры), отслеживая влияние изменений.
Регулярные учения — обязательная практика. Мы тестируем отказоустойчивость, включая отключение серверов, проверку бэкапов и переключение реплик. Все документируется в DR-планах, особенно если команды распределены (администраторы, разработчики, 1С-специалисты).
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
Вступайте в нашу телеграмм-группу Инфостарт
