Розділ11. Забезпечення високої доступності

11.1. Доступність. Основні поняття

Інформаційна система надає своїм користувачам певний набір послуг (сервісів). Говорять, що забезпечено потрібний рівень доступності цих сервісів, якщо наступні показники перебувають у заданих межах:

Ефективність послуг. Ефективність послуги визначається в термінах максимального часу обслуговування запиту, кількості підтримуваних користувачів і т.п. Потрібно, щоб ефективність не знижувалася нижче заздалегідь установленої межі.

Час недоступності. Якщо ефективність інформаційної послуги не задовольняє накладеним обмеженням, послуга вважається недоступною. Потрібно, щоб максимальна тривалість періоду недоступності й сумарний час недоступності за деякий період (місяць, рік) не перевищували заздалегідь заданих меж.

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

До переважної більшості комерційних систем пред'являються менш суворі вимоги, однак сучасне ділове життя й тут накладає досить жорсткі обмеження, коли кількість користувачів, що обслуговують, може вимірюватися тисячами, час відповіді не повинен перевищувати декількох секунд, а час недоступності - декількох годин на рік.

Завдання забезпечення високої доступності необхідно вирішувати для сучасних конфігурацій, побудованих у технології клієнт/сервер. Це означає, що в захисті страждає весь ланцюжок - від користувачів (можливо, вилучених) до критично важливих серверів (у тому числі серверів безпеки).

Основні загрози доступності були розглянуті нами раніше.

Тому, під відмовою розуміється подія, що полягає в порушенні працездатності виробу. У контексті цього виріб - це інформаційна система або її компонент. У найпростішому випадку можна вважати, що відмова будь-якого компонента складеного виробу призводить до загальної відмови, а розподіл відмов у часі являє собою простий пуассонівський потік подій. У такому випадку вводять поняття інтенсивності відмов і середнього часу опрацювання на відмову, які зв'язані між собою співвідношенням

де і - номер компонента, λ - інтенсивність відмов, Т, - середній час опрацювання на відмову.

Інтенсивності відмов незалежних компонентів додаються:

а середній час опрацювання на відмову для складеного виробу задається співвідношенням

Уже ці найпростіші вирази показують, що якщо існує компонент, інтенсивність відмов якого є набагато більше, ніж в інших, таким чином він визначає середній час опрацювання на відмову всієї інформаційної системи. Це є теоретичним обгрунтуванням принципу першочергового зміцнення найслабшої ланки.

Пуассонівська модель дозволяє обґрунтувати ще одне важливе положення, яке полягає в тому, що емпіричний підхід до побудови систем високої доступності не може бути реалізований за прийнятний час. При традиційному циклі тестування/налагодження програмної системи за оптимістичними оцінками кожне виправлення помилки призводить до експонентного зниження (приблизно на половину десяткового порядку) інтенсивності відмов. Отже, щоб на досвіді переконатися в досягненні необхідного рівня доступності, незалежно від застосованої технології тестування й налагодження, доведеться витратити час, який практично дорівнює середньому часу опрацювання на відмову. Наприклад, для досягнення середнього часу опрацювання на відмову 10⁵ годин буде потрібно більше 10⁴⁵ годин, що складає більше трьох років. Виходить, потрібні інші методи побудови систем високої доступності, методи, ефективність яких доведена аналітично або практично за більш ніж п'ятдесят років розвитку обчислювальної техніки й програмування.

Пуассонівська модель застосовується в тих випадках, коли інформаційна система містить одиничні крапки відмови, тобто компоненти, виведення яких з ладу призводить до відмови всієї системи. Для дослідження систем з резервуванням застосовується інший формалізм.

Відповідно до постановки завдання будемо вважати, що існує кількісна міра ефективності надаваних виробом інформаційних послуг. У такому випадку вводяться поняття показників ефективності окремих елементів та ефективності функціонування всієї складної системи.

Як міру доступності можна прийняти ймовірність прийнятності ефективності послуг, надаваних інформаційною системою, протягом усього розглянутого проміжку часу. Чим більшим запасом ефективності володіє система, тим вищою є її доступність.

При наявності надмірності в конфігурації системи ймовірність того, що в розглянутий проміжок часу ефективність інформаційних сервісів не знизиться нижче допустимої межі, залежить не тільки від імовірності відмови компонентів, але й від часу, протягом якого вони залишаються непрацездатними, оскільки при цьому сумарна ефективність знижується, і кожна наступна відмова може стати фатальною. Щоб максимально збільшити доступність системи, необхідно мінімізувати час непрацездатності кожного компонента. Крім того, варто враховувати, що ремонтні роботи можуть призвести до зниження ефективності або навіть тимчасового відключення працездатних компонентів; такого типу вплив також необхідно мінімізувати.

Декілька термінологічних зауважень. Звичайно в літературі по теорії надійності замість доступності говорять про готовність (у тому числі про високу готовність). Ми віддали перевагу терміну "доступність", щоб підкреслити, що інформаційний сервіс повинен бути не просто „працездатним", але й бути доступним для своїх користувачів в умовах, коли ситуації недоступності можуть викликатися причинами, які на перший погляд не мають прямого відношення до сервісу (приклад - відсутність консультаційного обслуговування).

Далі, замість часу недоступності зазвичай говорять про коефіцієнт готовності. Нам хотілося б звернути увагу на два показники - тривалість одиничного простою й сумарну тривалість простоїв, тому ми віддали перевагу терміну "час недоступності" як більш ємному.

11.2. Основи заходів забезпечення високої доступності

Основою звходів підвищення доступності є застосування структурованого підходу, що знайшов втілення в об'єктно-орієнтованій методології. Структуризація необхідна по відношенню до всіх І аспектів і складових частин інформаційної системи - від архітектури до адміністративних баз даних, на всіх етапах її життєвого циклу - від ініціації до виведення з експлуатації. Структуризація, важлива сама по собі, є одночасно необхідною умовою практичної реалізації інших заходів підвищення доступності. Тільки маленькі системи можна будувати й експлуатувати як завгодно. У більших системах свої закони, які, як ми вже вказували, програмісти вперше усвідомили більше ЗО років тому.

При розробці заходів забезпечення високої доступності інформаційних сервісів пропонується керуватися наступними архітектурними принципами, що розглядалися раніше:

* апробованість усіх процесів і складових частин інформаційної системи;

* уніфікація процесів і складових частин;

* керованість процесів, контроль стану частин;

* автоматизація процесів;

* модульність архітектури;

* орієнтація на простоту рішень.

Доступність системи в загальному випадку досягається за рахунок застосування трьох груп заходів, спрямованих на підвищення:

* безвідмовності (під пим розуміється мінімізація ймовірності виникнення якої-небудь відмови; це елемент пасивної безпеки, що далі розглядатися не буде);

* відмовостійкості (здатності до нейтралізації відмов, "живучості", тобто здатності зберігати необхідну ефективність, незважаючи на відмови окремих компонентів);

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

Головне при розробці й реалізації заходів забезпечення високої доступності - повнота й систематичність. У цьому зв'язку уявляється доцільним скласти (і підтримувати в актуальному стані) карту інформаційної системи організації (на що ми вже звертали увагу), у якій фігурували б усі об'єкти ІС, їхній стан, зв'язки між ними, процеси, асоційовані з об'єктами й зв'язками. За допомогою подібної карти зручно формулювати намічені заходи, контролювати їхнє виконання, аналізувати стан ІС.

11.3. Відмовостійкість і зона ризику

Інформаційну систему можна уявити у вигляді графа сервісів, ребра якого відповідають відношенню "сервіс А безпосередньо використовує сервіс В".

Нехай у результаті здійснення деякої атаки (джерелом якої може бути як людина, так і природне явище) виводиться з ладу підмножина сервісів В| (тобто ці сервіси в результаті нанесених ушкоджень стають непрацездатними). Назвемо Б і зоною поразки.

У зону ризику Б ми будемо включати всі сервіси, ефективність яких при здійсненні атаки знижується нижче припустимої межі. Очевидно, Б і ­підмножина S. S суворо включає S_b коли є сервіси, безпосередньо не порушені атакою, але критично залежні від уражених, тобто нездатні перемкнутися на використання еквівалентних послуг або в силу відсутності таких, або в силу неможливості доступу до них. Наприклад, зона поразки може зводитися де одного порту концентратора, що обслуговує критичний сервер, а зона ризику охоплює всі робочі місця користувачів сервера.

Щоб система не містила одиночних крапок відмови, тобто залишалася "живучою" при реалізації кожної з розглянутих загроз, жодна зона ризику не повинна містити в собі надавані послуги. Нейтралізацію відмов потрібно виконувати усередині системи, непомітно для користувачів, за рахунок розміщення достатньої кількості надлишкових ресурсів. З іншого боку, природно порівнювати зусилля по забезпеченню "живучості" з розглянутими загрозами. Коли розглядається набір загроз, що відповідають ним, зони поразки можуть виявитися вкладеними, так що "живучість" стосовно більш серйозної загрози автоматично спричиняє й "живучість" у більш простих випадках. Варто враховувати, однак, що звичайно вартість перемикання на резервні ресурси зростає разом зі збільшенням обсягу цих ресурсів. Виходить, що для найбільш ймовірних загроз доцільно мінімізувати зону ризику, навіть якщо передбачено нейтралізацію всеохоплюючої загрози. Немає сенсу перемикатися на резервний обчислювальний центр тільки тому, що в одного із серверів вийшов з ладу блок живлення.

Зону ризику можна трактувати не лише як сукупність ресурсів, але і як частину простору, яка використовується під час реалізації загрози. У такому випадку, як правило, чим більшою відстань дублюючого ресурсу від межі зони ризику, тим вищою вартість його підтримки, оскільки збільшується довжина ліній зв'язку, час переїзду персоналу й т.п. Це ще одне твердження на користь адекватної протидії загрозам, яке варто брати до уваги при розміщенні надлишкових ресурсів й, зокрема, при організації резервних центрів.

Уведемо ще одне поняття. Назвемо зоною нейтралізації загрози сукупність ресурсів, залучених у нейтралізацію відмови, що з'явилися внаслідок реалізації загрози. Маються на увазі ресурси, режим роботи яких у випадку відмови змінюється. Очевидно, зона ризику є підмножиною зони нейтралізації. Чим менше різниця між ними, тим економічним є даний механізм нейтралізації.

Усе, що перебуває поза зоною нейтралізації, відмови "не відчуває" і може трактувати внутрішність цієї зони як безвідмовну. Таким чином, в ієрархічно організованій системі межа між "живучістю" й обслуговуванням, з одного боку, і безвідмовністю, з іншого боку, відносна. Доцільно конструювати цілісну інформаційну систему з компонентів, які на верхньому рівні можна вважати безвідмовними, а питання "живучості" й обслуговування вирішувати в межах кожного компонента.