Проблема сайзинга оборудования под ERP-систему сегодня все чаще волнует средние компании. Почти всегда с этой проблемой сталкиваются крупные компании, внедряющие ERP-системы на большое количество пользователей. Но средним компаниям уже не удается купить оборудование один раз и годами работать на нем. Предугадать требуемую производительность системы на два года вперед становится все трудней.
Кроме того, проблема не в быстром росте компании, а в сложности той задачи, которую надо решить. "Сайзинг представляет собой очень сложный момент, - комментирует Анатолий Ермаков, директор офиса разработки решений компании Columbus IT Partner Russia. - К каждой ситуации приходится подходить индивидуально, потому что у задачи слишком много параметров. Сайзинг - это как решение многокритериальной задачи. Можно обратить внимание на десять основных показателей и не учесть одиннадцатого, что выльется в существенную ошибку".
Задумывая этот тест, компания Columbus хотела в первую очередь сравнить три самые распространенные на сегодняшний день технологии - x86, IA64 и х64 (ЕМ64T). "Мы попытались суммировать и проанализировать основную проблему производительности наших клиентов, - говорит Анатолий Ермаков. - Система Microsoft Axapta совмещает в себе свойства OLTP- и DSS-системы. Другими словами, нельзя сказать, что это в чистом виде транзакционная система, работающая с большим числом коротких транзакций. Поэтому с ростом базы данных для нее важно количество оперативной памяти. У малых и средних клиентов проблем с оперативной памятью практически не возникает. Эта проблема скорее проявляется в больших инсталляциях. База данных растет, и пользователи нередко хотят использовать данные полугодичной или годичной давности, строя, например, сложные аналитические отчеты, и этим загружают систему и память". Как известно, у 32-разрядной архитектуры x86 существуют ограничения на объем оперативной памяти, обусловленные адресацией - 4 Гб на процесс. Вообще, Microsoft Ахарtа может работать с двумя СУБД: MS SQL Server и Oracle. "Причем SQL-сервер будет занимать максимум 3 ГБ памяти (без использования специальных приемов), а этого не всегда бывает достаточно для производительной работы системы, - комментирует Анатолий Ермаков. - Выходом является либо более дорогая технология IA64 (truly 64 bit), либо технология ЕМ64T, как промежуточный вариант между 32-битной и 64-битной технологиями". Поскольку технология ЕМ64T появилась чуть больше года назад и производители не так давно представили серверы на ней, то тестирование ставило целью выяснить, как будет работать ERP-система на серверах, построенных на такой технологии".
Методика
Для тестирования использовалось стандартное средство Microsoft Axapta 3.0 SP4 - Benchmark Tool. Это инструмент, который позволяет эмулировать работу большого количества пользователей, производить операции, создавать нагрузку в системе. В процессе тестирования использовались сценарии "Заказы" и "Закупки", то есть модуль автоматически создавал документы и обрабатывал их. Сценарии выполнялись на каждом из трех тестируемых серверов в течение одного и того же периода времени.
Перед тем как запустить непосредственно само тестирование, была создана тестовая база. Были сгенерированы справочники системы, потом началось наполнение базы данных, создание заказов и обработка расходных накладных. В смоделированной базе данных было около 10 000 клиентов и 5000 наименований номенклатуры, а объем ее составил 20 Гб. Была включена система множественных складских транзакций, а также российская специфика. "Есть в российской версии Microsoft Axapta такая функциональность, как корреспонденция счетов, - комментирует Анатолий Ермаков. - Это связано с определенными накладными расходами и отражается на производительности в основном на операциях разноски в главную книгу. Можно сказать, что российская версия поэтому работает чуть-чуть медленнее". Кроме того, в подобных тестах важен масштаб. Количество серверов приложений было жестко зафиксировано - специалисты Columbus остановились на шести. По их мнению, это позволяет достаточным образом загрузить систему.
Для получения результатов тестирования использовались показатели Benchmark Tool и данные Performance Monitor на серверах приложений и базах данных. При различном количестве пользователей замерялись количество обрабатываемых строк заказов в час и время отклика системы, средняя загрузка процессоров сервера СУБД и серверов приложений.
Промежуточная технология выгоднее?
Победа в тестах, как и ожидалось, оказалась за Itanium 2. Однако полученные результаты выявили интересную, не совсем ожидаемую, закономерность. "Можно сказать, что пиковая производительность сервера на Xeon с технологией ЕМ64Т всего на 10% меньше, чем у сервера на Itanium 2, при том что разница в цене достаточно существенна", - комментирует Анатолий Ермаков. Производительность сервера IBM eServer xSeries 366 Intel Xeon MP c поддержкой 64-битных расширений EM64T довольно существенно превосходит показатели платформы предыдущего поколения IBM eServer xSeries 445 Intel Xeon (32 бит). Производительность промежуточного решения EM64T выше, чем у 32-битной технологии, а цена серверов практически одинакова. "Соотношение "цена/производительность" у технологии EM64T наилучшее из всех, и выбор в этом случае очевиден", - утверждает Анатолий Ермаков.
Насколько этот результат можно распространить на других производителей серверов? "Я считаю, что результат на серверах других производителей будет похожим, - утверждает Анатолий Ермаков. - Я не вижу ограничений. С моей точки зрения, более важный параметр здесь - сами технологии, которые мы тестировали. Нужно только учитывать определенные условия, при которых был проведен тест".
Безусловно, в реальной жизни на выбор архитектуры влияет множество факторов. Во многом выбор системы определяется не сегодняшними нагрузками, а задачами завтрашнего дня, и в этом случае 10% производительности могут оказаться совсем не лишними. Но даже если не заглядывать далеко вперед, результаты этого теста нельзя считать окончательными.
"Преимущества той или иной архитектуры будут во многом определяться типом рабочей нагрузки и ее соответствием исполнительным устройствам процессора, качеством оптимизации программного кода и конфигурацией системы, - комментирует результаты теста Всеволод Предтеченской, ведущий специалист по применению продукции компании Intel. - Реальные цифры будут зависеть и от объема базы данных, и от типа и настроек операционной системы, и от дополнительных приложений (например, систем администрирования сервера), работающих параллельно с основной задачей. Выигрыш в 10% сам по себе не маленький, особенно если считать стоимость решения как совокупность стоимости аппаратуры и программного обеспечения. В применении к процессорам это может быть, например, на 10% более низкая тактовая частота процессора, иногда позволяющая применить процессоры со значительно более низкой стоимостью".
Границы применимости
Каковы же границы применимости этого тестирования? Тест продемонстрировал производительность трех различных платформ при решении довольно узкой задачи, а именно обработки заказов и закупок. Насколько результаты данного теста можно распространить на весь набор модулей Microsoft Axapta? В основу теста легла стандартная версия продукта, которая является так или иначе базовой для любого клиентского решения, построенного на Microsoft Axapta. Однако, Microsoft Axapta - это система-конструктор и конкретная реализация всегда связана со значительными доработками. В среднем - доработки составляют более 30% от функционала созданной системы (реже - 50%, а в ряде случаев, как, например, при внедрении в компании ПИТ, по словам ИТ-директора компании Михаила Михайлова, - до 80%). Насколько эти доработки изменяют картину производительности системы?
"Да, зачастую система дорабатывается, и многое зависит от того, как сделана доработка", - считает Анатолий Ермаков. Понятно, что на производительность как раз и оказывают влияние именно те вещи, которые меняют стандарты. И чтобы результаты полученных тестов были применимы к реальной системе заказчика, следует четко соблюдать определенные правила кастомизации - изменения и разработки новых компонентов системы. Вот простой пример, связанный с программной модификацией: скажем, в руководстве разработчика Microsoft Axapta указаны правила, которые нужно применять при создании модели данных или при разработке новой иерархии классов. И достаточно, например, программно создавать объект класса и выполнять его не на сервере приложений, а на клиентском месте, как производительность будет более низкой. Аналогично, достаточно при разработке отчета не использовать определенное ключевое слово, которое заставляет параметризоваться SQL-запросы, как скорость работы данного отчета может сильно упасть". Таким образом, чтобы иметь возможность руководствоваться результатами тестов, нужно играть по правилам - придерживаться стандартов кастомизации. При этом, как утверждает Анатолий Ермаков, полученное соотношение по производительности серверов останется в силе.
В таком случае не лучше ли было протестировать конкретный функционал одной из реальных инсталляций Microsoft Axapta в российских компаниях? Специалисты Columbus уверены, что нет. Конечно, можно провести множество различных тестов, с тем, чтобы показать результаты работы самой что ни на есть реальной системы (с конкретно заданным функционалом, количеством пользователей, и что более важно, с уже проведенными доработками). "Здесь нужно понимать, что подобные тестирования - это всегда больше обобщение, нежели конкретная ситуация, - говорит Анатолий Ермаков. - Если бы мы взяли для тестирования настроенную под конкретного клиента систему, то полученные результаты имели бы сугубо частный характер. Эти данные и выводы было бы сложно передавать и интерпретировать. К тому же возникает сложность со сценариями. Модуль Benchmark сильно связан с функциональностью Microsoft Axapta, и если мы хотим измерить этим модулем производительность какого-то частного решения, то должны программно его доработать. При этом полученные результаты будет очень сложно с чем-нибудь сравнить. Мы тестировали стандартную версию именно потому, что она является общим универсальным фундаментом для построения самых различных отраслевых и горизонтальных решений".
Шаги сайзинга
Какова же должна быть логика сайзинга оборудования под ERP-систему? Первый шаг - использование результатов подобных тестов производительности. Но только как отправную точку в выборе платформы и соотнесения показателей производительности с конкретными конфигурациями оборудования. Дальнейшее - вопрос работы эксперта.
В ближайшее время Columbus IT Partner и IBM планируют обновление Sizing Tool для Axapta. Sizing Tool - это Web-инструмент для сайзинга, который на основе введенных данных (количество одновременно работающих пользователей в разбиении по модулям, СУБД, с которой планируется работа) формирует таблицу с перечнем рекомендуемых серверов. "Sizing Tool мы планируем использовать как некий минимум, который рекомендуется клиенту, - говорит Анатолий Ермаков. - Дальше, используя нашу экспертизу, смотрим, есть ли у нас похожий клиент, какое он использует оборудование, есть или нет у него проблемы с производительностью и т. д. Как итог выдаем свою экспертную оценку". В дальнейшем компании надеются создать Sizing Tool, который будет выдавать не минимальную, а более приближенную к реальности конфигурацию оборудования. Но пока это только планы, и опираться приходится на экспертные оценки.
Здесь возникает вопрос доверия к эксперту. И даже получив минимальный сайзинг от вендора и экспертные оценки, клиент может не согласиться с предложенным вариантом. "Если речь идет о сложной дорогостоящей инсталляции с большим функционалом, количеством пользователей, то лучше провести нагрузочный тест для конкретной системы - считает Анатолий Ермаков. - В этом случае затраты на специально подготовленный тест с конкретными данными компании гораздо ниже, чем ошибка. По сравнению со стоимостью оборудования, протестировать конкретные данные стоит не так дорого. Обычно он делается за несколько месяцев до промышленной эксплуатации на планируемом оборудовании, которое либо уже есть, либо берется на время в аренду. Но такой подход справедливо использовать для сложных инсталляций и дорогих решений. Что касается более простых решений, то здесь проще довериться нашей экспертизе".
Понятно, что для любой компании ERP-проект сопряжен с определенными рисками. Компания инвестирует большие деньги в систему, в консалтинг, в изменение своих внутренних процессов. И рискуя вложенными средствами, не всегда готова вкладываться в аппаратную платформу с запасом мощностей, ориентированном на прогнозируемые нагрузки компании через год-два. Даже понимая, что приобретаемых мощностей сервера, скорее всего, не хватит для обработки тех данных, которые будут нагружать систему через год, компании по разным причинам не идет на поводу у консультантов, рекомендующих ту или иную платформу. В результате проект модернизации оборудования под ERP-систему превращается в спиральный процесс с постоянной заменой серверных мощностей. Можно, конечно, идти и по такому пути, только он заведомо более затратен, если не в плане денег, то уж точно, в плане времени.
