В этой статье мы расскажем о нашем опыте проектирования ИТ-структуры для крупного клиента.
К нам обратился крупный энергетический холдинг по производству тепло- и электроэнергии, передаче и поставке тепла и горячего водоснабжения потребителям. Одной из целей проекта данного заказчика было определение требований к производительности системы ERP, оптимальной для одновременной работы до 1 500 пользователей в режиме терминального доступа.
В качестве первого этапа, перед нами стояла задача реализовать рабочий прототип IT-структуры, на основе которого можно будет вычислить требования к полноценной системе. Прототип должен был максимально учесть следующие факторы:
- Отказоустойчивость
- Катастрофоустойчивость
- Безопасность
- Достаточную производительность
- Разделение на среду разработки, тестовую и производственную области с фильтрацией трафика между ними
- Запас ресурсов на ближайшие 2 года
Подготовка тестового стенда
Проектирование архитектуры и реализация тестового стенда происходила следующим образом:
- Для соблюдения требований по катастрофоустойчивости было решено разделить систему на два ядра - основное и резервное. Каждое из них расположить в дата-центре соответствующего класса (см. таблица 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 часа | Нет | Да |
- Между основным и резервным дата-центрами был построен шифрованный сетевой туннель класса IPsec с уровнем шифрования AES 256-bit.
- Репликация серверной структуры с основного на резервный хостинг производилась регулярно в режиме online посредством технологии синхронизации Hyper-V Replica.
- Маршрутизацию, ограничение сетевого доступа и предоставление сетевого доступа к сервису ERP в каждом дата-центре обеспечили два аппаратных маршрутизатора Cisco, объединенные в кластер active-passive с требованиями не ниже, чем указаны в таблице 2
Таблица 2. Требования к маршрутизаторам
| Параметры | Требования |
| Количество устройств | Не менее 2 шт |
| Встроенные интерфейсы 10GE | Не менее 2 шт |
| Встроенные интерфейсы 1 GE | Не менее 24 шт |
| Пропускная способность | Не менее 40 Гбит\с |
| Производительность | Не менее 55 млн пакетов в секунду |
| Поддержка протоколов | eBGP, iBGP, OSPF |
| Резервирование | Поддержка функционала автоматического резервирования сервисов по модели «основной\резервный» |
- Серверная структура в каждом дата-центре была разделена на три логических области – среду разработки, среду тестирования и продуктивную среду (см. схема 1).
Схема 1. Общая архитектура
- Каждая среда находится в отдельном vlan (логическая «виртуальная» локальная компьютерная сеть).
- Физическое ядро указанных структур состояло из:
- Система хранения данных Hitachi
- Две аппаратные серверные платформы класса Twin - носители виртуальных машин
- Два аппаратных сервера ERP и СУБД
- SAN-сеть, базированная на Fibre Channel 16 Gbit/s
- Структура среды разработки представляла собой сервер терминального доступа и сервер ERP+СУБД
- Среда тестирования являлась приближенной копией продуктивной среды и архитектурно полностью повторяет ее строение, но с меньшим количеством ресурсов.
- Структура продуктивной среды состояла из (см. схема 2):
- Кластера нескольких серверов ERP
- Кластер нескольких web-серверов
- Основного и резервного серверов управления базами данных MS SQL
Схема 2. Архитектура производственной среды
- Формат ERP-кластера был active-active. Это означает, что запросы клиентов ERP равномерно были распределены по всем серверам ERP.
- Сервера управления базами данных SQL основной и резервной структуры были объединены в кластер Microsoft SQL AlwaysOn с регулярной онлайн репликацией баз данных.
- Взаимодействие кластера серверов ERP с сервером управления базами данных было выполнено посредством сетевого доступа TCP/IP через специальный сервис Microsoft SQL Listener. Такая архитектура обеспечивает автоматическое переключение запросов на резервную структуру СУБД в случае возникновения проблем с основной структурой СУБД.
- Кластер web-сервисов объединил службу IIS в основном и резервном датацентре. Запросы к web-сервису происходят посредством сетевого доступа TCP/IP через специальный сервис Microsoft web cluster. Такая архитектура обеспечивает автоматическое переключение запросов на резервный web-сервис в случае возникновения проблем с основным.
- Более подробное описание схем обеспечения отказоустойчивости в таблице 3:
Таблица 3. Схемы отказоустойчивости
| Объект | Описание технологии кластеризации |
| Отказоустойчивость маршрутизаторов | Отказоустойчивость достигается использованием системы, состоящей из основного и дублирующего аппаратных шлюзов |
| Отказоустойчивость серверов ERP | Отказоустойчивость достигается за счет объединения всех серверов ERP в единый кластер с автоматическим переключением при сбое и сохранением текущих сессий |
| Отказоустойчивость серверов SQL | Реализуется при помощи технологии AlwaysOn Microsoft SQL Server, при которой основной и резервный экземпляр СУБД находятся на разных физических носителях и работают одновременно. Синхронизация данных происходит в режиме реального времени. При выходе из строя основного SQL-сервера - запросы автоматически переводятся на резервный, благодаря роли прослушивателя группы доступности |
Проведение тестирования
Вторым этапом была выполнена подготовка нагрузочных тестов совместно с программистами, запуск итерационного тестирования и расчет требуемых мощностей для 1 500 пользователей ERP:
- На основании имеющихся реестров процессов и контрольных примеров макета базы ERP, была создана матрица сценария тестирования производительности.
- Количественные и целевые показатели операций были усредненно рассчитаны, исходя из данных реальных баз клиентов ERP и экспертных оценок. На входе сценария было дано количество вводимых документов в день по каждому виду документа, количество пользователей и время тестирования, а система сама рассчитывала сколько документов и отчетов должно создаваться и проводиться за указанный промежуток времени и с каким интервалом.
- Тесты проводились в рамках нескольких групп пользователей. Группа состояла из 4 пользователей, у каждого из которых была своя роль и перечень последовательных операций, которые выполняет каждый из пользователей:
- количество групп пользователей рассчитывалось по формуле N=K/4, где K – количество пользователей (из расчета, что в одной группе 4 пользователя);
- количество цепочек на одну группу рассчитывалось исходя из того, что одна группа в день за 8 рабочих часов делает 24 цепочки. Таким образом за 1 час одна группа делает 24/8=3 цепочки с интервалом 20 минут;
- количество номенклатур в массиве, из которого будет случайным образом подбираться номенклатура в документ поступления, рассчитывалось по формуле: P=(K/4)*10*93%, где K – это количество пользователей.
- На каждом шаге тестирования были определены показатели Apdex по нагрузке на систему из расчета на одного пользователя:
- Обращений к диску в секунду;
- Потребляемая оперативная память;
- Потребляемые процессорные мощности.
- На основании этих показателей были рассчитаны требования к параметрам оборудования на 150 пользователей ERP.
- Далее, исходя из этих расчетов были проведены эти же тесты на 150 пользователей. Были сверены теоретические прогнозы с фактическими расчетами, выведен коэффициент погрешности.
- Далее были повторены итерации тестов Apdex на 100, 200 и 500 пользователей. Для каждой итерации были сверены теоретические прогнозы с фактическими расчетами, выведен коэффициент погрешности.
- В итоге, для 1 500 пользователей ERP были выполнены теоретические расчеты методом прямой экстраполяции замеров, полученных на меньших объемах.
Таким образом, мы проработали все поставленные задачи:
- Создан рабочий прототип ИТ-структуры для ERP, включающий в себя зоны разработки, тестирования и производственную зону.
- Структура предусматривала соблюдение требований к стабильности, быстродействию и отказоустойчивости сервисов.
- Путем проектировочных расчетов и замеров производительности были вычислены требования для одновременной работы до 1 500 пользователей системы ERP в режиме терминального доступа для конкретных баз ERP.
Мы готовы предоставить хостинг для 1С:ERP и спроектировать необходимую инфраструктуру любого размера.
EFSOL