AsBase® DataGuard Suite
Демонстраційна версія доступна для завантаження...
Проблема збереження даних та доступності системи
До складку практично будь-якої інформаційної системи (банківська система, система продажу авіа білетів чи інтернет-магазин) входить база даних (БД). Саме БД є тим «місцем» де зберігається та накопичується інформація, що необхідна для роботи системи. Наприклад, у випадку банку, це інформацію щодо рахунків клієнтів, грошових переказів, операцій з картками. У випадку інтернет-магазину це дані щодо товарів, їх типів, наявності на складі, цінах, замовленнях і т.д.
Зупинка роботи БД через несправність може призвести до серйозних наслідків, що у свою чергу, спричинять значні фінансові втрати. Зрозумілим є бажання мінімізувати ймовірність таких аварій.
Рішення 1 – резервне копіювання БД
Одним із можливих варіантів вирішення зазначеної задачі може бути створення та періодичне оновлення резервних копій БД – спеціального набору файлів, що містять всю інформацію із БД на визначений період часу. Резервні копії можна зберігати на окремому диску і навіть на окремому сервері, що значно віддалений від основної БД. У випадку зупинки роботи БД вся інформація може бути відновлена із резервної копії, отже система може продовжувати роботу.
Однак даний підхід має два значні недоліки.
Недолік 1 – неможливість відновити абсолютно всі дані.
Оскільки резервні копії створюються через певний період часу, завжди існує певна частина інформації, яку не можна буде встановити із резервної копії. Більше того, у багатьох випадках саме ця частина є найціннішою, оскільки містить дані щодо останніх виконаних у системі операціях. Розглянемо приклад з інтернет-магазином. Нехай резервна копія БД створюється щопонеділка. У такому випадку, якщо аварія відбулася у середу, відновити можна буде лише ті дані, що були збережені при останньому резервному копіюванні – тобто станом на понеділок. При цьому, буде втрачена інформація щодо всіх замовлень, які були оформлені в період понеділок-середа. Клієнти, що оформили замовлення, і не отримали товар, будуть незадоволені. Магазин втратить не лише гроші, а й репутацію надійного торгівельного майданчика. Отже, навіть якщо виконувати резервне копіювання щоденно, залишатиметься частина даних, що не підлягатиме відновленню у разі аварії.
Недолік 2 – відновлення БД займає час.
Операція з відновлення БД із резервної копії може вимагати значних часових витрат – в залежності від масштабу аварії та об’єму відновлюваних даних, від однієї години до доби і більше. Під час операції відновлення система не може обслуговувати користувачів. Повернемося до прикладу з інтернет-магазином. На додачу до втрачених замовлень, магазин протягом декількох годин буде недосяжним для покупців, що також спричинить втрати репутації та фінансів.
Рішення 2 – синхронізація реплікацій даних
У пошуках підходу, що дозволятиме гарантовано відновлювати всі дані та забезпечуватиме мінімальний простій системи, інженери прийшли до наступного рішення.
100%-а збереженість даних
На додачу до основного сервера, на якому розгорнута БД, встановлюється один або декілька додаткових (резервних серверів). На кожному із них розгортається точна копія БД, після чого за допомогою спеціального програмного забезпечення налаштовується синхронна реплікація даних. Сутність даного механізму полягає у тому, що всі операції, які виконуються на основному сервері, автоматично повторюються (реплікуються) на резервних серверах. Синхронним даний процес називається тому, що жодна операція із основною БД не вважається завершеною, доки її результати не будуть розповсюджені на всі резервні сервери. Саме завдяки такій синхронності забезпечується збереження абсолютно всіх даних. У прикладі з інтернет-магазином це означає, що у випадку аварії не буде втрачено жодне із кінцево оформлених замовлень. Повторимося – у резервній копії БД збережуться дані про абсолютно всі замовлення, котрі клієнти магазину встигли оформити до виникнення аварії.
Мінімальний простій БД
Що ж робити, коли аварія на основній БД все ж виникла? Найбільш очевидний та прямолінійний шлях – надати адміністратору БД можливість «підмінити» зіпсовану основну БД однією із копій, що розгорнута на резервних серверах. Говорячи технічною мовою, надати адміністратору можливість перемикання ролей вузлів реплікацій. Вузол (сервер), що раніше виконував роль резервного, за командою адміністратора стає основним та продовжує обслуговувати запити клієнтів з того самого «місця», на якому закінчив попередній (аварійний) вузол. Дане перемикання займає не більше 2-3 хвилин, проте з однією вагомою умовою – якщо адміністратор знаходиться на своєму робочому місці, вчасно отримавши від системи повідомлення щодо аварії, виконав команду на перемикання.
Проте що робити, у разі, якщо адміністратор через певні причини немає на місці, а кожна хвилина простою системи коштує не мало? На допомогу приходить функція автоматичного перемикання ролей. Якщо дана функція автоматизована, система самостійно визначить аварійну ситуацію та «підмінить» базу даних. Користувачі можуть навіть не помітити короткотермінового відключення БД.
AsBase DataGuard Suite – збереження та доступність даних за розумні гроші
Маючи значний досвід розробки «великих» інформаційних систем, розробники AsBase DataGuard Suite чудово розуміли важливість описаних проблем та необхідність їхнього вирішення. У той самий час очевидною була й інша обставина – існування рішень світових виробників систем управління базами даних (СУБД), таких як Oracle, що мають один значний недолік – надзвичайно висока вартість.
Зокрема, продукт Oracle DataGuard Broker, що виконує функції синхронної реплікації даних та автоматичного перемикання ролей вузлів реплікації, наявний лише у складі СУБД Oracle Enterprise Edition, вартість якої вимірюється десятьма тисячами доларів США.
Далеко не всі замовники мають змогу здійснювати такі капіталовкладення у програмне забезпечення. У той же час, відмовостійкість БД та збереженість даних стають на порядку денному багатьох підприємств. При цьому багато компаній використовують дешевші чи безкоштовні рішення від Oracle – відповідно СУБД Oracle Standard Edition та Oracle Express Edition.
Проаналізувавши ситуацію, група компаній Corside прийняла рішення щодо розробки власного продукту - AsBase DataGuard Suite.
Продукт AsBase DataGuard Suite є повноцінною заміною Oracle DataGuard Broker та забезпечує:
• Створення мережі синхронної реплікації даних, включно до 8-ми серверів.
• Автоматичне та ручне (за командою адміністратора) перемикання ролей вузлів реплікацій.
Використання AsBase DataGuard Suite у зв’язці із СУБД Oracle забезпечує практично 100%-у збереженість інформації та цілодобову доступність БД для клієнтського програмного забезпечення.
До складу AsBase DataGuard Suite внесені зручні та інтуїтивно зрозумілі засоби інсталяції та конфігурування мережі реплікацій, а також утиліта командного рядка, що аналогічна до існуючої утиліти від Oracle. Останнє робить AsBase DataGuard Suite зручним для використання адміністратора БД, які знайомі із продуктом Oracle.
Окрім перерахованих переваг, AsBase DataGuard Suite володіє ще однією – значно нижчою вартістю (у порівнянні із рішеннями Oracle).
