← На главную

При настройке серверной инфраструктуры для 1С:Предприятия часто возникает дилемма: оставить всё на "голом железе" или использовать виртуализацию. В нашей ситуации мы имеем мощный двухпроцессорный сервер (2 x Intel Gold 6154, итого 36 ядер и 256 Гб ОЗУ) и задачу максимально эффективно распределить эти ресурсы между виртуальными машинами 1С и MSSQL под управлением Hyper-V. Рассмотрим подробнее, как избежать деградации производительности и учесть аппаратные особенности оборудования.

Анализируем целесообразность виртуализации

Первым делом проанализируем ситуацию с разделением ролей. Размещение 1С и SQL на разных виртуальных машинах (ВМ) дает удобство администрирования и бэкапирования, но лишает нас главного преимущества — использования протокола Shared Memory. Когда оба сервера находятся в одной ОС, они обмениваются данными через общую память практически мгновенно. В случае с разными ВМ обмен идет через виртуальный коммутатор по протоколу TCP/IP, что вносит задержку (Latency) от 5% до 15%.

Если решение о виртуализации принято, выясним причину возможных тормозов и постараемся их минимизировать. Для этого на виртуальных сетевых адаптерах обязательно включим режим VMMQ (Virtual Machine Multi-Queue), чтобы распределить обработку сетевого трафика по разным ядрам процессора.

Распределение процессорных ядер и учет лицензии 1С:Проф

Разберем по шагам настройку процессоров. Важно помнить, что лицензия «1С:Предприятие 8.3 ПРОФ» имеет техническое ограничение: один рабочий процесс rphost может использовать не более 12 ядер процессора. Если мы выделим виртуальной машине 24 ядра, один процесс 1С всё равно будет задействовать только половину из них.

Посмотрим на пример оптимального распределения для наших процессоров (по 18 ядер каждый):

1. Для ВМ с сервером 1С: Выделим ровно 12 физических ядер. Это позволит серверу 1С работать максимально эффективно в рамках одного рабочего процесса без лишних переключений контекста.
2. Для ВМ с MSSQL: Отдадим оставшиеся ядра (например, 18-20 ядер). SQL Server отлично масштабируется и умеет эффективно использовать большое количество потоков.
3. Оставим резерв: Обязательно зарезервируем 2-4 ядра для работы самой хостовой операционной системы (Hyper-V), чтобы исключить зависания при высокой нагрузке на виртуальные машины.

Оптимизация оперативной памяти и архитектура NUMA

Теперь проанализируем ситуацию с оперативной памятью. Наш сервер имеет 256 Гб ОЗУ, распределенных по 128 Гб на каждый физический процессор. Это называется архитектурой NUMA (Non-Uniform Memory Access). Если виртуальная машина попытается забрать 192 Гб, гипервизор будет вынужден брать часть памяти из соседнего сокета, что резко снизит скорость доступа к ней.

Рассмотрим рекомендации по настройке ОЗУ:

• Используйте только Static Memory: Для MSSQL категорически запрещено использовать динамическую память. SQL Server захватывает кэш (Buffer Pool) при старте, и попытки гипервизора "откусить" память обратно приведут к критическим тормозам.
• Соблюдайте границы сокета: Постарайтесь выделить серверу 1С около 100-110 Гб, а серверу SQL — аналогичный объем, чтобы каждая ВМ работала в рамках своего локального NUMA-узла (своего процессора).
• Настройка Max Server Memory: Внутри SQL Server обязательно ограничим аппетит базы данных. Оставим ОС внутри виртуалки минимум 4-8 Гб свободными, иначе система начнет уходить в Swap.

Тонкая настройка SQL Server и ОС

Чтобы выжать максимум, разберем по шагам дополнительные настройки внутри гостевых ОС:

1. Lock Pages in Memory (LPIM): В локальной политике безопасности сервера SQL предоставим учетной записи службы SQL право на "Блокировку страниц в памяти". Это предотвратит сброс кэша SQL в файл подкачки Windows.
2. Электропитание: Как на физическом хосте в BIOS, так и внутри виртуальных машин установим план "Высокая производительность" (High Performance). Выясним причину: парковка ядер (Core Parking) и снижение частоты процессора в моменты простоя создают микро-задержки, которые крайне чувствительны для пользователей 1С.
3. C-States: В BIOS физического сервера отключим режимы энергосбережения процессора (C-States, Intel SpeedStep), чтобы обеспечить стабильную частоту ядер под нагрузкой.

Настройка дисковой подсистемы

Даже на корпоративных SSD RAID 1 дисковая очередь может стать "бутылочным горлышком". Проанализируем ситуацию с виртуальными дисками:

Для Hyper-V всегда используйте диски типа Fixed Size (фиксированного размера). Динамические диски VHDX расширяются "на лету", что создает дополнительные задержки при интенсивной записи логов транзакций SQL (файлы .ldf).

Если есть возможность, внутри виртуальной машины SQL разнесем файлы данных и логи на разные виртуальные диски. Это позволит Windows и гипервизору более эффективно обрабатывать очереди запросов к дисковой подсистеме.

Резюме по распределению ресурсов

Подведем итог нашей совместной работы. Оптимальная конфигурация для данного "железа" будет выглядеть так:

• ВМ 1С: 12 ядер, 110 Гб статической памяти, фиксированный VHDX.
• ВМ SQL: 18-22 ядер, 120 Гб статической памяти, настройка Max Server Memory на уровне 110 Гб, включение LPIM.
• Хост: Оставшиеся ресурсы для нужд гипервизора, отключение всех функций энергосбережения.

Такой подход обеспечит максимальную стабильность и позволит 1С:Предприятию использовать всю мощь процессоров Intel Gold без лишних накладных расходов на виртуализацию.