Переезд с файловой КА 1.1 на КА 2 под Linux и PostgreSQL: по шагам, с граблями и цифрами

На файловой 1С:КА 1.1 мы начали работать примерно в 2009 году, после Excel. К переходу на КА 2 готовились с 2018-го, а в начале 2019 года запустили КА 2.4; позже перешли на 2.5. База клиент-серверная, на PostgreSQL, сервер и рабочие места — на Linux.

Описываемая установка: Debian, платформа 8.3.27.1719, PostgreSQL 16, база около 200 ГБ, 10 пользователей, в часы пик до 15, и 2 ТСД. До выделенного сервера 1С пять лет работала в виртуальной машине на CentOS 7. Ниже я отдельно разбираю исторические замеры 2024 года.

Сразу о масштабе: это опыт небольшой компании без ИТ-отдела, и железо у нас не самое новое. В компании покрупнее многое разумно делать иначе.

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

Самая неожиданная цифра — в шаге 3. Новый сервер на чистом железе из коробки показал на тесте Гилёва 9,86 — меньше, чем 1С в виртуалке на нём же. После настройки процессора в BIOS — 29,24.

Содержание

Шаг 1. Когда переезжать: с начала года и остатками

Шаг 2. Перенос данных: типовая обработка, дописанная под себя

Шаг 3. Сервер: подобрать железо и проверять каждое изменение замером

Шаг 4. 1С под Linux: пять вещей, которые придётся решить

Шаг 5. Рабочие места: от терминального сервера к клиентам 1С на Linux

Шаг 6. Резервные копии, реплика и тестовый стенд

Шаг 7. Обновления: не ради обновления и только через стенд

Что бы я сделал иначе

Чек-лист переезда

Шаг 1. Когда переезжать: с начала года и остатками

С начала 2018 года мы готовились и тестировали, а с начала 2019-го начали работать в КА 2.4. В новую базу документами ввода начальных остатков перенесли все остатки и расчёты на 31 декабря 2018 года.

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

Документы прошлых лет оставили в КА 1.1. Перенос всей истории между по-разному устроенными конфигурациями потребовал бы отдельной сверки, а для наших задач хватало доступа к старой базе. В новой проверяли входящие остатки: сальдо по счетам, товары и материалы на складах, взаиморасчёты.

Шаг 2. Перенос данных: типовая обработка, дописанная под себя

Сначала мы протестировали типовую обработку перехода с КА 1.1 на КА 2, потом дописали её под свои задачи. Главная из них — CRM.

Когда-то мы перевели работу с клиентами из Excel в КА 1.1, и там накопилась вся история продаж, звонков и клиентов. Потерять её было нельзя.

Перенос и сверка остатков заняли пару дней: был конец года, учёт вёлся ровно. Доработка обработки у подрядчика заняла около недели, и то в основном из-за его загрузки.

Порядок, который я бы советовал:

• Составьте список того, без чего в новой базе нельзя работать с первого дня.

• На копии проверьте, что из этого переносит типовая обработка, и сверьте остатки с оборотно-сальдовой ведомостью старой базы.

• Для данных, которые типовая обработка не переносит, подготовьте доработку. У нас подрядчик добавил перенос истории CRM.

• Определите, какую историю можно оставить в старой базе, и сохраните к ней доступ.

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

Шаг 3. Сервер: подобрать железо и проверять каждое изменение замером

Пять лет сервер 1С и PostgreSQL работал в виртуальной машине на CentOS 7. Это был не идеал, и мы это понимали, но на тот момент решение было нормальным и экономически оправданным. В августе 2024 года мы переехали на выделенный сервер под Debian.

Конфигурация сервера в описываемой установке: 2 × Xeon E5-2643 v2 — по 6 ядер, 3,5 ГГц, в турбо до 3,8 ГГц. Всего 12 ядер; Hyper-Threading выключен. Память позже нарастили с 64 до 128 ГБ. Диски: NVMe на 2 ТБ, два RAID-тома на дисках 15 000 об/мин — 512 и 750 ГБ — и том на 2 ТБ на дисках 7 200 об/мин. База и WAL размещены на NVMe, резервные копии — на HDD. Замеры, которые разбираю ниже, сделаны до установки NVMe.

$ lscpu
Model name: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz
Thread(s) per core: 1
Core(s) per socket: 6
Socket(s): 2
CPU max MHz: 3800,0000
CPU min MHz: 1200,0000
NUMA node(s): 2

$ free -h
total used free shared buff/cache available
Mem: 125Gi 44Gi 15Gi 37Mi 67Gi 81Gi

Процессоры 2013 года, зато с высокой частотой ядра — это было важно для нашего выбора. Но выбирать сервер для любой базы только по частоте я бы не стал: нужно учитывать конкретные операции и одновременную работу пользователей. Здесь описано железо под нашу нагрузку.

Изменения проверял однопоточным синтетическим тестом Гилёва TPC. Он удобен для сравнения настроек, но время проведения документов и работу нескольких пользователей нужно измерять отдельно. Новый сервер сначала проверял как хост виртуальной машины с 1С, затем — без виртуализации. В шести замерах ниже 1С и PostgreSQL находились на одной машине; замеры были локальными, без сетевого клиента.

Это последовательность наших настроек. В ней нет одинакового набора условий для всех шести строк.

Рисунок 1. Результаты TPC при разных конфигурациях, август — ноябрь 2024 года

На чистом железе сервер из коробки показал 9,86 — меньше, чем 1С в виртуалке на нём же. Ничего ещё не было настроено, и были включены снапшоты LVM.

После этапа настройки BIOS результат вырос с 9,86 до 29,24 — примерно втрое за один вечер. Следующая запись, после настройки PostgreSQL, — 30,86. В ноябре получили 31,06, примерно на 6,2% выше августовских 29,24. Но к этому времени менялись и настройки CPU, и платформа: в августе была 8.3.23, в ноябре — 8.3.25. Последний прирост нельзя целиком отнести к одному параметру. Во всех случаях речь о баллах теста, а не о таком же ускорении каждой операции в 1С.

Что меняли в BIOS: профиль питания, C-states, турбо-режим и Hyper-Threading — его выключили. Точные значения подбирали по замерам. Ниже — параметры нашего исторического стенда, а не готовый профиль для любого сервера:

• Профиль питания в BIOS сервера: режим максимальной производительности вместо энергосбережения.

• В Linux проверяли регулятор частоты процессора и режим performance. Набор доступных режимов зависит от процессора и драйвера, поэтому готовой команды для любого сервера здесь нет.

В виртуальной машине использовали модель процессора хоста — host-passthrough. Одновременно добавили память, и результат вырос с 15,67 до 20,16. Этот замер показывает совместный результат двух изменений. При выборе host-passthrough нужно учитывать будущий перенос виртуальной машины: документация libvirt предупреждает о риске при различиях оборудования, версий QEMU, микрокода и настроек хостов.

Правила замеров, которые я для себя вынес:

• Меняйте одну вещь за раз. postgresql.conf я правил постепенно и после каждой правки гонял тест.

• Различайте режимы работы. На одной виртуальной машине файловый вариант получил 58,14, клиент-серверный — 21,93. Файловый вариант оказался быстрее именно в этом однопоточном тесте. Для выбора режима нашей рабочей базы нужно учитывать одновременную работу десяти пользователей.

• Сеть — тоже режим. Старый рабочий сервер, замеренный по сети с терминального сервера, давал 12,05.

• Делайте несколько прогонов в одинаковых условиях. В записях для виртуальной машины есть 22,94 за декабрь 2023 года и 15,67 за август 2024-го. Это разные даты, а не серия повторов одного эксперимента; по ним нельзя оценить устойчивость результата после одной настройки.

На сохранённом экране вместе с TPC 29,24 виден отдельный дисковый тест G1C. Его поле «Максимальная скорость на 1 поток» показывает 88 175 КБ/с. Этот замер также выполнен до установки NVMe.

Рисунок 2. TPC 29,24 после этапа настройки BIOS

Шаг 4. 1С под Linux: пять вещей, которые придётся решить

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

1. Принтеры и МФУ. Пробросить их вместе со сканированием через SANE на виртуальный сервер — ещё та история. Выручило то, что я заранее понимал, какие МФУ покупать под такой стек, и они у нас уже стояли. Драйвер под Linux есть не у каждой модели, так что проверьте весь парк до переезда.

2. Системные библиотеки. Требования к ОС и зависимостям нужно сверять для конкретного релиза платформы. Один только выбор знакомого дистрибутива этого не заменяет. CentOS Linux 7, на котором работала наша прежняя виртуальная машина, достиг конца поддержки 30 июня 2024 года.

3. Активация программных лицензий. У нас использовались программные лицензии. Смена параметров компьютера или виртуальной машины может потребовать повторной активации; перед переносом нужно сохранить сведения о лицензии и предусмотренные для неё резервные пин-коды. Для аппаратного ключа отдельно проверяют, как он будет доступен 1С в выбранной схеме.

У нас была и более частная проблема: активация завершалась сообщением «Сбор информации о компьютере для привязки лицензии выполняется длительное время». В самом окне 1С было пояснение: долгим может оказаться поиск сетевых ключей защиты; если они не используются, их поиск можно запретить в nethasp.ini.

В нашем случае помог этот фрагмент nethasp.ini. Он относится к поиску сетевых HASP-ключей, а не к сетевому доступу 1С вообще. Если от таких ключей зависит выдача лицензий, отключать поиск нельзя. Параметры секции описаны в руководстве администратора 1С 8.3.27, приложение 3, раздел 3.25.2.

[NH_COMMON]
NH_IPX = Disabled
NH_NETBIOS = Disabled
NH_TCPIP = Disabled

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

5. Производительность. Её разобрал в шаге 3: после настройки примерно втрое вырос результат синтетического теста. Для оценки рабочих операций нужны отдельные замеры.

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

Шаг 5. Рабочие места: от терминального сервера к клиентам 1С на Linux

Сначала пользователи работали через терминальный сервер на x2go в домене FreeIPA. Позже мы отказались от терминальной схемы: клиент 1С стал запускаться прямо на рабочих местах.

С терминала ушли по нескольким причинам:

• убрали отдельный терминальный сервис, который требовал настройки и сопровождения;

• упростили работу с носителями ключей: на локальном компьютере им не нужен доступ через терминальную сессию;

• снизили нагрузку на основной сервер.

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

На рабочих местах стоит наш собственный образ: Debian, KDE Plasma, LibreOffice вместо Excel. Большинство сотрудников пришли из Windows и Excel, и незнакомый интерфейс их пугал. Сначала учили, потом собрали образ с настройками окружения, внешне близкими к привычным, — и адаптация пошла быстро.

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

Шаг 6. Резервные копии, реплика и тестовый стенд

Резервное копирование у нас на своих скриптах: базовая копия и архив журналов WAL для PITR. Восстановление на выбранный момент требует подходящей базовой копии и непрерывной цепочки WAL до этого момента. Реплика работает на другой площадке.

Реплика повторит и ошибочное удаление из рабочей базы. Поэтому для возврата к состоянию до ошибки нам нужны сохранённые резервные данные для PITR.

Аварийного восстановления рабочей системы у нас пока не было. Восстановление копий проверяем на тестовом стенде.

Стенд — отдельная виртуальная машина. Каждую ночь около 01:00 на ней восстанавливается копия рабочей базы; это занимает около часа. Утром на вчерашних данных проверяем обновления и доработки. Час относится к восстановлению базы на готовом стенде; время возвращения всех сервисов после аварии мы так не измеряли.

Рисунок 3. Обновления рабочей базы после проверки на тестовом стенде

С рабочей базы сохраняются резервные данные для PITR, отдельно работает реплика. Из копии восстанавливаем стенд. После проверки обновления повторяем в рабочей базе; рабочие документы, введённые на стенде при тестировании, обратно не переносим.

Шаг 7. Обновления: не ради обновления и только через стенд

Я не обновляю платформу только ради нового номера версии. Причинами служат исправления безопасности и ошибок, нужные функции и совместимость. При этом приходится следить за поддержкой используемых версий и требованиями конфигурации. В августе 2024 года на новом сервере была платформа 8.3.23, в ноябре — 8.3.25; описываемая позднейшая установка работает на 8.3.27.1719.

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

На стенде проверяем ОСВ, остатки на складах и работу ключевых компонентов и расширений. Цикл от выхода релиза до рабочей базы — в среднем неделя.

Этот порядок нас уже спас. Когда проверили переход на КА 2.5, увидели на стенде, что изменения типовых механизмов нарушают нашу давальческую схему. Переход отложили на полгода и за это время вместе с подрядчиком подготовили собственное расширение. Эта история входит в парный материал о производственном учёте.

Что бы я сделал иначе

Главный урок для меня — подбирать сервер под рабочие задачи и сразу проверять настройки на нём. Цифры без условий замера легко создают неверное представление о результате.

Виртуалка на CentOS 7 была для своего времени разумным решением. Старый сервер на тесте Гилёва давал 12,05, а новый после настройки — 31,06, но режимы замера различались: прежний тест шёл по сети, новый — локально. По этим двум значениям нельзя надёжно оценить выигрыш от замены сервера.

Чек-лист переезда

• Выберите дату перехода и состав данных. Нам было удобно начать год с остатков, сохранив документы прошлых лет в старой базе. Историю CRM перенесли с доработкой типовой обработки.

• Подбирайте сервер под свои операции и одновременную нагрузку. В нашем проекте использовали 2 × E5-2643 v2 на 3,5 ГГц; это описание исторической конфигурации, а не рекомендация покупать её сегодня.

• Сначала зафиксируйте исходный результат, затем проверяйте изменения BIOS в сопоставимых условиях. На нашем стенде после настройки баллы теста выросли с 9,86 до 29,24.

• Настройку CPU виртуальной машины выбирайте с учётом нагрузки и требований к её переносу. Изменение CPU и добавление памяти проверяйте отдельно.

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

• Сверяйте поддержку ОС и зависимостей с выбранным релизом 1С. Наш исторический CentOS Linux 7 уже завершил жизненный цикл; позднее мы выбрали Debian.

• Принтеры, МФУ и токены проверьте до переезда, каждую модель, а технику покупайте под стек.

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

• PITR, реплика на другой площадке и регулярное восстановление на тестовом стенде.

• Проверяйте обновления на стенде и планируйте их с учётом поддержки, безопасности и требований учёта.

• Перед покупкой отраслевого решения проверьте, что оно работает на Linux и PostgreSQL.

Какой замер при настройке 1С оказался для вас самым неожиданным? Если поделитесь результатом в комментариях, укажите режим базы, откуда запускали тест и что меняли — так будет проще сравнить опыт.