Тенденцією останніх років є стрімке зростання кількості інформаційних систем, побудованих з використанням новітніх Інтернет технологій та підходів. І в такому тренді є великий сенс, зважаючи на вибуховий розвиток телекомунікацій, обчислювальної техніки, комп’ютерної грамотності людей. При цьому існують приклади, коли державні структури мають найсучасніше обладнання, але з різних причин стримують розвиток новітніх програмних комплексів.
Ця стаття присвячена порівнянню інформаційних систем розподіленої архітектури та web-орієнтованих, з єдиною центральною базою даних. На моє переконання, перші з них повинні бути якнайшвидше витіснені другими, як свого часу двигуни внутрішнього згоряння прийшли на зміну паровим машинам.
Наведений тут матеріал можна використовувати при необхідності обґрунтувати кардинальну модернізацію IT-середовища організації.
Основою для аналізу став 15 річний досвід по створенню державних інформаційних систем, елементи яких розташовуються по всій території України.
Системи з розподіленою архітектурою
Основною ознакою розподіленого варіанту архітектури інформаційної системи є наявність в кожній точці її впровадження (вузлі) повноцінного клієнт-серверного комплексу з локальною базою даних. Типовим прикладом «вузла» є районне або обласне управління будь-якої державної структури, відділення банку. Обмін даними з іншими вузлами, як правило, відбувається у пакетному режимі з використанням різних засобів обміну даними.
Така архітектура була актуальною 15-20 років тому, коли рівень телекомунікації не йшов ні в яке порівняння з сучасним. Тому основним варіантом функціонування систем був локальний режим роботи з накопиченням та обробкою даних, які потім в межах коротких сеансів обміну передавались до інших рівнів (як правило, з районного до обласного, з обласного – до центрального і назад; іншою поширено топологією обміну була «зірка», центром якої виступав центральний орган відомства).
Узагальнена схема розподіленої системи з обміном по принципу «зірки» виглядає наступним чином:
Рис.1. Розподілений варіант архітектури.
Основними елементами розподіленої архітектури системи є (див. Рис.1):
- Основний Центр обробки даних (ЦОД) – відповідає за зберігання та обробку всіх даних інформаційної системи (центральної бази даних); реалізує частину прикладної (ділової) логіки програмного забезпечення (ПЗ) на центральному рівні.
- Резервний ЦОД – забезпечує відмовостійкість, резервне збереження даних всієї системи на центральному рівні. Звичайно ж, більшість державних установ резервного ЦОДу не мають, та й основний саме «ЦОДом» часто назвати можна з великою натяжкою.
- Користувачі – клієнтське програмне забезпечення (ПЗ) в технології “товстого клієнта” (desktop), що забезпечує реалізацію частини прикладної (ділової) логіки, візуалізацію даних та взаємодію користувача з системою.
- Сервера баз даних, сервера додатків у вузлі – відповідають за зберігання, обробку всіх даних у конкретному вузлі (локальна база даних у вузлі); реалізує частину прикладної (ділової) логіки ПЗ на рівні вузла; додатково забезпечує функції обміну даними з іншими рівнями.
Необхідними елементами централізованої архітектури також є:
- Телекомунікаційна мережа, яка забезпечує підключення та обмін даними між різними вузлами (Інтернет або корпоративна мережа – власна чи на базі національних операторів передачі даних).
- Система захисту інформації – забезпечує захист всіх вузлів.
- Сервери обміну даними – реалізують обмін даними між вузлами системи.
Розподілений варіант архітектури характеризується наступними позитивними властивостями (через які свого часу він і набув популярності):
1. Відсутність необхідності у постійному телекомунікаційному зв’язку вузлів з центральним рівнем. Інформація передається у пакетному режимі з максимальним ущільненням, чим мінімізуються вимоги до каналів зв’язку. Працездатність локального вузла не залежить від наявності в кожний момент часу телекомунікаційного зв’язку.
2. Додатково може реалізовуватись незалежність системи обміну інформації від середовища передачі даних. Можлива передача пакетів як засобами телекомунікаційної мережі, так і у будь-який інший спосіб (наприклад, на зовнішніх носіях).
3. Певна перевага у ергономічності інтерфейсу «товстого клієнта» перед web-інтерфейсом, особливо стосовно операцій масового вводу даних через інтерфейс користувача (але варто відмітити, що в останні роки така відмінність майже нівелювалася).
Негативні властивості розподіленої архітектури:
1. Локальні бази даних розташовані в кожному вузлі системи. Такий підхід вимагає створення складної технології обміну даними між ними. Обов’язковою умовою при цьому є підтримка всіх баз даних в узгодженому стані, що, як показує багаторічний досвід експлуатації таких систем, є однією з найбільш складних задач як в плані реалізації, так і наступної технічної підтримки.
2. Наявність в кожному вузлі достатньо складного апаратно-програмного комплексу: сервер баз даних, сервер додатків, сервер обміну, робочі станції тощо.
3. Система управління базами даних може бути як безкоштовною (Firebird…), так і промисловою ліцензійною (Oracle…). У другому випадку забезпечується значно вищий рівень інформаційної безпеки та функціональних можливостей, але, відповідно, необхідні значні фінансові витрати на ліцензування та технічну підтримку.
4. Наявність складних технічних та програмних елементів у кожному вузлі системи призводить до наступних наслідків:
- Значно вищі, порівняно з централізованою архітектурою, витрати на технічне і загальносистемне програмне забезпечення (ліцензії).
- Потреба у якісному адмініструванні системи у кожному вузлі. При чому, як показує досвід експлуатації, потрібен дійсно кваліфікований системний адміністратор у кожному вузлі на постійній основі (що вкрай важко досягти в умовах вітчизняних реалій, в першу чергу, зарплат на держслужбі та концентрації IT-спеціалістів у великих містах).
- Необхідність синхронізації баз даних і версій прикладного програмного забезпечення центрального рівня та інших вузлів. Ця задача є однією з найбільш складних, особливо у випадках аварійних ситуацій у вузлах системи. Часткова втрата даних призводить до необхідності виконувати узгодження станів інформації в різних базах даних розподіленої системи (часто – з залученням розробників інформаційної системи). Взагалі, дана проблема є однією з найбільш критичних в процесі технічної підтримки розподіленої системи і мало залежить від особливостей реалізації алгоритмів обміну даними.
- Необхідність розповсюдження по всіх вузлах системи нових версій програмного забезпечення та здійснення контролю версій (що також збільшує витрати на адміністрування системи).
- Мала гнучкість, оперативність, високі витрати при створені нових вузлів або переміщенні (реорганізації, реформуванні) діючих.
5. Менші можливості для забезпечення високого рівня інформаційної безпеки (в кожному вузлі система повністю залежна від системного адміністратора вузла, керівництва організації; традиційно низький рівень виконавської дисципліни).
6. Особливу проблематичність викликає ситуація, коли вузол системи необхідно розгорнути на території іншої організації, яка формально не підпорядковується основному власнику системи (проблеми технічного забезпечення, регламенту експлуатації та адміністрування тощо).
7. Низька (порівняно з web-системою) актуальність інформації на центральному рівні.
Узагальнюючи вищенаведене, вважаємо, що критичними недоліками розподіленої архітектури в більшості випадків є:
- необхідність у кваліфікованих системних адміністраторах у кожному вузлі;
- вкрай високі витрати на апаратну частину та ліцензування загальносистемних програмних засобів;
- складна організаційна схема підтримки та адміністрування;
- невисокі можливості по якісному забезпеченню захисту інформації;
- ступінь актуальності інформації в кожний момент часу невизначений.
Системи з централізованою веб-орієнтованою архітектурою
Як свідчать світові тенденції розвитку ІТ-індустрії, переважна більших сучасних інформаційних систем будуються за централізованою архітектурою. Або існуючі системи модифікуються під таку архітектуру, хоча це далеко не завжди можливо чи доцільно. Яскравим підтвердженням цього факту є вибуховий розвиток «хмарних» (cloud) технологій як глобального тренду.
Базовим стимулом до розвитку саме такої архітектури є стрімка еволюція телекомунікаційних сервісів, підвищення їх надійності та пропускної спроможності, зниження вартості послуг передачі даних, широке проникнення як в географічному сенсі, так і серед різних верств населення, бізнесу.
Як правило, централізована система будується з використанням сучасної трирівневої архітектури та web-технологій, на базі потужного високонадійного ЦОД.
.jpg)
Рис.2. Централізований варіант архітектури.
Основними елементами централізованої архітектури є (див. Рис.2)
- Основний ЦОД – відповідає за зберігання та обробку всіх даних інформаційної системи (єдиної бази даних системи), реалізує переважну частину прикладної (ділової) логіки web-системи, взаємодію з віддаленими користувачами; для даної архітектури являє собою критично важливий елемент (як з точки зору надійності, так і продуктивності).
- Резервний ЦОД – забезпечує відмовостійкість, резервне збереження даних всієї системи на центральному рівні.
- Користувачі – клієнтський інтерфейс, що забезпечує візуалізацію даних та взаємодію користувача з системою; виконується у web-браузері.
Іншими необхідними елементами централізованої архітектури є:
- Телекомунікаційна система, забезпечує підключення до системи та обмін даними між віддаленими клієнтами; для даної архітектури являє собою критично важливий елемент.
- Система захисту інформації – найбільш критичною ділянкою для захисту є центральний рівень системи.
Централізований варіант архітектури характеризується наступними позитивними властивостями:
1. Наявність однієї (єдиної) бази даних, з якою взаємодіють всі користувачі системи (як на центральному рівні, так і віддалені користувачі).
2. Відсутність складних технічних та загальносистемних програмних елементів на стороні «клієнта». Внаслідок чого:
- мінімізовані витрати на технічне та загальносистемне програмне забезпечення для клієнтських робочих станцій;
- фактично, єдиними необхідними загальносистемними елементами є операційна система (в т.ч. і безкоштовна, чи мобільна) та web-браузер;
- роботи по адмініструванню на всіх рівнях, окрім центрального, складаються тільки з встановлення клієнтських робочих станцій та налагодження телекомунікаційного зв’язку з центральним рівнем;
- відсутність необхідності у синхронізації баз даних та версій прикладного програмного забезпечення між рівнями/вузлами системи;
- відсутність проблем, які виникають при реальному функціонуванні обміну інформацією між різними локальними базами даних, необхідності їх відновлення, узгодження стану тощо;
- і, як загальний висновок – відсутність необхідності у кваліфікованому системному адміністраторі у кожному вузлі, загалом, мінімізація затрат на клієнтські робочі місця.
3. Побудова у типовій для такого класу систем трирівневій архітектурі «сервер баз даних – сервер додатків – клієнт» забезпечує:
- використання всіх можливостей сучасних промислових систем керування базами даних (СКБД), серверів додатків (в т.ч. з точки зору адміністрування, забезпечення безпеки та цілісності інформації, резервування, масштабування, продуктивності, аналізу даних тощо);
- використання в якості середовища виконання прикладного програмного забезпечення на стороні клієнта web-браузеру; таким чином, серед іншого, досягається незалежність клієнтського ПЗ від операційної системи та особливостей архітектури клієнтської робочої станції (в т.ч. можливість використання апаратних терміналів зниженої вартості);
- унеможливлення прямого доступу (в т.ч. несанкціонованого) до центральної бази даних;
- простоту створення нових вузлів системи або перенесення в інше місце діючих (фактично, для цього необхідно забезпечити телекомунікаційний зв’язок з центром та робочу станцію з web-браузером);
- можливість побудови мобільних робочих місць, реалізації доступу користувачів до системи в будь-який час з будь-якого місця (при забезпеченні належного захисту інформації, звичайно).
4. Використання єдиного комплексу загальносистемного та прикладного програмного забезпечення для всіх користувачів системи на всіх рівнях забезпечує:
- використання єдиного способу доступу до системи з використанням web-технологій;
- контроль прав використання користувачем конкретних функцій та доступу до даних системи у відповідності до його прав, що зберігаються в каталозі зареєстрованих користувачів;
- зменшення витрат на розробку програмного забезпечення (розробляється один комплекс).
5. Широкі можливості щодо масштабування. Кожний з основних елементів (сервер баз даних, сервер додатків, web-сервер) дозволяє застосувати ефективні методи масштабування у випадку збільшення навантаження на систему.
6. Можливість миттєвого (санкціонованого) доступу з будь-якого вузла по всій території України до всієї бази даних системи. Таким чином ліквідуються проблеми актуалізації, узгодження локальних баз даних, синхронізації нормативно-довідкової інформації тощо (вся необхідно інформація доступна кожному користувачу негайно по її надходженню в єдину базу даних).
7. Централізована система набагато більш керована у порівнянні з розподіленою, оскільки значно простіше забезпечити надійні організаційні процедури в одному центрі, який обслуговують кваліфіковані фахівці, ніж виконати схожі задачі у всіх вузлах на всіх рівнях. З тих самих причин набагато ефективнішими стають заходи по захисту інформації в системі.
8. Отже, централізована модель кардинально спрощує організаційну, технічну складові створення, впровадження, експлуатації системи, а також забезпечення безпеки інформації.
При цьому централізований варіант архітектури характеризується наступними негативними властивостями:
1. Підвищені вимоги до потужності апаратного забезпечення центрального рівня (порівняно з розподіленим варіантом) та рівня готовності (надійності) апаратно-програмного комплексу центрального рівня (оскільки працездатність кожного клієнта напряму залежить від працездатності ЦОД).
2. Необхідність забезпечення постійного телекомунікаційного зв’язку з центром. Дана задача вирішується побудовою основного, а також резервних каналів зв’язку. Важливим фактором є надійність (безперервність) зв’язку, а також достатня пропускна здатність каналів.
3. Певна перевага у зручності інтерфейсу «товстого клієнта» перед web-інтерфейсом (хоча сучасні web-клієнти майже так само зручні, як і desktop).
4. Необхідність забезпечення централізованої процедури реєстрації та ведення всіх користувачів системи. Дана проблема успішно вирішується делегуванням повноважень щодо керування користувачами в межах ієрархічного підпорядкування різних рівнів системи/організації.
Висновки
Розглянемо порівняльну таблицю характеристик розподіленого та централізованого варіантів архітектури системи.
Таблиця 1.
.png)
Висновок з аналізу порівняльної таблиці: варіант централізованої архітектури є оптимальним з точки зору переважної більшості показників. Основними критичним елементами цієї архітектури є ЦОД і телекомунікаційна система. Але сучасний рівень розвитку ІТ дозволяє побудувати ЦОД та телекомунікаційну систему, що відповідають необхідним вимогам, і при цьому з прийнятним рівнем витрат. Крім того, на сьогодні в Україні існує декілька потужних ЦОД, які можуть бути розглянуті як платформа для розміщення централізованих систем (альтернатива побудові власного ЦОДу).
Проводячи загальну оцінку двох архітектур можна констатувати, що чим більше розподілена система має вузлів, тим складніше і дорожче її розробка, впровадження та експлуатація у порівнянні з централізованим варіантом.
Отже, зважаючи на більшість порівняльних критеріїв, в сучасних умовах настійно рекомендується вибрати централізовану модель архітектури інформаційної системи.
Олексій Бондарчук
Заступник директора, директор департаменту проектів
