
- •Журнал транзакцій
- •Стандарт odbc
- •Робота з апаратурою
- •Raid-масиви
- •Кластерна організація роботи
- •Метод дзеркальних сховищ
- •Рівні ізоляції
- •Адміністративні методи захисту
- •Insert – дозволяє користувачу заносити нові дані в таблицю або представлення таблиці;
- •Розсинхронізація даних в розподіленій моделі
- •Вбудована Java
Кластерна організація роботи
Існує достатня кількість засобів побудови надійних систем. Дискові масиви RAID, наприклад, дозволяють не переривати обробку запитів до інформації, яка зберігається на дисках, при виході з ладу одного або кількох елементів масива. Є технології, що гарантують надлишковість інших систем сервера. Однак жоден з цих варіантів не врятує, якщо з ладу вийде вся обчислювальна система. Ось тут в нагоді і стане кластеризація.
Спочатку перед кластерами ставилися дві задачі: потужні обчислення і підтримка розподілених баз даних, особливо таких, для яких потрібна підвищена надійність. Привабливість кластера визначається перш за все його можливістю побудувати унікальну архітектуру, що володіє достатньою продуктивністю, стійкістю до відмов апаратури і програмного забезпечення і при цьому легко збільшуєму і модернізуєму, але універсальними засобами, з стандартних компоненетів і за помірну ціну.
Найпростіший варіант кластеризації – дзеркалювання, коли один з мережних серверів виступає в ролі “дзеркала” для іншого. На “дзеркальному” сервері встановлено таке саме програмне забезпечення, що й на основному, причому актуальність цього програмного забезпечення підтримується шляхом передачі даних по комунікаційному каналу, який з’єднує сервери в кластері. Єдина відміна між двома системами полягає в тому, що дзеркальний сервер не реагує на мережні запити доти, доки не вийде з ладу основний. Збій знаходить “дзеркало” і ініціює виконання додатку на ньому, при цьому всі запити обробляються так само, як і на основному сервері. Таку конфігурацію кластера називають “активний/резервний”.
З точки зору користувачів основний і дзеркальний сервер – це єдина система, вони не знають і не можуть дізнатися, який з серверів в даний момент обслуговує запити. Дещо змінений варіант такої кластеризації – це два сервери, які підмінюють один одного у випадку збою (конфігурація “активний/активний”). Наприклад, Web-сервер і сервер додатків в одній мережі можуть виконувати функції “дзеркала” один для одного. Якщо вийде з ладу Web-сервер, його функції візьме на себе сервер додатків і навпаки. Деякі програмні рішення навіть дозволяють будь-якому комп’ютеру в мережі виступати в якості “дзеркала” для будь-якої іншої машини в тій самій мережі.
На відміну від відмовостійких систем з надлишковими елементами, кластери об’єднують відносно незалежні одна від одної машини, кожну з яких можна зупинити для профілактики або реконфігурування, не порушуючи при цьому дієздатності кластера в цілому. Висока продуктивність кластера і зведення до мінімуму часу простоїв додатків досягається завдяки тому, що:
у випадку збою програмного забезпечення на одному з вузлів додаток продовжує функціонувати або автоматично перезапускається на інших вузлах кластера;
вихід з ладу одного з вузлів (або кількох) не призведе до краху всієї кластерної системи;
профілактичні і ремонтні роботи, реконфігурацію або зміну версій програмного забезпечення, як правило, можна виконувати в вузлах кластера почерзі, не перериваючи роботи інших вузлів.
Помітним рух за проведення в життя кластерів став лише після створення Oracle Parallel Server – першого комерційного продукту на ринку професійних СУБД для багатьох користувачів, орієнтованого одночасно на багатопроцесорну архітектуру і масові застосування.
Parallel Server Option є спеціальним розширенням СУБД Oracle, орієнтованим на підтримку слабозв’язаних комп’ютерних систем. Логічна структура паралельного сервера обрана таким чином, щоб на кожному процесорі виконувався свій екземпляр Oracle. Основною вимогою до систем такого роду є використання розділяємих накопичувачів. Реалізація паралельного сервера базується на концепції розподіленого кеша, коли кожний процесор, і відповідно, кожний екземпляр працює зі своєю локальною пам’яттю (кешем в термінах Oracle), але при цьому взаємодіє з іншими для обміну даними.
Практично головну роль в управлінні кластером грає розподілений менеджер блокувань (DLM – Distributed Lock Manager).
Для того, щоб ефективність наращування кластера не спадала із збільшенням кількості вузлів, необхідний такий засіб внутрикластерної взаємодії, який забезпечував би адекватну швидкість обміну даними між вузлами кластера. Найпривабливіше (за умов доброго фінансування) виглядають системи з комутацією каналів високої продуктивності, Fibre Channel, наприклад.
Крім значної масштабуємості, OPS забезпечує сервіс, отримавший назву “висока готовність” (пропонуємий словниками науково-технічних термінів переклад англійського high avalibility), по суті означаючий можливість знаходження, локалізації і усунення поодиночних збоїв і відмов системи. Коли відмовляє одна з обчислювальних систем, які входять до кластера (одного з процесорних модулей), наступний SQL-запит переадресується іншій. Для підвищення надійності кластера і функціонуючої на ньому бази даних рекомендується використання дискових масивів RAID, які можуть дублюватися в рамках кластера. Для забезпечення рівномірного завантаження використовують монітори транзакцій.
Скажимо декілька слів про те, як побудований кластер.
Кластер об’єднує кілька серверів, поєднаних між собою спеціальним комунікаційним каналом, який часто також називають “системною мережею”. Невід’ємною частиною кластера є спеціальне програмне забезпечення, яке, власне, і вирішує проблему відновлення вузла у випадку збою, а також вирішує інші задачі, наприклад, змінює ІР-адресу сервера додатків, якщо він вийшов з ладу і виконання перекладено на інший вузел. Кластерне програмне забезпечення зазвичай має кілька попередньо заданих сценарієв відновлення дієздатності системи, а також може надавати адміністратору можливості настройки таких сценаріїв. Відновлення після збоїв може підтримуватися як для вузла в цілому, так і для окремих його частин.
Кластери можуть мати розділяєму пам’ять на зовнішніх дисках, як правило, на дисковому масиві RAID. Замість розділяємої пам’яті, в кластерах може реалізовуватися принцип дзеркалювання інформації, коли дані одного вузла тиражуються на дискові накопичувачі іншго.
Вузли кластера контролюють дієздатність один одного і обмінюються специфічною кластерною інформацією. Контроль за дієздатністю здійснюється за допомогою спеціального сигналу (в літературі по кластерах його часто називають “headbeat” – серцебиття), який вузли кластера передають один одному, для того щоб підтвердити своє нормальне функціонування. Зупинення “серцебиття” одного з вузлів сигналізує кластерному програмному забепеченню про збій, який стався, і про необхідність перерозподілити навантаження на вузли, що залишилися.
В якості комунікаційного канала можуть викоритсовуватися звичайні мережні технології, розділяємі шини введення/виведення, високошвидкий інтерфейс Fibre Channel або спеціалізовані технології. Вимоги до швидкодії комутаційного канала залежать від ступіня інтеграції вузлів кластера і характера роботи додатків.
Забезпечення цілісності даних
Дані, що зберігаються в базі даних, можуть представляти собою велику цінність. Це легко зрозуміти, пригадавши, що найбільш активними і масовими споживачами СУБД є комерційні структури, наприклад, банки. Тому питання надійності збереження даних стає практично першочерговим при виборі СУБД.
Метод backup-a
Одним з базових методів збереження даних є резервне копіювання (backup). Останнє полягає в періодичному запуску процедури отримання копії бази даних і лога транзакцій на носій, який знаходиться окремо від системи.
Будь-яка система може зазнати збоїв в роботі, питання лише в тому, коли саме вони відбудуться. Виходячи з цього, необхідно бути готовими, що в якийсь момент система “відмовиться” працювати.
Метод резервного копіювання фактично являє собою “фотознімок” стану системи в певний момент часу. Сучасні СУБД надають засоби резервного копіювання, які також дозволяють відновлювати базу даних у випадку її пошкодження. Цей механізм може бути запущений в автоматичному режимі. Таким чином можна організувати щоденний backup даних в автоматичному режимі.