Создание прототипа ИТ-структуры для 1С:ERP на 1500 пользователей

В этой статье мы расскажем о нашем опыте проектирования ИТ-структуры для крупного клиента.

К нам обратился крупный энергетический холдинг по производству тепло- и электроэнергии, передаче и поставке тепла и горячего водоснабжения потребителям. Одной из целей проекта данного заказчика было определение требований к производительности системы ERP, оптимальной для одновременной работы до 1 500 пользователей в режиме терминального доступа.

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

  • Отказоустойчивость
  • Катастрофоустойчивость
  • Безопасность
  • Достаточную производительность
  • Разделение на среду разработки, тестовую и производственную области с фильтрацией трафика между ними
  • Запас ресурсов на ближайшие 2 года

Подготовка тестового стенда

Проектирование архитектуры и реализация тестового стенда происходила следующим образом:

  1. Для соблюдения требований по катастрофоустойчивости было решено разделить систему на два ядра - основное и резервное. Каждое из них расположить в дата-центре соответствующего класса (см. таблица 1), находящихся на расстоянии не менее 50 км друг от друга и связанных между собой прямым оптоволокном с пропускной способностью не менее 2 гбит/с.

Таблица 1. Требования к дата-центрам

Требования к дата-центру Резервный дата-центр класса Tier2 Основной дата-центр класса Tier3
Активное оборудование N N+1
Распределенные потоки 1 2
Возможность обслуживания ЦОД без остановки Нет Да
Годовой простой (часов) 28,8 1,6
Надежность инфраструктуры 99,671 99,982
Вероятность остановки в течение 5 лет 37,17 25,91
Дублирование каналов связи и IT-оборудования клиента Нет Да
Отдельное здание Нет Да
Серверные комнаты от других помещений отделены стенами, выдерживающими огонь не менее 1 часа Нет Да
  1. Между основным и резервным дата-центрами был построен шифрованный сетевой туннель класса IPsec с уровнем шифрования AES 256-bit.
  2. Репликация серверной структуры с основного на резервный хостинг производилась регулярно в режиме online посредством технологии синхронизации Hyper-V Replica.
  3. Маршрутизацию, ограничение сетевого доступа и предоставление сетевого доступа к сервису ERP в каждом дата-центре обеспечили два аппаратных маршрутизатора Cisco, объединенные в кластер active-passive с требованиями не ниже, чем указаны в таблице 2

Таблица 2. Требования к маршрутизаторам

Параметры Требования
Количество устройств Не менее 2 шт
Встроенные интерфейсы 10GE Не менее 2 шт
Встроенные интерфейсы 1 GE Не менее 24 шт
Пропускная способность Не менее 40 Гбит\с
Производительность Не менее 55 млн пакетов в секунду
Поддержка протоколов eBGP, iBGP, OSPF
Резервирование Поддержка функционала автоматического резервирования сервисов по модели «основной\резервный»
  1. Серверная структура в каждом дата-центре была разделена на три логических области – среду разработки, среду тестирования и продуктивную среду (см. схема 1).

Схема 1. Общая архитектура

  1. Каждая среда находится в отдельном vlan (логическая «виртуальная» локальная компьютерная сеть).
  2. Физическое ядро указанных структур состояло из:
    • Система хранения данных Hitachi
    • Две аппаратные серверные платформы класса Twin - носители виртуальных машин
    • Два аппаратных сервера ERP и СУБД
    • SAN-сеть, базированная на Fibre Channel 16 Gbit/s
  3. Структура среды разработки представляла собой сервер терминального доступа и сервер ERP+СУБД
  4. Среда тестирования являлась приближенной копией продуктивной среды и архитектурно полностью повторяет ее строение, но с меньшим количеством ресурсов.
  5. Структура продуктивной среды состояла из (см. схема 2):
    • Кластера нескольких серверов ERP
    • Кластер нескольких web-серверов
    • Основного и резервного серверов управления базами данных MS SQL

Схема 2. Архитектура производственной среды

  1. Формат ERP-кластера был active-active. Это означает, что запросы клиентов ERP равномерно были распределены по всем серверам ERP.
  2. Сервера управления базами данных SQL основной и резервной структуры были объединены в кластер Microsoft SQL AlwaysOn с регулярной онлайн репликацией баз данных.
  3. Взаимодействие кластера серверов ERP с сервером управления базами данных было выполнено посредством сетевого доступа TCP/IP через специальный сервис Microsoft SQL Listener. Такая архитектура обеспечивает автоматическое переключение запросов на резервную структуру СУБД в случае возникновения проблем с основной структурой СУБД.
  4. Кластер web-сервисов объединил службу IIS в основном и резервном датацентре. Запросы к web-сервису происходят посредством сетевого доступа TCP/IP через специальный сервис Microsoft web cluster. Такая архитектура обеспечивает автоматическое переключение запросов на резервный web-сервис в случае возникновения проблем с основным.
  5. Более подробное описание схем обеспечения отказоустойчивости в таблице 3:

Таблица 3. Схемы отказоустойчивости

Объект Описание технологии кластеризации
Отказоустойчивость маршрутизаторов Отказоустойчивость достигается использованием системы, состоящей из основного и дублирующего аппаратных шлюзов
Отказоустойчивость серверов ERP Отказоустойчивость достигается за счет объединения всех серверов ERP в единый кластер с автоматическим переключением при сбое и сохранением текущих сессий
Отказоустойчивость серверов SQL Реализуется при помощи технологии AlwaysOn Microsoft SQL Server, при которой основной и резервный экземпляр СУБД находятся на разных физических носителях и работают одновременно. Синхронизация данных происходит в режиме реального времени. При выходе из строя основного SQL-сервера - запросы автоматически переводятся на резервный, благодаря роли прослушивателя группы доступности

Проведение тестирования

Вторым этапом была выполнена подготовка нагрузочных тестов совместно с программистами, запуск итерационного тестирования и расчет требуемых мощностей для 1 500 пользователей ERP:

  1. На основании имеющихся реестров процессов и контрольных примеров макета базы ERP, была создана матрица сценария тестирования производительности.
  2. Количественные и целевые показатели операций были усредненно рассчитаны, исходя из данных реальных баз клиентов ERP и экспертных оценок. На входе сценария было дано количество вводимых документов в день по каждому виду документа, количество пользователей и время тестирования, а система сама рассчитывала сколько документов и отчетов должно создаваться и проводиться за указанный промежуток времени и с каким интервалом.
  3. Тесты проводились в рамках нескольких групп пользователей. Группа состояла из 4 пользователей, у каждого из которых была своя роль и перечень последовательных операций, которые выполняет каждый из пользователей:
    • количество групп пользователей рассчитывалось по формуле N=K/4, где K – количество пользователей (из расчета, что в одной группе 4 пользователя);
    • количество цепочек на одну группу рассчитывалось исходя из того, что одна группа в день за 8 рабочих часов делает 24 цепочки. Таким образом за 1 час одна группа делает 24/8=3 цепочки с интервалом 20 минут;
    • количество номенклатур в массиве, из которого будет случайным образом подбираться номенклатура в документ поступления, рассчитывалось по формуле: P=(K/4)*10*93%, где K – это количество пользователей.
  4. На каждом шаге тестирования были определены показатели Apdex по нагрузке на систему из расчета на одного пользователя:
    • Обращений к диску в секунду;
    • Потребляемая оперативная память;
    • Потребляемые процессорные мощности.
  5. На основании этих показателей были рассчитаны требования к параметрам оборудования на 150 пользователей ERP.
  6. Далее, исходя из этих расчетов были проведены эти же тесты на 150 пользователей. Были сверены теоретические прогнозы с фактическими расчетами, выведен коэффициент погрешности.
  7. Далее были повторены итерации тестов Apdex на 100, 200 и 500 пользователей. Для каждой итерации были сверены теоретические прогнозы с фактическими расчетами, выведен коэффициент погрешности.
  8. В итоге, для 1 500 пользователей ERP были выполнены теоретические расчеты методом прямой экстраполяции замеров, полученных на меньших объемах.
Таким образом, мы проработали все поставленные задачи:
  • Создан рабочий прототип ИТ-структуры для ERP, включающий в себя зоны разработки, тестирования и производственную зону.
  • Структура предусматривала соблюдение требований к стабильности, быстродействию и отказоустойчивости сервисов.
  • Путем проектировочных расчетов и замеров производительности были вычислены требования для одновременной работы до 1 500 пользователей системы ERP в режиме терминального доступа для конкретных баз ERP.
Аватар EFSOL

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

Заказ демонстрации по продукту

Создание прототипа ИТ-структуры для 1С:ERP на 1500 пользователей

обязательные поля
*
Фамилия, имя, отчество:

Как к Вам обращаться?

 
  
Название организации:

Нужно нашим специалистам

 
  
Ваш E-mail адрес:

Необходим для обратной связи и оповещений

 
*
Ваш номер телефона:

Введите код и номер телефона

 
* Антиробот:
Введите ответ

Есть вопросы?

Закажите звонок специалиста!

Есть вопросы?

Закажите звонок специалиста!
нажимая на кнопку, вы даете согласие на обработку персональных данных