Кластерні технології СУБД Oracle. Частина 3, Інші СУБД, Бази даних, статті

Поперемінне оновлення програмного забезпечення


Oracle дозволяє виробляти поперемінне оновлення (patch) програмного забезпечення в RAC. Оновлення здійснюється по черзі на кожному вузлі, при цьому в неробочому стані знаходиться лише один вузол, а решта продовжують працювати. Подібний сценарій допустимо із спеціально поміченими для цього оновленнями. Ця можливість присутня в RAC починаючи з Oracle 10g.


Для Oracle Clusterware ВСЕ оновлення можуть бути застосовані поперемінно.

Підтримка поперемінного переходу між версіями


Oracle Clusterware підтримує попеременний перехід на вузлах між версіями. Таку ж можливість надає Automatic Storage Management, починаючи з версії Oracle 11g. Все це забезпечує безперервне функціонування бізнесу в режимі 24×7.

Real Application Clusters дозволяє виробляти попеременний перехід між версіями з перервами в роботі близькими до нульових при допомогою логічної резервної бази даних (SQL Apply) Data Guard. У випадку реалізації даного сценарію, спочатку логічна резервна перекладається на нову версію. В цей момент часу бази даних Data Guard працюють під управлінням різних версій СУБД Oracle. Після того як на новому програмному забезпеченні проведені всі необхідні тести для підтвердження працездатності системи, здійснюється переключення ролей між основною і резервною базами даних. Наступними кроками є переклад на нову версію основної бази даних, а потім зворотне перемикання ролей. У разі відмови від продовження переходу, під час роботи в змішаному режимі можливий відкат змін без втрати даних. Для додаткового захисту при виконанні даної процедури може використовуватися інша резервна база даних.

Oracle Clusterware: Захист інших програм


Крім підтримки роботи кластерних баз даних RAC програмне забезпечення Oracle Clusterware для будь-яких інших додатків дозволяє створити середовище так званого “Failover” кластера. В такому кластері захищається завдання працює тільки на одному вузлі і в разі його збою мігрує на інший “живий” вузол кластера. Ця можливість реалізована в Oracle Clusterware починаючи з версії 10g Release 2.

Включення програми в середу високої доступності Oracle Clusterware складається з трьох етапів:

• Створення зовнішньої програми для старту, моніторингу та остановкіпріложенія, що приймає від Clusterware один з можливих аргументів – “start”, “stop” або “check”.

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

• Реєстрація профілю програми. Крім цього, для більшої інтеграції додатків в Oracle Clusterware є програмний інтерфейс “C” (API). За допомогою цього інтерфейсу захищається програма під час роботи може маніпулювати вмістом Oracle Cluster Registry (OCR), і змінювати поведінку Oracle Clusterware з управління додатком.

Навіть без використання RAC кластерна конфігурація, побудована за допомогою Oracle Clusterware, може забезпечити високу готовність працюючим на ньому додаткам, в тому числі некластерного екземплярів СУБД Oracle, дозволити консолідацію дискових систем і простий перехід до RAC в подальшому, коли для баз даних Oracle потрібно ще більша доступність і гнучке масштабування.

Oracle Clusterware є безкоштовним програмним забезпеченням і ліцензоване для використання на кластері за умови:

• захищається програмне забезпечення вироблено компанією Oracle;

• захищається програмне забезпечення використовує базу даних Oracle;

• захищається програмне забезпечення працює на Oracle Unbreakable Linux;

• принаймні на одному з вузлів кластера ліцензована для використання СУБД Oracle редакцій Enterprise або Standard.

Кластером вважається група комп’ютерів з виконуваних на них Oracle Clusterware і одним набором файлів OCR і Voting File.


Опис прикладу: В кластер за допомогою Oracle Clusterware об’єднані чотири комп’ютери з одним набором файлів OCR і Voting File, розташованих на загальних дискових пристроях. На кластері під керуванням Clusterware працюють чотири програми: програма A на вузлі 1, Додаток B на вузлі 2, Додаток З на вузлі 3, некластерного СУБД Oracle працює на вузлі 4. Для всіх чотирьох додатків будь-який інший вузол може бути налаштований в якості резервного. Вузли 1 і 2 використовуються для роботи кластерної СУБД Oracle.

Automatic Storage Management

Механізм Automatic Storage Management (ASM) спочатку представлений в СУБД Oracle 10g об’єднує в собі кластерну файлову систему і можливості менеджера томів. ASM входить в стандартний функціонал СУБД Oracle і не вимагає додаткового ліцензування. ASM скорочує вартість володіння системами зберігання для файлів СУБД Oracle, автоматизуючи безліч дискових операцій.

Механізм ASM виробляє балансування розподілу даних між дисковими пристроями для оптимізації продуктивності і захищає дані за підтримки їх надмірності.

Можливості ASM доступні як в одиночних екземплярах СУБД Oracle, так і в кластерних базах даних під управлінням Oracle RAC. При цьому ASM може використовуватися за бажанням, і його можливості можуть бути застосовані в змішаних конфігураціях, коли одна частина файлів розміщується на дискових групах ASM, а інша на альтернативних файлових системах або на неформатованих розділах дисків.

ASM виробляє віртуалізацію дискових пристроїв – окремі диски об’єднуються в дискові групи, які є одиницями зберігання файлів з точки зору адміністратора бази даних і самої СУБД Oracle. Крім скорочення кількості одиниць управління, СУБД Oracle може робити автоматичне іменування файлів бази даних.

Механізм ASM виробляє оптимізацію розподілу даних між дисковими пристроями однієї дискової групи, використовуючи технологію схожу з ідеєю чергування даних (striping), але за власним алгоритмом. Для цього ASM розбиває дані на екстенти розміром в 1 мегабайт або 128 кілобайт в залежності від типу файлу.

Кластерні технології СУБД Oracle

Механізм ASM дозволяє змінювати склад дискових груп “на льоту”, без зупинки доступу до даних на них розташованих. При додаванні або видаленні дискового пристрою з дискової групи ASM проводить автоматичну перебалансировку даних. Перебалансування може здійснюватися з різним ступенем інтенсивності, що дозволяє уникнути падіння продуктивності вироблених в цей момент операцій введення-виведення з базами даних.

ASM підтримує три режими надмірності даних:

• External – надмірність не підтримується. Рекомендується використовувати при застосуванні RAID масивів здійснюють надмірність даних на апаратному рівні;

• Normal – 2-х кратна надмірність. Підтримуються дві копії одного екстента.

• High – 3-х кратна надмірність. Підтримуються три копії одного екстента.

Для захисту від збоїв апаратних пристроїв забезпечують роботу відразу безліч дисків, в дискових групах можна визначити failure групи, при цьому надмірність даних буде підтримуватися між дисками знаходяться в різних failure групах. Це дозволяє забезпечити “дзеркалювання” даних між дисками, що знаходяться під управлінням різних контролерів і навіть між окремими дисковими масивами.

Основними нововведеннями ASM версії Oracle 11g є:

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

• Покращена підтримка дуже великих баз даних – розмір екстента файлу бази даних відтепер буде змінюватись в залежності від його розмірів. Розміри екстентів можуть варіюватися від 1 одиниці розміщення (Allocation Unit) до 8 і 64 одиниць. Крім цього при створенні дискових груп дозволено встановлювати одиницю розміщення відмінну від значення за замовчуванням в 1МБ. Можливі значення можуть бути 1/2/4/8/16/32/64МБ. І те, і інше нововведення дозволяють: збільшити максимальні розміри керованого дискового простору (до 140PB без надмірності, 42PB c 2-х кратної надмірністю, 15PB з 3-х кратною), заощадити ресурси пам’яті і збільшити продуктивність.

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

• Поперемінне оновлення програмного забезпечення ASM – дозволяє проводити оновлення по черзі на кожному з вузлів кластера. Під час виконання процедури поновлення на вузлах допускаються різні версії програмного забезпечення.

Консолідація дискових пристроїв зберігання


Automatic Storage Manager з допомогою Oracle Clusterware дозволяє провести консолідацію дискових ресурсів в групи, так що вони можуть використовуватися спільно всім базами даних, що працюють на одному кластері. Для користування спільним дисковим пулом база даних не повинна бути кластерної, в цьому випадку опадає необхідність придбання ліцензій Real Application Clusters.


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

Oracle Clusterware, використовується єдиний пул дискових пристроїв. Файли кластерної бази даних з примірниками на вузлах 1 і 2, кластерної бази даних з примірниками на вузлах 3 і 4 і не кластерної бази даних з примірником на вузлі 4 розміщуються у загальних дискових групах під управлінням кластерної конфігурації ASM.

Real Application Testing – нова опція СУБД Oracle 11g


Принциповою відмінністю опції Real Application Testing від відомих засобів емуляції навантаження є те, що замість трудомісткого створення синтетичного тесту, проводиться її захоплення на промисловій системі. Захоплена у вигляді SQL команд навантаження відтворюється на тестовому стенді з наступним автоматичним аналізом виконання.

Таким чином, опція Real Application Testing для багатьох замовників і розробників робить реальним недосяжне повнофункціональне тестування з реальним обсягом навантаження, а значить істотно знижує ризики міграції на нову платформу.

Приклад можливого сценарію роботи з опцією Real Application Testing:

• Повне резервне копіювання виробничої БД – це забезпечить акуратне відтворення навантаження на тестовій системі і знизить

кількість логічних помилок;

• Захоплення та збереження в двійкові файли активності клієнтів бази даних при мінімальному впливі на систему. Можливі фільтри: по

окремим сесій, за іменами користувачів, модулів, програм або сервісів;

• Поновлення на тестовій системі копії виробничої БД. Бажана установка системного часу на час початку захоплення

активності;

• Трансформація захоплених файлів в програється формат, для можливого багаторазового відтворення;

• Установка режиму відтворення: синхронний або асинхронний.

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

• Запуск відтворення навантаження на тестовій базі даних.


• Отримання звітів.


Додаткові настройки при відтворенні тестів для асинхронного режиму:

• час між sql викликами:

• 0% – виконувати якомога швидше;

• <100% виконувати швидше, ніж у реальній ситуації;

• 100% виконувати точно як в реальній ситуації;

•> 100% виконувати повільніше, ніж у реальній ситуації

• послідовність входу сесій:

• 0% – все сесії з’єднуються в БД негайно;

• 100% всі сесії з’єднуються точно так, як у реальній ситуації;

• порядок операцій commit:

• зберігати порядок операції;

• не зберігати порядок операцій.

Крім цього можна вказати, число сесій, які повинні відтворювати навантаження.

Автоматично формується звітність включає:

• Число рядків, які повернув кожен sql виклик в промислових і тестових системах, і відхилення між ними;

• Звітність по помилках для кожного виклику для нових помилок, які сталися на тестовій системі, а так же по помилках, які змінилися на тестовій системі;

• Звіти Automatic Workload Repository (AWR)

Всі операції по захопленню, відтворення навантаження здійснюються з графічного інтерфейсу Enterprise Manager (EM)

У версії СУБД Oracle 10.2.0.4 планується поява можливості захоплення навантаження на СУБД Oracle 10g для її відтворення її на СУБД Oracle 11g, що дозволить значно спростити перехід з однієї версії на іншу.


Опція Real Application Testing може працювати як з кластерної так не-кластерної базою даних. Але особливу користь вона може принести саме при міграції додатків в середу Oracle RAC.


Висновок

Технологія Oracle Real Application Clusters призначена для забезпечення гнучкої економічної масштабованості і високої доступності. Захищаючи від збоїв програмної та апаратної частини, Oracle RAC забезпечує безперервний доступ до даних.

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

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

Навіть без використання RAC побудова кластерної конфігурації на основі Oracle Clusterware може принести вигоди. Oracle Clusterware дозволяє забезпечити високу доступність для додатків розроблених іншими виробниками, а спільне його використання з Automatic Storage Management дає можливість побудувати єдиний кластеризованих пул дискових пристроїв підприємства.


Закінчення.

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


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

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

Ваш отзыв

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

*

*