Перенос критически важных бизнес-систем, таких как связка «1С:Предприятие» и MS SQL Server, со старого перегруженного оборудования на новый производительный сервер — это классическая задача для системного администратора. Ситуация усложняется, когда текущее окружение представляет собой так называемую «файлопомойку», где на одном физическом хосте развернуты сервер 1С, СУБД, служба терминалов (RDP) и множество сопутствующих программных продуктов. В этой статье мы подробно разберем, как правильно спланировать миграцию, оптимизировать настройки оборудования, операционной системы и СУБД для достижения максимального быстродействия.
При планировании миграции ключевым вопросом является распределение ролей между серверами. Рассмотрим архитектуру исходной системы: у нас есть старый сервер (Supermicro, 128 Гб RAM, старые процессоры Xeon E5) и новый мощный сервер (SuperServer, 96 Гб RAM, быстрые процессоры Xeon Gold 6144 и производительный массив SAS SSD в RAID 10).
Основная рекомендация для высоконагруженных систем — совместное размещение СУБД MS SQL Server и сервера приложений 1С:Предприятие на одном физическом хосте. Проанализируем, почему такое решение является оптимальным:
Выясним важную деталь: если пользователи работают в режиме толстого клиента (например, в конфигурации «Управление производственным предприятием» — УПП), архитектурные требования существенно ужесточаются. В отличие от тонкого клиента, где основная логика выполняется на сервере приложений, толстый клиент выполняет большую часть кода на стороне пользователя (в данном случае — в его терминальной сессии на RDP-сервере).
Толстый клиент активно обменивается с базой данных огромными объемами нефильтрованных данных. Если мы разнесем сервер терминалов (RDP) и MS SQL Server на разные физические серверы, между ними возникнет колоссальный сетевой трафик. При работе 80–100 активных пользователей стандартный сетевой стык в 1 Гбит/с гарантированно станет узким местом системы («бутылочным горлышком»).
Решение проблемы: Если разделение ролей неизбежно, необходимо организовать между сервером RDP и сервером СУБД выделенный сетевой канал пропускной способностью не менее 10 Гбит/с. Если такой возможности нет, наиболее эффективным решением будет размещение терминального сервера и SQL-сервера на одном мощном физическом хосте.
Желание запустить все службы на виртуальных машинах (под управлением Hyper-V или VMware ESXi) вполне понятно — это удобно для резервного копирования и администрирования. Однако для высоконагруженных систем 1С виртуализация несет в себе серьезные риски снижения производительности. Проанализируем основные факторы влияния гипервизора на работу систем:
Настройка параметров параллелизма в MS SQL Server — один из главных факторов стабильности работы 1С. Посмотрим на примере, к чему приводит неправильная конфигурация. Если параллелизм включен по умолчанию, то один тяжелый или некорректный пользовательский запрос (например, построение сложного отчета или перерасчет себестоимости) может захватить все доступные ядра процессора. В результате остальные 80 пользователей столкнутся с полной блокировкой системы.
Рассмотрим традиционную рекомендацию 1С: установить параметр Max Degree of Parallelism (MAXDOP) равным 1. Это полностью отключает параллельное выполнение запросов, заставляя каждый запрос обрабатываться строго на одном процессорном ядре.
Однако жесткое ограничение MAXDOP = 1 имеет обратную сторону — тяжелые регламентные операции (ночные расчеты, закрытие месяца) будут выполняться медленнее. Разберем более гибкий профессиональный подход:
Для настройки параметров выполним следующий скрипт в среде СУБД:
USE master;
GO
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
EXEC sp_configure 'max degree of parallelism', 1;
GO
EXEC sp_configure 'cost threshold for parallelism', 50;
RECONFIGURE;
GO
Новый сервер укомплектован высокопроизводительными SAS SSD дисками HGST Ultrastar в массиве RAID 10 под управлением контроллера Adaptec. Чтобы выжать максимум из этой дисковой подсистемы, выполним следующие действия:
tempdb является самым нагруженным местом в системах 1С. Разобьем её на несколько файлов данных одинакового размера. Оптимальное количество файлов — 1 файл на каждый логический процессор (ядро), но не более 8 файлов на один NUMA-узел. Все файлы должны иметь фиксированный и одинаковый шаг авторасширения (например, по 512 МБ), чтобы SQL Server распределял нагрузку равномерно по алгоритму Round-Robin..mdf) и файлы журналов транзакций (.ldf) по разным разделам. Запись в журнал транзакций всегда идет последовательно, в то время как чтение данных базы носит хаотичный характер. Разделение очередей на логическом уровне позволяет снизить время ожидания транзакций (ожидания типа WRITELOG).Современные многоядерные процессоры (такие как Xeon Gold) по умолчанию используют агрессивные технологии энергосбережения. При резком поступлении короткого запроса от 1С процессор физически не успевает выйти из глубокого режима сна и поднять тактовую частоту ядра до максимума (Turbo Boost). Это приводит к микросекундным задержкам, которые в сумме вызывают сильное замедление интерфейса («тупит 1С»).
Для устранения этой проблемы выполним шаги по настройке электропитания:
powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c
Перенос систем на новое оборудование всегда сопряжен с рисками потери лицензий. Программные лицензии 1С жестко привязываются к уникальным характеристикам сервера: UUID материнской платы, процессору, сетевой карте, размеру оперативной памяти и версии ОС. Любое изменение этих параметров (или миграция виртуальной машины на другой хост) мгновенно деактивирует лицензию.
Как минимизировать риски: Для стабильной работы в виртуальных средах рекомендуется использовать выделенный сервер лицензирования 1С (небольшая виртуальная машина, параметры которой никогда не меняются) либо использовать аппаратные USB-ключи защиты.
Отдельно отметим опасность использования нелегальных (взломанных) платформ 1С. Начиная с версий 8.3.15 и новее, разработчики внедрили асинхронные фоновые проверки целостности кода. Измененные библиотеки могут успешно пройти тесты при запуске, но при достижении высокой пользовательской нагрузки (80–100 пользователей) сервер аварийно завершит работу с ошибкой целостности системы, что приведет к полной остановке бизнес-процессов.