Как настроить сеть при разделении серверов 1С и SQL на разные физические машины?

← На главную

Разделение ролей сервера приложений 1С:Предприятие и сервера баз данных SQL Server на разные физические машины — это стандартный шаг при масштабировании системы. Однако такой переход несет в себе как преимущества, так и скрытые риски. Рассмотрим подробно, как правильно организовать сетевое взаимодействие между серверами, чтобы не потерять в производительности и выиграть в безопасности.

Анализ перехода: Shared Memory против TCP/IP

Когда 1С и SQL работают на одном сервере, они обмениваются данными через протокол Shared Memory (общая память). Это самый быстрый способ, так как данные не покидают пределов оперативной памяти. При разносе серверов на разные физические узлы обмен будет происходить по протоколу TCP/IP. Проанализируем ситуацию: даже самая быстрая сеть 10 Гбит/с будет медленнее, чем шина памяти. Наша задача — максимально минимизировать эти задержки (latency).

Организация выделенного канала Point-to-Point

Рассмотрим вариант создания прямой связи между серверами через выделенные сетевые карты. Это позволит изолировать «тяжелый» трафик обмена между 1С и SQL от общего трафика локальной сети и запросов клиентов.

Выбор оборудования: Для обеспечения максимальной пропускной способности и минимальных задержек используем сетевые адаптеры со скоростью 10 Гбит/с. Как показывает практика, карты на чипах Intel (например, серия X500) имеют хорошую поддержку драйверов в Windows Server 2019/2022/2025.
Физическое подключение: Соединяем серверы напрямую патч-кордом категории 6a или 7 (для меди) или через SFP+ модули (для оптики). Это и есть схема Point-to-Point.
Настройка IP-адресации: Выделяем для этого канала отдельную подсеть, которая не пересекается с основной локальной сетью. Например:
- Сервер 1С (вторая карта): 192.168.10.1, маска 255.255.255.252
- Сервер SQL (вторая карта): 192.168.10.2, маска 255.255.255.252

Тонкая настройка сетевых параметров

Чтобы 10-гигабитный канал работал эффективно, выполним ряд настроек в операционной системе. Разберем по шагам:

1. Настройка Jumbo Frames (9000 MTU):

Стандартный размер пакета 1500 байт заставляет процессор тратить много ресурсов на обработку огромного количества мелких пакетов. Увеличив MTU до 9000, мы снизим нагрузку на CPU. Это критично для серверов 1С, где процессоры и так нагружены бизнес-логикой. Настройку необходимо выполнить на обоих серверах в свойствах сетевого адаптера.

2. Использование файла hosts для жесткой привязки:

Выясним причину, почему трафик может продолжать идти через медленную 1 Гбит/с сеть. Если в консоли администрирования 1С указано имя сервера SQL, Windows может разрешить его через DNS в IP-адрес основной сети. Чтобы гарантировать использование 10 Гбит/с канала, пропишем соответствие в файле C:\Windows\System32\drivers\etc\hosts на сервере 1С:

192.168.10.2 SQL-SERVER-NAME

Где SQL-SERVER-NAME — сетевое имя вашего нового сервера SQL.

3. Настройка RSS (Receive Side Scaling):

Убедимся, что на сетевых картах включена функция RSS. Она позволяет распределять обработку входящих сетевых пакетов между всеми ядрами процессора. Без этого один поток обмена с SQL может «упереться» в производительность одного ядра CPU.

Вопросы безопасности: Закрытый контур

Разберем ситуацию с безопасностью данных. Разделение сетей создает дополнительный барьер:

Изоляция SQL-сервера: Сервер БД больше не обязан иметь доступ к общей локальной сети. Он общается только с сервером 1С по выделенному кабелю.
Защита от шифровальщиков: Если злоумышленник или вирус-шифровальщик получит доступ к рабочей станции пользователя, он не сможет «увидеть» SQL-сервер напрямую, так как тот находится в другой подсети, доступной только для сервера приложений.
Порты: На внутреннем интерфейсе SQL-сервера можно оставить открытым только порт 1433 (TCP), закрыв все остальные запросы извне.

Риски устаревшего оборудования

Проанализируем состояние «старого» сервера 1С на чипсете X299. Даже если мы перенесем SQL на новую мощную машину, сервер 1С остается критическим звеном. Сервер 1С активно использует дисковую подсистему для хранения временных файлов сеансов и кэша метаданных. Если SSD на старой машине начинают «отваливаться», это приведет к падению рабочих процессов rphost и аварийному завершению работы всех пользователей. Рассмотрим рекомендации по выживанию:

Замена дисков: Если планируется оставить сервер 1С на старом железе, необходимо в первую очередь заменить нестабильные SSD на надежные накопители (желательно Enterprise-класса).
Мониторинг памяти: Сервер 1С версии 8.3 крайне требователен к памяти, особенно при работе с маркировкой (Честный Знак). Освободившиеся после переноса SQL 128 Гб памяти — это хороший ресурс, но следите за утечками памяти в коде конфигураций.

Преимущества новых версий (Windows Server 2025 и SQL 2022)

Посмотрим на пример использования современного ПО. Переход на SQL Server 2022 дает 1С дополнительные инструменты оптимизации:

Query Store: Позволяет быстрее находить проблемные запросы, которые стали тормозить после разделения серверов (дополнительно можно проанализировать SQL сервер глазами 1С-ника).
Intelligent Query Processing: Автоматически корректирует планы выполнения запросов, что частично нивелирует задержки, а для стабильности стоит внедрить адаптивное обновление индексов.
Windows Server 2025: Имеет более совершенный стек работы с сетью и NVMe, что делает связку с SQL 2022 максимально производительной.

Итоговые рекомендации по внедрению

Рассмотрим краткий план действий:

Устанавливаем в оба сервера сетевые карты 10 Гбит/с.
Настраиваем между ними отдельную подсеть и включаем Jumbo Frames.
В консоли 1С при создании информационной базы указываем IP-адрес SQL-сервера из «быстрой» подсети (192.168.10.2), а для наблюдения за системой используем монитор кластеров серверов.
На старом сервере 1С обязательно проверяем состояние дисков (полезно оценить размер таблицы SQL базы 1С), так как без стабильного кэша никакая быстрая сеть не спасет от тормозов.
Если бюджет позволяет, в ближайшем будущем планируем перенос сервера 1С на ту же физическую машину, где стоит SQL (совместное использование ресурсов нового сервера обычно эффективнее, чем поддержка старого «железа»).