Проектування високопродуктивної системи MBS-Axapta
Сергій Котов, керівник відділу ІТ ЗАТ "АСБ-Рейтинг-Центр" [email protected]
У цій статті ми розглядатимемо питання продуктивності по відношенню до Microsoft Business Solutions-Axapta як до комплексної системи, що складається з багатьох взаємозалежних компонентів: серверів баз даних (БД) та додатків, архітектури з'єднань та ЛОМ, операційної системи, клієнтів – робочих місць користувачів. Тому під терміном "система Microsoft Axapta" треба розуміти весь комплекс технічної інфраструктури для Microsoft Axapta - рішення класу ERP, що забезпечує супровід бізнес-функцій підприємства.
Найбільш критична всім користувачів продуктивність при навігації по візуальному інтерфейсу. Тут зазвичай припустимі затримки менше секунди. З іншого боку, час підготовки великих статистичних звітів може становити кілька хвилин, і це сприйматиметься цілком нормально. Нижче ми обговоримо це та багато інших питань забезпечення продуктивності докладніше, а перше, про що ми поговоримо, - це про те, як визначити стратегію підвищення продуктивності бізнес-систем Microsoft Axapta з урахуванням перспектив розвитку.
Стратегія побудови високопродуктивної системи
Дуже часто на практиці про продуктивність системи згадують лише тоді, коли починаються проблеми на етапі її повномасштабної промислової експлуатації, тобто вже після успішного закінчення проекту впровадження. У результаті під пресом невдоволення користувачів доводиться поспіхом шукати швидкі коригувальні рішення. Подібної ситуації краще не допускати та планувати свої рішення та дії заздалегідь.
У проектуванні продуктивної системи Microsoft Axapta виділяється два напрями: проектування апаратної архітектури тазабезпечення якості програмних розробок. Необхідно розуміти принципову різницю між цими двома напрямами. Забезпечення якості програмних розробок (у разі щодо продуктивності) - це безперервний процес, критичний як етапі впровадження, а й етапі супроводу. Відповідно до принципів TQM (Total Quality Management), процес забезпечення якості програмних рішень щодо продуктивності повинен входити до загальної безперервної політики забезпечення якості робіт у компанії.
У разі кращим методом проектування апаратної архітектури, можливо, стане моделювання з урахуванням попереднього досвіду (рис. 1). Метод підходить як початкового впровадження, так великого оновлення апаратних ресурсів, наприклад, при заміні сервера баз даних.
Для ефективного використання цього методу необхідний досвід попередніх успішних проектів впровадження Microsoft Axapta з відомими параметрами, що вимірюються в трьох областях: основні параметри системи, технічні характеристики апаратної архітектури, індекси продуктивності.
Доосновних параметрівсистеми входять:
- діюча функціональність (модулі);
- інтенсивність різних операцій (наприклад, кількість рядків замовлень на місяць);
- середня кількість конкурентних користувачів у робочий час (ще краще знати розбиття за функціональними групами та визначити число ASU - Axapta Standard User);
- обсяг БД та середнє зростання її розміру за місяць.
Підтехнічними характеристикамиапаратної архітектури маються на увазі:
- тип архітектури (триланкова, дволанкова, термінальне рішення);
- технічна схема організації системи (кількість серверів, схема їх з'єднання);
- технічні характеристики (число та потужність процесорів, обсяг оперативної пам'яті, характеристики дискової підсистеми серверів, архітектура та тип ЛОМ).
Знаючи представлені вище дані та ґрунтуючись на передбачуваних основних параметрах проектованої системи (характеристики 1-ї області), далі вже можна шукати оптимальне поєднання майбутніх технічних характеристик системи та бажаного рівня продуктивності.
У процесі моделювання не слід забувати про витрати. Наприклад, дуже високі показники продуктивності можуть бути досягнуті за рахунок таких характеристик апаратури, що передбачувані витрати на обладнання перевищать рамки бюджету проекту впровадження. У цьому випадку варто знизити вимоги до продуктивності та отримати прийнятне технічне рішення.
У принципі, метод досить простий, але вся складність його ефективного використання полягає в досвіді експертів, які проводять моделювання. Необхідно розуміти суть нелінійних залежностей між змінами різних параметрів системи.
Що робити, якщо немає хороших експертів для проектування системи? У наступному розділі ми представимо варіант технічної реалізації, можливо найбільш типового проекту впровадження Microsoft Axapta.
Технічна архітектура для середньої компанії
Приймемо за основу такі характеристики системи:
- комплексна функціональність Microsoft Axapta (управління фінансами, ланцюжками поставок, продажами, персоналом, дистрибуція, бізнес-аналіз);
- 100 одночасно працюючих (конкурентних) користувачів;
- об'єм БД 20 Гбайт;
- середній щомісячний приріст обсягу БД 3 Гб;
- одна робоча БД;
- чотири копії робочої БД (для розробок, тестування, навчання);
- необхідність періодичного архівування БД.
Найважливіший з представлених параметрів, що показує інтенсивність операцій у Microsoft Axapta, - це швидкість зростання БД , яку можна вимірювати, наприклад, в гігабайтах за місяць.
На рис. 2 представлений перевірений практично варіант технічної архітектури для заявлених характеристик. Розглянемо цю схему докладніше.
В першу чергу необхідно відзначити організацію двох середовищ системи: робочої, де відбувається експлуатація діючої системи Microsoft Axapta, та середовища підтримки, призначення якої полягає в обслуговуванні завдань розробки, тестування, архівування БД, додатків тощо. Середовище підтримки служить також аварійним варіантом запуску системи Axapta у разі виходу з експлуатації основного сервера баз даних.
Для побудови всіх більш менш великих варіантів системи краще використовувати триланкову архітектуру. Сервери програм дозволяють досить ефективно централізовано керувати навантаженням на сервер БД. Набагато простіше в цьому випадку стають і адміністрування та аналіз системи. Ймовірно, при числі конкурентних користувачів понад 20-30 триланкова архітектура – це найкращий варіант.
Серверів додатків у разі два. Для типового за характеристиками двопроцесорного сервера (2 процесори Xeon 2,4 ГГц) краще спочатку планувати навантаження трохи більше 60-80 користувачів однією сервер. Надалі необхідно аналізувати вже поточне навантаження на сервер, оскільки різні типи користувачів (точніше, різні задачі) по-різному задіяють ресурси сервера додатків.
Сервери додатків та сервер БД з'єднані безпосередньо через виділені мережеві адаптери, минаючи комутатор ЛОМ.
Сервер баз даних повинен матипродуктивну та надійну дискову підсистему. Переважний тип RAID-масиву - 10 (позначається також 0+1). Даний тип RAID – це продуктивний та надійний варіант відмовостійкого масиву.
Технічні характеристики устаткування схеми, наведеної на рис. 2, такі:
- AOS1, AOS2: два процесори Xeon 2,4 ГГц/2 Гбайт; SQL1: чотири Xeon 2,4 ГГц/4 Гбайт, зовнішній корпус, RAID 10, 12x36x15K;
- SQL2: два Xeon 2,4 ГГц/2 Гбайт, зовнішній корпус, RAID 5, 12×76×10К;
- Комутатор ЛОМ 1 Гбіт/с.
Планування архітектури на етапі супроводу
Допустимо, етап впровадження успішно завершено, продуктивність системи Microsoft Axapta виявилася прийнятною. Чи можна на цьому заспокоїтись? Звичайно, ні! У процесі промислової експлуатації систему впливає ряд чинників, неминуче знижують рівень поточної продуктивності. До таких негативних чинників можна віднести:
- зростання обсягу БД;
- ускладнення функціональності;
- зростання кількості користувачів системи;
- швидкі розробки без контролю якості.
Останній фактор, можливо, є найбільш критичним. Один-єдиний безграмотно написаний програмістом запит при несприятливому збігу обставин здатний ввести в ступор як завгодно потужний сервер баз даних або сервер програми.
Для ефективного контролю та підтримки продуктивності системи Microsoft Axapta на прийнятному рівні необхідно впровадити додатковий процес, показаний на рис. 3.
