Настройка кластера 1с sql server 2019
Устанавливая 1С в клиент-серверном варианте, случается, что специалисты оставляют настройки кластера серверов 1С 8.3 по умолчанию. Это может приводить к неоптимальному использованию аппаратных ресурсов эксплуатируемых серверов и к нестабильной работе серверов 1С и СУБД.
В статье рассмотрим рекомендации по основным настройкам кластера серверов 1С 8.3 и СУБД MS SQL.
С помощью параметров «Количество ИБ на процесс» и «Количество соединений на процесс» можно управлять распределением работы сервера 1С по рабочим процессам.
(1) Пока не купишь версию КОРП не узнаешь, что не все настройки кластера можно использовать в версии ПРОФ, поэтому нарушения соглашения ПРОФ не наступает (нет об этом упоминания).
интересная какая позиция. юридический аспект упускаете или изучали вопрос до "дна"?
(4) Вы ошибаетесь, на конфе инфостарта 2016 ( видео- Малый зал Круглый стол НighLoad с 5 минуты ) задавали этот вопрос и Антон Дорошкевич ответил что это нарушение лиц соглашения.
(11)Слова Антона Дорошкевича во время конференции изменили текст лицензионного соглашения? На желтой бумаге проявились дополнительные буквы?
Пока ограничения нет в соглашении на ПРОФ платформу - это только пожелания и просьбы не использовать.
При чем здесь несуществующий пункт?
Мой вопрос о том, на сколько полно рассмотрен вопрос, учитывая: лицензионное соглашение, Гражданский кодекс и другие, связанные с вопросом, правоохраняющие нормы.
Такое бывает, когда пункта нет, а ответственность есть
(20) каким образом может появится ответственность если в лицензионном соглашении нет ограничения на использования настроек? В суде аргумент "одна бабка сказала" не применим.
Представьте, завтра вы покупаете хлеб в Магните, а на выходе уборщица вам говорит, что пакетик (упаковку) от хлеба надо обязательно вернуть назад в магазин, это его собственность, при этом никакой информации в чеке и на ценнике на эту тему нет. Вы будете на следующий день относить пакетик?
С точки зрения закона - использование настроек в версии ПРОФ возможно, так как это не ограничено лицензионным соглашением. Прочитайте его внимательно, именно оно будет аргументом в суде.
p.s. "Пункта нет а ответственность есть" - это вариант когда изменения лицензионного соглашения могут вноситься путем публикации на определенных ресурсах, соответственно отслеживание изменений становится более сложной задачей. Либо есть отсылки на другие документы. Но об этом тоже должна быть информация в первоначальном соглашении (на ноябрь 2016 я не встречал). Либо это просто развод ))).
Павел, не нужно мне дополнительных комментариев. просто интересно, изучали ли вопрос.
Вы хоть раз в суде были по подобным вопросам? Если были, то имеете преставление о том, что там (в суде) может являться основанием. Там наша с Вами логика вообще никому не интересна.
вот читаю переписку и вижу с одной стороны аргументы, а с другой стороны "а вы были в суде" , " там наша логика никому не интересна" ит.п. Если судовая система работает то работаю законы и аргументы, и если нет запрета - то запрета нету, не стоит сюда тулить разные придуманные ситуации как это может случиться в реалиях конкретной страны.
(57)
уважаемый softgarant. По отношению к Авторскому праву "если нет запрета - то запрета нету" не применимо.
(22) Т.е. лицензионное соглашение, где этот пункт про параметры настройки отсутствует, для суда не будет иметь значение, а какой-то видос, где какой-то чувак сказал "так нельзя" будет значим для суда? Оригинально. Хотя наши суды это не про право, справедливость и независимость.
(62)Вы посмотрите лицензионное соглашение именно вашей версии платформы (C:\Program Files (x86)\1cv8\\licenses\1CEnterprise_ru.htm)
Пищите в файле: Лицензирование сервера "1С:Предприятия 8"
Я к сожалению не помню с какой именно версии появилось описание в лицензионном соглашении ограничений ПРОФ, может у вас как раз та версия где этих ограничений и не прописано.
"какой-то чувак" не просто так так говорил)
В общем, читайте лицензионное соглашение, там ВСЕ(!) сказано.
про КОРП. и про остальное, что представлено в документации в свободном (если не ошибаюсь) доступе :)
Это гон.
Все можно ставить, как хочешь. Разве что, не забывать если 1 база то соединений должно хватать на все лицензии.
Max degree of parallelism – определяет, сколько процессоров используется при выполнении одного запроса. СУБД распараллеливается получение данных при выполнении сложных запросов на несколько потоков. Для 1С рекомендуется устанавливать в «1», то есть одним потоком.
Такого не стоит делать, если у вас на сервере СУБД есть базы, не относящиеся к 1С, например от MS Project.
(2) В MS SQL 2016 параметр Max degree of parallelism можно устанавливать на каждую базу в отдельности.
Ого! Что-то не видно этого в 2016. Да и MSDN по этому поводу никаких нововведений не рассказал.
Дайте скрин или ссылку пожалуйста.
Тут есть маленький нюанс - МаксДоП = 1 стоит включать всем тем, кто не в курсе, что такое параллелизм на сервере СУБД, как он работает и на что влияет.
А просто сказать "такого не стоит делать" - не достаточно, если получивший совет врубит МаксДоП = 0 и не настроит стоимостные пороги, то, с достаточно большой вероятностью, он получит жутко "тормозящую" базу почти во всех сценариях работы.
>>Обновление статистики - рекомендуется обновлять статистику хотя бы 1 раз в день.
Кем это такое рекомендуется?
Хорошо бы посмотреть на "героев" статистики, а то перестроите на свою голову.
Споры по той статье, в основном, велись вокруг рекомендации очищать процедурный кэш после каждого обновления статистики и рекомендуемых интервалов выполнения обслуживания. Но все спорящие были согласны с тем, что лучше настроить обновление статистики согласно приведённым в статье рекомендациям, чем вообще не настраивать.
- рекомендация очень неоднозначная, когда этот интервал может по каким-то причинам попасть на рабочие часы. Например, сервер перезагрузили, и интервал стал отсчитываться от момента последнего запуска. А пользователей он рубит достаточно жестко.
Я настраивал регламентное задание по рассписанию, которое запускает батник со строками такого вида:
net stop "1C:Enterprise 8.2 Server Agent (x86-64)" && net start "1C:Enterprise 8.2 Server Agent (x86-64)" >> C:\Restart_Services\Restart.log
(12) Есть два аспекта. Собственно перезапуск сервера и когда это происходит.
Поведуйте, чем перезапуск в настройках кластера мягче перезапуска сервиса net stop/start?
Управлять моментом перезапуска сервера в настройках кластера не получается. У меня был случай то ли питание отключилось настолько, что ИБП потушил и потом рестартовал днем сервер, то ли админы в воскресение днем его перезагрузили. В общем через сутки он сделал перезапуск сервера (ещё 8.2) в соответствии с настройками кластера. И сделал это он ультимативно с отвалом всех пользователей. Пользователи были не рады. Перезапуск же планировщиком системы можно привязать к абсолютному времени (01:00). Именно это я называю мягче.
В более крупных внедрениях писали скрипты которые предварительно выгоняли пользователей или останавливали перезапуск. Но это уже другая история.
Авторасширение файлов БД - определяем шаг в МБ, с которым «расширяется» файл базы данных. Если шаг будет маленький, то при активном росте БД, частые расширения приведут к дополнительной нагрузке на дисковую систему. Лучше установить в 500 – 1000 МБ.
>так как это не ограничено лицензионным соглашением
добавлю, что никаких "презумпций" по отношению к авторским правам быть не может. Запрещено все, на что вы не получали соответствующих прав.
"Лицензиат обязуется не допускать нарушений исключительных прав Правообладателя на ПРОГРАММНЫЙ ПРОДУКТ, в частности, не совершать и не допускать совершения третьими лицами следующих действий без специального письменного разрешения Правообладателя:
распространять ПРОГРАММНЫЙ ПРОДУКТ или отдельные его компоненты;
вносить какие-либо изменения в код ПРОГРАММНОГО ПРОДУКТА, содержимое баз данных и других наборов данных, в которых система хранит информацию, за исключением тех изменений, которые вносятся штатными средствами, входящими в состав ПРОГРАММНОГО ПРОДУКТА и описанными в сопроводительной документации;
доступ к информационной базе ПРОГРАММНОГО ПРОДУКТА и построение систем на основе ПРОГРАММНОГО ПРОДУКТА с помощью средств и технологических решений, не предусмотренных в сопроводительной документации;
совершать действия, результатом которых является устранение или снижение эффективности технических средств защиты авторских прав, применяемых Правообладателем, включая применение программных и технических средств "мультиплексирования", средств, изменяющих алгоритм работы программных или аппаратных средств защиты ПРОГРАММНОГО ПРОДУКТА, а также использовать ПРОГРАММНЫЙ ПРОДУКТ с устраненными или измененными без разрешения Правообладателя средствами защиты;
восстанавливать исходный код, декомпилировать и/или деассемблировать программную часть системы, за исключением тех случаев и лишь в той степени, в какой такая деятельность специально разрешена действующим законодательством.
Настоящее Лицензионное соглашение действует в течение всего срока эксплуатации Лицензиатом ПРОГРАММНОГО ПРОДУКТА и/или нахождения у него экземпляров ПРОГРАММНОГО ПРОДУКТА.
"
"Использование Сервера "1С:Предприятия 8" будет являться правомерным при одновременном выполнении следующих условий:
у Лицензиата имеется один или несколько правомерно приобретенных ПРОГРАММНЫХ ПРОДУКТОВ;
установка Сервера "1С:Предприятия 8" произведена на один компьютер-сервер;
на соответствующее количество рабочих мест, с которых планируется организовать доступ к Серверу "1С:Предприятия 8", у Лицензиата имеются и правомерно используются Клиентские лицензии на "1С:Предприятие 8". "
Явно указанно, что запрещено, а в каких случаях все ОК.
построение систем на основе ПРОГРАММНОГО ПРОДУКТА с помощью средств и технологических решений, не предусмотренных в сопроводительной документации
Интересно, а Вы сами читали то, что вставили в пост?
(26) С каких пор консоль администрирования - это средство, не предусмотренное сопроводительной документацией? Или это особое технологическое решение?
Я этот вопрос изучал, и не нашел официальных ограничений на использование настроек.
Павел, ну при чем здесь консоль администрирования?
Никакое технологическое решение, относящееся согласно документации, к версии КОРП .не может использоваться с лицензией на "обычный" сервер.
Вы плохо изучали вопрос, я Вам по секрету скажу. На след неделе планирую получить право опубликовать здесь дополнительные сведения по данному вопросу, жду разрешения от Контрольной группы.
(28) Ключевая фраза "относящееся согласно документации, к версии КОРП ", в лицензии на "обычный" сервер есть такая фраза?
Проконсультируйтесь с юристами, являются ли ограничениями на один продукт текст лицензии на другой продукт?
Позиция фирмы 1С - нельзя использовать большую часть настроек кластера без наличия лицензии КОРП, но данная позиция только озвучена и никак не закреплена документальна для тех, кто не использует версию КОРП.
Как вы не можете понять, что все доп сведения и тому подобное, что вы опубликуете никакой юридической силы не имеют.
"Дополнительные сведения" не изменят уже подписанные договор и соглашение.
Есть договор, есть лицензионное соглашение, всё остальное: комментарии, мнения, выступления сотрудников - это просто слова.
До тех пор пока в соглашении на "обычный" сервер не появится информация о запрете использования настроек сервера приложений - использование их возможно.
p.s. "Вы плохо изучали вопрос" - общаться с вами бесполезно, так как вы даже не пытаетесь понять, что вам говорят.
Это может быть обусловлено разными причинами:
1) вы действуете в интересах фирмы франчайзи, которым выгодно продавать платформу версии КОРП, из-за более высокой цены как самого продукта, так и годового обслуживания.
2) вы верите в то, что произнесенные слова сотрудников фирмы 1С, автоматически изменяют лицензионное соглашение, а бумажные документы - это всего лишь полотна мертвого дерева, пришедшие к нам из прошлого века.
>Это может быть обусловлено разными причинами
Ок, чтобы вам было интересно продолжать (если есть еще что обсуждать), обозначу следующее:
1. Это не обусловлено тем, что поддерживаю интересы фирмы франчайзи.
2. Слова сотрудников фирмы 1С ни при чем.
3. Профессиональная деятельность связана с администрированием 1С:Предприятие 8, вопрос является важным как и с точки зрения позиции фирмы 1С, так и с точки зрения позиции других лиц, которые "видят" возможность использования КОРП без наличия соответствующих лицензий.
4. Имею образование, непосредственно связанное IT, может быть поэтому вижу явный запрет использования функционала КОРП, который не видите Вы.
5. Богатый опыт участия в разборе подобных вопросов на разном уровне заставляет быть осторожным в их рассмотрении
>в лицензии на "обычный" сервер есть такая фраза?
Не такая, а такая есть:
"не совершать и не допускать совершения третьими лицами следующих действий. с помощью средств и технологических решений, не предусмотренных в сопроводительной документации"
А функционал КОРП не предусмотрен для ПРОФ и это в явном виде указано в сопроводительной документации.
>Проконсультируйтесь с юристами, являются ли ограничениями на один продукт текст лицензии на другой продукт?
Зачем? это не связано с тем, что нельзя использовать средства, не предусмотренные для версии продукта документацией.
>Позиция фирмы 1С - нельзя использовать большую часть настроек кластера без наличия лицензии КОРП, но данная позиция только озвучена и никак не закреплена документальна для тех, кто не использует версию КОРП.
Закреплена. Посмотрите вставленный вами же текст лиц соглашения или начало этого поста.
>Как вы не можете понять
Кажется, все наоборот :) Понять не можете Вы.
>Есть договор, есть лицензионное соглашение, всё остальное: комментарии, мнения, выступления сотрудников - это просто слова
Верно. Но на тек момент я обозначаю вам явные указания из лиц соглашения, а вы "льете воду".
>До тех пор пока. не появится информация о запрете использования
Ранее уже оценил вашу позицию как "странную". Прочтите начало этого поста. Разрешено ТО, что предусмотрено ДОКУМЕНТАЦИЕЙ.
>общаться с вами бесполезно, так как вы даже не пытаетесь понять, что вам говорят
:)
>1) вы действуете в интересах фирмы франчайзи, которым выгодно продавать платформу версии КОРП, из-за более высокой цены как самого продукта, так и годового обслуживания
Неа, все не так.
>2) вы верите в то, что произнесенные слова сотрудников фирмы 1С, автоматически изменяют лицензионное соглашение, а бумажные документы - это всего лишь полотна мертвого дерева, пришедшие к нам из прошлого века
Опять недолет :) Просто прочтите начало поста. Там есть, кажется, все что нужно для правильного вывода.
Инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие
Ниже приводится инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие.
Рекомендуется при настройке рабочего сервера пройти указанный ниже сheck-лист и продумать, нужна ли указанная ниже настройка в вашем конкретном случае.
Если такая настройка нужна, то выполнить её. Важно на каждом пункте сознательно принимать решение о том, как именно вы хотите настроить рабочий сервер.
1. Определить, сколько информационных баз будут использоваться в кластере для работы пользователей
Существует несколько вариантов развертывания:
- в продуктивной среде и подготовительной зоне;
- в тестовой зоне;
- в зоне разработки.
Наибольшие требования с точки зрения доступности информационной системы будут в случае развертывания в продуктивной и подготовительной зонах.
В этих случаях желательно все нерабочие информационные базы вынести в отдельный кластер на отдельные серверы.
Возможно, возникнет желание сделать копию рабочей информационной базы и развернуть в том же кластере в продуктивной среде, например, для того, чтобы восстановить определенные данные за прошлые сутки. Стоит перебороть это желание и проследить, чтобы
- к копии базы не было доступа у пользователей;
- в копии базы были выключены регламентные задания;
- копия базы не участвовала в обменах.
Для восстановления данных за предыдущие сутки не стоит использовать продукционный кластер, а получать необходимые данные с подготовительной зоны информационной системы.
Рекомендуется в продуктивной зоне настраивать кластер с минимальным числом необходимых баз, чтобы снизить возможное влияние тестовых баз на работу пользователей.
В тестовой зоне и зоне разработки ограничений по числу информационных баз в кластере условно нет.
2. Определить, сколько пользователей будет работать одновременно
Число одновременно работающих пользователей информационной базы является одним из основных параметров, определяющих нагрузку на информационную систему.
Этот параметр также необходим для корректного расчета конфигурации оборудования, который выполняется исходя из
- Конфигурации системы;
- Сценария работы пользователей;
- Числа одновременно работающих пользователей;
- Используемых версий программных продуктов.
3. Настроить профили пользователей ОС, от которых будут запускаться процессы кластера
Необходимо определиться, будут ли процессы кластера серверов работать от имени различных пользователей информационной системы.
Это может быть необходимо для того, чтобы код, который выполняется в rphost точно не мог обратиться к каким-либо определенным данным на рабочем сервере или выполнить операцию с административными правами.
Для этого нужно:
Для того, чтобы создать профили пользователей ОС достаточно один раз войти от их имени в ОС Windows.
4. Настроить логирование и дампы
Для этого необходимо настроить:
- Технологический журнал
- Сбор дампов процессов кластера средствами Платформы (указнием в logcfg.xml секции dump) либо Windows Error Reporting Services
Хорошей практикой будет настроить сбор WER для rmngr и ragent, но не указывать rphost.
5. Проверить настройки операционной системы
5.1. Настроить рабочий сервер
5.2. Настроить рабочий сервер
Необходимо настроить рабочий сервер в соответствии с инструкцией, которая позволяет избежать ошибки "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full"
5.3. Убедиться, что брадмауэр операционной системы настроен таким образом, что не запрещает процессам кластера взаимодействовать корректно.
Информация по клиент-серверному варианту работы здесь;
Обратите внимание на используемые порты, которые указываются в параметрах центрального сервера,
в свойствах кластера серверов,
и рабочих серверов кластера.
--port или -p указывает сетевой порт, по которому утилита администрирования будет взаимодействовать с сервером администрирования. Значение по умолчанию равно 1545.
5.4. Убедиться, что на рабочих серверах кластера одновременно не используется IPv4 и IPv6.
5.5. Убедиться, что схема управления питанием - "Высокая производительность".
5.6. Убедиться, что установлены компоненты Microsoft Data Access Components
Этот пункт нужен для настройки с СУБД MS SQL Server.
В противном случае будете получать ошибку вида: "Компоненты OLE DB провайдера не найдены".
6. Необходимо настроить сетевой стек для обеспечения возможности обработки большого числа подключений
Настройки, которые необходимо выполнить (в дополнение к настройке 5.2. Настроить рабочий сервер в соответствии с инструкцией):
- Запустить regedit и в ветке HKLM\System\CurrentControlSet\Services\Tcpip\Parameters указать
- MaxFreeTcbs= 100000
- TcpTimedWaitDelay= 30
- MaxUserPort= 65535
- EnableDynamicBacklog= 1
- MinimumDynamicBacklog= 20
- MaximumDynamicBacklog= 20000
- DynamicBacklogGrowthDelta= 10
- Выполнить: netsh int ipv4 set dynamicport tcp start=10000 num=55536
- Выполнить: netsh int ipv4 set dynamicport udp start=10000 num=55536
7. Настроить кластер серверов
7.1. Необходимо добавить рабочие серверы в кластер
7.2. Настроить условия перезапуска
Настроить условия перезапуска по превышению порога памяти.
7.3. Настроить расположение каталога кластера
Необходимо убедиться, что
- на дисках достаточно места;
- сеансовые данные расположены на быстрых дисках;
7.4. Настроить число соединений и информационных баз на процесс
Настройку необходимо выполнить с учетом конфигурации системы
Постарайтесь выполнять настройку таким образом, чтобы она не приводила к запуску 100 процессов rphost, т.к. значительное число процессов rphost приводит к неэффективному использованию памяти процессами кластера.
Не стоит просто так уменьшать параметр "Число соединений на процесс" или "Число информационных баз на процесс".
Если у вас нет технического обоснования, почему именно так лучше, рекомендуем оставить значения по умолчанию
7.5. Выполнить настройки для случая нескольких рабочих серверов в кластере.
- Обязательно должно быть явно указано расположение:
- сервиса журнала регистрации;
- сервиса полнотекстового поиска данных;
- сервиса работы с внешними источниками данных;
- расположение клиентских и серверных лицензий и сервисов лицензирования;
- расположение сеансовых данных.
8. Первый запуск
На этом этапе следует выполнить следующие шаги:
- Запустить кластер серверов, создать информационную базу;
- Зарегистрировать программные лицензии;
- Убедиться, что пользователь может войти в информационную базу без ошибок.
9. Отказоустойчивость
В случае необходимости настройки отказоустойчивого кластера, выполните следующие шаги.
9.1. Проверить лицензии.
Убедитесь, что на рабочих серверах, которые должны выполнять роль Центральных серверов достаточно лицензий для работы всех пользователей в информационной системе при отсутствии одного из Центральных серверов в случае возможного (теоретически) отказа.
9.2. Установить флаг "Центральный сервер".
Установить флаг как на рисунке ниже.
9.3. Установить флаг "Уровень отказоустойчивости"
Установить параметр, пример на рисунке ниже.
Подробную информацию про уровень отказоустойчивости вы можете прочитать в статье
Обратите внимание, что не нужно просто так указывать максимально возможный уровень отказоустойчивости, т.к. это приведет к избыточным накладным расходам.
9.4. Скорректировать строку соединения
Необходимо скорректировать строку соединения с информационной базой.
Имеется возможность указания списка резервирования с помощью строки соединения с информационной базой или в соответствующем поле свойств информационной базы.
Список указывается в формате Server1, Server2:Port, Server3.
10. Замечания
10.1. Не настраивайте exec backup (или аналогичные утилиты) на директории кластера серверов
Причина в том, что в этих директориях могут располагаться хранилища с сеансовыми данными, выполнять backup которых не нужно, а создание backp-а которых будет приводить к избыточным накладным расходам.
10.2. Не настраивайте сжатие данных дисков с директорией кластера
10.3. Не забывайте про периодическое выполнение дефрагментации дисков ОС Windows.
10.4. Настроить защиту от вирусов.
В случае расположения рабочих серверов кластера в зоне, к которой доступ строго ограничен, не имеет смысл настраивать антивирусные решения на рабочих серверах.
Настройка антивирусных решений на таких серверах будет оказывать существенное влияние на производительность при практическом отсутствии выигрыша с точки зрения защиты.
При этом, стоит обеспечить защиту антивирусными решениями те пользовательские компьютеры, с которых выполняется доступ к рабочим серверам кластера и сетевым директориям.
В данной статье будут рассмотрены несколько вариантов структуры 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С
В высоконагруженных системах 1С требуется тщательно проработать систему отказоустойчивости, чтобы бизнес не испытывал простоев, а все сбои были незаметны для конечного потребителя.
Мы тщательно анализируем возможности отказоустойчивости в разных системах, вплоть до холодного резервного копирования на европейских серверах (дублирование на уровне ЦОД).
В данной статье мы рассмотрим возможность кластеризации сервера 1С. Мы подобрали два аналогичных сервера, чтобы получилось распределить нагрузку на сервера 1С.
Устанавливаем 1С:Предприятие 8 на двух серверах с запуском службы “Агент сервера 1С:Предприятие 8.3 (x86-64)”.
Рисунок 1 - Установка сервера 1С:Предприятие
После установки, переходим в “Администрирование серверов 1С Предприятия x86-64”.
Заходим в параметры кластера и вводим общее имя кластера, а также указываем “уровень отказоустойчивости” в нашем случае ставим 1 уровень.
Рисунок 2 - Параметры кластера
На втором сервере удаляем “Локальный кластер”, сделанный по умолчанию. Подключаемся к новому созданному кластеру с именем “Cluster1C”.
Создаем “рабочий сервер”, указываем что этот рабочий сервер является “центральным”.
Рисунок 3 - Параметры рабочего сервера
Заходим в Рабочие серверы => SQL => Требования назначения функциональности, создаем новое требования для клиентского соединение с ИБ, тип требования: назначить.
Повторяем тоже самое на рабочем сервере SQL2.
Управление кластером заключается в том, что администратор определяет состав компьютеров (рабочих серверов), на которых размещается кластер. Кроме этого (при необходимости), он может определить требования к ним: какие сервисы и соединения с информационными базами должны работать на каждом из рабочих серверов.
Менеджеры кластера и рабочие процессы запускаются автоматически, исходя из назначенных требований. Требования к рабочим серверам могут быть заданы интерактивно, из консоли администрирования кластера, или программно, из встроенного языка.
После этого мы можем наблюдать как происходит распределение нагрузки на кластере 1С.
Интересует отказоустойчивое решение 1С? Мы предлагаем готовый кластер 1С в аренду.
Устанавливая 1С в клиент-серверном варианте, случается, что специалисты оставляют настройки кластера серверов 1С 8.3 по умолчанию. Это может приводить к неоптимальному использованию аппаратных ресурсов эксплуатируемых серверов и к нестабильной работе серверов 1С и СУБД. В статье рассмотрим рекомендации по основным настройкам кластера серверов 1С 8.3 и СУБД MS SQL.
1. Рекомендации по настройке кластера 1С 8.3
Обратите внимание, что настройки кластера отвечают за настройки всех серверов принадлежащих настраиваемому кластеру. Кластер подразумевает работу нескольких физических или виртуальных серверов, работающих с одними и теми же информационными базами.
Интервал перезапуска – отвечает за частоту перезапуска рабочих процессов кластера. Этот параметр необходимо выставлять при круглосуточной работы сервера. Рекомендуется частоту перезапуска связывать с технологическим циклом информационных баз кластера. Обычно это каждые 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 раз в день. Статистика отвечает за производительность выполнения запросов.
План электропитания – в настройках электропитания операционной системы установить на высокую производительность.
Читайте также: