Серверная инфраструктура для ERP-системы

Александр Герасимов
руководитель группы анализа рынка, «Консалтинговая группа «Борлас».
С ним можно связаться по e-mail: a.gerasimov@borlas.ru

Андрей Кувалдин
руководитель группы серверных решений, «Консалтинговая группа «Борлас».
С ним можно связаться по e-mail: a.kuvaldin@borlas.ru

Недооценка требований ERP-системы в ходе модернизации ИТ-инфраструктуры может привести к невозможности нормального ее функционирования; а переоценка — к неоправданным затратам и существенному ухудшению показателей ROI и TCO проекта в целом. Наш опыт говорит о том, что при создании ИТ-инфраструктуры под ERP не существует универсально оптимальных решений. Поэтому в каждой конкретной ситуации необходимо пройти все стадии проектирования.

ERP относится к классу «тяжелых» бизнес-приложений, предъявляющих определенные и весьма жесткие требования к аппаратной платформе, обеспечивающей ее функционирование. В первую очередь это относится к серверной составляющей и системе хранения данных и выражается в требованиях как к архитектуре перечисленных составляющих инфраструктурной платформы, так и к техническим характеристикам элементов, ее образующих. В данной статье нам бы хотелось выйти за рамки только технической стороны задачи и попытаться рассмотреть эту задачу в целом, по возможности осветив и некоторые «нетехнические» аспекты, которые, тем не менее, весьма сильно влияют на выбор того или иного технического решения.

Общие требования к инфраструктурной платформе

Очевидно, что функции серверной системы и дисковой подсистемы диктуются требованиями бизнес-приложения, в рассматриваемом нами случае — ERP-системой.

Требованиям ERP-системы отвечают следующие функции:

• обеспечение доступа пользователей к приложениям (основное требование — скорость отклика системы);
• обработка и хранение данных (основные требования — высокая производительность и надежность);
• защита данных на уровнях хранения, доступа и передачи.

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

1. Серверная платформа. Решить задачу создания эффективной серверной платформы под ERP можно лишь на основе системного подхода к ее организации. Основа такого подхода — использование иерархической архитектуры, отвечающей архитектуре программного комплекса. Основной архитектурой тяжелых ERP-систем является трехуровневая архитектура: уровень серверов баз данных, уровень приложений и уровень доступа (пользовательский). Соответственно архитектура аппаратной платформы должна отвечать архитектуре ERP-системы. Для каждого уровня характерны свои особенности и, как следствие, требования к аппаратному обеспечению и системам хранения данных. В таблице перечислены основные характеристики уровней информационной системы и приведены основные требования, предъявляемые к оборудованию. Кроме того, процесс внедрения ERP-системы предполагает наличие трех видов сред: продуктивной среды, среды разработки и среды тестирования.

Таблица. Характеристики уровней иерархической информационной системы

2. Дисковая подсистема. Наряду с серверами важной составляющей аппаратной платформы под ERP является система хранения данных. Для небольших и тестовых систем могут использоваться внутренние системы хранения и системы начального уровня с прямым подключением к серверу (SAS — Server Attached Storage), а для более-менее серьезных инсталляций речь всегда идет о сети хранения данных (SAN) и системе хранения данных в масштабе предприятия.

Определение требуемых технических характеристик составляющих архитектуры представляет собой классическую задачу оптимизации: как обеспечить требуемое быстродействие, надежность и доступность системы, при этом не затратив лишних средств. Всеми основными вендорами ERP и серверного оборудования разработаны методики сайзинга (sizing), используя которые, можно «в первом приближении» оценить количество процессоров и оперативной памяти серверов по количеству и типу пользователей (включая планируемую динамику их роста), а также по набору модулей внедряемой ERP-системы.

Этапы реализации и проектирование

Задачу создания любой ИТ-системы, в том числе и задачу создания/модернизации ИТ-инфраструктуры под требования ERP-системы, можно разбить на три основных этапа:

• проектирование (системное, техническое, рабочее), включая аудит существующей (унаследованной) ИТ-инфраструктуры предприятия;
• монтаж, тестирование, ввод в эксплуатацию;
• техническая поддержка системы и обучение персонала.

Этап проектирования во многом определяет успешность проекта в целом, поэтому нам хотелось бы осветить именно его основные аспекты.

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

Однако именно на этом этапе и начинаются основные проблемы. Наиболее типичны следующие.

1. На практике определение параметров оборудования под ERP-систему — значительно более сложная задача, нежели просто расчет сайзинга. Реальные требования со стороны ERP-системы зачастую существенно отличаются от расчетных из-за доработки стандартной функциональности ERP-системы (кастомизации).
2. Помимо определения необходимых в настоящий момент характеристик оборудования, необходимо учесть текущую ситуацию с ИТ-инфраструктурой предприятия, а также перспективы развития его бизнес-приложений. Именно такой подход может дать ключ к оптимизации масштабов ИТ-инфраструктуры под задачи бизнес-приложений.
3. Обязательно должны быть учтены «нетехнические» факторы: время жизни применяемых в том или ином «железе» технологий, перспективы рассматриваемых линеек оборудования на рынке, наличие квалифицированной технической поддержки в требуемой точке, политика вендора в России и т. д. и т. п. Зачастую именно такие факторы и играют в реальной жизни ключевую роль при выборе инфраструктурной платформы под ERP-систему.
4. Функционирование ERP-системы предполагает выполнение большого количества задач. Во-первых, ERP-система не является монолитным приложением: она состоит из сервера баз данных, сервера (или серверов) приложений и сервера доступа. Во-вторых, жизненный цикл внедрения и эксплуатации ERP-системы предполагает функционирование как минимум трех сред — продуктивной, тестовой и среды разработки. Существует довольно много вариантов распределения вычислительных ресурсов между данными задачами. Варианты отличаются друг от друга подходами к организации управления ресурсами, утилизации доступных ресурсов, а также тесно связанных с указанными выше вопросами обеспечения надежности и отказоустойчивости.
5. Вычислительная система и дисковая подсистема — не единственные составляющие инфраструктурной платформы. В нее также входят: телекоммуникационная подсистема, система бесперебойного электропитания, система прецизионного кондиционирования и прочее. Поэтому рассматриваемые в данной статье системы должны проектироваться и создаваться в комплексе, с учетом оптимизации работы смежных систем, что также добавляет сложности при проектировании.

На самом деле получить ответы на эти вопросы можно только эмпирическим путем, основываясь на глубоком понимании особенностей развертывания и функционирования бизнес-приложения (ERP-системы), хорошем знании всей линейки оборудования основных вендоров серверных систем и СХД, наличии адекватной информации о текущем состоянии ИТ-инфраструктуры предприятия и более-менее четком понимании его бизнес-стратегии. Именно бизнес-стратегии, а не ИТ-стратегии, поскольку требования бизнеса первичны, а ИТ-стратегия компании, даже если она и существует, зачастую оторвана от задач бизнеса. Универсально оптимальных решений здесь не существует. Поэтому, не тратя время на их поиски, мы постараемся рассмотреть несколько основных аспектов решения.

Выбор вендора аппаратной платформы

На стадии проектирования самым сложным решением будет выбор вендора аппаратной платформы. Стоит обратить внимание на следующие основные моменты.

• Уровень развития ИТ на российских предприятиях сейчас уже достаточно высок, и аппаратная платформа под ERP, как правило, создается не на пустом месте. Поэтому, пожалуй, основным требованием на этапе выбора вендора (наряду с нужной функциональностью) является сохранность ранее сделанных предприятием инвестиций и преемственность платформы, наличие обученного персонала и многое другое, что подразумевается понятием «преемственность». Другими словами, чем шире используется продукция вендора на предприятии, тем больше вероятность ее использования и в новых ИТ-проектах этого предприятия.
• Не менее важен полный учет требований вендоров ERP-систем, которые во многом отражают степень совместимости бизнес-ПО и аппаратной платформы.
• Поскольку для реализации различных уровней архитектуры системы требуются серверы различной мощности, а аппаратную платформу лучше создавать на базе продуктов одного вендора, то весьма важна полнота продуктовой линейки, перекрывающей весь диапазон серверов — от начального уровня до мощных high-end систем.
• При выборе системы хранения данных отдельной задачей окажется выбор производителя. Принципиальный вопрос: использовать моновендорное решение (серверы и система хранения данных одного производителя) или систему хранения независимого производителя? У каждого варианта есть свои плюсы и минусы. С одной стороны, моновендорные решения проще и стабильнее — поставка и сопровождение из одних рук (имеется в виду как вендор, так и партнер), гарантированная совместимость на всех уровнях, единое управление. С другой стороны, системы хранения независимых производителей могут быть функционально богаче (обычно такая дополнительная функциональность заметно удорожает решение). Однако для ERP-систем эта функциональность часто оказывается невостребованной, так как те же задачи успешнее решаются на уровне программного обеспечения. Однозначных рекомендаций в данном вопросе быть не может, но хотелось бы акцентировать внимание на том, что базовым требованиям со стороны ERP-систем, таким как обеспечение производительности, надежности и масштабируемости, отвечают правильно сконфигурированные системы хранения всех основных производителей. Применение системы хранения данных от независимого производителя должно быть оправданным. Прежде всего это актуально для проектов по консолидации систем хранения, при использовании встроенных сервисов для решения задач по управлению данными и так далее. К слову, в линейке продуктов всех основных производителей RISC-серверов имеются системы хранения данных, где подобная развитая функциональность также доступна.

Выбор конфигурации

Следующий этап — определение оптимальной конфигурации системы и обеспечение масштабируемости платформы. Как правило, требования, которые ERP-системы предъявляют к производительности и масштабируемости серверного оборудования и дисковой подсистемы, оказываются на порядок выше требований старых унаследованных систем и всего того, с чем ранее имело дело предприятие. Недооценка этих требований, желание сэкономить может привести к очень и очень серьезным проблемам на стадии перехода к промышленной эксплуатации ERP-системы (когда более производительное оборудование придется закупать и устанавливать все равно, но — в авральном порядке и в стрессовых условиях). В случае же особо критичных для бизнеса приложений, функционирующих в непрерывном режиме, когда простой может повлечь за собой существенные финансовые потери (иногда в таком режиме функционируют и отдельные модули ERP-системы), рекомендуются отказоустойчивые дублированные конфигурации серверного оборудования. С другой стороны, к вопросу резервирования следует подходить разумно и взвешенно, поскольку любое ИТ-решение должно быть экономически обосновано, и затраты на резервирование не должны превышать возможных потерь от сбоев системы. Резервирование — это своего рода страховка, стоимость которой не должна превышать стоимость застрахованного объекта.

При определении конфигурации стоит обратить внимание на следующие моменты.
1. Дифференциация требований. Как следует из таблицы, требования к производительности и отказоустойчивости существенно различаются в зависимости от уровня составляющих аппаратной платформы (уровень серверов СУБД, уровень приложений и уровень доступа). Наиболее жесткие требования предъявляются к уровню серверов СУБД. Обычно это многопроцессорный hi-end UNIX-сервер с не менее чем восемью процессорами и достаточной масштабируемостью и отказоустойчивостью.
2. Дисковая подсистема может быть «узким местом». ERP-системы стоят на фундаменте СУБД, которые характеризуются высокой дисковой активностью. Недооценка требований к производительности дисковой подсистемы может привести к дисбалансу в производительности аппаратного комплекса, когда дисковая подсистема оказывается «узким местом». Расчет дисковой подсистемы «по объему», а не «по производительности» — типичная ошибка, результатом которой может оказаться недостаточная производительность всей системы в целом. Для больших инсталляций дисковые массивы с десятками и сотнями дисков — вполне обычное дело.
3. Масштабируемость и гибкость платформы должна быть максимальной. К сожалению, редко когда удается на стадии проектирования точно рассчитать оптимальную конфигурацию рассматриваемых систем хотя бы на ближайшую перспективу. Ведь даже если у предприятия есть четкий, расписанный по этапам план развития программных бизнес-приложений, где гарантия, что все будет сделано в соответствии именно с этим планом? Очень часто приходится и аппаратную платформу подстраивать под изменившиеся реалии. Поэтому единственно возможное эффективное решение — это обеспечение уже на стадии проектирования максимальной гибкости и масштабируемости аппаратной платформы. Как показывает опыт, в реальной ситуации, с учетом упомянутых сложностей с точным определением требуемых технических характеристик аппаратной платформы, масштабируемость и гибкость системы никогда не бывают излишними, и эти характеристики целесообразно запроектировать «по максимуму».
4. Практический подход к обеспечению отказоустойчивости. Вопрос крайне обширен, и в данной статье мы вкратце остановимся лишь на аспекте оптимизации этого показателя. С отказоустойчивостью ситуация несколько иная, нежели с масштабируемостью. Здесь необходимо соблюдать баланс между основным показателем отказоустойчивости — временем восстановления системы — и стоимостью реализации, поскольку зависимость между этими показателями — нелинейная (см. рис). Поэтому нужно четко просчитать, во сколько, с одной стороны, обойдется (в единицу времени) простой системы для предприятия, а с другой — во сколько обойдется сокращение времени восстановления, и найти оптимум.

Управление ресурсами

Еще один важный момент — возможность управления аппаратными ресурсами. Для успешной эксплуатации ERP-системы в течение всего ее жизненного цикла крайне важна правильная архитектура серверной платформы. От нее зависит возможность управления ресурсами, повышение их утилизации (следовательно, и оптимизация финансовых параметров платформы), а также обеспечение отказоустойчивости.

Как же можно управлять аппаратными ресурсами? Мы не говорим о тривиальном варианте “под каждую задачу — свой сервер”. Понятно, что при таком подходе возможности управления ресурсами минимальны. Во-первых, часть задач может совмещаться на одном сервере. Разделение ресурсов при этом осуществляется средствами операционной системы либо специального менеджера ресурсов. Возможности современных UNIX-систем позволяют управлять ресурсами довольно эффективно. Во-вторых, возможна виртуализация ресурсов и создание программных разделов. В-третьих, в условиях многокомпонентных бизнес-приложений оказывается весьма востребованной функциональность современных многопроцессорных RISC-серверов в области организации разделов: возможность динамического разделения аппаратных ресурсов между несколькими хостами, организуемыми внутри одного физического сервера, позволяет, с одной стороны, разделять задачи, с другой — поддерживать максимальную утилизацию ресурсов.

Мы не ставили себе задачи рассказать про все возможности управления ресурсами, но хотелось бы отметить, что правильная архитектура дает возможность эффективно управлять ресурсами, надежностью системы и оптимизировать стоимость решения.

Для наглядности проиллюстрируем имеющиеся возможности управления ресурсами на примере решений Sun Microsystems. Старшие серверы линейки Sun Fire допускают разбиение на домены. Каждый домен представляет собой полностью изолированную машину со своей копией операционной системы. При этом аппаратные ресурсы могут без остановки сервера и перезагрузки операционной системы в доменах добавляться и перераспределяться между доменами. Внутри домена ресурсы между задачами могут разделяться посредством так называемых “контейнеров”, которым назначаются лимиты по использованию процессорной мощности и оперативной памяти. И наконец, в новейшей версии операционной системы Solaris 10 появились так называемые “зоны”, которые позволяют создавать внутри одной машины множество виртуальных машин — со своими процессами, программным обеспечением и сетевыми адресами. Как и в случае контейнеров, встроенный в операционную систему менеджер ресурсов контролирует распределение процессорной мощности, оперативной памяти и полосы пропускания сети между виртуальными серверами.

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

Описанные выше возможности создают предпосылки для консолидации вычислительных ресурсов. С одной стороны, стартовая стоимость консолидированного сервера и системы хранения данных существенно превосходит стоимость нескольких небольших серверов и разрозненных дисковых массивов. Но с учетом масштабируемости и отказоустойчивости high-end оборудования, широких возможностей управления ресурсами — в долговременной перспективе, с учетом совокупной стоимости владения, внедрение консолидированных систем может быть оправданным. Никто не призывает консолидировать абсолютно все информационные ресурсы, однако на этом пути определенно есть оптимум.

***

Наш опыт показывает, что у задачи создания серверной инфраструктуры под ERP-систему нет универсального оптимального решения. По ходу статьи мы всего лишь попытались дать некоторые рекомендации и описать самые принципиальные аспекты решения этой задачи.

Хотелось бы обратить внимание и на специализацию внешних поставщиков ИТ-услуг, привлекаемых для построения инфраструктуры под ERP-систему. По нашему глубокому убеждению, целесообразно привлекать к решению задачи компанию, не просто специализирующуюся на ИТ-инфраструктуре, а имеющую опыт решения бизнес-задач предприятия средствами бизнес-приложений и умеющую правильно проектировать и реализовывать ИТ-инфраструктуру для этих бизнес-приложений.