1с виртуальная машина sql настройки
Я ничего не хочу знать, просто сделайте так, чтобы все работало хорошо.
Обычная постановка задачи от заказчика звучит именно так. Не спешите посылать его в привычное место по всем известной дороге. Сделать так чтобы все работало хорошо - можно, но это не просто и не дешево. Да, да дорогие заказчики, если вы не хотите знать и думать, то кто-то должен сделать это за вас. Некий технический специалист должен вникнуть в вашу ситуацию, найти решение, воплотить его в конкретное аппаратное и програмное обеспечение, в общем должен затратить массу своего времени. Все это время ему нужно как-то жить, кушать, во что-то одеваться, отапливать помещение, платить какие-никакие налоги. Это в Индии или Малазии тепло и не нужно много еды и одежды, да и горячие батареи зимой не вызывают в жителях теплых чувств. И строить там проще - поставил фанерный теремок, провел электричество и живи себе не тужи - погода позволяет, никаких фундаментов погруженных ниже границы промерзания грунта.
Из теплых стран вернемся в наши суровые реалии. Доказано, чтобы все было хорошо - нужен специалист тонко понимающий что и как работает и ему нужно заплатить хорошие деньги. Но это еще не все, нужно прикупить соответствующее оборудование. Потому, что на комплектующих из соседнего магазина или радиорынка надежной серверной инфраструктуры не построишь. С некоторыми оговорками можно построить работоспособное решение, но на проектирование и утрясание возникающих в процессе неожиданностей - уйдет дорогое время специалиста. А в дальнейшем это хозяйство нужно будет обслуживать, разбираться почему не работает или работает не так как ожидалось и не факт, что при росте вы не упретесь в надежный тупик и все придется начинать сначала. При использовании серверных решений 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.
На этом позвольте откланяться. Комментарии и вопросы приветствуются, равно как и материальная помощь проекту.
· в рамках виртуальной машины можно работать с устаревшими программными решениями и операционными системами;
Как раз мой случай. Можно использовать имеющиеся в наличие лицензии на Win2003 сервер, который просто не встает на многие современные контроллеры жестких дисков.
· возможность создать защищенные пользовательские окружения для работы с сетью, в этом случае вирусные атаки могут нанести вред операционной системе, а не виртуальной машине;
· несколько виртуальных машин, развернутых на физических ресурсах одного компьютера, изолированы друг от друга, таким образом, сбой одной из виртуальных машин не повлияет на доступность и работоспособность сервисов и приложений других;
Тоже полезная вещь для 1С. Разнести сервер приложений 1С и сервер SQLпо разным виртуальным машинам и выделив каждой по 4ГБ оперативки (предел для 32 разрядной Win32) позволит хоть немного бороться с бичом 32 разрядных систем –фрагментацией оперативной памяти при выполнение больших запросов.
Крайне не рекомендую использовать 32 разрядные системы с большими конфигурациями типа УПП. В какой-то момент вы просто не сможете обновить конфигурации без перезагрузки сервера 1С. В какой-то момент не поможет и перезагрузка. В нашем случае мы пока экономим деньги, а потом можно будет легко создать другую ВМ с 64 разрядной системой и перенести все на нее почти не прерывая работы.
· поскольку каждая виртуальная машина представляет собой программный контейнер, то она может быть перенесена или скопирована, как и любой иной файл;
Полезная вещь, когда надо быстро перенести систему на другой сервер.
· возможность сохранения состояния виртуальной машины позволяет быстро вернуться к точке до внесения изменений в систему;
· в рамках одной гостевой операционной системы может быть развернуто несколько виртуальных машин, объединенных в сеть и взаимодействующих между собой;
· виртуальные машины могут создавать представления устройств, которых физически нет (эмуляция устройств).
Из недостатков – вполне предсказуемое некоторое снижение скорости работы. Но намного менее существенное, чем при использовании бесплатных SQLсерверов.
Железо для сервера:
Процессор intel-corei3-4130 (4 ядра)
Материнская плата GA-Z87M-HD3 (с поддержкой RAID)
2 жестких диска по 1GB (sata).
8 ГБ ОЗУ.
Итак, этапы создания:
Я отступил от рекомендуемой схемы и не стал делать отдельный раздел для HOSTOSи для данных. Это вызвано тем, что мне не удалось создать файл виртульной машины в подмонтируемой области. К сожалению мне будет сложнее переставить ОС и не затронуть данные.
Я выделил на SWAP 10 GB (чуть больше ОЗУ), остальное создал один большой раздел EXT4.
6. Сразу после загрузки меняем графический интерфейс на старый добрый гном. Иначе после установки VirtualBoxпропадут все менюшки из интерфейса и вы останетесь с красивым но пустым экраном. Подробные инструкции
Эти драйвера позвляют использовать нормальное разрешение экрана из GUESTсистемы, что очень важно для дальнейшей установки и работы. Драйвер можно найти в дистрибутиве, но проще скачать из интернета.
11. Меняя подмонтированные ISOили из файлов дистрибутивов устанавливаем Сервер 1С, ServerSQL,настраиваем терминальный сервер. Действия ничем не отличаются от настройки невиртуальной системы.
Порт 3389 – порт Терминального сервера
1540,1541,1560-1561 -порты 1С
1433,1434,1954 SQLсервер (необязательно)
При размещении 1С в облачной инфраструктуре и среде виртуализации наиболее важными и непростыми задачами являются повышение скорости работы платформы «1С» и настройка СУБД. Для достижения максимальной производительности инфраструктуры 1С рекомендуется правильно выбирать архитектуру инфраструктуры, режимы работы, проверить и выполнить ряд важных настроек.
В зависимости от количества пользователей, размера баз данных и ограничений бюджета (с учетом стоимости дополнительных лицензий на сервер «1С:Предприятие 8» и лицензий на СУБД) платформа «1С» может работать в файловом и клиент-серверном вариантах (на основе трехуровневой архитектуры «клиент-сервер» (рис. 1): клиентское приложение, кластер серверов «1С:Предприятия 8», СУБД).
Рис. 1
Как правильно выбрать вариант/режим работы 1С: файловый или SQL?
Обычно для 1-10 пользователей выбирается файловый режим
От 10 и более пользователей выбирается режим работы с использованием SQL
В файловом варианте все пользователи могут работать на одной виртуальной машине в облаке, например на терминальном сервере.
Для клиент-серверного варианта лучше выбрать не менее двух виртуальных машин:
Сервер с клиентским приложением, например терминальный сервер с клиентской частью «1С» (толстый клиент)
Сервер «1С» и СУБД (MS SQL или PostgreSQL)
Как рассчитать мощности сервера для 1С в файловом режиме работы?
В обоих вариантах: файловом и SQL, для работы с пользовательским приложением 1С в классическом режиме, например, «удаленного рабочего стола» (так называемый «толстый клиент»), необходимы следующие минимальные ресурсы виртуального сервера:
Количество виртуальных ядер CPU = 1 или 2 для ОС + 0,25 * количество пользователей
Объем памяти RAM = 1 или 2 ГБ для ОС + 0,5 ГБ * количество пользователей
Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (0,1-10) ГБ * количество пользователей. Для ОС и 1С рекомендуется использовать самые быстрые диски
Как рассчитать мощности сервера для 1С в варианте работы с SQL?
В клиент-серверном варианте работы 1С, в котором используется СУБД SQL, рекомендуется разместить 1С Сервер и сервер SQL на отдельном виртуальном сервере в общей с клиентским сервером локальной подсети. Необходимы следующие минимальные мощности для этого виртуального сервера:
Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (10-1000) ГБ в зависимости от объема и количества баз данных. Для ОС и СУБД рекомендуется использовать самые быстрые диски
------------
ОС - операционная система, например, Windows Server
Здесь Сервер 1С - ПО "сервер "1С:Предприятия 8"
Наиболее важными и непростыми задачами являются повышение продуктивности использования платформы «1С» в облаке и настройка СУБД. Типичные проблемы при развертывании и эксплуатации облачной инфраструктуры для «1С» следующие:
Неправильный выбор мощностей
Неквалифицированная настройка сервисов виртуальной инфраструктуры
Недостаточное внимание к тестированию производительности платформы «1С»
Для достижения максимальной производительности рекомендуется проверить и выполнить ряд настроек. Прежде всего необходимо исключить свопинг, для чего с помощью системы мониторинга следует обязательно удостовериться в том, что объем оперативной памяти достаточен для работы ВМ. Кроме того, файл подкачки ОС, профили пользователей, файлы баз данных, файлы логов транзакций (SQL) и tempDB (SQL) лучше разместить на дополнительных SSD-дисках, а для файла подкачки установить фиксированный размер.
На SQL-сервере необходимо выключить все ненужные службы, например FullText Search и Integration Services, установить максимально возможный объем оперативной памяти, максимальное количество потоков (Maximum Worker Threads) и повышенный приоритет сервера (Boost Priority), задать ежедневную дефрагментацию индексов и обновление статистики, настроить автоматическое увеличение файла базы данных (не менее 200 Мбайт) и файла лога (не менее 50 Мбайт), а также полную реиндексацию не реже одного раза в неделю. При размещении серверов SQL и «1С:Предприятие» на одной ВМ следует включить протокол Shared Memory.
Следуя перечисленным выше рекомендациям, можно добиться увеличения быстродействия платформы «1С» в облаке в 1,5–2 раза.
Квалифицированное размещение ИТ-сервисов, в том числе «1С», на облачной платформе позволяет:
Существенно сократить расходы
Повысить уровни безопасности (доступ к данным, резервное копирование, антивирусная защита и др.) и технического обслуживания
Обеспечить централизованное администрирование и мониторинг
Организовать эффективную и безопасную удаленную работу
Воспользоваться гибкими возможностями масштабирования, лицензирования и оперативного перехода на необходимые версии конфигураций «1С»
ЧЕК-ЛИСТ ПО ОПТИМИЗАЦИИ ИНФРАСТРУКТУРЫ 1С С MS SQL
1. Включить возможность мгновенной инициализации файлов (Database instant file initialization)
Это позволяет ускорить работу таких операций как:
Создание базы данных
Добавление файлов, журналов или данных в существующую базу данных
Увеличение размера существующего файла (включая операции автоувеличения)
Восстановление базы данных или файловой группы
Для включения настройки:
На компьютере, где будет создан файл резервной копии, откройте приложение Local Security Policy (secpol.msc)
Разверните на левой панели узел Локальные политики, а затем кликните пункт Назначение прав пользователей
На правой панели дважды кликните Выполнение задач по обслуживанию томов
2. Включить параметр «Блокировка страниц в памяти» (Lock pages in memory)
Эта настройка определяет, какие учетные записи могут сохранять данные в оперативной памяти, чтобы система не отправляла страницы данных в виртуальную память на диске, что может повысить производительность.
Для включения настройки:
В меню Пуск выберите команду Выполнить. В поле Открыть введите gpedit.msc
В консоли Редактор локальных групповых политик разверните узел Конфигурация компьютера, затем узел Конфигурация Windows
Разверните узлы Настройки безопасности и Локальные политики
Выберите папку Назначение прав пользователя
Политики будут показаны на панели подробностей
На этой панели дважды кликните параметр Блокировка страниц в памяти
В диалоговом окне Параметр локальной безопасности — блокировка страниц в памяти выберите «Добавить» пользователя или группу
В диалоговом окне Выбор: пользователи, учетные записи служб или группы добавьте ту учетную запись, под которой у вас запускается служба MS SQL Server
Чтобы изменения вступили в силу, перезагрузите сервер или зайдите под тем пользователем, под которым у вас запускается MS SQL Server
3. Включить каталоги с файлами базы данных в правила исключения для антивируса.
Если антивирус будет сканировать файлы базы, это может сильно замедлить работу СУБД.
Для опытных администраторов: антивирус на сервер СУБД лучше не устанавливать.
4. Включить каталоги с файлами базы данных в список исключений для системы автоматического копирования.
Если на сервере установлена система автоматического копирования файлов, то, когда она будет копировать файлы базы, это может привести к замедлению работы. Копии базы необходимо делать средствами самой СУБД.
5. Отключить механизм DFSS для дисков.
Механизм Dynamic Fair Share Scheduling отвечает за балансировку и распределение аппаратных ресурсов между пользователями. Иногда его работа может негативно сказываться на производительности 1С.
Чтобы отключить его только для дисков, нужно:
Найти в реестре ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk
Установить значение параметра EnableFairShare в 0
6. Отключить сжатие данных для каталогов, в которых лежат файлы базы.
При включенном сжатии ОС будет пытаться дополнительно обрабатывать файлы при модификации, что замедлит сам процесс записи, но сэкономит место.
Чтобы отключить сжатие файлов в каталоге, необходимо:
Открыть свойства каталога
На закладке Общие нажать кнопку Другие
Снять флаг «Сжимать» содержимое для экономии места на диске
7. Установить параметр «Максимальная степень параллелизма» (Max degree of parallelism) в значение 1.
Данный параметр определяет, во сколько потоков может выполняться один запрос. По умолчанию параметр равен 0, это означает, что сервер сам подбирает число потоков. Для баз с характерной для 1С нагрузкой рекомендуется поставить данный параметр в значение 1, т.к. в большинстве случаев это положительно скажется на работе запросов.
Для настройки параметра необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Дополнительно
Установить значение параметра равное единице
8. Ограничить максимальный объем памяти сервера MS SQL Server.
Необходимо ограничить максимальный объем памяти, потребляемый MS SQL Server, особенно это критично, если роли сервера 1С и сервера СУБД совмещены. Максимальный объем памяти, рекомендуемый для MS SQL Server, можно рассчитать по следующей формуле:
Память для MS SQL Server = Память всего – Память для ОС – Память для сервера 1С
Например, на сервере установлено 64 ГБ оперативной памяти, необходимо понять, сколько памяти выделить серверу СУБД, чтобы хватило серверу 1С.
Для нормальной работы ОС в большинстве случаев более чем достаточно 4 ГБ, обычно – 2-3 ГБ.
Чтобы определить, сколько памяти требуется серверу 1С, необходимо посмотреть, сколько памяти занимают процессы кластера серверов в разгар рабочего дня. Этими процессами являются ragent, rmngr и rphost, подробно данные процессы рассматриваются в разделе, который посвящен кластеру серверов. Снимать данные нужно именно в период пиковой рабочей активности, когда в базе работает максимальное количество пользователей. Получив эти данные, необходимо прибавить к ним 1 ГБ – на случай запуска в 1С «тяжелых» операций.
Чтобы установить максимальный объем памяти, используемый MS SQL Server, необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Память
Указать значение параметра Максимальный размер памяти сервера
9. Включить флаг «Поддерживать» приоритет SQL Server (Boost SQL Server priority).
Данный флаг позволяет повысить приоритет процесса MS SQL Server над другими процессами.
Имеет смысл включать флаг только в том случае, если на компьютере с сервером СУБД не установлен сервер 1С.
Для установки флага необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Процессоры
Включить флаг «Поддерживать приоритет SQL Server (Boost SQL Server priority)» и нажать Ок
10. Установить размер авто увеличения файлов базы данных.
Автоувеличение позволяет указать величину, на которую будет увеличен размер файла базы данных, когда он будет заполнен. Если поставить слишком маленький размер авторасширения, тогда файл будет слишком часто расширяться, на что будет уходить время. Рекомендуется установить значение от 512 МБ до 5 ГБ.
Для установки размера авторасширения необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства нужной базы и выбрать закладку Файлы
Напротив каждого файла в колонке Автоувеличение поставить необходимое значение
Данная настройка будет действовать только для выбранной базы. Если вы хотите, чтобы такая настройка действовала для всех баз, нужно выполнить эти же действия для служебной базы model. После этого все вновь созданные базы будет иметь те же настройки, что и база model.
11. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.
В этом случае работа с файлами может идти не последовательно, а практически параллельно, что повышает скорость работы дисковых операций. Лучше всего для этих целей подходят диски SSD.
Для переноса файлов необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства нужной базы и выбрать закладку Файлы
Запомнить имена и расположение файлов
Отсоединить базу, выбрав через контекстное меню Задачи – Отсоединить
Поставить флаг Удалить соединения и нажать Ок
Открыть Проводник и переместить файл данных и файл журнала на нужные носители
В Management Studio открыть контекстное меню сервера и выбрать пункт Присоединить базу
Нажать кнопку Добавить и указать файл mdf с нового диска
В нижнем окне сведения о базе данных в строке с файлом лога нужно указать новый путь к файлу журнала транзакций и нажать Ок
12. Вынести файлы базы TempDB на отдельный диск.
Служебная база данных TempDB используется всеми базами сервера для хранения, промежуточных расчетов, временных таблиц, версий строк при использовании RCSI и многих других вещей. Обычно обращений к этой базе очень много, и если она будет лежать на медленных дисках, это может замедлить работу системы.
Рекомендуется хранить базу TempDB на отдельном диске для повышения производительности работы системы.
Для переноса базы TempDB на отдельный диск необходимо:
Запустить Management Studio и подключиться к нужному серверу
Создать окно запроса и выполнить скрипт:
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'Новый_Диск:\Новый_Каталог\tempdb.mdf')
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'Новый_Диск:\Новый_Каталог\templog.ldf')
Перезапустить MS SQL Server
13. Включить Shared Memory, если сервер 1С расположен на том же компьютере, что и сервер СУБД.
Протокол Shared Memory позволит общаться приложениям через оперативную память, а не через протокол TCP/IP.
Для включения Shared Memory необходимо:
Запустить диспетчер конфигурации SQL Server
Зайти в пункт SQL Native Client – Клиентские протоколы – Общая память – Включено
Поставить значение Да и нажать Ок
Протокол Именованные каналы нужно выключить аналогичным образом
14. Перезапустить службу MS SQL Server
Внимание! Когда все настройки выполнены, необходимо перезапустить службу MS SQL Server
Спустя несколько лет использования 1С в контейнерной виртуализации Proxmox, появилось достаточно набитых шишек, которые оформлю здесь в виде коротких общих заметок по этапам процесса внедрения.
Это не не руководство к действию и не мануал. Если какой-то из пунктов следует расписать более подробно — пожалуйста, не стесняйтесь в комментариях.
Планирование и оценка рисков
Когда вы с горящими глазами расписали менеджменту суммы экономии, стабильность, масштабируемость и прочие плюшки — не забудьте о себе. Минимум — это хорошее железо, нормальный райд, быстрые диски, х64-версия сервера 1С. Желательно еще стребовать какое-то обучение по теме. Чтобы у менеджмента было понимание, что он инвестирует в свою собственную инфраструктуру и персонал, а не просто на ровном месте экономит круглую сумму.
Покупка ПО. Интегратор.
Желательно выбрать того, кто имел хоть какой-то опыт поддержки linux-версий 1С. Не поленитесь обзвонить и спросить. В итоге, вам все равно никто не поможет, и вы останетесь один на один со всеми проблемами, но хотя бы без раздражающих глупых советов про rdp и mssql.
Настройка хоста
При работе с proxmox, грех не задействовать чудесный механизм lxc.mount для монтирования каталогов с хоста в контейнеры (причем, с сохранением acl). Чтобы контейнеры не пухли от логов и бэкапов нужно заранее создать на хосте разделы и каталоги под эти цели, и cron-задания для ротации и очистки. Так вы будете рулить бэкапами и логами через одно место, и увидите, что это хорошо.
Выбор конфигурации сервера приложений и сервера БД
Вы, наверняка, уже знакомы с классическим подходом 1с-гуру, по размещению БД на том же сервере, что и сервер приложений. Сейчас как раз отличный шанс этого не делать. Дело в том, что если вы измерите скорость «сетевой» передачи данных между контейнерами, то получите не меньше 25-30 Гбит/с. Смело гоните БД с пляжа, и у вас получится легкий монолитный сервер приложений и несколько серверов БД, которые легко будет профилировать, бэкапить и обслуживать.
Настройка сервера БД
PostgreSQL от 1С или Postgres Professional прекрасно работают в контейнерах «из коробки».
Единственно, для удобства, я бы сделал сначала пустой шаблон контейнера с сервером БД, а потом клонировал его под каждую информационную базу, подключаемую к серверу приложений. В этом шаблоне стоит сразу же сделать монтирование лог и бэкап каталогов с хоста, и, соответственно, перенаправление туда наиболее толстых логов. Так же имеет смысл сразу сделать бэкап-задания, например, через механизм pg_dump all в эти каталоги. При формировании выходных файлов использовать $hostname. Так у вас получится джентельменский набор для любого случая
Настройка сервера приложений
Лицензирование
Многие против программных лицензий и ратуют за более дорогой, но надежный HASP. Это как с лыжами и сноубордом. Вам решать что ломать — ключицу или лодыжку. Проблемы бывают и пробросом hasp в контейнер, и с корректным получением программных лицензий.
Если вы решили брать программные лицензии — будьте внимательны с ядрами CPU. Как сказано в документации, вы можете увеличивать (но не уменьшать) количество ядер и процессоров без перелицензирования. Однако Proxmox, при изменении количества доступных ядер процессора в контейнере, меняет CoreID первого ядра. То есть, если вы для старта сделали контейнер с 1 ядром и при лицензировании привязались к CoreID 0. Вы будете удивлены, когда увеличив число ядер до 4, нумерация CoreID будет не 0,1,2,3 а 1,2,2,4. Соответственно, лицензии слетят
Если такое произошло — не отчаивайтесь. Лицензии можно достаточно просто реактивировать по приложенным кодам. А можно в конфигурации контейнера поставить на одно ядро больше реального количества. Например, 9 для восьмиядерного сервера. Тогда CoreID 0 вернется и не покинет вас.
Работает отказоустойчивый кластер Hyper-V из 2-х серверов (на Intel Xeon E5 2609, 16 Гб ОЗУ), на котором крутится виртуальная машина на Windows Server 2012 Standart, на ней 1C 7.7 и 8.3 нескольких конфигураций. Виртуальная машина кластеризована, находится на дисковой полке Synology.
Работает 10-30 пользователей одновременно. Обновили платформу 1С до версии 8.3.10.2753 и установили конфигурацию «Бухгалтерия государственного учреждения». Начались тормоза при формировании отчётов, 1-2 минуты минимум приходилось ждать, также долго запускается.
Дисковая полка поддерживает SSD кеширование, думаю попробуем ускорить ускорить систему установив твердотельные диски и добавить памяти, т.к. свободно было 1-2 Гб в среднем на виртуалке из 9 доступных для неё вначале.
Показываю тест скорости дисков до установки SSD диска для кэша и дополнительных модулей ОЗУ. Посмотрев монитор работы системы было заметно когда используют 1С ГБУ, сразу подскакивает обращение к диску. Причем когда сидит 15-20 человек — нагрузка до 5%, как только садится 1 пользователь 1С 8.3 ГБУ — подскакивает до 20%.
Добавил оперативной памяти, теперь на обоих серверах по 32 Гб, выделил 20 Гб под виртуальную машину с 1С.
Ставим SSD-диски на полку и запускаем SSD-кеш
Дисковая полка Synology RackStation RS2414+, обновил DSM до версии DSM 6.2-23739 Update 2, вместо дисков:
- RAID10 6*500 гб Hitachi Ultrastar A7K2000 HUA722050CLA330 – 1 пул и
- RAID10 6*2000гб Hitachi Ultrastar 7K4000 HUS724020ALA640 – 2 пул
Установил 10 дисков 4ТБ WD Red Pro WD4003FFBX в Raid 10, для SSD кэша буду ставить 2 SSD 2.5» Seagate XF1230-1A0480:
Вставляю 2 диска в полку, создаю в диспетчере хранения SSD-кеш с помощью мастера, выбираю использовать для «чтение/запись», и кешировать массив дисков №1, на котором LUN-ы с виртуальными дисками, на которых крутится 1C.
Если кратко, то LUN это идентификатор, логический том внутри массива дисков, который для наших серверов, работающих в кластере виден как физический диск.
На форумах читал, что для корректной работы кэша 2 дисков такого же как у меня объема необходимо 16 Гб ОЗУ, у меня же 2 и максимум 4 может быть, посмотрим, что получится. С дисками можно было бы проще, 1 и на меньший объем я думаю.
Смотрим работу 2 дня, несколько дней. Настроек никаких нет
Увеличение скорости есть, для запуска 1С, формирования отчетов и прочее, заметно быстрее, но работа 1С ГБУ также идет медленно.
Проведя тест скорости видим незначительные улучшения, так быть не должно, как будто SSD и нет.
Скорее всего это из-за того, что диск у виртуальной машины располагается на подключенном , созданный на и нужно было SSD-кеш не делать, а ставить машину на эти 2 физических диска в массиве RAID-1. По-пробуем.
Переносим виртуальный жесткий диск на SSD
Ради интереса, даст ли это прирост. Удаляем SSD кеш, создаём новый пул дисков, добавляем в него наши 2 SSD в RAID1.
Создаём новый Lun и сопоставляем с новым Target.
Замеряем скорость: стало даже хуже.
Если SSD кеш не помог и расположение виртуальных дисков на SSD массиве тоже, идём дальше.
SSD кеш дело интересное, но нам он не помог.
Перенос баз на SSD без виртуальных дисков
Первый диск виртуальной машины — ОС, второй — базы данных, оставляем первый на пуле дисков в RAID10, второй виртуальный диск оставляем также и для сравнения подключаем третий диск как физический SSD массив напрямую.
С точки зрения производительности виртуальные диски IDE и SCSI друг от друга не отличаются. Я оставил IDE. Копируем базы на наш SSD.
Запускаем виртуальную машину и смотрим.
Из под сервера гипервизора виден неинициализированный диск, в виртуальной машине видим наш новый как бы физический SSD.
Запускаю, тестируем скорость, пользователи при этом тоже работают. Тест Гилева дал 22 балла.
Может потому, что это из-под виртуалки? Тогда делаем тест скорости не из-под виртуальной машины, а напрямую из под папки — результат тот же. Думал разница в файловых системах, но BTRFS в общем работает быстрее EXT4, скорость немного выше у первой.
В 2.5 раза скорость выше. Поэтому остаётся последний вариант: добавить в виртуальную машину физический диск, то есть на сервер напрямую его подключить, чтобы он был инициализирован, но в состоянии offline. Затем добавить его также как описано выше.
Дополнительные настройки
Отключаем в ОС Dynamic Fair Share Scheduling: открываем PowerShell и запускаем команду
(gwmi win32_terminalservicesetting -N «root\cimv2\terminalservices»).enabledfss
Читайте также: