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

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

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

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

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

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

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

Виділимо наступні класи тиражування:

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

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

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

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

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

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

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

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

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

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

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

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

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

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