"Невская косметика"

При создании новых корпоративных информационных систем основной целью является максимально полное решение функциональных задач, обеспечение высокой надежности, масштабирование и защищенность инвестиций. Требования рынка приводят к необходимости быстроразвивающимся предприятиям искать наиболее эффективные формы управления. АО Невская косметика - один из лидеров отечественной парфюмерно-косметической продукции, летом 1999 года приняло решение о внедрении корпоративной системы управления SAP R/3. По рекомендации Санкт-Петербургского подразделения SAP группа специалистов АО Невская косметика осуществила ряд мероприятий по выбору системотехнического решения для R/3

Компания Lynx приняла участие в консультациях, проектировании, поставке и реализации системотехнического решения под R/3 для АО "Невская косметика". Предлагаемая к рассмотрению корпоративная система управления предприятием (КСУП) на базе SAP R/3 предназначена для решения основных бизнес-функций Заказчика, прежде всего для решения задач финансового управления (модуль FI), материально-технического снабжения (модуль ММ), контроллинга (модуль СО) и управления продажами и дистрибуцией (модуль SD). На первом этапе проекта предполагалось развернуть 50 рабочих мест с максимальным увеличением их в перспективе до 100. При дальнейшем развитии проекта Заказчик предполагает внедрять модули PP (производственное планирование), QM (управление качеством), PN (техническое обслуживание и ремонт) и EIS (информационная система для руководства). Кроме того, предполагалось, что корпоративная система управления должна обеспечивать ряд вспомогательных функций - целостность данных компании, их архивирование и резервирование. Наиболее важным требованием Заказчика являлось обеспечение высокой надежности эксплуатации системы R/3 в целом, а также постоянной доступности основных ресурсов (таких как вычислительные, дисковые, ленточные и сетевые). Руководство АО "Невская косметика" хотело иметь высокий уровень масштабируемости, поскольку ресурсоемкость приложений типа R/3 и данных при внедрении зачастую существенно превышает проектную. Поэтому системотехническое решение должно было иметь высокий потенциал наращивания производительности (желательно линейный) по процессорам, оперативной памяти, подсистеме ввода/вывода и т.д, гарантируя Заказчику как защиту начальных инвестиций, так и безболезненную адаптацию прикладных систем в случае резкого возрастания нагрузок.

Общие требования, предъявляемые к ERP-решениям на базе SAP R/3

В ходе создания корпоративной системы управления R/3 АО "Невская Косметика" нашей фирмой было предложено использовать современную сетецентрическую модель для реализации вычислительного комплекса, при которой основная функциональность, масштабируемость и надежность решения обеспечиваются центральными серверами, а клиентские места реализуют только доступ к информационным ресурсам (имеют минимальную функциональность).

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

Функциональность

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

Уже на этапе предварительного выбора системотехнического решения стало очевидно, что обеспечение полноценного функционирования системы SAP R/3 и сопутствующих сервисов возможно только с использованием кластеров SMP-серверов на базе высокопроизводительных RISC-процессоров и ОС UNIX. Решения с использованием Windows NT как принципиально ненадежные и немасштабируемые были отвергнуты сразу, а закрытые решения не рассматривались в силу высокой стоимости. Согласно предварительным данным, предоставленных Заказчиком, были сформулированы требования к используемой модели КСУП (трехуровневая), а также к серверам R/3 и Oracle, (осуществлен предварительный sizing). Для реализации этих требований необходимо было создать высоконадежную и производительную программно-аппаратную среду, которая бы удовлетворяла следующим требованиям:

• Работа в режиме On-Line в среде UNIX c СУБД ORACLE и SAP R/3;
• Реализация высоконадежного кластерного решения, обеспечивающего быстрый рестарт основных приложений и сервисов
• Возможность интеграции существующих компонент ПО и аппаратных средств в общую систему;
• Обеспечение приемлемой стоимости решения и его наращивания в будущем;
• Низкая стоимость эксплуатации и возможность максимальной автономности Заказчика при обслуживании комплекса.

По предварительным оценкам требования к такому решению были формализованы в виде следующей таблицы:

Надежность

Надежность решения для фактически непрерывных производств - важнейшее качество корпоративной системы управления предприятием. Использование кластера серверов вместо одиночного сервера в качестве ядра такой системы позволяет существенно повысить надежность функционирования всех прикладных систем Заказчика, обеспечивая работу сервера базы данных и приложений в режиме НА (High Availability - высокая готовность). Отказоустойчивость комплекса должна быть обеспечена правильным построением кластера (оптимальная топология, полное дублирование всех компонент, в том числе и соединений). Решение, выбранное Заказчиком, гарантирует максимально возможную для таких кластеров скорость восстановления работы приложений и сервисов (от 10 до 20 минут).

Масштабируемость

Для реализации системы управления предприятием R/3 фирмой Lynx было предложено использовать сервера такого известного производителя вычислительной техники как Fujitsu Siemens Computers. Принцип построения серверов фирмы Fujitsu Siemens Computers обеспечивает практически линейное увеличение производительности технологии системы SAP R/3 при увеличении количества процессоров, оперативной памяти и при наращивании подсистемы ввода/вывода.

Кластерное решение высокой готовности (НА) серверов R/3 и серверов баз данных

Основным компонентом системотехнического решения, предложеного нашей фирмой для КСУП R/3 АО "Невская Косметика" является кластер серверов высокой готовности. Под кластерами традиционно понимается объединение нескольких вычислительных систем (узлов), которые используются как единое целое, обеспечивая доступ пользователей к приложениям, системным ресурсам и данным. В качестве узлов могут использоваться как однопроцессорные, так и SMP-сервера. Кластерные решения обеспечивают высокий уровень надежности: при выходе из строя одного или даже нескольких узлов работа приложений может быть продолжена на любых других узлах, входящих в состав кластера. При этом дополнительная нагрузка может быть равномерно распределена среди работающих узлов кластера. Другой важной задачей, решаемой при помощи кластерных технологий, является увеличение производительности системы путем добавления в кластер новых узлов (процессоров, памяти, дисковых подсистем и т.д.). Для объединения узлов в кластер используются различные соединения. При этом линии связи, используемые для обслуживания внутренних потребностей кластера, называются внутрикластерными (private link), а соединения для подключения потребителей - внешними (public link) На рисунке 1 приводится схема, иллюстрирующая концепцию уровней готовности.

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

Концепция миграции приложений и ресурсов в кластере НА

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

Миграция приложения (правильнее - виртуальной машины с приложением) с основного сервера на резервный внутри кластера может занимать достаточно продолжительное время в зависимости от самого приложения. Для сокращения этого времени программное обеспечение настроено таким образом, чтобы локализовать сбой внутри сервера и предотвратить миграцию приложения на другой сервер в кластере. В качестве примера таких настроек можно привести программное обеспечение OBSNET, которое обеспечивает автоматическое переключение сетевых и дисковых интерфейсов сервера при выходе из строя соответствующих адаптеров. Кластерное ПО RMS (производcтва Fujitsu Siemens Computers) обеспечивает возможность динамического реконфигурирования (Dynamic Reconfiguration) и замены компонент (процессоров, оперативной памяти, контроллеров ввода/вывода) без останова сервера и без прекращения работы и/или миграции приложения. Одной из важных функций, реализуемых RMS, является поддержка альтернативных путей доступа (Alternate Pathing) к устройствам.

Помимо мониторинга состояния сервера и хранилищ данных, кластерное ПО осуществляет постоянный контроль состояния самого приложения, предотвращая ситуации остановки работы в случае внутренней ошибки, "зависания" и пр. Для этого существуют специальные агенты, разработанные для стандартных приложений: SAP R/3, Oracle, Informix, Sybase, Netscape, NFS и многих других.

Синхронизация дисковых подсистем

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

Маскирование внешних пользовательских сетей

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

Полное дублирование соединений

Кластера НА должны обеспечивать полное дублирование всех соединений для бесперебойного функционирования внутрикластерной (private link) сети, внешней сети (public link), дисковых соединений и т.д. Только при полном дублировании всех соединений и компонент кластера можно говорить о реальном соответствии такой конструкции требованиям высокой готовности.

Реализация системотехнического решения на базе кластеров НА фирмы Fujitsu Siemens Computers

Общие данные о реализации

В качестве основы предложенного Заказчику системотехнического решения был использован кластер НА фирмы Fujitsu Siemens Computers, представляющий собой единую систему из двух серверов с набором процессоров, сетевых подключений, адаптеров, специализированных соединений и дискового массива. Каждый компонент кластера создавался таким образом, чтобы обеспечить надежность, маштабируемость и управляемость всего кластера в целом. Fujitsu Siemens Computers включает в свои кластерные решения самые надежные и высокопроизводительные компоненты. Все поставляемые Fujitsu Siemens Computers системы хранения данных можно использовать в кластерах благодаря избыточности и использовании технологии "горячей замены" (Hot Plug) для всех компонентов. Сервера кластера функционируют под управлением Reliant Unix 5.45 - современной 64-х разрядной ОС, поддерживающей многопроцессорные и многонитевые вычисления, эффективно реализующей сетевые и общесистемные сервисы и интерфейсы. Уникальной особенностью ОС Reliant Unix является ее способность практически линейно держать производительность серверов при всем диапазоне нагрузок.

Предварительный расчет требуемых ресурсов для SAP R/3

В результате проведенного предварительного обсуждения проекта КСУП Заказчику было рекомендовано использовать трехуровневую модель реализации SAP R/3. В рамках данной модели предлагается использовать отдельный сервер под базу данных Oracle (сервер базы данных) и отдельный сервер под собственно R/3 (сервер приложений). Все предварительные расчеты для определения требований к серверам производились согласно SAP AG Check List. Эти расчеты включают в себя определение нагрузки в условных единицах называемых SAPS и оцениваются по следующей методике:

SAPS = SD-dialogsteps/h * 100/6000
SD-dialogsteps/h = SD-dialogsteps/sec * 3600
SD-dialogsteps/sec = N / (Tthink + Tres)

SD-dialogsteps/sec - количество диалоговых сессий в сек. для пользователей модуля SD (который используется в качестве базиса для расчетов SAPS). Нагрузка по остальным модулям учитывается путем нормализации их к SD при помощи коэффициентов согласно SAP AG Check List;
Tthink - время между двумя шагами диалога;
TRes - время ответа системы;
N - общее количество пользователей.

Cогласно методике SAP значение SAPS увеличивается на 32% для учета фоновых нагрузок и на 17% для учета пиковых ситуаций. Таким образом, общая нагрузка в SAPS будет складываться из Dialog Workload, Update Workload и DB Workload:

Central SAPS = Dialog + DB + Update

Update Workload = Dialog Workload * 0.21
DB Workload = Dialog Workload * 0.2

Исходя из данных указанных в таблице, ниже приводится расчет оперативной памяти и количества процессоров на серверах кластера. При этом предполагалось, что на сервере СУБД будут осуществляться и работы по Update (приводимые ниже расчеты приводятся для SAP R/3 версии 4.0В и СУБД Oracle версии 8.0.5.i фирмы Oracle).

Расчет оперативной памяти.

В данном случае 512 Мб оперативной памяти требуется для инсталляции серверной части R/3 и при этом объеме памяти обеспечивается одновременная работа 15-20 пользователей R/3. Для увеличения числа пользователей на 100, на платформе RM400 E достаточно увеличить оперативную память на сервере приложений до 600 Mб. Память на сервере БД (необходимый начальный уровень - 256 Мб) будет расти незначительно - 280 Мб для 100 пользователей (с учетом того, что на сервере БД будут выполняться фоновые процессы R/3). Так как в рамках трехуровневой модели предполагается разнесение сервера приложений и сервера СУБД по разным машинам кластера, то для нормального функционирования этих задач для 100 пользователей на машинах кластера потребуется соответственно 600 и 490 Мб оперативной памяти. Однако, поскольку при выходе из строя одного из узлов на оставшемся предполагался рестарт как R/3 так и Oracle, на каждом сервере было рекомендовано установить по 1000 Мб оперативной памяти (память сервера БД с серверной частью R/3 для фоновых задач плюс память сервера приложений, на котором запускаются модули диалога).

Расчет процессорной производительности.

Для сервера СУБД достаточно 1 процессора MIPS R10000/250 МГц/4Mб для каждых 100 пользователей при загрузке сервера БД на 30-40%. Для сервера приложений достаточно двух процессоров MIPS R10000/250 МГц/4Mб для 100 пользователей при загрузке сервера приложений на 40-50%. Все эти значения предусматривают высокую активность пользователей (для которых R/3 - основной инструмент) и невысокую загрузку серверов - комфортные условия для пользователей и минимум двукратный запас производительности при необходимости увеличения нагрузки без изменения конфигурации. При расчете учитывалась фоновая нагрузка на сервер БД (примерно 20%).

Расчет емкости дискового пространства:

минимальные требования для инсталляции R/3 (совмещенные сервер базы данных Oracle и сервер приложений R/3) составляют 18 Гб дисковой памяти, кроме этого, необходима дисковая память для хранения создаваемых документов. По опыту эксплуатации уже установленных фирмой SAP систем R/3 при записи порядка 2000 документов в день используемая дисковая память составляет около 30 Гб в течение года. Поэтому нами предложена разделяемая дисковая память в 50 Гб с резервом роста (максимально 500 Гб при заполнении конструктива дискового массива).

Расчет загрузки Локальной Вычислительной Сети и удаленных соединений.

В сети с технологией клиент-сервер существует несколько потоков данных, оказывающих влияние на сетевую загрузку:

• диалоговые взаимодействия (SAPGUI <- - -> Application Server),
• локальная печать (Application Server (Spool)<- - -> Print Server),
• взаимодействие Front-end PC <- - -> LAN Server,
• дополнительный сетевой трафик (Mailing,....).

В среднем за один диалоговый шаг передается 1,5 - 2,0 Кб данных, а одна операция требует в среднем прохода по 3 - 4 экранам, поэтому средний объем операции принимается равным 16000 байт. Для того, чтобы обеспечить требуемое время ответа (response time) утилизация сети не должна превышать 50%. При этом предполагается, что сеть загружена только диалогами SAP.

Фирма SAP предлагает расчет трафика диалогов SAPGUI по следующей формуле:

С = 16000 * N / (L * (Tthink + Tres)) бит/с

С - требуемая загрузка сети;
L - утилизация сети (0 < L <1);
Tthink - время между двумя шагами диалога;
TRes - время ответа системы;
N - общее количество пользователей.

С = 16000 * 100 / (0,5 *(27 + 2)) = 22857 бит/с

Фирма SAP не предлагает методики расчета загрузки сети для остального трафика, но из полученных расчетов видно, что при использовании в локальной вычислительной сети технологии Ethernet 10Мбит/с при 50% утилизации сети трафик SAPGUI составляет примерно 1% от общей пропускной способности локальной вычислительной сети.

Возможности по наращиванию и развитию системы

Установленный в АО "Невская косметика" комплекс обладает уникальными возможностями по масштабированию. Как было отмечено выше, масштабируемость серверной платформы в первую очередь определяется возможностями наращивания количества процессоров, оперативной памяти и подсистем вода/вывода.

Применение в качестве серверной платформы Fujitsu Siemens Computers RM400 CS42 позволяет путем модернизации процессоров увеличивать производительность каждого узла в 2 раза, а объем оперативной памяти - до 8(4) Гб. Возможен и другой путь для увеличения производительности комплекса: кластерное ПО RMS от Fujitsu Siemens Computers поддерживает в настоящее время до восьми узлов, поэтому возможно наращивание мощности комплекса путем включения новых узлов (в том числе и несимметричных) в существующий кластер. Этот способ перспективен еще и тем, что он позволяет интегрировать будущие перспективные сервера фирмы Fujitsu Siemens Computers и сохраняет инвестиции в существующее оборудование.

Виталий Кузьмичев, технический директор компании Lynx

Тел/Факс   +7 (812) 325-72-60
E-mail:    VITAL@lynx.ru