Рассмотрим весьма популярную, но полную скрытых нюансов ситуацию: системный администратор планирует развернуть чистый физический сервер под нужды службы сервера 1С:Предприятие на операционной системе Linux. При этом сами базы данных (СУБД) располагаются на выделенных серверах под управлением Windows (в наличии имеются как Microsoft SQL Server, так и PostgreSQL под Windows). Давайте подробно проанализируем, работоспособна ли подобная схема, с какими жесткими ограничениями придется столкнуться, как ведет себя производительность в различных конфигурациях и как правильно настроить сопутствующие службы вроде КриптоПро.
Разберем главный и самый критичный нюанс этой схемы. В процессе обсуждения системные администраторы часто упускают из виду базовые принципы многоплатформенности 1С. Сервер 1С:Предприятие, запущенный на операционной системе Linux, принципиально не может работать с СУБД MS SQL Server в качестве основной базы данных системы.
Выясним причину этого ограничения. Технологическая платформа 1С для Linux физически не содержит в своем составе программного кода (компиляторов запросов и драйверов связи), способного напрямую транслировать вызовы к MS SQL Server. Данная связка не поддерживается разработчиками 1С на уровне ядра платформы. Если ваша СУБД работает на MS SQL, то и рабочий сервер 1С обязан функционировать исключительно под управлением ОС Windows.
Однако существует важное исключение. Работа сервера 1С на Linux с MS SQL возможна только для механизмов внешних источников данных (когда из кода 1С требуется подключиться к сторонней таблице на MS SQL для чтения или записи данных). Для реализации такого подключения на Linux-сервере настраивается связка через UnixODBC и FreeTDS. Посмотрим, как выглядит пример конфигурации файлов для организации подобного доступа.
Для начала отредактируем конфигурационный файл freetds.conf, чтобы указать параметры подключения к удаленному серверу MS SQL:
[MSSQLServer]
host = 192.168.1.50
port = 1433
tds version = 7.4
client charset = UTF-8
Затем настроим системный файл драйверов ODBC odbcinst.ini:
[FreeTDS]
Description = FreeTDS Driver
Driver = /usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so
Setup = /usr/lib/x86_64-linux-gnu/odbc/libtdsS.so
FileUsage = 1
И, наконец, пропишем само системное имя источника данных (DSN) в файле odbc.ini:
[MSSQL_1C_External]
Driver = FreeTDS
Description = Connection to MS SQL External Source
Servername = MSSQLServer
Database = ExternalDataDB
Помните, что данный метод предназначен исключительно для интеграции и обмена данными, но не позволит вам развернуть саму информационную базу 1С на Linux-сервере с использованием MS SQL.
Проанализируем производительность систем при переходе на Linux. Здесь важно разделять работу самого сервера приложений 1С и работу СУБД.
Сам сервер 1С (процессы rphost, rmngr) при переносе на Linux работает как минимум не медленнее, чем на Windows. Начиная с версий платформы 1С:Предприятие 8.3.20 и выше, разработчики уделили огромное внимание оптимизации платформы под облачные решения (1С:Фреш). В условиях высокой многопоточной нагрузки сервер 1С под Linux демонстрирует отличное распределение процессорного времени и более эффективную работу с оперативной памятью.
Shared Memory (общая память). На Linux обмен данными между процессами 1С и PostgreSQL чаще всего происходит через локальные сокеты (TCP Loopback), что добавляет микроскопические накладные расходы на сетевой стек ядра.Теперь рассмотрим работу СУБД PostgreSQL под управлением Windows и Linux. Запуск СУБД PostgreSQL на операционной системе Windows крайне не рекомендуется для высоконагруженных систем. Выясним причину этой архитектурной проблемы.
СУБД PostgreSQL исторически проектировалась под Unix-подобные операционные системы и использует процессную модель работы (системный вызов fork()). При каждом новом клиентском подключении СУБД создает отдельный процесс. В Linux создание процессов реализовано на уровне ядра как чрезвычайно «дешевая» и быстрая операция.
В Windows создание полноценного процесса является крайне тяжелой операцией, так как ОС изначально проектировалась под потоковую модель (threads). Для работы на Windows PostgreSQL вынужден эмулировать поведение Unix-процессов через специальные API-библиотеки, что создает огромный оверхед (избыточную нагрузку) на процессоры и дисковую подсистему при частых подключениях и отключениях пользователей. Поэтому, если вы выбираете PostgreSQL в качестве СУБД для 1С, она обязательно должна работать под управлением Linux.
Разберем современные технологические решения, которые предлагают разработчики отечественных СУБД (в частности, Postgres Pro) для максимального ускорения систем на базе 1С. Эти технологии позволяют обойти многие исторические ограничения PostgreSQL по сравнению с MS SQL Server.
Технология Join Predicate Pushdown: Это уникальная оптимизация планировщика запросов. Конфигурации 1С (особенно тяжелые ERP, КА и УПП) при построении отчетов генерируют сложнейшие SQL-запросы с большим количеством вложенных соединений и подзапросов. Данный механизм умеет «проталкивать» условия фильтрации из внешнего запроса глубоко внутрь вложенных подзапросов еще на этапе формирования плана выполнения. Это снижает объем обрабатываемых данных в оперативной памяти и ускоряет выполнение сложных отчетов в 2–3 раза.
Временные таблицы на репликах (Hot Standby): Исторически архитектура платформы 1С не позволяла распределять нагрузку на чтение отчетов на резервные сервера-реплики СУБД. Причина заключалась в том, что любой отчет в 1С создает в процессе работы временные таблицы (запись данных), а реплика СУБД доступна строго в режиме «только для чтения». В специализированных редакциях Postgres Pro Enterprise реализован механизм, позволяющий создавать и изменять временные таблицы непосредственно на сервере-реплике, находящемся в режиме Hot Standby. Это дает возможность полностью перенаправить тяжелые аналитические отсчеты на дополнительный сервер, разгрузив основную СУБД.
Автонастройка (Autotune): Современные дистрибутивы СУБД при установке автоматически определяют объем установленной на сервере оперативной памяти, количество ядер процессора и тип дисковой подсистемы (SSD/NVMe). Утилита автотюнинга самостоятельно рассчитывает и прописывает в конфигурационном файле оптимальные параметры работы с памятью, такие как shared_buffers, work_mem и maintenance_work_mem, исключая человеческий фактор при ручной настройке.
Рассмотрим практический аспект, с которым сталкивается каждый администратор при переносе сервера 1С на Linux — работу с шифрованием, сдачей отчетности и электронным документооборотом (ЭДО) через КриптоПро. Современные версии КриптоПро CSP действительно обзавелись удобной графической утилитой cptools, однако для работы сервера 1С этого недостаточно.
Посмотрим на ситуацию изнутри. Служба сервера 1С на Linux функционирует в контексте безопасности специального системного пользователя usr1cv8 (или аналогичного, в зависимости от дистрибутива). У этого пользователя нет доступа к графической оболочке (GUI) и терминальному сеансу администратора. Если вы установите сертификаты через графическую утилиту под учетной записью администратора (например, root), сервер 1С их просто не увидит.
Разберем по шагам правильный алгоритм установки ключей шифрования для 1С на сервере Linux:
Шаг 1. Предоставим права на чтение контейнера закрытого ключа. По умолчанию контейнеры КриптоПро создаются с жесткими ограничениями прав. Нам необходимо перенести контейнер в каталог КриптоПро и назначить владельцем пользователя сервера 1С:
chown -R usr1cv8:grp1cv8 /var/opt/cprocsp/keys/usr1cv8/
chmod -R 700 /var/opt/cprocsp/keys/usr1cv8/
Шаг 2. Выполним импорт сертификата непосредственно в персональное хранилище пользователя usr1cv8. Для этого необходимо запустить консольную утилиту КриптоПро certmgr от имени пользователя, под которым запущена служба 1С:
su -s /bin/bash - usr1cv8 -c "/opt/cprocsp/bin/amd64/certmgr -inst -file /tmp/company_signature.cer -store uMy"
Шаг 3. Проверим успешность установки сертификата в контексте пользователя 1С, выполнив команду просмотра хранилища:
su -s /bin/bash - usr1cv8 -c "/opt/cprocsp/bin/amd64/certmgr -list"
Только после выполнения этих шагов в консольном режиме службы ЭДО и отчетности в 1С смогут корректно подписывать документы закрытым ключом на сервере под управлением Linux.
Подведем итоги нашего детального разбора и сформируем понятную матрицу принятия решений для системного администратора.
Выбирайте связку Windows Server + MS SQL Server, если:
Выбирайте связку Linux + PostgreSQL (Postgres Pro), если: