Создание кластера 1с 8.3. Решение возможных проблем с установкой

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

Прежде чем брать в руки мышку и бежать в серверную, следует четко усвоить необходимый минимум знаний, а именно иметь представление о структуре сервера 1С Предприятия и назначении его отдельных компонентов. Большинство проблем при внедрении связано с тем, что сервер 1С Предприятия воспринимается в качестве некоего монолитного образования, в котором все компоненты связаны между собой хитрым, одному разработчику известным, способом. Однако это не так и сегодня мы разберемся из чего же состоит наш сервер и как это все между собой работает.

Хотелось бы еще раз подчеркнуть чрезвычайную важность того, о чем пойдет речь ниже. Не обладая данными знаниями будет проблемно добиться стабильной работы, не говоря уже о диагностике узких мест и увеличении производительности. В итоге может получится классическая картина: вроде бы железо мощное, сделано все по инструкции, а тормозит. К сожалению, большинство инструкций для начинающих (и наша в том числе) содержат информацию лишь о том как сделать, не заостряя внимание что именно делается и почему. Поэтому начнем исправляться.

Клиент-серверная версия 1С Предприятия представляет собой трехуровневую структуру (т.н. "трехзвенка"), в которую входят: клиент, сервер 1С Предприятия и сервер СУБД. Это полностью независимые компоненты, которые могут сочетаться в любой допустимой комбинации для достижения наилучшего результата. Рассмотрим следующую схему:

Начнем с клиентов, текущая версия платформы (8.2) предусматривает использование трех типов клиентов. Разберем их подробнее.

Толстый клиент

Это классическое клиентское приложение 1С, до выхода платформы 8.2 он был единственно доступным видом клиента. Схема работы толстого клиента следующая: клиентское приложение запрашивает данные у сервера 1С, то в свою очередь запрашивает их из БД и предает обратно клиенту, на котором и производится их обработка. Как можно заметить, данная схема неоптимальна: сервер 1С по сути является всего лишь прослойкой между клиентом и БД, все вычисления происходят на клиенте. Это накладывает повышенные требования на клиентские ПК, т.к. вычислительные мощности сервера не используются. Стоит четко понимать, что в режиме толстого клиента вы не получите увеличения быстродейстивия от перехода к клиент-серверной версии, возможно даже наоборот.

Тонкий клиент

Его можно назвать основным видом клиентского приложения для платформы 8.2, в теории, на практике не все так гладко и мы еще к этому вернемся. Схема его работы кардинально иная: клиент запрашивает данные у сервера 1С, тот получает их из БД, обрабатывает и отдает клиенту результат вычислений. Основная вычислительная нагрузка при этом ложится на сервер, поэтому особых требований к клиентским ПК и каналу от клиента к серверу не предъявляется.

Также тонкий клиент может работать как по протоколу TCP/IP в локальной сети, так и через HTTP через интернет. Для этого требуется еще один посредник - веб-сервер, который передает запросы клиента серверу 1С, никакой обработки данных на веб-сервере не производится, он используется исключительно как транспорт. Преимущества тонкого клиента понятны, он позволяет, при наличии мощного сервера, значительно ускорить работу с программой, также значительно снижается сетевой трафик, что весьма актуально для офисных сетей.

Веб-клиент

Его существование логично вытекает из некоторых свойств тонкого клиента, действительно, если все запросы обрабатываются сервером, транспортом служит HTTP, то почему бы не использовать для работы браузер? Схема работы веб-клиента ничем не отличается от тонкого, однако на сегодняшний день не все функции поддерживаемые тонким клиентом реализованы и корректно работают в веб-клиенте. Отчасти это можно исправить в конфигурации, отчасти накладывает ограничения механизм вывода информации в браузер. Однако веб-клиент у 1С есть и он работает и никто не мешает вам (опять таки в теории) работать в программе лежа на пляже с планшетом.

Теперь о ложке дегтя в бочке меда. Для нормальной работы в режиме тонкого и веб-клиентов конфигурация должна работать в режиме управляемого приложения и поддерживать все функции в данном режиме. Режим управляемого приложения является основным для платформы 8.2 и довольно радикально отличается от того, что было раньше, в том числе и внешне. Визуально управляемое приложение можно отличить по новому интерфейсу, отличительными чертами которого являются вкладки и гиперссылки:

Как минимум, непривычно, особенно в сравнении с классическим интерфейсом, но не спешите радоваться, увидев новый интерфейс, кроме внешнего вида, конфигурация должна поддерживать исполнение на сервере всего своего функционала, вполне может оказаться, что в режиме тонкого и веб-клиента будут доступны не все возможности.

На сегодня в режиме управляемого приложения работает лишь часть типовых конфигураций, такие как: Управление небольшой фирмой, Управление торговлей 11, Розница 2 и Зарплата и управление персоналом. Эти решения могут использовать все преимущества новой платформы. Бухгалтерия предприятия 2.0 не использует режим управляемого приложения и в тонком и веб-клиентах работать не будет, это же относится и ко многим сторонним решениям, таким как "Камин" и т.п.

Выводы

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

Веб-клиент следует использовать тогда, когда нет возможности воспользоваться тонким, например с чужого ПК в командировке, при этом следует быть готовым к отсутствию или некорректной работе некоторых функций.

Кластер серверов 1С

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

Также система не накладывает никаких требований к платформам. Вы можете совместно использовать как Windows так и Linux сервера, в качестве веб-сервера можно использовать Apache и IIS, из СУБД поддерживаются PostgreSQL, MS SQL Server, IBM DB2 и Oracle. Поэтому никто не мешает вам создать схему, в которой сервер 1С работающий на платформе Linux будет работать совместно с сервером БД под управлением Windows Server и IIS и наоборот. Кроме того вы можете использовать несколько серверов СУБД (как и веб-серверов) располагая разные базы на разных серверах.

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

И наконец самое интересное: кластер серверов 1С Предприятия. Да, именно так, не одиночный сервер, а кластер серверов. Обычно здесь и начинаются непонятки, особенно если сервер один. Однако все встает на свои места, если принять во внимание, что понятие кластера серверов в первую очередь логическое, однако данный подход легко позволяет масштабировать схему повышая ее производительность или отказоустойчивость.

Любой кластер состоит из Центрального сервера 1С Предприятие и рабочих серверов. В простейшей конфигурации это будет один и тот же физический сервер. Однако при необходимости мы можем добавить дополнительные рабочие сервера, нагрузку по которым будет балансировать центральный сервер. Это позволяет быстро и прозрачно для пользователей увеличить вычислительную мощь системы и увеличить отказоустойчивость. Кластер также не накладывает требований к однородности платформы, в его составе могут работать сервера как под управлением Windows, так и под управлением Linux.

Какие выводы можно сделать из вышесказанного? Во первых, клиент-серверная система 1С Предприятие является весьма гибкой и позволяет оптимальным образом использовать доступные вычислительные ресурсы для получения оптимального результата. Какую именно конфигурацию выбрать, зависит от конкретных задач и средств, выделяемых для их решения.

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

И наоборот, при использовании управляемого приложения в режиме тонкого клиента сервер СУБД и кластер серверов лучше разнести по разным серверам, каждый из которых будет оптимизирован под свою задачу.

Ставя очередное обновление Бухгалтерии получил ошибку "Я работаю только на 8.3.4", ну вот... пришло время поставить 8.3.4. и так:

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

Служба Агент Сервера 1С
По умолчанию он ставиться на порт 1540, а там у меня крутится 8.2, поэтому меняем в ветке рееста
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent Параметр ImagePath
меняем номера портов, добавляя смещение: "C:\Program Files\1cv8\8.3.4.365\bin\ragent.exe" -srvc -agent -regport 1741 -port 1740 -range 1660:1691 -d "C:\Program Files\1cv8\srvinfo"

Запускаем Агента и Открываем консоль Администрирования серверов 1С и создаем кластер 8.3
Указал имя сервера и настроил на порт 1740 (на 1540 работает 8.2)

Создаем кластер + чуток оптимизировал(У меня всего небольшой ОДИН сервер, поэтому - указываю Интервал перезапуска рабочих процессов и объем памяти. т.к у меня один сервер - уровень отказоустойчивости - 0)


Теперь подробнее:
1. Интервал перезапуска: 86400 сек (24 часа). Момент перезапуска не регламентируется, видимо с момента установки параметров, либо запуска сервера приложений.
2. Также можно указать допустимый объем памяти: 3000000 Кб (3 Гб) - Для сервера с 4 ГБ оперативы, Если ее меньше, то не заполняйте этот параметр! .
3. Интервал превышения допустимого объема памяти - это непрерывный интервал времени превышения допустимого объема памяти, после которого сервер перезапустит процесс. Если указано 0 сек - будет ждать вечно.
4. Количество Рабочих процессов расчитывается автоматически на основании Ваших настроек
5. Уровень отказоустойчивости можно задавать уровень отказоустойчивости кластера как количество рабочих серверов, которые могут одновременно выйти из строя, и это не приведет к аварийному завершению работы пользователей. Резервные сервисы запускаются автоматически в количестве, необходимом для обеспечения заданной отказоустойчивости; в реальном режиме времени выполняется репликация активного сервиса на резервные.
6. Режим распределения нагрузки, который можно использовать либо для повышения производительности системы вцелом, либо использовать новый режим «экономии памяти», который позволяет работает «с ограниченной памятью» в случаи если используемая конфигурация «любит отъедать память».

Рабочий сервер
Сервер у меня простенький, 2 Gb оперативы всего и на нем будет всего 2 базы, поэтому настрою его так:

параметр Количество ИБ на процесс ставлю равным 1, т.е. хочу чтобы для каждой ИБ запускался свой процесс - это позволит уменьшить взаимное влияние как по надежности, так и по производительности. Вы же настраивате под характеристики своего сервера!

Информационная база
Добавляю ИБ:

В стартере пописываю базу:

Требования назначения функциональности
Я у себя это не настраиваю но думаю надо сказать об этом:
Управление кластером заключается в том, что администратор определяет состав компьютеров (рабочих серверов), на которых размещается кластер. Кроме этого (при необходимости) он может определить "требования" к ним: какие сервисы и соединения с информационными базами должны работать на каждом из рабочих серверов. Менеджеры кластера и рабочие процессы запускаются автоматически, исходя из назначенных "требований". "Требования" к рабочим серверам могут быть заданы интерактивно, из консоли администрирования кластера, или программно, из встроенного языка.
Так на ноутбуке с ключом защиты чтобы не запускать пользователей на сервер кластера надо добавить «требования» для объекта требования «Клиентское соединение с ИБ» - «Не назначать», т.е. запретить рабочим процессам данного сервера обрабатывать клиентские соединения. Еще больший интерес предоставляет возможность запускать «только фоновые задания» на рабочем сервере кластера без сеансов пользователей. Таким образом можно высоконагруженные задачи (код) вынести на отдельный машины. При чем можно одно фоновое задание «закрытия месяца» через «Значение дополнительного параметра» запускать на одном компьютере, а фоновое задание «Обновление полнотекстового индекса» на другом. Уточнение происходит через указание "Значение дополнительного параметра". Например если указать BackgroundJob.CommonModule в качестве значения, то можно ограничить работу рабочего сервера в кластере только фоновыми заданиями с любым содержимым. Значение BackgroundJob.CommonModule..- укажет конкретный код.

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

Стандартно, после создания, профиль безопасности запрещает выполнение всех потенциально опасных действий:
-обращение к файловой системе сервера;
-запуск COM-объектов;
-использование внешних компонентов 1С:Предприятия;
-запуск внешних обработок и отчётов;
-запуск приложений, установленных на сервере;
-обращение к ресурсам Интернета.
Таким образом защититься от нежелательных действий незнакомого прикладного решения очень просто: нужно создать пустой профиль безопасности и назначить его информационной базе. Далее, если есть необходимость, можно расширять этот профиль, описывая в нём действия, которые разрешается выполнять прикладному решению.

Расположение служебных файлов менеджера кластера в 1С Предприятии 8.3
Если при установке системы! «1С:Предприятие» был выбран вариант запуска сервера «1С:Предприятия» как сервиса, то первый запуск агента сервера будет выполнен еще в процессе установки системы. При этом сервис будет запущен от имени пользователя, выбранного в диалоге установки системы, но служебные файлы кластера серверов будут расположены в каталоге <каталог установки системы 1С:Предприятие>\srvinfo (в параметрах сервиса будет в явном виде указан ключ запуска -d).

Если при установке системы «1С:Предприятие» был выбран вариант запуска сервера как приложения, то запуск сервера в процессе установки системы не выполняется; агента сервера необходимо запустить самостоятельно, после того как установка системы будет закончена. При этом если ключ запуска -d указан не будет, служебные файлы кластера серверов будут расположены в каталоге по умолчанию: %USERPROFILE%\LocalSettings\ApplicationData\lC\lCv8 (%LOCALAPPDATA%\lC\lCv8 для ОС WindowsVista и старше).

ВНИМАНИЕ! Если однажды на данном центральном сервере уже был создан кластер, то при смене варианта запуска агента сервера (сервис, приложение) или при смене пользователя, от имени которого работает агент сервера, всегда следует заботиться о правильном указании пути к каталогу служебных файлов кластера серверов. Если в процессе запуска агент сервера не обнаружит список кластеров, он создаст новый кластер на данном сервере.
В операционной системе Linux служебные файлы кластера серверов будут расположены в папке /home/usrlcv8/.lcv8/lC/lcv8 (или сокращенный вариант записи - ~/.1cv8/1C/1cv8).

Если в вашей компании программным обеспечением от 1С пользуются несколько сотрудников, то достаточно закупить хороший сервер и правильно его настроить. Однако если число пользователей достигло 150-200 человек и это еще не предел, то установка кластера серверов поможет снизить нагрузку на оборудование. Конечно, установка дополнительного оборудования и подготовка специалистов для поддержки работоспособности кластера потребует некоторых финансовых и временных ресурсов, но это долговременное вложение, компенсирующее впоследствии все затраты за счет бесперебойной работы системы. При этом многое зависит от правильной настройки кластера – производительность можно увеличить в несколько раз без дорогостоящих вложений. Поэтому, перед тем как изучать функционал и закупать сервера, необходимо удостовериться, нужен ли вам кластер серверов 1С вообще.

Когда стоит устанавливать кластер серверов 1С?

При проектировании схемы работы и расчете необходимых мощностей серверов в ПО достаточно часто случаются ошибки. На начальном этапе системные администраторы могут их нивелировать с помощью увеличения количества оперативной памяти или модернизации ЦПУ и других узлов. Но всегда приходит момент, когда эти возможности иссякают, и установка кластера серверов становится фактически неизбежной. Именно она позволит решить основные проблемы высоконагруженных систем:

  • Отказы оборудования и сетей. Для особо важных баз данных рекомендуется создать кластер серверов, исполняющий роль резервного;
  • Недостаточная безопасность баз данных. Дополнительным преимуществом является возможность шифрования данных из ПО на платформе 1С;
  • Неравномерное распределение нагрузки на узлы сервера. Решается с помощью создания нескольких «рабочих процессов», контролирующих клиентские соединения и запросы;
  • Помимо решения данных проблем правильно настроенный кластер серверов 1С позволяет существенно экономить на поддержке стабильной работы приложений 1С.

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

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

Рассмотрим данный алгоритм на примере объединения двух серверов 1С 8.2 в кластер

Допустим, на сегодня у вас имеется два сервера, на одном из которых (S1C-01) установлен сервер 1С и информационные базы. Чтобы настроить отказоустойчивый кластер серверов, необходимо на сервере S1C-02 развернуть сервер 1С:Предприятие и начать рабочий процесс. Убедитесь, что в его свойствах установлен пункт «Использование» в состояние «Использовать». Регистрировать информационные базы нет необходимости.


После этого в консоли администрирования 1С необходимо добавить в раздел «Резервирование кластеров» резервный кластер с именем второго сервера – S1C-02. В аналогичный раздел второго сервера добавляем резервный кластер с именем S1C-01 и перемещаем его на верхнюю позицию. Для этого воспользуйтесь контекстным меню и командой «Переместить вверх». Необходимо добиться одинакового порядка в этих группах обоих серверов.

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

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

Нагрузка на кластер и оптимизация

Тестирование нагрузки

Наиболее распространенными технологиями тестирования кластера серверов 1С считаются:

  1. Тест Гилева;
  2. Тест центр из 1С:КИП.

В первом случае мы имеем дело с инструментом, позволяющим оценить файловые и клиент-серверные базы. Он включает в себя оценку скорости работы системы, интерфейсов, длительных операций и количества ресурсов для функционирования. Большим плюсом является универсальность – нет никакой разницы, какую конфигурацию вы будете им тестировать. На выходе получается оценка в условных единицах.

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

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

Самый простой путь ускорить работу 1С – увеличить характеристики серверов. Но бывали случаи, когда из-за неверных настроек после модернизации железа ситуация лишь ухудшалась. Поэтому при жалобах на зависания, рекомендуется в первую очередь проверить настройки кластера в сервисе администрирования.

Необходимо отнестись с полной ответственностью ко всем действиям. Параметры кластера могут серьезно повлиять на производительность и возможность работы, как в лучшую сторону, так и в противоположную. Каждый параметр оказывает влияние на все сервера, входящие в кластер. Поэтому перед тем, как изменять что-либо, необходимо понять, за что отвечает настройка кластера 1С.


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

Очень важно, чтобы отказоустойчивый кластер серверов 1С был защищен от перерасхода памяти. Один неудачный запрос в цикле может забрать себе всю мощность многоядерных серверов. Чтобы воспрепятствовать этому существует два параметра кластера – «Допустимый объем памяти» и «Интервал превышения допустимого объема». Если вы правильно и точно настроите эти параметры, то обезопасите свои информационные базы от многих распространенных бед.

Ограничение процентного показателя «Допустимое отклонение количества ошибок сервера» позволит выявить рабочие процессы со слишком большим количеством ошибочных обращений. Кластер будет их принудительно завершать, если выставлена соответствующая галка. Это поможет обезопасить «безошибочные» процессы от зависаний и ожиданий.

Еще один параметр – «Выключенные процессы останавливать через» отвечает за регулярное отключение подключений к серверу через заданные промежутки времени. В 1С после завершения работы рабочие процессы висят некоторое время, чтобы данные корректно перенеслись на новые процессы. Иногда происходят сбои и на сервере остаются висеть процессы. Они тратят ресурсы и намного полезнее существенно минимизировать их количество.

Кроме оптимизации непосредственно кластера, также необходимо правильно настроить каждый сервер, входящий в него. Для удобства оптимизации сервера и проверки производительности администраторы используют агент сервера – ragent. В нем храниться информация о том, что запущено на определенном сервере. Для получения данных по используемым информационным базам необходимо обратиться к менеджеру сервера – rmngr.

Для грамотной оптимизации воспользуйтесь консолью кластера серверов и для каждого сервера настройте следующие параметры:

  • Максимальный объем памяти всех рабочих процессов. Если этот показатель равен 0, то система отводит под процессы 80% оперативной памяти, если же в поле стоит 1, то все 100%. Если на одном сервере стоят вместе 1С и СУБД, то существует вероятность конфликта из-за памяти и необходимо воспользоваться этой настройкой. В ином случае достаточно будет стандартных 80% или рассчитать, сколько необходимо памяти ОС, а оставшееся количество занести в это поле;
  • Безопасный расход памяти за 1 вызов. По умолчанию значение «0», означающее, что 1 рабочий процесс будет занимать менее 5% максимального объема оперативной памяти на все процессы. Значение «-1» проставлять не рекомендуется, так как оно снимет все ограничения, что чревато последствиями в виде зависаний;
  • Количество информационных баз и соединений на процесс. Эти параметры управляют распределением нагрузки на рабочие процессы. Вы можете настроить их по своим требованиям, чтобы минимизировать потери при излишней нагрузке на сервер. Если установлено значение в 0, то ограничения не действуют, что опасно при большом количестве рабочих мест.

В версии 8.3 еще одной полезной характеристикой для верного распределения нагрузки на сервер является «Менеджер под каждый сервис». Этот параметр дает возможность использовать не один менеджер сервера (rmngr), а множество, каждый из которых отвечает за свою задачу. Это отличная возможность отследить, какой сервис вызывает ухудшение производительности, и измерить количество ресурсов на каждую задачу.

После установки данной характеристики агент сервера ragent перезагрузится и вместо одного rmngr.exe в консоли вы обнаружите целый список. Теперь вы сможете через диспетчер задач найти процесс, загружающий систему и заняться точечной настройкой. Отличить эти процессы друг от друга вам поможет их pid. Однако, так как это нововведение, специалисты 1С рекомендуют осторожно использовать эту возможность.

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

Заказать демонстрацию Заказать

В данной статье будут рассмотрены несколько вариантов структуры 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С + SQL AlwaysOn Кластер 1С + SQL AlwaysOn с шифрованием
Кластер 1С с одним сервером СУБД
Классический 1С+СУБД SharedMemory
Легкость инсталляции и обслуживания Удовл. Удовл. Хорошо Отлично
Отказоустойчивость Отлично Отлично Удовл. Не применимо
Безопасность Удовл. Отлично Удовл. Удовл.
Бюджетность Удовл. Удовл. Хорошо Отлично

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


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

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

Этап тестирования состоит из двух ключевых инструментов синтетической генерации нагрузки и имитации работы пользователей в 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
  • RAM - 96 ГБ
  • I\o: Intel Sata SSD Raid1

Сервер 1С и СУБД - физический сервер

  • 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С.



Схема архитектуры 1С

Среднее время выполнения операции, сек

 Средний процент отклонения от эталона Тест Гилева, усл. ед.
50 пользователей 100 пользователей 150 пользователей
Схема структуры №1 "Кластер 1С-серверов, подсоединенный к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP" 0,42245 0,44433 0,4391 На 14% 25,13
Схема структуры №2 "Кластер 1С-серверов, подсоединенный к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP с шифрованием" 0,435505 0,425227 0,425909 На 12% 21,65
Схема структуры №3 "Кластер серверов 1С "active-active", подсоединенный к единственному серверу СУБД по протоколу IP." 0,40901 0,41368 0,42852 На 9% 28,09
Эталон. Схема структуры №4 "Расположение сервера 1С и СУБД на одном аппаратном сервере без виртуализации с взаимодействием по SharedMemory" 0,36020 0,42385 0,36335 --- 34,23

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