Файл: 10_ua_5_.doc

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

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

---

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

---

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

---

1.5 Програмне забезпечення проміжного шару

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

Про можливості і властивості ПО проміжного шару можна прочитати в статті Ф. Бернстайна "Middleware: модель сервісів розподіленої системи" (Jet Info, 1997, 11).

Перерахуємо основні достоїнства ПО ПС, істотні для забезпечення високої доступності.

• ПО ПС зменшує складність створення розподілених систем. Подібне ПО бере на себе частина функцій, які в локальному випадку виконують операційні системи;

• ПО ПС бере на себе маршрутизацію запитів, дозволяючи тим самим забезпечити "живучість" прозорим для користувачів чином;

• ПО ПС здійснює балансування завантаження обчислювальних потужностей, що також сприяє підвищенню доступності даних;

• ПО ПС в змозі здійснювати тиражування будь-якої інформації, а не тільки вмісту баз даних. Отже, будь-який додаток можна зробити стійким до відмов серверів;

• ПО ПС в змозі відстежувати стан додатків і при необхідності тиражувати і перезапускати програми, що гарантує "живучість" програмних систем;

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

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

Забезпечення обслуживаемости

Заходи по забезпеченню обслуживаемости направлені на зниження термінів діагностики і усунення відмов і їх наслідків.

Для забезпечення обслуживаемости рекомендується дотримувати наступні архітектурні принципи:

• орієнтація на побудову інформаційної системи з уніфікованих компонентів з метою спрощення заміни частин, що відмовили;

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

---