Я ничего не хочу знать, просто сделайте так, чтобы все работало хорошо.

Обычная постановка задачи от заказчика звучит именно так. Не спешите посылать его в привычное место по всем известной дороге. Сделать так чтобы все работало хорошо - можно, но это не просто и не дешево. Да, да дорогие заказчики, если вы не хотите знать и думать, то кто-то должен сделать это за вас. Некий технический специалист должен вникнуть в вашу ситуацию, найти решение, воплотить его в конкретное аппаратное и програмное обеспечение, в общем должен затратить массу своего времени. Все это время ему нужно как-то жить, кушать, во что-то одеваться, отапливать помещение, платить какие-никакие налоги. Это в Индии или Малазии тепло и не нужно много еды и одежды, да и горячие батареи зимой не вызывают в жителях теплых чувств. И строить там проще - поставил фанерный теремок, провел электричество и живи себе не тужи - погода позволяет, никаких фундаментов погруженных ниже границы промерзания грунта.

Из теплых стран вернемся в наши суровые реалии. Доказано, чтобы все было хорошо - нужен специалист тонко понимающий что и как работает и ему нужно заплатить хорошие деньги. Но это еще не все, нужно прикупить соответствующее оборудование. Потому, что на комплектующих из соседнего магазина или радиорынка надежной серверной инфраструктуры не построишь. С некоторыми оговорками можно построить работоспособное решение, но на проектирование и утрясание возникающих в процессе неожиданностей - уйдет дорогое время специалиста. А в дальнейшем это хозяйство нужно будет обслуживать, разбираться почему не работает или работает не так как ожидалось и не факт, что при росте вы не упретесь в надежный тупик и все придется начинать сначала. При использовании серверных решений HP, DELL, Huawei, Supermicro такие риски значительно ниже.

Итак формула успеха:

НАДЕЖНЫЕ (Аппаратные ресурсы + Программное обеспечение) + МОТИВИРОВАННЫЕ Кадры

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

Начнем с физики, нужно определиться с тремя основными параметрами; процессор, память, дисковая подсистема.

Процессоров нам нужно как минимум два, выбор частоты и количества ядер - процесс творческий и неоднозначный. С одной стороны нужно иметь большую частоту на ядре для того, чтобы висящий на нем rphost имел больше вычислительных ресурсов. С другой - требуется большое количество ядер для распараллеливания большого количества пользовательских процессов на терминальном сервере. Не забывайте про HyperThreading - каждое хипертрединговое полуядро выглядит внутри виртуальной машины (ВМ) как полноценный виртуальный процессор (vCPU). Отключив данную опцию можно получить внутри ВМ более производительные vCPU правда в меньшем количестве - это позволит одному процессу использовать больше вычислительных ресурсов.

Память. Оставим 4Гб на нужды гипервизора. Для MSSQL можно выделить память по размеру БД, это не повредит, но на практике достаточно и половины. Эта рекомендация предполагает, что основная часть БД это данные предыдущих периодов, которые используются редко и нет смысла резервировать память под них. Для 1С сервера потребление памяти очень сильно зависит от размера БД и используемой конфигурации, на практике 50-300 МБ на одно соединение. На терминальном сервере количество потребляемой памяти зависит только от фантазии пользователя. Поэтому, чтобы упростить задачу введем ограничение - пользователю разрешено запускать только один экземпляр 1С, для этого на терминальную сессию потребуется 100-200 Мб.

Дисковая подсистема это всегда узкое место. Для начала нужен RAID контроллер с достаточным количеством кэша защищенного батарейкой. Кэш не только ускоряет доступ к данным, но и меняет входящее и внутреннее соотношение операций чтения/записи. Например, от ОС на контроллер поступает 80% операций записи и 20% операций чтения, а при использовании кэша на дисках это соотношение уже становится 50/50. Понижение количества операций записи (не путать с объемом записываемой информации) позволяет использовать RAID5 вместо дорогого RAID10. Нам понадобится 2 HDD SAS диска в RAID1 для установки гипервизора, 5 SSD SAS дисков в RAID5 для данных 1С и MSSQL и 1 SSD SAS в качестве запасного. Восемь дисков это стандарт для одноюнитовых серверов. Если сервер позволяет разместить 10-12-24 диска, тогда можно использовать RAID10 и предусмотреть отдельные RAID группы для SQL логов и tempdb.

Поскольку 1С, MSSQL, терминал у нас виртуализированы, в дальнейшем можно легко перебрасывать ресурсы с одной ВМ на другую в зависимости от обстоятельств. Главное, чтобы эти ресурсы были на физическом сервере, поэтому не экономьте на спичках и при проектиорвании делайте 20-30% запас.

Итак, есть физический сервер, на нем установлен гипервизор HyperV или VMWare. Созданы две ВМ: 1С+MSSQL и терминальный сервер, если пользователей много можно создать дополнительную ВМ с домен-контроллером.

Заглянем внутрь гостевых ОС. ВМ 1С+MSSQL. Обращаю внимание, что 1С и MSSQL должны быть установлены на одной ВМ, в этом случае возможно использовать механизм обмена shared memory не привлекая стек TCP/IP, что даст заметный прирост производительности. Разносить 1С и MSSQL на разные сервера можно только при наличии серъезных/непреодолимых показаний к этому, например, использование SQL кластера.

Устанавливаем MSSQL с Management Studio. Все файлы SQL размещаем на диске ВМ расположенном на RAID5 группе. Проверяем, что лицензия MSSQL позволяет использовать все vCPU выделенные ВМ (при старте MSSQL сервер пишет в ERRORLOG данные по найденным и лицензированным процессорам). Через MSSQL Configuration Manager настраиваем использование shared memory. Проверяем, что все соединения 1С идут именно через shared memory:

SELECT program_name,net_transport FROM sys.dm_exec_sessions AS t1 LEFT JOIN sys.dm_exec_connections AS t2 ON t1.session_id=t2.session_id WHERE NOT t1.program_name is null

Используя MSSQL Management Studio зададим ограничения на использование памяти MSSQL сервером исходя из расчета памяти который мы делали ранее. Если у нас много ядер (>8) то необходимо изменить еще два параметра сервера: Cost Treshold for Parallelism и Max Degree of Parallelism. Если оставить настройки по умолчанию, то на многопроцессорной системе начнет расти время ожидания Latch. Это отдельная история, планировщик MSSQL может выполнить запрос используя одно ядро/vCPU или распараллеливать его на несколько. При принятии решения используются вышеприведенные параметры. Что же плохого, в выполнении запросов на нескольких ядрах, ведь это сделает нагрузку равномерной? Да, но не во всех случаях. Дело в том, что не все запросы хорошо распараллеливаются, часто встречаются ситуации когда запрос раскинут, например, на 8 ядер, а в результате блокировок выполняется только один поток на одном ядре, остальные потоки на других ядрах находятся в ожидании. Первым признаком этой ситуации являются большие значение Latch (см. Resource Waits в Activity Monitor или sys.dm_os_wait_stats). Cost Treshold определяет стоимость распараллеливания запросов, чем больше значение, тем меньше запросов будет разбиваться на несколько ядер. Точного расчет для параметра не существует, начальное значение 5, практически не пригодно на производительных серверах и унаследовано из далеко прошлого. Потестируйте значения 25-50, посмотрите как изменилась статистика по Latch. Параметр Max Degree определяет на сколько ядер/vCPU будет раскидан запрос после принятия решения о его распараллеливании, на практике используются значения 4-8.

Следующая настройка это отключение хранения транзакционных логов, сделать это можно используя Management Studio изменив параметр БД Recovery Model с Full на Simple. Очень много споров хорошо это или плохо, предоставлю судить вам самим. При модели восстановления = Full все транзакции SQL записываютяс в лог файлы на диске и хранятся там, до момента создания резервной копии. Хранение логов позволяет вам при необходимости вернуться к более ранней копии БД, причем возвращаться можно потранзакционно. В этом случае восстанавливается Full резервная копия и затем можно накатывать логи до нужного вам момента времени (БД можно восстановить практически на любой момент времени). При Simple - транзакционный лог очищается сразу по завершении транзакции и откатится можно только на момент создания резервной копии.

Если физическая конфигурация позволяет создать несколько RAID групп, то очень хорошо будет разнести на независимые группы транзакционные логи и tempdb. Считаем, MSSQL сконфигурированным, в дальнейшем наблюдаем статистику через Management Studio Activity Monitor или счетчики Performance Monitor операционной системы.

Переходим к 1С. В отличие от MSSQL который при наличии Enterprise лицензии умеет сам распределять нагрузку между всеми доступными vCPU 1С сервер не таков. Каждый процесс rphost который непосредственно обслуживает БД 1С работает на одном ядре. И если оставить настройки по умолчанию - то получится следующая ситуация: один rphost обслуживает все соединения и работает на одном vCPU (на одном физическом или что еще хуже хипертрединговом полуядре). Ограничим 1С сервер количеством соединений допустимых на один rphost. Настройка выполняется через MMC консоль 1С сервера, раздел Рабочие серверы - Свойства сервера - Количество соединений на процесс. Если мы зададим количество соединений = 10, то при превышении, каждый раз будет создаваться новый процесс rphost. При 100 соединениях у нас будет 10 rphost, выполняющихся на 10 vCPU.

Конечно, число 10 это просто пример, рассчитать начальное количество соединений можно по формуле:

Количество_соединений_на_процесс = Планируемое_максимальное_количество_соединений / Количество_NUMA_нод

Касательно дисковой подсистемы у 1С тоже есть сюрприз, кроме ожидаемой активной работы с каталогом srvinfo, идет не менее активная запись в каталог временных файлов. Этот каталог нужно вынести на отдельную дисковую группу, в нашем случае на отдельный SSD, который мы выше обозначили как запасной. Если служба 1C:Enterprise 8.3 Server Agent (x86-64) запущена от Local System то нужно изменить системные переменные окружения TMP и TEMP. Это можно сделать в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. Если служба работает от имени пользователя используйте раздел HKEY_USERS\USER_SID\Environment с соответствующим SID.

Просмотреть SID для пользователя можно в реестре HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList или командой wmic useraccount get name,sid или через powershell команду Get-WmiObject win32_useraccount.

Терминальный сервер. Ограничим пользователей запуском при входе в систему 1С клиента. Если у вас есть домен, то все просто, в свойствах учетной записи Active Directory, на закладке Environment указываем требуемую строку запуска. В этом случае при входе пользователя будет запускаться указанная программа, а по ее завершению, сеанс пользователя будет завершаться. Но не всегда все проходит гладко. Операционная система терминального сервера принимает решение о завершении пользовательского сеанса при условии, что от имени пользователя запущен только список процессов указанный в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcs. Если клиент 1С завершил работу, но какой-либо порожденный им процесс не перечисленный в вышеуказанном разделе реестра не завершен, то сеанс пользователя будет считаться активным. Со стороны пользователя это будет выглядеть в виде черного экрана. Если на терминальном сервере стоит ограничение на создание только одного сеанса на пользователя, то при повторном подключении пользователь будет попадать в свой незавершенный черный сеанс и работать не сможет. Частой причиной такого поведения является печать из 32 битного приложения на 64 битном сервере. При этом печающий процесс порождает дочерний процесс splwow64.exe который завершается не сразу после окончания печати, а имеет таймаут 3 минуты. Для решения проблемы, как вы уже поняли, добавляем в раздел реестра DWORD параметр с названием splwow64.exe и значением 0.

Нужно помнить, что RCM начиная с Windows Server 2016 по умолчанию не обращается к домен-контроллеру и ничего не знает про аттрибут UserParameters в котором хранится строка запуска программы. Чтобы RCM стал вести себя привычным образом нужно добавить параметр REG_DWORD с именем fQueryUserConfigFromDC и значением 1 в следующие разделы реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp

Если у вас нет домена - ситуация усложняется. Вам нужно написать маленькую программку, которая будет запускаться при входе пользователя в систему, стартовать 1С клиент, отслеживать его наличие в памяти и завершать сеанс пользователя при его завершении. Запускать программу можно через параметр реестра Shell расположенный в разделе HKEY_USERS\USER_SID\Software\Microsoft\Windows NT\CurrentVersion\Winlogon.

На этом позвольте откланяться. Комментарии и вопросы приветствуются, равно как и материальная помощь проекту.