← На главную

При администрировании серверной инфраструктуры 1С:Предприятия нередко возникает потребность снизить нагрузку на текущее оборудование или оптимизировать затраты на лицензирование. В такой ситуации системные администраторы часто рассматривают добавление второго сервера СУБД другого типа — например, бесплатного PostgreSQL к уже работающему коммерческому Microsoft SQL Server. Разберем детально, как платформа 1С поддерживает одновременную работу с разными типами СУБД, какие архитектурные ограничения накладывает выбор операционной системы и с какими трудностями можно столкнуться при практической реализации такой схемы.

Архитектурный принцип работы кластера 1С с несколькими СУБД

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

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

1. Тип СУБД: выбирается конкретная СУБД из поддерживаемого списка (например, MS SQL Server, PostgreSQL, IBM DB2, Oracle Database).
2. Сервер баз данных: сетевое имя или IP-адрес хоста, на котором развернута выбранная СУБД.
3. Имя базы данных: имя базы в рамках указанного сервера СУБД.
4. Пользователь и пароль: учетные данные для авторизации процессов кластера 1С на сервере СУБД.

Таким образом, кластер серверов 1С может без каких-либо конфликтов обслуживать часть информационных баз на MS SQL Server, а другую часть — на PostgreSQL. Все рабочие процессы кластера (rphost) взаимодействуют с соответствующей СУБД через стандартные клиентские библиотеки.

Однако важно помнить о ключевом архитектурном правиле: одну информационную базу нельзя распределить («размазать») по двум разным СУБД. Таблицы одной и той же информационной базы всегда целиком располагаются внутри одного сервера управления базами данных. Добавление второго сервера СУБД позволяет разгрузить инфраструктуру исключительно за счет физического переноса отдельных баз (например, баз разработки, тестирования, архивных или вспомогательных конфигураций) на новую площадку.

Ограничения операционных систем: Windows и Linux

Возможность совместной работы с разнородными СУБД напрямую зависит от того, под управлением какой операционной системы запущен сам кластер серверов 1С:Предприятия.

Проанализируем доступные связки операционных систем и СУБД:

1. Сервер 1С на ОС Windows: универсальный вариант. Рабочие серверы 1С под управлением Windows поддерживают работу со всеми доступными СУБД, включая MS SQL Server и PostgreSQL. При этом сам сервер PostgreSQL может быть развернут как на Windows, так и на Linux. В такой конфигурации никаких архитектурных ограничений нет.
2. Сервер 1С на ОС Linux: имеет строгие платформенные ограничения. В силу архитектуры и отсутствия официальных механизмов взаимодействия рабочих серверов 1С под Linux с Microsoft SQL Server, рабочий сервер 1С под Linux не может взаимодействовать с СУБД MS SQL Server. Если рабочий процесс кластера 1С запущен на Linux, он способен работать только с PostgreSQL, IBM DB2 или Oracle. Кроме того, на серверах под Linux не поддерживается прямое взаимодействие с технологией COM-соединений, а аутентификация пользователей строится по протоколу Kerberos.

Следовательно, если планируется сохранить рабочую базу на MS SQL Server и добавить базы на PostgreSQL, то основной сервер приложений 1С обязан оставаться под управлением операционной системы Windows.

Специфика развертывания PostgreSQL для 1С

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

1. Специализированная сборка СУБД: стандартная («ванильная») сборка PostgreSQL из репозиториев Linux или с официального сайта не подходит для полноценной работы с 1С. Фирма «1С» выпускает специализированные патчи, которые оптимизируют регистронезависимое сравнение строк, специфические агрегаты, работу с временными таблицами и многопоточные блокировки. Необходимо использовать дистрибутивы СУБД, адаптированные для 1С (от самой фирмы «1С» или профильных вендоров, например Postgres Pro 1C).
2. Выбор ОС для PostgreSQL: распространено заблуждение, что PostgreSQL не может работать под Windows. Это не так: дистрибутивы PostgreSQL для 1С успешно собираются и функционируют под ОС Windows. Однако на высоконагруженных продуктивных базах инсталляция под Linux традиционно обеспечивает меньшие накладные расходы на дисковые операции и выделение памяти. Если в штате нет компетентного Linux-администратора, развертывание PostgreSQL на Windows является вполне рабочим компромиссом.
3. Регламентное обслуживание: принципы сопровождения MS SQL и PostgreSQL кардинально различаются. В PostgreSQL используется версионная модель транзакций (MVCC), поэтому критически важно грамотно сконфигурировать фоновые процессы autovacuum, регулярно проводить актуализацию статистик (ANALYZE) и перестроение индексов (REINDEX). Без правильной настройки таблицы базы данных начинают раздуваться, а оптимизатор запросов СУБД начинает строить неоптимальные планы выполнения.

Перенос данных между разными СУБД

Прямой перенос файлов баз данных (дампов на уровне СУБД) между MS SQL и PostgreSQL технически невозможен из-за принципиальной разницы форматов хранения данных и внутреннего устройства таблиц.

Рассмотрим способы миграции информационных баз с MS SQL на PostgreSQL:

1. Выгрузка и загрузка файла информационной базы (.dt): штатный инструмент, запускаемый через конфигуратор (меню «Администрирование» — «Выгрузить информационную базу...»). Это наиболее простой способ для баз малого и среднего объема (до 10–20 ГБ). Для крупных баз этот метод часто оказывается неприменимым из-за нехватки оперативной памяти при формировании архива или превышения внутренних лимитов формата .dt.
2. Выгрузка и загрузка данных в формате XML: универсальная обработка ВыгрузкаЗагрузкаДанныхXML, которая выгружает все объекты метаданных и их табличные части по частям, позволяя перенести информацию между идентичными конфигурациями любого размера.
3. Механизмы распределенных информационных баз (РИБ): развертывание узла РИБ на новой СУБД с полной синхронизацией данных и последующим отсоединением базы от главного узла вызовом функции ПланыОбмена.УстановитьГлавныйУзел(Неопределено).

Сетевые задержки и нагрузка на хост 1С

Разберем еще один критически важный аспект при подключении второго сервера СУБД — сетевую инфраструктуру и нагрузку на сервер приложений.

Объем сетевого трафика между процессами сервера 1С (rphost) и сервером СУБД в десятки раз превышает трафик между клиентом 1С и кластером серверов. При выносе PostgreSQL на отдельный физический компьютер обязательно необходимо обеспечить сетевое соединение с минимальным временем отклика (ping менее 1 мс) и пропускной способностью не ниже 1 Гбит/с (рекомендуется 10 Гбит/с).

Также важно понимать: если производительность системы страдает из-за нехватки вычислительных ресурсов (процессора и оперативной памяти) на самом сервере 1С:Предприятия, то появление второй СУБД не решит проблему. Нагрузка на сервер приложений останется прежней либо даже возрастет из-за параллельного взаимодействия с двумя различными драйверами СУБД.

Итоги и рекомендации

Совместное использование MS SQL Server и PostgreSQL в рамках одного кластера 1С — полностью штатная и поддерживаемая платформой конфигурация при соблюдении следующих условий:

1. Сервер приложений 1С:Предприятия должен быть установлен на операционной системе Windows, чтобы сохранить возможность работы с MS SQL Server.
2. Каждая отдельная информационная база целиком привязана только к одному серверу СУБД.
3. Для PostgreSQL используется специализированный дистрибутив с патчами от 1С.
4. Инфраструктура имеет низкие сетевые задержки между хостом 1С и обоими серверами СУБД.
5. Администратор готов сопровождать две принципиально разные платформы управления базами данных с различными методиками резервного копирования и оптимизации.