Чимало Enterprise додатків і систем віртуалізації мають власні механізми для побудови відмовостійких рішень. Зокрема, Oracle RAC (Oracle Real Application Cluster) є кластером з двох або більше серверів баз даних Oracle, що працюють спільно з метою балансування навантаження та забезпечення відмовостійкості на рівні сервера/додатку. p align="justify"> Для роботи в такому режимі необхідне загальне сховище, в ролі якого зазвичай виступає СГД.
Як ми вже розглядали в одній із своїх , сама собою СХД, попри наявність дубльованих компонент (зокрема і контролерів), все-таки має точки відмови – головним чином, як єдиного набору даних. Тому для побудови рішення Oracle з підвищеними вимогами до надійності схему «N серверів – одна СГД» необхідно ускладнити.
Спершу, звичайно, треба визначитися, від яких ризиків ми намагаємось застрахуватися. У рамках цієї статті ми не розглядатимемо захист від загроз типу «метеорит прилетів». Отже, побудова територіально рознесеного рішення disaster recovery залишиться темою для однієї з наступних статей. Тут ми розглянемо так зване рішення Cross-Rack Disaster Recovery, коли захист будується на рівні серверних шаф. Самі шафи можуть бути як в одному приміщенні, так і в різних, але зазвичай в межах однієї будівлі.
Ці шафи повинні містити весь необхідний набір обладнання та програмного забезпечення, який дозволить забезпечувати роботу баз даних Oracle незалежно від стану «сусіда». Іншими словами, використовуючи рішення Cross-Rack disaster recovery, ми виключаємо ризики при відмові:
- Сервера програми Oracle
- системи зберігання
- Систем комутації
- Повний вихід із ладу всього обладнання в шафі:
- Відмова від харчування
- Відмова системи охолодження
- Зовнішні чинники (людина, природа та ін.)
Дублювання серверів Oracle має на увазі сам принцип роботи Oracle RAC і реалізується за допомогою програми. Дублювання засобів комутації теж не є проблемою. А ось із дублюванням системи зберігання все не так просто.
Найпростіший варіант – це реплікація даних із основної СГД на резервну. Синхронна чи асинхронна, залежно від можливостей СГД. При асинхронної реплікації відразу постає питання забезпечення консистентності даних стосовно Oracle. Але навіть якщо є програмна інтеграція з додатком, у будь-якому випадку, при аварії на основний СГД, потрібно втручання адміністраторів у ручному режимі для того, щоб переключити кластер на резервне сховище.
Більш складний варіант – це програмні та/або апаратні «віртуалізатори» СГД, які позбавлять проблем із консистентністю та ручного втручання. Але складність розгортання та подальшого адміністрування, а також дуже непристойна вартість таких рішень відлякує багатьох.
Якраз для таких сценаріїв, як Cross-Rack disaster recovery, відмінно підходить рішення All Flash масив AccelStor NeoSapphire™ із використанням архітектури Shared-Nothing. Дана модель є двонодовою системою зберігання, що використовує власну технологію FlexiRemap® для роботи з флеш накопичувачами. Завдяки NeoSapphire™ H710 здатна забезпечувати продуктивність до 600K IOPS@4K random write та 1M+ IOPS@4K random read, що недосяжно при використанні класичних RAID-based СГД.
Але головна особливість NeoSapphire™ H710 – виконання двох нод у вигляді окремих корпусів, кожна з яких має власну копію даних. Синхронізація нід здійснюється через зовнішній інтерфейс InfiniBand. Завдяки такій архітектурі можна рознести ноди з різних локацій на відстань до 100м, забезпечивши цим рішення Cross-Rack disaster recovery. Обидві ноди працюють повністю у синхронному режимі. З боку хостів H710 виглядає як звичайна двоконтрольна СГД. Тому ніяких додаткових програмних та апаратних опцій та особливо складних налаштувань виконувати не потрібно.
Якщо порівняти всі вищенаведені рішення Cross-Rack disaster recovery, то варіант від AccelStor помітно виділяється на тлі інших:
AccelStor NeoSapphire™ Shared Nothing Architecture
Програмний чи апаратний «віртуалізатор» СГД
Рішення на базі реплікації
Доступність
Відмова сервера
Без простоїв
Без простоїв
Без простоїв
Відмова комутатора
Без простоїв
Без простоїв
Без простоїв
Відмова системи зберігання
Без простоїв
Без простоїв
Час простою
Відмова всієї шафи
Без простоїв
Без простоїв
Час простою
Вартість та складність
Вартість рішення
Низька*
Висока
Висока
Складність розгортання
низька
Висока
Висока
*AccelStor NeoSapphire™ – це все ж таки All Flash масив, який за визначенням коштує не «3 копійки», тим більше маючи дворазовий запас по ємності. Однак, порівнюючи підсумкову вартість рішення на його базі з аналогічними від інших вендорів, вартість можна вважати низькою.
Топологія підключення серверів додатків і нод All Flash масиву виглядатиме так:
При плануванні топології також вкрай рекомендується зробити дублювання комутаторів управління та інтерконект серверів.
Тут і надалі йтиметься про підключення через Fibre Channel. У разі використання iSCSI буде все те ж саме, з поправкою на типи комутаторів, що використовуються, і трохи інші налаштування масиву.
Підготовча робота на масиві
Використовуване обладнання та програмне забезпечення
Специфікації серверів та комутаторів
Компоненти
Опис
Oracle Database 11g servers
Два
Server operating system
Oracle Linux
Oracle database version
11g (RAC)
Processors per server
Два 16 cores Intel Xeon CPU E5-2667 v2 @ 3.30GHz
Physical memory per server
128GB
FC network
16Gb/s FC with multipathing
FC HBA
Emulex Lpe-16002B
Dedicated public 1GbE ports for cluster management
Intel ethernet adapter RJ45
16Gb/s FC switch
Парча 6505
Dedicated private 10GbE ports for data synchonization
Intel X520
Специфікація AccelStor NeoSapphhire™ All Flash масиву
Компоненти
Опис
Система зберігання
NeoSapphire™ високої потужності: H710
Image version
4.0.1
Total number of drives
48
Розмір диска
1.92TB
Тип приводу
SSD
FC target ports
16х 16Gb ports (8 на ноду)
Порти управління
The 1GbE ethernet cable connecting to hosts via an ethernet switch
Порт серцебиття
The 1GbE ethernet cable connecting between two storage node
Data synchronization port
56Gb/s InfiniBand cable
Перед використанням масиву його необхідно ініціалізувати. За замовчуванням адреса управління обох нод однакова (192.168.1.1). Потрібно по черзі підключитися до них і задати нові (вже різні) адреси керування та налаштувати синхронізацію часу, після чого Management порти можна підключити до єдиної мережі. Після здійснення об'єднання нод в HA пару шляхом призначення підмереж для Interlink з'єднань.
Після завершення ініціалізації керувати масивом можна з будь-якої ноди.
Далі створюємо необхідні томи та публікуємо їх для серверів додатків.
Вкрай рекомендується створити кілька томів для Oracle ASM, оскільки це збільшить кількість target для серверів, що в результаті покращить загальну продуктивність (докладніше про черги в інший ).
Тестова конфігурація
Storage Volume Name
Розмір об'єму
Дані01
200GB
Дані02
200GB
Дані03
200GB
Дані04
200GB
Дані05
200GB
Дані06
200GB
Дані07
200GB
Дані08
200GB
Дані09
200GB
Дані10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Деякі пояснення щодо режимів роботи масиву та процесів, що відбуваються при позаштатних ситуаціях
Набір даних кожної ноди має параметр «номер версії». Після первинної ініціалізації він однаковий і дорівнює 1. Якщо з якихось причин номер версії різний, то відбувається синхронізація даних від старшої версії до молодшої, після чого в молодшої версії номер вирівнюється, тобто. це означає, що копії ідентичні. Причини, за якими версії можуть бути різні:
- Заплановане перезавантаження однієї з нід
- Аварія на одній з нід через раптове відключення (харчування, перегрів та ін.).
- Обрив InfiniBand з'єднання з неможливістю синхронізації
- Аварія на одній із нід через пошкодження даних. Тут вже знадобиться створення нової HA групи та повна синхронізація набору даних.
У будь-якому випадку нода, що залишається в онлайні, збільшує свій номер версії на одиницю, щоб після відновлення зв'язку з парою синхронізувати її набір даних.
Якщо відбувається обрив з'єднання по Ethernet лінку, Heartbeat тимчасово перемикається на InfiniBand і повертається назад протягом 10с при його відновленні.
Налаштування хостів
Для забезпечення відмовостійкості та збільшення продуктивності необхідно включити підтримку MPIO для масиву. Для цього потрібно додати файл /etc/multipath.conf рядки, після чого перезавантажити сервіс multipath
Прихований текстпристрої {
пристрій {
vendor «AStor»
path_grouping_policy "group_by_prio"
path_selector «queue-length 0»
path_checker «tur»
features «0»
hardware_handler «0»
prio «const»
failback immediate
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names так
detect_prio yes
rr_min_io_rq 1
no_path_retry 0
}
}
Далі, щоб ASM працював з MPIO через ASMLib, необхідно змінити файл /etc/sysconfig/oracleasm і потім виконати /etc/init.d/oracleasm scandisks
Прихований текст
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER=«dm»
# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE="sd"
Примітка
Якщо немає бажання використовувати ASMLib, можна використовувати правила UDEV, які є основою ASMLib.
Починаючи з версії 12.1.0.2, Oracle Database опція доступна для установки як частина ASMFD.
Обов'язково слід переконатися, щоб диски для Oracle ASM, що створювалися, були вирівняними по відношенню до розміру блоку, з яким фізично працює масив (4K). Інакше можливі проблеми із продуктивністю. Тому необхідно створювати томи з відповідними параметрами:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Розподіл баз даних за створеними томами для нашої тестової конфігурації
Storage Volume Name
Розмір об'єму
Volume LUNs mapping
ASM Volume Device Detail
Розмір одиниці розподілу
Дані01
200GB
Map all storage volumes to storage system all data ports
Redundancy: Normal
Name:DGDATA
Purpose:Data files
4MB
Дані02
200GB
Дані03
200GB
Дані04
200GB
Дані05
200GB
Дані06
200GB
Дані07
200GB
Дані08
200GB
Дані09
200GB
Дані10
200GB
Grid01
1GB
Redundancy: Normal
Name: DGGRID1
Purpose:Grid: CRS and Voting
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundancy: Normal
Name: DGGRID2
Purpose:Grid: CRS and Voting
4MB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Redundancy: Normal
Name: DGREDO1
Purpose: Redo log of thread 1
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redundancy: Normal
Name: DGREDO2
Purpose: Redo log of thread 2
4MB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Налаштування бази даних
- Block size = 8K
- Swap space = 16GB
- Disable AMM (Automatic Memory Management)
- Disable Transparent Huge Pages
Інші налаштування
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ kernel.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓ vm.swappiness=10
✓ vm.min_free_kbytes=524288 # Ви не можете використовувати цей Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ grid hard nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ grid soft stack 10240
✓ grid hard stack 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ oracle hard nofile 65536
✓ oracle soft stack 10240
✓ oracle hard stack 32768
✓ soft memlock 120795954
✓ hard memlock 120795954
sqlplus “/as sysdba”
alter system set processes=2000 scope=spfile;
alter system set open_cursors=2000 scope=spfile;
alter system set session_cached_cursors=300 scope=spfile;
alter system set db_files=8192 scope=spfile;
Тест на відмовостійкість
Для демонстрації використовувався HammerDB для емуляції OLTP навантаження. Конфігурація HammerDB:
Кількість складів
256
Total Transactions per User
1000000000000
Virtual Users
256
В результаті було отримано показник 2.1M TPM, що далеко від межі продуктивності масиву , але є «стелі» для поточної апаратної конфігурації серверів (насамперед через процесори) та їх кількості. Метою даного тесту все ж таки є демонстрація відмовостійкості рішення в цілому, а не досягнення максимумів продуктивності. Тому просто відштовхуватимемося від цієї цифри.
Тест на відмову однієї з нід
Хости втратили частину шляхів до сховища, продовживши працювати через ті, що залишилися з другою нодою. Продуктивність просіла на кілька секунд через перебудову колій, а потім повернулася до нормальних показників. Перерви в обслуговуванні не сталося.
Тест на відмову шафи з усім обладнанням
У цьому випадку продуктивність також просіла на кілька секунд через перебудову шляхів, а потім повернулася до половини від початкового показника. Результат знизився вдвічі від початкового через виключення з одного сервера додатків. Перерви в обслуговуванні також не сталося.
Якщо є потреби в реалізації відмови від стійкості рішення Cross-Rack disaster recovery для Oracle за розумну вартість і з невеликими зусиллями з розгортання/адміністрування, то спільна робота Oracle RAC та архітектури буде одним із найкращих варіантів. Замість Oracle RAC може бути будь-яке інше програмне забезпечення, яке передбачає кластеризацію, ті ж СУБД або системи віртуалізації, наприклад. Принцип побудови рішення залишиться тим самим. І підсумковий показник – це нульове значення для RTO та RPO.
Джерело: habr.com