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

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

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

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

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

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

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

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

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

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

Рисунок 8.5 - Зони ризику S та ураження S1

В зону ризику S ми включатимемо всі сервіси, ефективність яких при здійсненні атаки падає нижче за допустиму межу. Очевидно, S1 - підмножина S. S строго включає S1, коли є сервіси, безпосередньо не зачеплені атакою, але критично залежні від уражених, тобто нездібні перемкнутися на використання еквівалентних послуг або через відсутність таких, або через неможливість доступу до них. Наприклад, зона ураження може зводитися до одного порту концентратора, обслуговуючого критичний сервер, а зона ризику охоплює всі робочі місця користувачів сервера.

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

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

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