← На главную

В современных высоконагруженных системах на базе 1С:Предприятие 8.3 вопросы отказоустойчивости и производительности СУБД выходят на первый план. Технология MS SQL Always On Availability Groups является одним из наиболее мощных инструментов для решения этих задач. В этой статье мы подробно разберем, как интегрировать 1С с фермой MS SQL, какие существуют ограничения по распределению нагрузки и как правильно настроить среду для стабильной работы.

Основы технологии Always On в контексте 1С

Для начала проанализируем, что представляет собой Always On. Это решение для обеспечения высокой доступности и аварийного восстановления, которое пришло на смену классическому зеркалированию (Mirroring). В отличие от обычного кластера (Failover Cluster Instance), где используется общее хранилище, Always On позволяет иметь копии базы данных на разных серверах с собственными дисковыми подсистемами. Для 1С это означает, что даже при полном выходе из строя одного сервера базы данных, система продолжит работу на другом узле.

Рассмотрим ключевой момент: распределение нагрузки. Стандартно в Always On существует одна первичная реплика (Primary), доступная на чтение и запись, и несколько вторичных реплик (Secondary). Разберем ситуацию с записью объектов, которая часто волнует разработчиков. В рамках архитектуры SQL Server распределить запись на несколько серверов в одной группе доступности невозможно — транзакции всегда фиксируются сначала на первичной ноде.

Настройка подключения 1С через Availability Group Listener

Выясним, как заставить платформу 1С корректно работать с кластером. Для этого используется механизм Listener (прослушиватель) — виртуальное имя и IP-адрес, которые всегда указывают на текущую активную ноду.

Посмотрим на шаги по настройке подключения:

1. В консоли администрирования кластера 1С при создании или редактировании информационной базы в поле "Сервер баз данных" мы указываем не имя физического сервера SQL, а именно DNS-имя Listener.
2. Это позволяет платформе 1С не "знать" о том, какой именно сервер сейчас является основным. При переключении ролей (Failover) SQL Server сам перебросит виртуальный IP на новую первичную реплику.
3. Важно учитывать параметр MultiSubnetFailover. Если ваши узлы SQL находятся в разных подсетях (например, в разных дата-центрах), необходимо обеспечить поддержку этого параметра драйвером на сервере 1С.

Проанализируем технический нюанс: без активации MultiSubnetFailover=True в строке подключения, время переключения на резервный узел может составлять несколько минут, что приведет к массовому отвалу пользовательских сессий 1С. Хотя в консоли 1С нет отдельной галочки для этого параметра, он настраивается на уровне системных параметров ODBC или через дополнительные настройки драйвера SQL Server Native Client.

Проблема распределения нагрузки на чтение (Read-Only Routing)

Рассмотрим ситуацию, когда мы хотим разгрузить основной сервер, перенаправив тяжелые отчеты на вторичные реплики. В SQL Server для этого существует механизм Read-Only Routing.

Однако здесь мы сталкиваемся с архитектурной особенностью платформы 1С. Проблема заключается в том, что 1С:Предприятие устанавливает одно соединение с СУБД и использует его как для записи данных, так и для чтения. Платформа не передает в SQL-запросе признак ApplicationIntent=ReadOnly, который необходим серверу SQL, чтобы понять: "этот запрос можно отправить на вторичную реплику".

Таким образом, стандартными средствами 1С и MS SQL реализовать автоматическое распределение нагрузки (чтение — на одну ноду, запись — на другую) "из коробки" не получится. Все запросы будут уходить на первичную ноду.

Использование сторонних драйверов и прокси-решений

Если задача распределения чтения стоит остро, разберем альтернативные подходы, упоминаемые экспертами. Одним из решений является использование специализированного промежуточного ПО, например, разработок компании SoftPoint.

Суть метода заключается в следующем:

• Вместо стандартного драйвера OLE DB или Native Client используется модифицированный драйвер.
• Этот драйвер анализирует SQL-трафик, исходящий от сервера приложений 1С.
• Если драйвер видит команду SELECT, которая не требует блокировок первичной базы, он прозрачно для платформы перенаправляет этот запрос на вторичную реплику Always On.
• Команды INSERT, UPDATE, DELETE всегда уходят на Primary-ноду.

Такой подход позволяет существенно масштабировать систему, но он вносит дополнительные риски, такие как Replication Lag (задержка репликации). Выясним причину: данные на вторичную реплику попадают с небольшой задержкой. В 1С это может привести к ситуации, когда пользователь создал документ, нажал "Записать", тут же открыл отчет, а документа там еще нет, так как отчет прочитался со вторичной ноды, куда данные еще не "долетели".

Синхронный и асинхронный режимы фиксации

При настройке Always On для 1С крайне важно выбрать правильный режим фиксации транзакций. Разберем два варианта:

1. Синхронный режим (Synchronous-commit): Первичный сервер ждет подтверждения от вторичного о записи лога на диск.
   Плюс: Гарантия отсутствия потери данных при аварии.
   Минус: Увеличение времени отклика (Latency). Любая запись в 1С будет тормозить, если канал между серверами SQL медленный.
2. Асинхронный режим (Asynchronous-commit): Первичный сервер не ждет подтверждения.
   Плюс: Максимальная производительность, сопоставимая с одиночным сервером.
   Минус: Риск потери последних транзакций при сбое. Для 1С это может означать логическую деформацию базы, если часть связанных таблиц обновилась, а часть — нет.

Для критически важных систем 1С рекомендуется использовать синхронный режим, но только при наличии высокоскоростной сети (10 Гбит/с и выше) с минимальными задержками (latency менее 1 мс) между узлами кластера.

Обслуживание и регламентные задания

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

Во-первых, транзакционный лог базы 1С не будет очищаться (truncate) до тех пор, пока все записи не будут доставлены на все вторичные реплики. Если одна из нод "отвалится" или связь с ней пропадет, лог на основном сервере начнет стремительно расти, что может привести к полной остановке работы 1С из-за нехватки места на диске. Необходимо настроить мониторинг состояния synchronization_state.

Во-вторых, операции перестроения индексов генерируют огромный объем записей в логе транзакций. Этот объем должен быть передан по сети на все реплики. Рассмотрим пример: если база 1С весит 1 ТБ и вы решили перестроить индексы, приготовьтесь к тому, что по сети будет передано сопоставимое количество данных. Это может парализовать работу пользователей из-за загрузки канала связи.

Юридические и лицензионные аспекты

Проанализируем так называемый "65 пункт" лицензионного соглашения 1С. Он ограничивает использование средств, модифицирующих стандартный протокол взаимодействия платформы и СУБД. При использовании официальных механизмов MS SQL Always On для целей отказоустойчивости (через Listener) никаких нарушений нет — это стандартный режим работы, поддерживаемый фирмой "1С".

Однако при внедрении решений по распределению чтения через сторонние драйверы (как в случае с SoftPoint), стоит внимательно изучить актуальную позицию вендора, так как это может трактоваться как обход штатного механизма работы платформы. Тем не менее, для крупных корпоративных систем такие решения часто являются единственным способом достичь требуемой производительности.

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

Подводя итог, можно сказать, что связка 1С 8.3 и MS SQL Always On — это отличное решение для обеспечения High Availability.

Основные выводы для успешного внедрения:

• Используйте Listener для подключения 1С.
• Тщательно выбирайте между синхронным режимом (для надежности) и асинхронным (для скорости).
• Помните, что стандартная 1С не умеет разделять чтение и запись сама по себе.
• Контролируйте размер лога транзакций и состояние репликации, чтобы избежать внезапной остановки системы.

Соблюдение этих правил позволит создать надежную и масштабируемую инфраструктуру для автоматизации вашего бизнеса.