Быстрое внедрение ERP Комплексные услуги
от 1С:Центр ERP!
Управление доставкой Для торговых и курьерских компаний!
1C:ЭДО Узнайте о всех преимуществах электронного документооборота!
Переход на «1С:ЗУП ред. 3» Фирма «1С» прекращает поддержку «1С:ЗУП 2.5»!
Аренда сервера 1С
в облаке
Работайте в 1С удаленно с экономией до 70%!

В данной статье будут рассмотрены несколько вариантов структуры 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

Сервер 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

Сервер 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 серверами, но при таких настройках мы не получим автоматического переключения приложений на резервную ноду в случае сбоя. Переключение придется выполнять вручную.


 
Схема архитектуры 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С


Скачать полную таблицу сравнительных результатов



EFSOL

Системная интеграция. Консалтинг

ИТ-обслуживание

обязательные поля
* Антиробот:
Введите ответ

ИТ-обслуживание

Все поля формы выделенные значком * обязательны к заполнению
* Антиробот:
Введите ответ
Поделиться:
  • Здравствуйте. А почему не рассматривается вариант с классическим Failover-кластером SQL Server на редакции Standard (active-passive) ? SQL Server Enterprise со своим AlwaysOn стоит чуть меньше самолёта.
  • Здравствуйте. Не рассматривали по нескольким причинам 1) В интернет тестов по классическому кластеру SQL великое множество. Мы хотели продемонстировать менее заезженные модели архитектур. 2) Классический кластер требует единого хранилища СХД. А по нашему опыту - даже самые именитые брендированые СХД выходят из строя с утерей информации. Варианты же с организацией общего логического тома на нескольких распределенных физических хранилищах, по нашему мнению, имеют сомнительную надежность и пока что слабо развиты для Enterprise-сектора. 3) Статью писали с ориентированием на высоконагруженные системы, т.к. именно там мы сталкивались с проблемой торможения классического кластера SQL на СХД. А по нашему опыту, наполнение брендовых СХД SSD-дисками по стоимости гораздо выше закупки SQL Enterprise. 4) В последнее время повсеместно распространена модель аренды ПО Microsoft SPLA. В таком случае стоимость лицензии SQL Enterprise в месяц довольно необременительна

У вас конкретная задача? Свяжитесь с нами прямо сейчас!


Обратный звонок RedConnect