Настройка кластера 1с sql server 2019

Обновлено: 06.07.2024

Релиз версии 1С: Предприятие 8.3 был анонсирован в 2012 году. Вместо резервного кластера ( как в версии 8.2 ) сделали один кластер, но внутри кластера можно указывать различные параметры, т.е. значительно упростили настройку отказоустойчивости.

В этой версии был существенно переписан весь код самой платформы.

Перед тем, как рассмотреть настройки, отмечу ключевые параметры запуска ragent :

–range – Порты рабочих процессов
–d – Директория, где живет сервер (было рассмотрено в предыдущей статье)
–debug – Флаг отладки на сервере

Строку запуска ragent можно посмотреть в службе, а настроить параметры в редакторе регистра: «HKLM -> SYSTEM -> Current Control Set - > Services». Строку запуска ragent можно посмотреть в службе, а настроить параметры в редакторе регистра: «HKLM -> SYSTEM -> Current Control Set - > Services».

Файлы и каталоги сервера 1С

Общий каталог сервера (C:\Program Files\1cv8\srvinfo\)
lst – файл настроек кластера
lst – файл со списком баз
Каталоги баз:1Cv8FTxt – файлы полнотекстового поиска
1Cv8Log – файлы журналов регистрации
Snccntx – сеансовые данные.

Поместить во временное хранилище помещает данные в сеансовые данные (snccntx на диске), при этом часть данных может кэшироваться в оперативной памяти.

Основные настройки кластера 1С: 8.3

Защищенное соединение:

Шифрует данные между клиентом и сервером 1С.

Поэтому и в данном случае, при включенном шифровании, производительность будет падать, т.к. тратятся ресурсы.

Рекомендуется оставлять «выключено», тогда будет шифроваться пароль только при первом соединении(!). Не влияет на шифрование данных между 1С и СУБД.

Интервал перезапуска:

Автоматически перезапускает рабочие процессы (rphost). Начало отсчета интервала перезапуска = момент нажатия на кнопку «ОК», поэтому ставите интервал 1 раз в сутки (86 400 с.), то ставьте ночью.

Перезапуск процесса (выключение старого и включение нового) разделен на этапы:

Процесс помечается как выключенный, теперь на него не назначаются новые сеансы.
Создается новый процесс, на который перекидываются все сеансы с выключенного.
Если за интервал времени « проблемные процессы завершать через » (например, 1 минута) остались висеть сеансы, то они обрываются принудительно, а процесс убивается (клиент получит ошибку).

Имеет смысл только для 32 разрядных систем, т.к. там есть фрагментация памяти (рассматривается на занятии 01-01. Знакомство с 1С ). Для 64 полезно использовать только тогда, когда есть утечки памяти, и проблема пока не решается.

Уровень отказоустойчивости (УО):

Имеет смысл только если в кластере более 1 сервера. Максимальный уровень отказоустойчивости - это количество серверов в кластере минус 1, т.е. если в кластере 1 сервер, то уровень отказоустойчивости = 0. Если же их 3, то есть возможность задать значение УО равным от 0 до 2.

Уровень отказоустойчивости – это количество серверов, которые могут упасть, без последствий для пользователя.

Важный момент, что резервирование идет именно для служебных серверов, т.е. если упадет центральный, то весь кластер умрет. Все обеспечивается за счет резервирования сеансовых данных (копирование на резервный сервер), а это опять же влияет на производительность.

В данной статье будут рассмотрены несколько вариантов структуры 1С для высоконагруженных систем (от 200 активных пользователей), построенных на базе клиент-серверной архитектуры – их преимущества и недостатки, стоимость инсталляции и сравнительные тесты производительности каждого варианта.

Мы не будем проводить описание, оценку и сравнение общепринятых и всем давно известных классических схем построения серверной структуры 1С, таких как отдельный сервер 1С и отдельный сервер СУБД, либо кластер Microsoft SQL с кластером 1С. Таких обзоров великое множество, в том числе и проведенных самими производителями программных продуктов. Мы предложим обзор схем построения структуры 1С, которые встречались за последние несколько лет в наших ИТ-проектах для среднего и крупного бизнеса.

Требования к высоконагруженным системам 1С

Высоконагруженные системы 1С, работающие с крупными массивами данных в режиме 24/7/365 подвержены факторам риска, которые в стандартных ситуациях обычно не наблюдаются. Как следствие, для их устранения и упреждения требуется применение особенных схем архитектуры 1С и новых технологий.

Катастрофоустойчивость СУБД. В процессе проектирования архитектуры 1С делается упор на вычислительные мощности и высокую доступность сервисов, выраженную в их кластеризации. Серверы 1С:Предприятие по умолчанию способны работать в дублирующем кластере, а для кластера СУБД обычно применяется промышленная система хранения данных (СХД) и технология кластеризации (к примеру, Microsoft SQL Cluster). Однако, ситуация становится плачевной, когда проблемы случаются с самой СХД (зачастую, по нашему опыту последних лет – это проблемы программного характера). Тогда у ИТ-инженера резко возникают две проблемы – где взять актуальные данные и куда их развернуть в кратчайшие сроки, поскольку система хранения данных с нужным объемом быстрого массива дисков недоступна.

Требования к безопасности базы данных. Работая с проектами среднего и крупного бизнеса, мы регулярно сталкиваемся с требованиями по защите персональных данных (в частности, для выполнения пунктов ФЗ-152). Одним из условий выполнения этих требований является обеспечение должной сохранности персональных данных, что требует шифрования базы данных 1С.

Высокая загрузка вычислительных ресурсов. При разработке схемы высоконагруженных систем 1С обычно обращают внимание в первую очередь на параметры дисковой системы ввода\вывода, на которой расположены базы данных. Но помимо этого, еще существует активная утилизация ресурсов ЦПУ и потребление ОЗУ сервером 1С. Зачастую именно этого типа ресурсов и не хватает, возможности аппаратной модернизации текущего сервера 1С исчерпываются и требуется добавление новых серверов 1С , работающих с единым сервером СУБД.

Схемы организации кластеров серверов 1С

Схема с кластером 1С-серверов, подсоединенным к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP.

Данная схема является одним из качественных вариантов решения проблемы катастрофоустойчивости базы данных 1С (см. Рисунок 1). Технология кластеризации баз SQL AlwaysOn основана на принципе онлайн-синхронизации таблиц SQL между основным и резервным серверами без вмешательства конечного пользователя. С помощью SQL Listener есть возможность переключиться на резервный сервер SQL в случае выхода из строя основного, что позволяет назвать данную систему полноценным катастрофоустойчивым кластером SQL, благодаря использованию двух независимых серверов SQL. Технология SQL Always On доступна только в версии Microsoft SQL Enterprise.

Рисунок 1 - схема кластера серверов 1С + SQL AlwaysOn

Вторая схема идентична первой, добавлено только шифрование баз SQL на основном и резервном сервере.

Мы уже упоминали о том, что работа с последними ИТ-проектами показала, что компании начали гораздо больше внимания уделять вопросу безопасности данных, по различным причинам – требования ФЗ-152, рейдерские захваты серверов, утечка данных в облаке и тому подобное. Так что считаем данный вариант схемы 1С довольно актуальным (см. Рисунок 2).

Рисунок 2 - схема кластера серверов 1С + SQL AlwaysOn с шифрованием

Кластер серверов 1С "active-active", подсоединенный к единственному серверу СУБД по протоколу IP.

В противовес потребностям в отказоустойчивости и безопасности – некоторым структурам в первую очередь требуется повышенная производительность, так сказать «вся вычислительная мощь». Поэтому максимальный приоритет отдается увеличению количества вычислительных кластеров сервера 1С, на которые современная платформа 1С позволяет дифференцировать различные типы вычислений и фоновые задания (см. Рисунок 3). Конечно же, комплектация основных ресурсов сервера SQL тоже должна быть на уровне, однако сам сервер баз данных представлен в единственном числе (видимо, расчет идет на своевременное резервное копирование баз).

Рисунок 3 - схема кластера серверов 1С с одним сервером СУБД

Сервер 1С и СУБД на одном аппаратном сервере с SharedMemory.

Поскольку наши практические тесты ориентированы на сравнение производительности разных схем, то обязательно требуется некий эталон для сравнения нескольких вариантов (см. Рисунок 4). В качестве эталона, по нашему мнению, нужно взять схему расположения сервера 1С и СУБД на одном аппаратном сервере без виртуализации с взаимодействием по SharedMemory.

Рисунок 4 - схема сервера 1С и СУБД на одном аппаратном сервере с SharedMemory

Ниже приведена общая сравнительная таблица, в которой показаны общие результаты по ключевым критериям оценки организации структуры системы 1С (см. Таблица 1).

Таблица 1 - сравнение вариантов построения систем 1С

Критерии оценки архитектур 1С	Кластер 1С + SQL AlwaysOn	Кластер 1С + SQL AlwaysOn с шифрованием	Кластер 1С с одним сервером СУБД	Классический 1С+СУБД SharedMemory
Легкость инсталляции и обслуживания	Удовл.	Удовл.	Хорошо	Отлично
Отказоустойчивость	Отлично	Отлично	Удовл.	Не применимо
Безопасность	Удовл.	Отлично	Удовл.	Удовл.
Бюджетность	Удовл.	Удовл.	Хорошо	Отлично

Как видим, остается один важный критерий, значение которого предстоит выяснить – это производительность. Для этого мы проведем серию практических тестов на выделенном тестовом стенде.

Описание методики тестирования

Этап тестирования состоит из двух ключевых инструментов синтетической генерации нагрузки и имитации работы пользователей в 1С. Это тест Гилева (TPC-1C) и «Тест центр» из инструментария 1С: КИП.

Тест Гилева. Тест относится к разделу универсальных интегральных кроссплатформенных тестов. Он может применяться как для файлового, так и для клиент-серверного вариантов 1С:Предприятие. Тест оценивает количество работы в единицу времени в одном потоке и подходит для оценки скорости работы однопоточных нагрузок, включая скорость отрисовки интерфейса, влияния ресурсных затрат на обслуживание виртуальной среды, перепроведения документов, закрытия месяца, расчета зарплаты и т.п. Универсальность позволяет делать обобщенную оценку производительности не привязываясь к конкретной типовой конфигурации платформы. Результатом теста является сводная оценка измеряемой системы 1С, выраженная в условных единицах.

Специализированный «Тест центр» из инструментария 1С: КИП. Тест-центр – инструмент автоматизации многопользовательских нагрузочных испытаний информационных систем на платформе 1С:Предприятие 8. С его помощью можно моделировать работу предприятия без участия реальных пользователей, что позволяет оценивать применимость, производительность и масштабируемость информационной системы в реальных условиях. Используя инструментарий 1С: КИП, на основании процессов и контрольных примеров формируется матрица «Список Объектов макета базы ERP 2.2» для сценария тестирования производительности. В макете базы 1С: ERP 2.2 генерируются обработкой данные по Нормативно-справочной информации (НСИ):

Несколько тысяч номенклатурных позиций;
Несколько организаций;
Несколько тысяч контрагентов.

Тест осуществляется в рамках нескольких групп пользователей. Группа состоит из 4 пользователей, у каждого из которых есть своя роль и перечень последовательных операций. Благодаря гибкому механизму задания параметров для тестирования, можно запускать тест на разное количество пользователей, что позволит оценить поведение системы при различных нагрузках и определить параметры, которые могут привести к снижению показателей производительности. Проводится 3 теста по 3 итерации в которых разработчик 1С запускает тест с эмуляцией работы пользователей и замеряет время выполнения каждой операции. Выполняются замеры всех трех итераций для каждой из схем структуры 1С. Результатом теста является получение среднего времени выполнения операции для каждого документа матрицы.

Показатели «Тест центра» и теста Гилева будут отражены в сводной таблице 2.

Тестовый стенд

vCPU - 16 ядер 2.6GHz
RAM - 32 ГБ
I\o: Intel Sata SSD Raid1

CPU - Intel Xeon Processor E5-2670 8C 2.6GHz – 2 шт
RAM - 96 ГБ
I\o: Intel Sata SSD Raid1
Роли: Сервер 1С 8.3.8.2137, Сервер MS SQL 2014 SP 2

CPU - Intel Xeon Processor E5-2670 8C 2.6GHz – 2 шт
RAM - 96 ГБ
I\o: Intel Sata SSD Raid1
Роли: Сервер 1С 8.3.8.2137, Сервер MS SQL 2014 SP 2

Выводы

Можем сделать вывод, что по среднему времени выполнения операции наиболее оптимальной является схема №3 «Кластер серверов 1С "active-active", подсоединенный к единственному серверу СУБД по протоколу IP» (см. Таблица 2). Для обеспечения отказоустойчивости такой архитектуры мы рекомендуем строить классический отказоустойчивый кластер MSSQL с размещением базы данных на отдельной СХД.

Важно отметить, что наиболее оптимальное соотношение факторов минимизации простоя, отказоустойчивости и сохранности данных - у схемы №1 «Кластер 1С-серверов, подсоединенный к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP», при этом падение производительности по отношению к самому производительному варианту составляет примерно 10%.

Как мы видим по результатам тестов, синхронная репликация базы SQL AlwaysOn достаточно негативно влияет на производительность. Объясняется это тем, что система SQL ждет окончания репликации каждой транзакции на резервный сервер, не позволяя работать с базой в это время. Этого можно избежать если настроить асинхронную репликацию между MSSQL серверами, но при таких настройках мы не получим автоматического переключения приложений на резервную ноду в случае сбоя. Переключение придется выполнять вручную.

На базе облака EFSOL мы предлагаем нашим клиентам кластер серверов 1С в аренду. Это позволяет существенно сэкономить средства на построение собственной отказоустойчивой архитектуры для работы с 1С.

Таблица 2 - Итоговая таблица (сокращенный вариант) практических испытаний разных вариантов построения систем 1С

Обратите внимание, что настройки кластера отвечают за настройки всех серверов принадлежащих настраиваемому кластеру. Кластер подразумевает работу нескольких физических или виртуальных серверов, работающих с одними и теми же информационными базами.

Интервал перезапуска – отвечает за частоту перезапуска рабочих процессов кластера. Этот параметр необходимо выставлять при круглосуточной работы сервера. Рекомендуется частоту перезапуска связывать с технологическим циклом информационных баз кластера. Обычно это каждые 24 часа (86400 сек). Как известно, рабочие процессы серверов 1С обрабатывают и хранят рабочие данные.

Автоматический перезапуск был разработан в платформе «для минимизации отрицательных последствий фрагментации и утечки памяти в рабочих процессах». На ИТС есть даже информация о том, как организовать перезапуск рабочих процессов по другим параметрам (объем памяти, занимаемые ресурсы и т.п.).

Допустимый объем памяти – защищает сервера 1С от перерасхода памяти. При превышении процессом этого объема в интервале превышения допустимого объема, процесс перезапускается. Можно рассчитать как максимальный размер памяти, занимаемый процессами «rphost» в периоды пиковой нагрузки серверов. Также стоит установить небольшой интервал превышения допустимого объема.

Допустимое отклонение количества ошибок сервера. Платформа рассчитывает среднее количество ошибок сервера по отношению к числу обращений к серверу в течение 5 минут. Если это отношение превысит допустимое, то рабочий процесс считается «проблемным», и может быть завершен системой, если установлен флаг «Принудительно завершать проблемные процессы».

Выключенные процессы останавливать через. При превышении допустимого объема памяти, рабочий процесс не завершается сразу, а становится «выключенным», чтобы было время «перенести» рабочие данные без потери на новый запущенный рабочий процесс. Если указан этот параметр, то «выключенный» процесс в любом случае завершится по истечении этого времени. Если наблюдаются «зависшие» рабочие процессы в работе сервера 1С, то можно стоит этот параметр на 2-5 минут.
Эти настройки устанавливаются для каждого сервера 1С индивидуально.

Максимальный объем памяти рабочих процессов – это объем совокупной памяти, которую могут занимать рабочие процессы (rphost) на текущем кластере. Если параметр установлен в «0», то занимает 80% оперативной памяти сервера. «-1» - без ограничений. Когда на одном сервере работают СУБД и сервер 1С, им нужно делить между собой оперативную память. Если в процессе эксплуатации обнаружится, что серверу СУБД не хватает памяти, то можно ограничить память, выделяемую серверу 1С с помощью этого параметра. Если СУБД и 1С разделены по серверам, то имеет смысл рассчитать этого параметр по формуле:

«Max объем» = «Общая оперативная память» – «Оперативная память ОС»;

«Оперативная память ОС» рассчитывается по принципу 1 Гб на каждые 16 Гб оперативной памяти сервера

Безопасный расход памяти за один вызов. В общем случае, отдельные вызовы не должны занимать всю оперативную память, выделенную рабочему процессу. Если параметр установлен в «0», то объем безопасного расхода будет равен 5 % от «Максимального объема памяти рабочих процессов». «-1» - без ограничения, что крайне не рекомендуется. В большинстве случаев этот параметр лучше оставлять «0».

С помощью параметров «Количество ИБ на процесс» и «Количество соединений на процесс» можно управлять распределением работы сервера 1С по рабочим процессам. Например, запускать под каждую информационную базу отдельный «rphost», чтобы в случае «падений» процесса, отключались только пользователи одной базы. Эти параметры стоит подбирать индивидуально под каждую конфигурацию сервера.

2. Рекомендации по настройке СУБД MS SQ

Ограничение на использование оперативной памяти сервером СУБД – У сервера СУБД MS SQL есть одна замечательная особенность – он любит загружать базы, с которыми ведется активная работа в оперативную память полностью. Если его не ограничивать, то он заберет себе всю оперативную память, какую только сможет.

Если сервер 1С:Предприятия установлен вместе с Microsoft SQL Server, то верхний порог памяти необходимо уменьшить на величину, достаточную для работы сервера 1С.
Если на сервере работает только СУБД, то для СУБД по формуле:

«Память СУБД» = «Общая оперативная память» – «Оперативная память ОС»;

Shared memory – об этом параметре известно много, но до сих пор встречается, что про него забывают. Выставляем в «1», если сервер 1С и СУБД работают на одном физическом или виртуальном сервере. Кстати, работает, начиная с платформы 8.2.17.

Max degree of parallelism – определяет, сколько процессоров используется при выполнении одного запроса. СУБД распараллеливается получение данных при выполнении сложных запросов на несколько потоков. Для 1С рекомендуется устанавливать в «1», то есть одним потоком.

Авторасширение файлов БД - определяем шаг в МБ, с которым «расширяется» файл базы данных. Если шаг будет маленький, то при активном росте БД, частые расширения приведут к дополнительной нагрузке на дисковую систему. Лучше установить в 500 – 1000 МБ.

Реиндексация и дефрагментация индексов – рекомендуется делать дефрагментацию/реиндексацию хотя бы раз в неделю. Реиндексация блокирует таблицы, поэтому лучше запускать в нерабочее время или периоды минимальной нагрузки. Нет смысла делать дефрагментацию после перестроения индекса (реиндексации). По рекомендации Microsoft дефрагментацию делают в том случае, если фрагментация индекса не превышает 30 %. Если выше, рекомендуется сделать реиндексацию.

Обновление статистики - рекомендуется обновлять статистику хотя бы 1 раз в день. Статистика отвечает за производительность выполнения запросов.

План электропитания – в настройках электропитания операционной системы установить на высокую производительность.

Существуют два варианта работы с системой 1С:Предприятие: файловый вариант и клиент-серверный вариант. В нашем случае, мы будем рассматривать настройку СУБД MS SQL Server 2019 , расположенного физически на одном и том же сервере, где работает кластер серверов 1С:Предприятия.

Тестовый стенд представляет из себя виртуальную машину со следующими характеристиками:

Процессор: Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz, 3200 МГц, ядер: 4, логических процессоров: 4.
ОЗУ: 18 Гб.
Диск С: (системный) - 70 Гб.
Диск Е: (диск для баз данных) - 50 Гб.

Первым делом нам необходимо завести учетную запись, из под которой будет работать служба сервера MS SQL. Для этого нам необходимо перейти в панель управления и выбрать пункт Администрирование :

Затем открываем пункт Управление компьютером и переходим к пункту Локальные пользователи и группы . После чего нажимаем правой кнопкой мыши на пункт Новый пользователь .

В появившемся окне вводим данные учетной записи для службы MS SQL (Имя и описание индивидуальны).

Далее необходимо добавить учетную запись в группу Администраторы .

Рисунок 4 - Добавление учетной записи в группу Администраторов Рисунок 4 - Добавление учетной записи в группу Администраторов

На данном этапе нужно подключить образ дистрибутива MS SQL Server 2019 к системе. Запускаем его.

В появившемся окне выбираем пункт Установка , а затем нажимаем на пункт Новая установка изолированного экземпляра SQL сервер или добавление компонента к существующей установке .

Следующим этапом нам необходимо ввести ключ продукта и нажать Далее.

Внимательно читаем лицензионное соглашение и жмем Далее.

На данном этапе вы решаете, необходимо ли использовать Центр обновления Microsoft при обновлении экземпляра MS SQL Server. Так как в дальнейшем мы его будем обновлять исключительно вручную, то чекбокс оставляем пустым.

На данном шаге проходит проверка правил установки. По её завершению нажимаем Далее.

Читайте также: