Немалы лік Enterprise прыкладанняў і сістэм віртуалізацыі маюць уласныя механізмы для пабудовы абароненай ад збояў рашэнняў. У прыватнасці, Oracle RAC (Oracle Real Application Cluster) уяўляе сабой кластар з двух або больш сервераў баз дадзеных Oracle, якія працуюць сумесна з мэтай балансавання нагрузкі і забеспячэнні адмоваўстойлівасці на ўзроўні сервера/прыкладанні. Для працы ў такім рэжыме неабходна агульнае сховішча, у ролі якога звычайна выступае СГД.
Як мы ўжо разглядалі ў адной са сваіх , сама па сабе СХД, нягледзячы на наяўнасць дубляваных кампанент (у тым ліку і кантролераў), усё ж мае кропкі адмовы – галоўным чынам, у выглядзе адзінага набору дадзеных. Таму, для пабудовы рашэння 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 на ноду)
Парты кіравання
1GbE ethernet cable connecting to hosts via ethernet switch
Heartbeat port
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 групы і поўная сінхранізацыя набору дадзеных.
У любым выпадку нода, якая застаецца ў online, павялічвае свой нумар версіі на адзінку, каб пасля ўзнаўлення сувязі з парай сінхранізаваць яе набор дадзеных.
Калі адбываецца абрыў злучэння па Ethernet лінку, то Heartbeat часова перамыкаецца на InfiniBand і вяртаецца зваротна на працягу 10С пры яго аднаўленні.
Настройка хастоў
Для забеспячэння адмоваўстойлівасці і павелічэння прадукцыйнасці неабходна ўключыць падтрымку MPIO для масіва. Для гэтага трэба дадаць у файл /etc/multipath.conf радкі, пасля чаго перазагрузіць сэрвіс multipath
Утоены тэкстdevices {
device {
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 yes
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 order disk scanning
ORACLEASM_SCANORDER=«dm»
# ORACLEASM_SCANEXCLUDE: Matching patterns 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% аlign-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
✓ 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