Подбор серверного оборудования для задач 1С — это всегда компромисс между бюджетом компании, требованиями к отказоустойчивости и производительностью. Ситуация, когда на одном физическом сервере приходится совмещать роли СУБД (SQL), сервера приложений 1С и терминального сервера (RDP) для 20 пользователей, является стандартной для малого и среднего бизнеса. Рассмотрим подробнее, как спроектировать производительный и надежный сервер, избежав классических ошибок при выборе процессоров, дисковой системы и операционной среды.
При проектировании сервера под 1С системные администраторы часто совершают классическую ошибку: выбирают дорогие многоядерные процессоры серверных линеек высокой плотности, такие как Xeon Gold 6234. Проанализируем технические характеристики и выясним причину, почему это решение не является оптимальным для 20 пользователей.
Для платформы 1С ключевым фактором быстродействия является однопоточная производительность процессора (тактовая частота одного ядра). Это связано с тем, что большинство критических бизнес-операций в 1С (проведение документов, проведение последовательностей, закрытие месяца) выполняются последовательно в один поток. Если ядро работает медленно, то даже при наличии 20 свободных ядер пользователи будут постоянно жаловаться на «зависание» интерфейса.
Сравним показатели производительности процессоров в тесте Гилёва:
Разберем экономику решения. Процессор семейства Xeon E стоит значительно дешевле, материнские платы под него доступнее, а скорость работы интерфейса 1С для конечного пользователя будет практически в два раза выше по сравнению с тяжеловесным Xeon Gold.
При обновлении серверного парка у администраторов часто возникает соблазн перенести старое настроенное окружение — в частности, операционную систему Windows Server 2008 R2. Делать этого категорически нельзя.
Рассмотрим основные проблемы, с которыми вы гарантированно столкнетесь при попытке установить старую ОС на современный сервер:
Для современного оборудования строго обязателен переход на актуальные версии операционных систем — Windows Server 2019 или Windows Server 2022.
Переход с механических дисков (SAS/SATA HDD) на твердотельные накопители (SSD) — это ключевой шаг, который радикально ускоряет работу СУБД. Однако в связке «аппаратный RAID-контроллер + SSD» кроется серьезная опасность.
Рассмотрим работу классического контроллера (например, LSI 9361-8i) с твердотельными дисками SATA SSD (например, Intel S4610). Главная проблема заключается в том, что большинство классических аппаратных RAID-контроллеров при объединении дисков в массивы RAID 1 или RAID 10 блокируют прохождение команды TRIM (UNMAP) от операционной системы к накопителям.
Без поддержки команды TRIM контроллер самого SSD не знает, какие блоки данных были удалены операционной системой. В результате ячейки памяти своевременно не очищаются. По мере заполнения диска и интенсивной записи логов SQL производительность массива начинает деградировать. Скорость случайной записи может упасть в несколько раз, а износ накопителей увеличится.
Какое решение будет правильным? Современный стандарт для баз данных — это использование высокоскоростных накопителей NVMe (PCIe) вместо SATA SSD. Разберем преимущества:
Для создания отказоустойчивых массивов из NVMe-дисков классические RAID-контроллеры не требуются. Зеркалирование (RAID 1) настраивается либо программно средствами операционной системы (динамические диски Windows или Storage Spaces), либо с помощью специализированной технологии Intel VROC (Virtual RAID on CPU), которая работает на уровне процессора и шины PCIe, сохраняя полную поддержку TRIM.
Если бюджет компании жестко ограничен и сервер действительно будет один, то запускать СУБД, сервер 1С и терминальные сессии пользователей на «голом железе» (bare metal) в рамках одной ОС крайне не рекомендуется. Терминальные пользователи запускают веб-браузеры, офисные пакеты, тяжелые отчеты, которые могут монополизировать процессорное время и оперативную память, вызывая микрофризы и сбои в работе SQL-сервера.
Рекомендуем развернуть на физическом сервере систему виртуализации (гипервизор), например, бесплатный Proxmox VE или встроенную роль Hyper-V в Windows Server. Внутри гипервизора необходимо создать минимум две изолированные виртуальные машины:
Виртуальная машина №1: СУБД + Сервер 1С.
Выделите под нее фиксированный объем оперативной памяти и закрепите за ней приоритетные ядра процессора. Настройте ограничение выделения памяти для MS SQL Server, чтобы СУБД не забрала все ресурсы операционной системы виртуальной машины. Для этого выполним в SQL Server Management Studio следующий скрипт:
-- Ограничение максимальной памяти для SQL Server до 48 Гб
EXEC sys.sp_configure N'show advanced options', N'1' RECONFIGURE WITH OVERRIDE;
GO
EXEC sys.sp_configure N'max server memory (MB)', N'49152' RECONFIGURE WITH OVERRIDE;
GO
Так как СУБД и сервер приложений 1С находятся внутри одной операционной системы, настройте их взаимодействие через протокол Shared Memory (общая память) вместо сетевого протокола TCP/IP. Это позволит сократить задержки при обмене данными между 1С и SQL на 15–20%.
Виртуальная машина №2: Терминальный сервер (RDP).
В этой машине будут работать пользователи. Преимущество такой схемы очевидно: даже если пользователь умудрится запустить вредоносный софт или вирус-шифровщик, пострадает только терминальное окружение. База данных, находящаяся в изолированной виртуальной машине №1, останется в безопасности. Кроме того, делать резервные копии (снапшоты) изолированных виртуальных машин «на лету» значительно проще и быстрее, что гарантирует быстрое восстановление работоспособности офиса в случае любых программных сбоев.