4. Забезпечення відмовостійкості

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

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

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

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

Резервування програм і даних може виконуватися багатьма способами – за рахунок дзеркалювання дисків, резервного копіювання й відновлення, реплікації баз даних і т.п. Будемо використовувати для всіх перерахованих способів термін "тиражування". Виділимо наступні класи тиражування:

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

Синхронне/асинхронне. Тиражування називається синхронним, якщо зміна передається всім екземплярам сервісу в межах однієї розподіленої транзакції. У протилежному випадку тиражування називається асинхронним.

Здійснюване засобами сервісу, що зберігає інформацію/зовнішніми засобами.

Розглянемо, яким способам тиражування варто надавати перевагу.

Безумовно, слід віддати перевагу стандартним засобам тиражування, які вбудовані у сервіс.

Асиметричне тиражування теоретично простіше симетричного, тому доцільно вибрати асиметрію.

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

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

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

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

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

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

Другий недолік "теплого" резерву випливає з небезпеки малих змін. Може виявитися, що в найпотрібніший момент терміновий переклад резерву в штатний режим неможливий.

З огляду на наведені міркування, потрібно в першу чергу розглядати можливість "гарячого" резервування, або ретельно контролювати використання "теплого" резерву й регулярно (не рідше одного разу на тиждень) проводити тестові перемикання резерву в "гарячий" режим.