Oracle RAC. Загальний опис. Частина 1, Інші СУБД, Бази даних, статті

Високонавантажених сайти, доступність “5 nines”. На задньому фоні (backend) купа оброблюваної інформації в базі даних. А що, якщо залізо забарахлила, якщо вилетить якась давно не виявлялася помилка в ОС, впаде мережевий інтерфейс? Що буде з доступністю інформації? З цікавості я вирішив розглянути, які рішення перелічених вище проблем пропонує Oracle. Останні версії, на відміну від Oracle 9i, називаються Oracle 10g (Або 11g), де g – означає “grid”, розподілені обчислення. В основі розподілених обчислень “як не крути” лежать кластера, і додаткові технології реплікації даних (DataGuard, Streams). У цій статті в загальних рисах описано, як влаштований кластер на базі Oracle 10g. Називається він Real Application Cluster (RAC).
Стаття не претендує на повноту і всеосяжність, також в ній виключені налаштування (щоб не збільшувати в об’ємі). Сенс – просто дати уявлення про технології RAC.
Статтю хотілося написати якомога доступніше, щоб прочитати її було цікаво навіть людині, мало знайомому з СУБД Oracle. Тому ризикну почати опис з аспектів найбільш часто зустрічається конфігурації БД – single-instance, коли на одному фізичному сервері розташовується одна база даних (RDBMS) Oracle. Це не має безпосереднього відношення до кластеру, але основні вимоги та принципи роботи будуть однакові.

Введення. Single-instance.


Найбільш поширена база даних, встановлена ​​на одному фізичному сервері, називається single-instance. Я раніше не зраджував особливого значення різниці понять між: примірник (Instance) бази даних і самої бази даних (в цілому). Тепер же хочу особливо відзначити, що під екземпляром мається на увазі ПО (процеси, потоки, сервіси) яке розташовується в оперативній пам’яті і обробляє дані (сортування, буферизація, обслуговування) отримані безпосередньо з диска. Таким чином, під базою даних розуміється сукупність:


 

У всіх сучасних реляційних БД дані зберігаються в таблицях. Таблиці, індекси та інші об’єкти в Oracle зберігаються в логічних контейнерах – табличних просторах (tablespace). Фізично ж tablespace розташовуються в одному або декількох файлах на диску. Зберігаються вони в такий спосіб:
Кожен об’єкт БД (таблиці, індекси, сегменти відкоту і.т.п.) зберігається в окремому сегменті – Області диска, яка може займати простір в одному або декількох файлах. Сегменти в свою чергу, складаються з одного або декількох екстентів. Екстент – Це безперервний фрагмента простору в файлі. Екстенти складаються з блоків. Блок – Найменша одиниця виділення простору в Oracle, за замовчуванням дорівнює 8K. У блоках зберігаються рядки даних, індексів або проміжні результати блокувань. Саме блоками сервер Oracle звичайно виконує читання і запис на диск. Блоки мають адресу, так званий DBA (Database Block Address).

При будь-якому зверненні DML (Data Manipulation Language) до бази даних, Oracle довантажує відповідні блоки з диска в оперативну пам’ять, а саме в буферний кеш. Хоча можливо, що вони вже там присутні, і тоді до диска звертатися не потрібно. Якщо запит змінював дані (update, insert, delete), то зміни блоків відбуваються безпосередньо в буферному кеші, і вони позначаються як dirty (брудні). Але блоки не відразу скидаються на диск. Адже диск – саме вузьке місце будь-якої бази даних, тому Oracle намагається якомога менше до нього звертатися. Брудні блоки будуть скинуті на диск автоматично фоновим процесом DBWn при проходженні контрольної точки (checkpoint) або при перемиканні журналу.

Припустимо, що була запущена одна тривала транзакція, зчитує дані, і десь в процесі її виконання запустилася інша транзакція з наміром змінити один з зчитувальних блоків. Як сервер скоординує роботу цих запитів? Насправді, питання поділяється на два:


  1. Що буде, якщо Oracle впаде десь на середині довгою транзакції (якби вона вносила зміни)?
  2. Які ж дані прочитає перша транзакція, коли в кеші у неї “під носом” інша транзакція змінила блок?

Для відповіді на ці питання розглянемо механізм забезпечення узгодженого читання CR (consistency read). Вся справа в чарівних бульбашках журналах транзакцій, які в Oracle представлені двома типами:


 

Коли в базу даних надходить запит на зміну, то Oracle застосовує його в буферному кеші, паралельно вносячи інформацію, достатню для повторення цієї дії, в буфер повторного зміни (redo log buffer), Що знаходиться в оперативній пам’яті. Як тільки транзакція завершується, відбувається її підтвердження (commit), і сервер скидає вміст redo buffer log на диск в redo log в режимі append-write і фіксує транзакцію. Такий підхід набагато менш витратний, ніж запис на диск безпосередньо зміненого блоку. При збої сервера кеш і всі зміни в ньому загубляться, але файли redo log залишаться. При включенні Oracle почне з того, що загляне в них і повторно виконає зміни таблиць (транзакції), які не були відображені в datafiles. Це називається “накотити” зміни з redo, roll-forward. Online redo log скидається на диск (LGWR) При підтвердженні транзакції, при проходженні checkpoint або кожні 3 секунди (default).
З undo трохи складніше. З кожною таблицею в сусідньому сегменті зберігається асоційований з нею сегмент скасування. При запиті DML разом з блоками таблиці обов’язково підвантажуються дані з сегмента відкату і зберігаються також в буферному кеші. Коли дані в таблиці змінюються в кеші, в кеші так само відбувається зміна даних undo, туди вносяться “протидії”. Тобто, якщо в таблицю було внесено insert, то в сегмент відкоту вноситься delete, delete – insert, update – вноситься попереднє значення рядка. Блоки (і відповідні дані undo) позначаються як брудні і переходять в redo log buffer. Да-да, в redo журнал записуються не тільки інструкції, які зміни варто внести (redo), але і які у них протидії (undo). Так як LGWR скидає redo log buffer кожні 3 секунди, то при невдалому виконанні тривалої транзакції (на пару хвилин), коли після хвилини сервер впав, в redo будуть записи не завершені commit. Oracle, як прокинеться, накотить їх (roll-forward), і по відновленим (з redo log) в пам’яті сегментам відкату даних скасує (roll-back) все незафіксовані транзакції. Справедливість відновлено.
Коротко варто згадати ще одну незаперечну перевагу undo сегмента. За другим сценарієм (зі схеми) коли select дійде до читання блоку (DBA) 500, він раптом виявить що цей блок в кеші вже був змінений (Позначка брудний), і тому звернеться до сегменту відкоту, для того щоб отримати відповідне попередній стан блоку. Якщо такого попереднього стану (flashback) в кеші не було присутнє, він прочитає його з диска, і продовжить виконання select. Таким чином, навіть при тривалому “select count (money) from bookkeeping” дебет з кредитом зійдеться. Узгоджено з читання (CR).

Відволіклися. Пора шукати підступи до кластерної конфігурації. =)


Рівень доступу до даних. ASM.


 

Сховищем (datastorage) У великих БД майже завжди виступає SAN (Storage Area Network), Який надає прозорий інтерфейс серверів до дисковим масивам.
Сторонні виробники (Hitachi, HP, Sun, Veritas) пропонують комплексні рішення по організації таких SAN на базі ряду протоколів (найпоширенішим є Fibre Channel), з додатковими функціональними можливостями: віддзеркалення, розподіл навантаження, підключення дисків на льоту, розподіл простору між розділами і.т.п.
Позиція корпорації Oracle в питанні побудови бази даних будь-якого масштабу зводиться до того, що Вам потрібно тільки відповідне ПЗ від Oracle (з відповідними ліцензіями), а вбрання обладнання – по можливості (якщо кошти залишаться після покупки Oracle :). Таким чином, для побудови високонавантажених БД можна обійтися без дорогих SPARC серверів і фаршированих SAN, використовуючи сервера на безкоштовному Linux і дешеві RAID-масиви.
На рівні доступу до даних і дискам Oracle пропонує своє рішення – ASM (Automatic Storage Management). Це окремо встановлюється на кожен вузол кластера міні-примірник Oracle (INSTANCE_ENGINE= ASM), що надає сервіси роботи з дисками.
Oracle намагається уникати звернень до диску, тому що це є, мабуть, основним bottleneck будь БД. Oracle виконує функції кешування даних, але ж і файлові системи так само буферизують запис на диск. А навіщо двічі буферізіровать дані? Причому, якщо Oracle підтвердив транзакцію і отримав повідомлення тому, що зміни у файли внесені, бажано, щоб вони вже знаходилися там, а не в кеші, на випадок “падіння” БД. Тому рекомендується використовувати RAW devices (диски без файлової системи), що робить ASM.
ASM працює поверх RAW device, його перевагами є:


Disk group – Об’єднання декількох дисків. При запису файлів на диски дані записуються екстента розмірами по 1 МБ, розподіляючи їх по всіх дисках в групі. Це робиться для того, щоб забезпечити високу доступність, адже частини однієї таблиці (з tablespace) розкидані по різним фізичним дискам.
Здібності ASM:


Припустимо, що кілька дисків підключені до певного контролеру-і, таким чином, є, SPF – single point of failure (При виході з ладу контроллера втрачаємо весь дисковий масив). У ASM є технологія визначення Failure Groups всередині Disk Group. При цьому механізмі дзеркалювання буде розкидати копії екстентів по дискам, що знаходяться в різних failure groups, щоб уникнути SPF (Single Point of Failure), Наприклад, при смерті SAN або RAID контролера.
Таким чином, кластер тепер може зберігати і читати дані з загального файлового сховища.

Пора на рівень вище.


Clusterware. CRS.


На даному рівні необхідно забезпечити координацію та спільну роботу вузлів кластера, тобто clusterware шар: десь між самим примірником бази даних і дисковим сховищем:
CRS (Cluster-Ready Services) – Набір сервісів, що забезпечує спільну роботу вузлів, відмовостійкість, високу доступність системи, відновлення системи після збою. CRS виглядає як “міні-екземпляр” БД (ПО) встановлюваний на кожен вузол кластера. Встановлювати CRS – в обов’язковому порядку для побудови Oracle RAC. Крім того, CRS можна інтегрувати з рішеннями clusterware від сторонніх виробників, таких як HP або Sun.
Знову трохи “термінології” …
CRS складається з 3-х основних компонентів:
























x Призначення (коротко) З якими правами працює При смерті процесу, перезавантажується:
CSSD Механізм синхронізації для взаємодії вузлів в кластерному середовищі. user процес
CRSD Основний “движок” для підтримки доступності ресурсів root хост
EVMD Процес оповіщення про події, що відбуваються в кластері user процес
Налаштування кластера зберігаються в OCR (Oracle Cluster Registry). OCR – це спеціальний файл профілів вузлів бази даних, що зберігає їх поточну конфігурацію: доступність вузлів, розподіл сервісів (кілька БД можуть підтримуватися різними групами вузлів в кластері), мережеві настройки і.т.п. Фізично OCR зберігається в загальному datastorage. При роботі кластера кожен вузол зберігає в пам’яті OCR, і тільки один вузол (master) виробляє безпосереднє оновлення OCR на диску.
Як вже стало ясно з таблички, найголовнішим процесом, “наймогутнішим демоном”, є CRSD (Cluster Ready Services Daemon). В його обов’язки входить: запуск, зупинка вузла, генерація failure logs, реконфігурація кластера в разі падіння вузла, він також відповідає за відновлення після збоїв і підтримку файлу профілів OCR. Якщо демон падає, то вузол цілком перезавантажується. CRS управляє ресурсами OCR: Global Service Daemon (GSD), ONS Daemon, Virtual Internet Protocol (VIP), listeners, databases, instances, and services.
В обов’язки сервісу CSSD (Cluster Synchronization Service Daemon) Входить координація взаємодії вузлів кластера, синхронізація вузлів і ресурсів між ними, визначення їх доступності через такі функції:

CSSD надає динамічну інформацію про вузлах і примірниках, які є частиною його на поточний момент, і відповідає за блокування ресурсів в кластері.
Інформатором в кластері виступає EVMD (Event Manager Daemon), Який сповіщає вузли про події: про те, що вузол запущений, втратив зв’язок, відновлюється. Він виступає сполучною ланкою між CRSD і CSSD. Сповіщення також направляються в ONS (Oracle Notification Services), універсальний шлюз Oracle, через який оповіщення можна розсилати, наприклад, у вигляді SMS або e-mail.
Стартує кластер приблизно за такою схемою: CSSD читає із загального сховища OCR, звідки зчитує кластерну конфігурацію, щоб пізнати, де розташований voting disk, читає voting disk, щоб дізнатися скільки вузлів (піднялося) в кластері та їх імена, встановлює з’єднання з сусідніми вузлами по протоколу IPC. Обмінюючись heartbeat, перевіряє, чи всі сусідні вузли піднялися, і з’ясовує, хто в поточній конфігурації визначився як master. Провідним (master) вузлом стає першим запустив вузол. Після старту, всі запущені вузли реєструються у master, і згодом будуть надавати йому інформацію про своїх ресурсах.
Рівнем вище CRS на вузлах встановлені екземпляри бази даних.
Один з одним вузли спілкуються по private мережі – Cluster Interconnect, За протоколом IPC (Interprocess Communication). До неї пред’являються вимоги: висока ширина пропускної здатності і малі затримки. Вона може будуватися на основі високошвидкісних версій Ethernet, рішень сторонніх постачальників (HP, Veritas, Sun), або ж набирає популярність InfiniBand. Останній крім високої пропускної здатності пише і читає безпосередньо з буфера програми, без необхідності в здійсненні викликів рівня ядра. Поверх IP Oracle рекомендує використовувати UDP для Linux, і TCP для середовища Windows. Також при передачі пакетів по interconnect Oracle рекомендує укладатися в рамки 6-15 ms для затримок.


Читати частина 2

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*