Версия для печати.   http://trsoft.ru/articles/9/?vprint=Y

«1С:УПП8»: практика масштабирования

 

Статьи по теме:

Реалистичное нагрузочное тестирование на 1000 пользователей

Технологическая экспертиза крупных внедрений и консультирование

«1С:УПП8»: практика масштабирования

Компания «Трейд Софт» в сентябре 2009 года провела серию тестов, в результате которых на практике получено подтверждение, что в одной информационной базе 1С может работать 1000 пользователей.

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

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

Для получения объективной картины при высокой нагрузке и очень большом количестве пользователей специалисты компании «Трейд Софт» провели реалистичное нагрузочное тестирование. За основу была взята типовая конфигурация «1С:Управление производственным предприятием 8» и предоставленное «Центром инноваций IBM» оборудование.

Отметим, что в данном случае речь идет не о синтетическом тестировании под нагрузкой, когда запускается 20, 50 или 100 псевдопользователей, каждый из которых работает за десятерых, а о более реалистичном сценарии. В ситуации, когда одновременно активны 1000 клиентских сессий, основные проблемы вызывает не столько высокая нагрузка от каждого конкретного пользователя, сколько общая острая конкуренция за информационные и аппаратные ресурсы.

Чтобы решить поставленную задачу, необходимо было определиться с комбинацией компонентов системы для выявления работоспособной конфигурации. Решение — это собранный стенд, на котором пользователи работают в одной базе, и при этом система справляется с нагрузкой.

Выбранные компоненты:

Первый компонент — технологическая платформа «1С:Предприятие 8», которая сама по себе производительна и масштабируема. Среди ее особенностей можно выделить три важные для решения задачи: клиент-серверная архитектура, возможность организации кластера серверов и построения распределенных информационных баз. Первый пункт комментариев не требует; второй на практике означает, что к кластеру можно подключать серверные рабочие процессы на физически разных компьютерах; третий, например, позволяет убрать тяжелые расчеты и отчеты из базы, в которой ведется напряженная оперативная работа.

Второй компонент решения — конфигурация «1С:Управление производственным предприятием 8». Этот флагманский продукт системы «1С:Предприятие 8» позиционируется как решение ERP-класса для комплексной автоматизации управления деятельностью предприятия; он ориентирован в том числе на крупных заказчиков, для одновременной работы на сотнях рабочих мест. (При этом программа сравнительно недорогая, учитывая масштаб задач, которые она позволяет решать.)

Третий компонент — «1С:Корпоративный инструментальный пакет 8». Это мощный, удобный и доступный в освоении инструмент, который предназначен для обслуживания системы и исследования производительности. Без такого инструмента проведение тестирования оказалось бы весьма затруднительным или невозможным в принципе. К примеру, имеется 1000 сеансов «1С:Предприятия», которыми надо управлять: инициировать определенные действия при подготовке и проведении теста, извлекать тестовую информацию и т.?д. Такая работа требует серьезных вычислительных мощностей, сопоставимых с основной задачей.

Четвертый компонент — СУБД IBM DB2. Эта СУБД обеспечивает высокие показатели производительности и надежности. Специфичных настроек почти не требуется, в частности, достаточно знать, какие буферпулы рекомендуется установить, изменить значение LOGFILSIZ на 16 384 вместо 1024 по умолчанию и сделать резервную копию.

Пятый компонент нашего решения — серверы серии IBM System P. При нагрузке в 1000 пользователей на четырехпроцессорном сервере СУБД вся работа выполнялась на одном процессоре, при этом он не сильно перегружался. Серверы IBM System P обеспечивают возможность гибкой настройки конфигурации. Например, при необходимости протестировать работу однопроцессорного сервера с 2-Гбайт памятью сотрудник «Центра инноваций» выполнял перенастройку в течение нескольких минут. Так же просто осуществлялось наращивание мощностей, например, до уровня четырехпроцессорной машины с 16-Гбайт ОЗУ.

Тестовый стенд состоял из семи машин. Два мощных сервера IBM X3950M2 — для клиентских рабочих мест, 650 на одном и 350 на другом. Сервер приложений был разнесен на две физические системы: половина на «блейде» IBM HS21 и половина на оставшихся ресурсах одного из X3950M2. СУБД DB2 9.7 функционировала на сервере IBM System P. Была сформирована классическая трехуровневая архитектура: клиент — сервер приложений — СУБД.

Обратим внимание на то, что основная нагрузка приходится на оборудование — компьютеры, на которых запускаются клиентские места. В реальных условиях это 1000 машин, в лабораторных — всего две, но с 64-Гбайт ОЗУ на каждой. Собственно, это и стало основной задачей, требующей решения при организации тестирования. Потребовалось также два вспомогательных сервера для размещения ключей защиты и отдельная машина, с которой запускается рабочее место оператора тест-центра.

На каждом сервере было сделано по восемь учетных записей, создан ярлычок быстрого доступа к БД с заданными реквизитами пользователя, который запускал виртуальное рабочее место. Была также подготовлена обработка, которая запускала виртуальных клиентов с интервалом в 5 с. Под каждой из учетных записей, как показала практика, на 64-бит архитектуре можно запустить около 240 пользователей, однако, чтобы сессия была «живая», лучше сделать эту цифру меньше — до 150. Процедура запуска теста выполнялась из терминальных клиентов (пятью-шестью учетными записями), из пустых баз стартовали обработки (по одной или до четырех параллельно).

Ключи защиты необходимо размещать на отдельных машинах, при этом из файла nethasp.ini были убраны все закомментированные и пустые строки. Оставлен минимум: только TCP/IP, единственный адрес менеджера лицензий и запрет на широковещательные рассылки пакетов. Тем, кто работает с ключами на большое количество лицензий (300 и 500), следует проверить в документации правила настройки nhsrv.ini; существует параметр, который обязательно надо редактировать.

После сборки и подготовки стенда были запущены виртуальные пользователи, каждый из которых выполнял действия, заданные тестовым сценарием, имитируя типичные рабочие операции. В этом качестве был принят типовой тестовый сценарий («Закупки, производство и продажа»), предполагающий работу четырех отделов (сбыта, снабжения, цеха и склада), в каждом — по 250 операторов, выполняющих ежедневную работу. Среди операций — отслеживание заказов, обеспечение потребностей, отражение выпуска, оформление отгрузок, документооборот и др. Каждые 7–8 мин поступает новый документ на 10–15 позиций. Пользователям предоставлена полная параллельность по данным; в этом есть некоторое отличие от реальной жизни, усложняющее ситуацию (но при такой настройке необходимых ожиданий на блокировках нет и нагрузка на оборудование максимальна).

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

По итогам испытаний можно сделать ряд выводов:

 
ГК Трейд Софт, Москва
Автор: Филиппов Е.В.
Источник: http://pcmag.ru/solutions/detail.php?ID=42079
Дата публикации: 01.08.2010 г.