← На главную

В современной корпоративной среде часто возникает необходимость распределения нагрузки между несколькими серверами баз данных. Рассмотрим ситуацию, когда у нас имеется один сервер приложений 1С:Предприятие и два независимых сервера баз данных — SQL10 и SQL20, физически расположенных на разных машинах. Наша задача — разобраться, как правильно сконфигурировать информационные базы, чтобы одна из них физически располагалась на первом SQL-сервере, а другая — на втором.

Понятие «Сервер баз данных» в консоли управления 1С

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

Проанализируем ситуацию: сервер приложений 1С является лишь посредником. Когда мы указываем имя в поле «Сервер баз данных», мы даем команду кластеру 1С, куда именно ему следует направлять запросы T-SQL. Это имя не имеет отношения к именам рабочих серверов в составе кластера 1С. Таким образом, для реализации нашей задачи мы должны:

1. При создании первой базы в поле «Сервер баз данных» указать сетевое имя или IP-адрес SQL10.
2. При создании второй базы в аналогичном поле указать SQL20.

Важно понимать: кластеру 1С абсолютно не важно, сколько серверов SQL вы используете. Вы можете распределить десятки баз по десяткам разных SQL-серверов, и все они будут администрироваться из единой консоли 1С.

Настройка подключения при использовании именованных экземпляров и нестандартных портов

Рассмотрим более сложный технический нюанс. Что делать, если на сервере SQL20 развернуто несколько экземпляров SQL Server (Named Instances) или сервер настроен на работу через нестандартный порт (отличный от 1433)?

В таких случаях простого указания имени сервера в консоли 1С будет недостаточно. Разберем по шагам, как правильно прописать путь:

• Если используется именованный экземпляр, формат записи будет следующим: ИмяСервера\ИмяЭкземпляра (например, SQL20\MSSQLSERVER2).
• Если SQL-сервер работает на специфическом TCP-порту, следует использовать запятую: ИмяСервера,Порт (например, SQL20,1543).

Это критически важно, так как 1С:Предприятие использует драйверы SQL Native Client или Microsoft OLE DB Driver for SQL Server для связи, и они должны четко понимать точку входа в сетевую службу SQL.

Обеспечение взаимодействия: Драйверы и протоколы

Посмотрим на ситуацию со стороны сервера приложений 1С. Чтобы он мог успешно «общаться» с двумя разными серверами SQL, на нем должны быть установлены соответствующие компоненты доступа к данным. Если один ваш сервер (SQL10) старой версии (например, SQL 2012), а второй (SQL20) — современной (SQL 2022), необходимо убедиться, что установленный на сервере 1С драйвер MSOLEDBSQL поддерживает обе версии.

Проанализируем вопрос сетевых протоколов. Поскольку сервер 1С и серверы SQL находятся на разных физических машинах, протокол Shared Memory (самый быстрый) работать не будет. Взаимодействие будет осуществляться исключительно по протоколу TCP/IP. Рекомендуется проверить в SQL Server Configuration Manager, что данный протокол включен на обоих серверах баз данных и разрешен в настройках брандмауэра (Firewall).

Права доступа и безопасность

Разберем вопрос авторизации. В консоли 1С при создании базы вы указываете «Пользователя базы данных» и его пароль. Рассмотрим два варианта:

1. SQL Server Authentication: Это наиболее простой и рекомендуемый способ для распределенных систем. Вы создаете пользователя (Login) непосредственно на каждом SQL-сервере (SQL10 и SQL20) и даете ему права db_creator и processadmin (или роль sysadmin для автоматического создания базы из 1С).
2. Windows Authentication: В этом случае служба 1С (обычно ragent) должна быть запущена от имени доменной учетной записи, которая имеет соответствующие права на обоих удаленных SQL-серверах.

Проблема миграции данных и бэкапов между версиями SQL

Часто при работе с разными серверами SQL возникает необходимость переноса баз между ними. Разберем «пикантный нюанс», упомянутый в обсуждении: бэкапы, сделанные в более новой версии SQL Server, не могут быть восстановлены на более старой версии.

Выясним причину этого ограничения. Формат файла .bak жестко привязан к версии ядра SQL Server. При восстановлении база проходит процесс апгрейда внутренней структуры, но процесс «даунгрейда» (понижения версии) технически не предусмотрен Microsoft.

Важное уточнение: Изменение уровня совместимости (Compatibility Level) в свойствах базы данных не меняет формат файла бэкапа. Эта настройка влияет только на работу оптимизатора запросов и синтаксис T-SQL, но не позволяет развернуть бэкап с SQL 2022 на SQL 2016.

Если вам все же нужно перенести базу с нового SQL20 на старый SQL10, рассмотрим доступные методы:

• Выгрузка в формат .dt: Универсальный способ 1С. Мы делаем выгрузку информационной базы в конфигураторе на новом сервере и загружаем её в пустую базу, созданную на старом сервере. Внимание: для баз объемом в несколько терабайт этот метод может быть крайне медленным или нестабильным.
• Схемы импорта-экспорта: Использование SQL Server Import and Export Wizard для переноса данных между таблицами напрямую.
• Скриптование: Генерация T-SQL скриптов на создание структуры и данных (подходит только для очень маленьких справочников или настроечных баз).

Сетевые задержки и производительность

Поскольку мы разносим сервер приложений и серверы баз данных, необходимо проанализировать влияние сетевой инфраструктуры. 1С:Предприятие крайне чувствительно к показателю Latency (задержка пакетов). Даже при наличии канала в 10 Гбит/с, высокий пинг между 1С и SQL20 приведет к тому, что формы будут открываться медленно, а проведение документов затянется.

Рекомендуем придерживаться следующих правил:

• Сервер 1С и оба сервера SQL должны находиться в одном сегменте сети (в одной стойке или одном коммутаторе).
• Задержка (ping) должна быть менее 1 мс.
• Использование виртуализации требует настройки резервирования ресурсов (CPU и RAM), чтобы исключить «замирания» сервера SQL, которые 1С воспримет как разрыв соединения.

Итоги настройки

Мы выяснили, что архитектура 1С позволяет гибко управлять размещением данных. Имя сервера 1С или имя кластера не привязано к имени SQL-сервера. Вы можете создавать неограниченное количество информационных баз на разных экземплярах SQL, просто указывая их сетевые реквизиты в поле Сервер баз данных при добавлении базы в список кластера.

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