Подходы к выбору инфраструктурного решения для компании на начальном этапе расчета решения

2309

 

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

О подходах

Вот давайте не усложнять. Надо ближе, как говорится, быть к народу и к корням. А у нас корни – это реальные проекты.

Я раздумывал, как сделать, чтобы публикуемые материалы были максимально приближены к жизни? Потому что материалов – море, информации много и все что-то советуют. Не хотелось бы стать таким же «советчиком».

И решил по-простому. У меня идут SAP-проекты с конкретными компаниями. Мне задают прямые вопросы – я даю прямые ответы. И буду я здесь часть материалов давать прямо по горячим следам, то есть давать как раз те ответы, которые я прорабатываю в ходе реальных проектов.

Вот, одна уважаемая компания как раз начинает проект SAP. И для этого нужно, конечно же, оборудование. Давайте, посмотрим, что волнует людей на практике.

1. Общие вопросы при выборе платформы.

Общая постановка задачи: необходимость выбора инфраструктурного решения для размещения нескольких программных модулей:

Для начала хорошо бы понять, сколько пользователей будет работать в данной системе. Положим, мы посчитали общее количество пользователей по модулям - что составляет N человек. Важно, что эти «N» человек по-разному нагружают систему. Для разных модулей и в зависимости от ряда факторов, эти диапазоны могут изменяться. На это есть специальные методики. Обычно соотношения примерно следующие: 10% пользователей относятся к категории «интенсивно использующие систему. Среднюю нагрузку дают 20% человек и оставшиеся 70% слабо нагружают систему.

Различия между данными типами пользователей в основном связано с количеством инофрмации, которое они вводят в систему (генерируют) и нагрузкой на вычислительные ресурсы системы. Так, активные пользователи работают в системе практически постоянно, при этом интенсивно пользуются расчетами, в том числе аналитическими, генерируют отчеты, совершают поиск по различным базам данных и т.д. Несмотря на то, что их количество составляет всего одну десятую от общего числа пользователей, создаваемая ими нагрузка является наиболее критической. Дело в том, что активные пользователи не только генерируют и используют большие объемы информации, но и чаще всего являются «критически важными» точками общей системы управления. Если обычный пользователь из категории «low», т.е. с низкой нагрузкой, не получит доступа к системе в нужное время, в большинстве случаев это не слишком отразится на бизнесе в целом. Активные же пользователи зачастую поставляют информацию к определенным срокам, для высокого уровня бизнеса и т.д., т.е. их обслуживание является сложной и приоритетной задачей с точки зрения SLA, доступности, надежности работы системы.

Вывод номер раз:

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

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

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

Вывод номер два:

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

Я отмечу, что компания, в котороя я работаю, то есть IBM, имеет существенный опыт внедрения крупных ERP систем и уже более 10 лет активно развивает специальные технологии, решающие данную задачу. Чтобы не показалось это пустой рекламой, уточню. Механизмы перераспределения нагрузки и при этом защиты данных как внутри одной операционной системы, так и между динамическими логическими разделами являются уникальными (то есть отсутствующими у других производителей) инновационными инструментами для решения этой важной задачи. Похожих инструментов много, но стоит разобраться в технических особенностях DLPAR (dynamic logical partitioning), которые предоставляет на платформе Power компания IBM, чтобы понять очень важные отличия.

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

Желательно при расчетах (сайзинговых ) представлять еще и распределение пользователей в структуре заказчика. Ведь абстрактные N пользователей на самом деле живые люди – сидят в отделах и имеют разные задачи и степени подчинения, а, следовательно, и по-разному генерируют и используют информацию в системе. Этот момент может иногда помочь получить дополнительное понимание ситуации и учесть при определении размера и структуры решения.

Например, в том проекте, который я взял за основу статьи, оказалось, что два департамента особенно резко выделяются по интенсивности использования системы с точки зрения соотношения количества сотрудников и пользователей.

Оказалось, что в департаменте №1 количество сотрудников и пользователей примерно одинаково, а в департаменте №2 при количество пользователей почти в пять раз больше, чем число сотрудников.

О чем это говорит? А о том, что в департаменте №2 в среднем каждый сотрудник использует 4-5 модулей одновременно!

Вот, где сконцентрированы активные пользователи. Они будут давать серьезную нагрузку – и это надо учесть, например, при расчете каналов связи и выделяемых ресурсов, если они будут «привязаны» как-то к структуре заказчика.

Вывод номер три:

Любая информация, даже минимальная, должна быть проанализирована с различных углов зрения, и в комплексе с другой информацией. Часто это дает интересные результаты. Не жалейте сил на предварительный анализ. Это экономит месяцы, если не годы при последующем внедрении.

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

Соответственно, для данных департаментов системы должны предоставлять более высокие уровни надежности и доступности.

Что такое «уровни надежности и доступности»? Вопрос этот слишком обширен и уведет нас за рамки выбранной темы. Я постараюсь дать его отдельной статьей позднее.

Также надо посмотреть, как пользователи распределены по SAP-модулям и построить графики, поскольку визуально часто легче анализировать данные и увидеть какие-то особенности, чем глядя на таблицы с числами.

Итак, какие соображения должны быть учтены при выборе платформы и построении решения? Необходимо учесть следующие моменты:

  • Обеспечение соответствующих уровней доступности и надежности для критически важных групп пользователей и модулей
  • Обеспечение независимости работы критически важных модулей друг от друга (требование SAP)
  • Обеспечение перераспределения нагрузки (динамического во времени) для снижения количества ресурсов и защиты от перегруза системы и останова от перегрузки

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

2. Традиционные подходы к решению проблем

Относительно недавно, чуть более пяти лет назад, отсутствие эффективных механизмов, целенаправленно разработанных для решения представленных выше задач приводили к необходимости применения следующих методов:

  • Изоляция критически важных приложений на отдельных серверах
  • Поставка «запасных», свободных ресурсов в виде процессорной мощности, памяти, , дополнительных каналов связи (систем ввода-вывода) для исопльзования при возникновении непредсказуемых нагрузок

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

Недостатки приведенных методов очевидны:

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

Ограниченный доступ

Для прочтения полной версии статьи необходимо зайти как зарегистрированный пользователь.


Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»