Кластерні рішення для r
Основна мета розробки корпоративних інформаційних систем - максимально повне рішення функціональних завдань, забезпечення високої надійності, масштабування і захищеності інвестицій. Сподіваюся, викладений в цій статті досвід фахівців АТ «Невська косметика», які мали вибрати системотехнічне рішення для системи R / 3, буде корисний багатьом.
Корпоративна система управління підприємством на базі SAP R / 3 призначена для виконання основних бізнес-функцій АТ «Невська косметика»: фінансове управління (модуль FI), матеріально-технічне постачання (модуль ММ), контролінг (модуль СО), управління продажами і дистрибуцією ( модуль SD). На першому етапі реалізації проекту передбачалося розгорнути 50 робочих місць, а пізніше збільшити їх кількість до 100. При подальшому розвитку проекту було вирішено впроваджувати модулі PP (виробниче планування), QM (управління якістю), PN (технічне обслуговування і ремонт) і EIS (інформаційна система для керівництва). Крім того, планувалося, що КСУП повинна забезпечувати ряд допоміжних функцій - цілісність даних компанії, їх архівування та резервування. Найбільш важливою вимогою було забезпечення високої надійності системи R / 3 в цілому, а також постійної доступності основних ресурсів: обчислювальних, дискових, стрічкових і мережевих. Керівництву «Невській косметики» був потрібний достатній рівень масштабованості, оскільки ресурсомісткість додатків типу R / 3 і даних зазвичай істотно перевищує проектну. Тому системотехнічне рішення повинно мати високий потенціал нарощування продуктивності по процесорам, оперативної пам'яті, підсистемі введення / виведення і т.д, щоб забезпечити захист початкових інвестицій і безболісну адаптацію прикладних систем в разі різкого зростання навантажень.
У процесі створення корпоративної системи було запропоновано використовувати сетецентріческой модель реалізації обчислювального комплексу, при якій основна функціональність, масштабованість і надійність рішення забезпечуються центральними серверами, а клієнтські місця реалізують тільки доступ до інформаційних ресурсів. Пропонований підхід забезпечує високу надійність - шляхом об'єднання серверів в кластери високої готовності; максимальну масштабованість - за рахунок застосування симетричних мультипроцесорних систем в якості компонентів кластерів; максимальний захист інвестицій - завдяки використанню в складі кластерів неоднорідного обладнання.
ФУНКЦІОНАЛЬНІСТЬ
Головна риса будь-КСУП - це функціональність, яка, в свою чергу, забезпечується необхідний рівень продуктивності устаткування, використовуваного ПО, якістю компонентів системи, а також складом додаткового обладнання. Уже на етапі попереднього вибору системотехнического рішення стало очевидно, що забезпечення повноцінного функціонування R / 3 і супутніх служб можливо тільки при використанні кластерів з SMP-серверів на базі RISC-процесорів і ОС UNIX. Рішення на базі Windows NT як ненадійні і немасштабіруемие були відкинуті відразу, а закриті рішення не розглядалися в силу їх високої вартості. За попередніми даними, наданими замовником, були сформульовані вимоги до використовуваної моделі КСУП (трехзвенная), а також до серверів R / 3 і Oracle. Для реалізації цих вимог необхідно було створити програмно-апаратне середовище, що задовольняє наступним вимогам:
- робота в режимі on-line в середовищі UNIX c СУБД ORACLE і SAP R / 3;
- реалізація високонадійного кластерного рішення, що забезпечує швидкий рестарт основних додатків і служб;
- можливість інтеграції існуючих компонентів ПО і апаратних засобів в загальну систему;
- забезпечення прийнятною вартістю рішення і його нарощування в майбутньому;
- низька вартість експлуатації і можливість максимальної автономності при обслуговуванні комплексу.
НАДІЙНІСТЬ І МАСШТАБОВАНІСТЬ
Для підприємств з безперервним циклом виробництва забезпечення надійності рішення - це найважливіша якість корпоративної системи управління підприємством. Використання кластера замість одиночного сервера в якості ядра такої системи дозволяє підвищити надійність всіх прикладних систем, забезпечуючи роботу сервера бази даних і додатків в режимі високої готовності. Однак відмовостійкість комплексу повинна бути забезпечена правильною побудовою кластера: оптимальна топологія, повне дублювання всіх компонентів, в тому числі і з'єднань.
У рішенні було запропоновано використовувати сервери від Fujitsu Siemens, принцип побудови яких забезпечує практично лінійне зростання продуктивності при збільшенні кількості процесорів, оперативної пам'яті і при нарощуванні підсистеми вводу / виводу. Кластер являє собою єдину систему з двох серверів з набором процесорів, здійснювати підключення до мережі, адаптерів, спеціалізованих з'єднань і дискового масиву. Кожен його компонент створювався таким чином, щоб забезпечити надійність, масштабованість і керованість всього кластера в цілому. Все що поставляються Fujitsu Siemens системи зберігання даних можна використовувати в кластерах завдяки надмірності і наявності технології «гарячої заміни». Сервери кластера працюють під управлінням ОС Reliant Unix 5.45, що підтримує багатопроцесорні і багатонитковою обчислення, що реалізує мережеві і загальносистемні служби і інтерфейси. Особливістю ОС Reliant Unix є її здатність практично лінійно тримати продуктивність серверів при всьому діапазоні навантажень.
РОЗРАХУНОК необхідний ресурс
В рамках триланкової моделі реалізації рішення на базі R / 3 було запропоновано використовувати окремий сервер під СУБД Oracle і окремий сервер для виконання додатків R / 3. Всі попередні розрахунки для визначення вимог до серверів проводилися згідно SAP AG Check List. Ці розрахунки включають в себе визначення навантаження в умовних одиницях званих SAPS і оцінюються за такою методикою:
Тут SD-dialogsteps / sec - кількість діалогових сесій в секундах для користувачів модуля SD, на основі якого виконуються розрахунки SAPS. Навантаження по іншим модулям враховується шляхом нормалізації їх до SD за допомогою коефіцієнтів; Tthink - час між двома кроками діалогу; TRes - час відповіді системи; N - загальна кількість користувачів.
Згідно методиці SAP значення SAPS збільшується на 32% для обліку фонових навантажень і на 17% для обліку пікових ситуацій. Таким чином, загальне навантаження Central SAPS буде дорівнює Dialog Workload + Update Workload + DB Workload.
У свою чергу Update Workload і DB Workload розраховуються за формулою:
Дані по завантаженню SAPS при Tthink = 27 с, TRes = 2 з з урахуванням попередніх даних розподілу користувачів по модулях SAP R / 3
На основі цих даних можна розрахувати обсяг необхідної оперативної пам'яті і кількість процесорів на серверах кластера, причому з огляду на, що на сервері СУБД будуть здійснюватися і роботи по Update.
Розрахунок оперативної пам'яті. Не менш 512 Мбайт оперативної пам'яті потрібно для інсталяції серверної частини R / 3 і забезпечення одночасної роботи 15-20 користувачів R / 3. Для збільшення їх числа на 100 достатньо збільшити оперативну пам'ять на сервері додатків (RM400 E) до 600 Мбайт. Пам'ять на сервері БД (необхідний мінімум - 256 Мбайт) буде рости незначно - 280 Мбайт для 100 користувачів, з огляду на, що на сервері БД будуть виконуватися фонові процеси R / 3). Так як в рамках трирівневої моделі передбачається розмістити сервер додатків і сервер СУБД на різних машинах кластера, то для виконання цих завдань для 100 користувачів потрібно відповідно 600 і 490 Мбайт пам'яті. Однак оскільки в разі відмови одного з вузлів на останньому передбачався рестарт як R / 3 так і Oracle, на кожному сервері було рекомендовано встановити по 1000 Мбайт оперативної пам'яті (пам'ять сервера БД з серверної частиною R / 3 для фонових завдань плюс пам'ять сервера додатків, на якому запускаються модулі діалогу).
Розрахунок продуктивності процесорів. Для сервера СУБД досить одного процесора MIPS R10000 / 250 МГц для кожних 100 користувачів при завантаженні сервера БД на 30-40%. Сервера додатків вистачає двох таких процесорів для нормальної роботи 100 користувачів при завантаженні сервера додатків на 40-50%. Всі ці значення передбачають високу активність користувачів, для яких R / 3 - основний інструмент, і невисоку завантаження серверів - комфортні умови для користувачів і мінімум дворазове запас продуктивності при необхідності збільшення навантаження без зміни конфігурації. При розрахунку враховувалася фонова навантаження на сервер БД (приблизно 20%).
Розрахунок завантаження локальної обчислювальної мережі і віддалених з'єднань. У мережі з технологією клієнт-сервер існує кілька потоків даних, що впливають на мережеву завантаження:
- діалогові взаємодії;
- локальна друк (Application Server Spool);
- взаємодія клієнтських ПК з сервером локальної мережі;
- додатковий мережевий трафік.
В середньому за один діалоговий крок передається 1,5 - 2,0 Кбайт даних, а одна операція вимагає зазвичай проходу по 3 - 4 екранам, тому середній обсяг операції приймається рівним 16000 байт. Для того, щоб забезпечити необхідний час реакції системи, утилізація мережі не повинна перевищувати 50%. При цьому передбачається, що мережа завантажена тільки діалогами R / 3. Розрахунок трафіку діалогів (SAPGUI) пропонується проводити за такою формулою:
де: С - необхідна завантаження мережі;
L - утилізація мережі (0
TRes - час відповіді системи;
N - загальна кількість користувачів.
Таким чином, завантаження при Tthink = 27 с і TRes = 2 з складе:
З отриманих розрахунків видно, що при використанні в локальній мережі Ethernet 10 Мбіт / с при 50% утилізації мережі трафік SAPGUI становить приблизно 1% від загальної пропускної здатності локальної обчислювальної мережі.