Oracle RAC-ի և AccelStor Shared-Nothing ճարտարապետության վրա հիմնված անսարքությունների հանդուրժող լուծումների ստեղծում

Ձեռնարկությունների զգալի թվով հավելվածներ և վիրտուալացման համակարգեր ունեն իրենց մեխանիզմները՝ անսարքության հանդուրժող լուծումներ ստեղծելու համար: Մասնավորապես, Oracle RAC-ը (Oracle Real Application Cluster) երկու կամ ավելի Oracle տվյալների բազայի սերվերների կլաստեր է, որոնք միասին աշխատում են բեռը հավասարակշռելու և սերվերի/հավելվածի մակարդակում սխալների հանդուրժողականություն ապահովելու համար: Այս ռեժիմում աշխատելու համար ձեզ անհրաժեշտ է ընդհանուր պահեստ, որը սովորաբար պահեստավորման համակարգ է:

Ինչպես մենք արդեն քննարկել ենք մեր մեկում Հոդվածներ, պահեստավորման համակարգը ինքնին, չնայած կրկնօրինակ բաղադրիչների առկայությանը (ներառյալ կարգավորիչները), դեռևս խափանման կետեր ունի՝ հիմնականում տվյալների մեկ հավաքածուի տեսքով: Հետևաբար, հուսալիության բարձր պահանջներով Oracle լուծում ստեղծելու համար «N սերվերներ՝ մեկ պահեստավորման համակարգ» սխեման պետք է բարդացվի:

Նախ, իհարկե, պետք է որոշել, թե ինչ ռիսկերից ենք փորձում ապահովագրվել։ Այս հոդվածում մենք չենք քննարկի պաշտպանությունը այնպիսի սպառնալիքներից, ինչպիսին է «երկնաքարը եկել է»։ Այսպիսով, աղետների վերականգնման աշխարհագրորեն ցրված լուծում ստեղծելը կմնա հաջորդ հոդվածներից մեկի թեման: Այստեղ մենք կանդրադառնանք այսպես կոչված Cross-Rack աղետի վերականգնման լուծմանը, երբ պաշտպանությունը կառուցված է սերվերի կաբինետների մակարդակով: Պահարաններն իրենք կարող են տեղակայվել նույն սենյակում կամ տարբեր սենյակներում, բայց սովորաբար նույն շենքում:

Այս կաբինետները պետք է պարունակեն սարքավորումների և ծրագրային ապահովման ողջ անհրաժեշտ փաթեթը, որը թույլ կտա Oracle-ի տվյալների շտեմարանների աշխատանքը՝ անկախ «հարևանի» վիճակից: Այլ կերպ ասած, օգտագործելով Cross-Rack աղետի վերականգնման լուծումը, մենք վերացնում ենք ձախողման ռիսկերը.

• Oracle հավելվածի սերվերներ
• Պահպանման համակարգեր
• Անջատիչ համակարգեր
• Կաբինետի բոլոր սարքավորումների ամբողջական ձախողում.
  • Իշխանության մերժում
  • Սառեցման համակարգի ձախողում
  • Արտաքին գործոններ (մարդ, բնություն և այլն)

Oracle սերվերների կրկնօրինակումը ենթադրում է Oracle RAC-ի գործող սկզբունքը և իրականացվում է հավելվածի միջոցով: Անջատիչ սարքերի կրկնօրինակումը նույնպես խնդիր չէ: Բայց պահեստավորման համակարգի կրկնօրինակմամբ ամեն ինչ այնքան էլ պարզ չէ:

Ամենապարզ տարբերակը տվյալների կրկնօրինակումն է հիմնական պահեստային համակարգից մինչև պահեստային: Սինքրոն կամ ասինխրոն՝ կախված պահեստավորման համակարգի հնարավորություններից։ Ասինխրոն կրկնօրինակման դեպքում անմիջապես հարց է առաջանում Oracle-ի հետ կապված տվյալների հետևողականության ապահովման մասին: Բայց նույնիսկ եթե կա հավելվածի հետ ծրագրային ապահովման ինտեգրում, ամեն դեպքում, հիմնական պահեստավորման համակարգի ձախողման դեպքում կպահանջվի ադմինիստրատորների ձեռքով միջամտություն՝ կլաստերը պահուստային պահեստի անցնելու համար:

Ավելի բարդ տարբերակ է ծրագրային ապահովման և/կամ ապարատային պահպանման «վիրտուալիզատորները», որոնք կվերացնեն հետևողականության խնդիրները և ձեռքով միջամտությունը: Սակայն տեղակայման և հետագա կառավարման բարդությունը, ինչպես նաև նման լուծումների շատ անպարկեշտ արժեքը վախեցնում է շատերին:

AccelStor NeoSapphire™ All Flash զանգվածի լուծումը կատարյալ է այնպիսի սցենարների համար, ինչպիսիք են Cross-Rack աղետի վերականգնումը H710 օգտագործելով Shared-Nothing ճարտարապետությունը: Այս մոդելը երկու հանգույցից բաղկացած պահեստավորման համակարգ է, որն օգտագործում է սեփականատիրական FlexiRemap® տեխնոլոգիա՝ ֆլեշ կրիչների հետ աշխատելու համար: Շնորհիվ FlexiRemap® NeoSapphire™ H710-ն ի վիճակի է մատուցել մինչև 600K IOPS@4K պատահական գրություն և 1M+ IOPS@4K պատահական ընթերցում, ինչը անհասանելի է դասական RAID-ի վրա հիմնված պահեստավորման համակարգերի օգտագործման ժամանակ:

Բայց NeoSapphire™ H710-ի հիմնական առանձնահատկությունը երկու հանգույցների կատարումն է առանձին դեպքերի տեսքով, որոնցից յուրաքանչյուրն ունի տվյալների իր պատճենը: Հանգույցների համաժամացումն իրականացվում է արտաքին InfiniBand ինտերֆեյսի միջոցով: Այս ճարտարապետության շնորհիվ հնարավոր է հանգույցներ բաշխել տարբեր վայրերում մինչև 100 մ հեռավորության վրա՝ դրանով իսկ ապահովելով Cross-Rack աղետի վերականգնման լուծում: Երկու հանգույցներն էլ գործում են ամբողջովին համաժամանակյա: Հյուրընկալող կողմից H710-ը կարծես սովորական կրկնակի վերահսկիչ պահեստավորման համակարգ լինի: Հետևաբար, կարիք չկա որևէ լրացուցիչ ծրագրային կամ ապարատային ընտրանք կամ առանձնապես բարդ կարգավորումներ կատարելու:

Եթե ​​համեմատենք վերը նկարագրված բոլոր Cross-Rack աղետի վերականգնման լուծումները, ապա AccelStor-ի տարբերակը նկատելիորեն առանձնանում է մնացածից.

AccelStor NeoSapphire™ Shared Nothing Architecture
Ծրագրային ապահովման կամ ապարատային «վիրտուալիզատոր» պահեստավորման համակարգ
Վերարտադրության վրա հիմնված լուծում

Հասանելիություն

Սերվերի ձախողում
Անգործության ժամանակ չկա
Անգործության ժամանակ չկա
Անգործության ժամանակ չկա

Անջատիչի ձախողում
Անգործության ժամանակ չկա
Անգործության ժամանակ չկա
Անգործության ժամանակ չկա

Պահպանման համակարգի ձախողում
Անգործության ժամանակ չկա
Անգործության ժամանակ չկա
Փոստ

Կաբինետի ամբողջական ձախողում
Անգործության ժամանակ չկա
Անգործության ժամանակ չկա
Փոստ

Արժեքը և բարդությունը

Լուծման արժեքը
Ցածր*
Բարձր
Բարձր

Տեղակայման բարդությունը
Ցածր
Բարձր
Բարձր

*AccelStor NeoSapphire™-ը դեռևս All Flash զանգված է, որն ըստ սահմանման չի արժե «3 կոպեկ», մանավանդ որ այն ունի կրկնակի հզորության պահուստ: Այնուամենայնիվ, դրա վրա հիմնված լուծման վերջնական արժեքը համեմատելիս այլ վաճառողների նմանների հետ, արժեքը կարելի է ցածր համարել:

Հավելվածի սերվերների և Բոլոր Flash զանգվածի հանգույցների միացման տոպոլոգիան այսպիսի տեսք կունենա.

Տոպոլոգիան պլանավորելիս խորհուրդ է տրվում նաև կրկնօրինակել կառավարման անջատիչները և սերվերները փոխկապակցել:

Այստեղ և հետագայում մենք կխոսենք Fiber Channel-ի միջոցով միանալու մասին: Եթե ​​դուք օգտագործում եք iSCSI, ամեն ինչ կլինի նույնը, հարմարեցված է օգտագործվող անջատիչների տեսակների և զանգվածի մի փոքր տարբեր պարամետրերի համար:

Նախապատրաստական ​​աշխատանք զանգվածի վրա

Օգտագործված սարքավորումներ և ծրագրեր

Սերվերի և անջատիչի բնութագրերը

Բաղադրիչներ
Նկարագրություն

Oracle Database 11g սերվերներ
Երկու

Սերվերի օպերացիոն համակարգ
Oracle Linux- ը

Oracle տվյալների բազայի տարբերակը
11 գ (RAC)

Պրոցեսորներ մեկ սերվերի համար
Երկու 16 միջուկ Intel® Xeon® CPU E5-2667 v2 @ 3.30 ԳՀց

Ֆիզիկական հիշողություն մեկ սերվերի համար
128GB

FC ցանց
16 Գբ/վ FC բազմուղիով

FC HBA
Emulex Lpe-16002B

Նվիրված հանրային 1GbE պորտեր՝ կլաստերների կառավարման համար
Intel Ethernet ադապտեր RJ45

16 Գբ/վ FC անջատիչ
Բրոկադ 6505

Հատուկ 10 ԳբԷ պորտեր տվյալների համաժամացման համար
Intel X520- ը

AccelStor NeoSapphire™ Ամբողջ Flash Array սպեցիֆիկացիա

Բաղադրիչներ
Նկարագրություն

Պահեստավորման համակարգ
NeoSapphire™ բարձր հասանելիության մոդել՝ H710

Պատկերի տարբերակ
4.0.1

Սկավառակների ընդհանուր քանակը
48

Սկավառակի չափը
1.92TB

Ուղեւորության տեսակը
SSD

FC թիրախային նավահանգիստներ
16 x 16 Գբ պորտ (8 մեկ հանգույցի համար)

Կառավարման նավահանգիստներ
1GbE Ethernet մալուխը, որը միանում է հոսթներին Ethernet անջատիչի միջոցով

Սրտի բաբախման նավահանգիստ
1GbE Ethernet մալուխը միանում է երկու պահեստային հանգույցների միջև

Տվյալների համաժամացման նավահանգիստ
56 Գբ/վ InfiniBand մալուխ

Նախքան զանգված օգտագործելը, դուք պետք է սկզբնավորեք այն: Լռելյայնորեն, երկու հանգույցների կառավարման հասցեն նույնն է (192.168.1.1): Դուք պետք է հերթով միանաք նրանց և սահմանեք կառավարման նոր (արդեն տարբեր) հասցեներ և կարգավորեք ժամանակի համաժամացումը, որից հետո կառավարման պորտերը կարող են միանալ մեկ ցանցին: Այնուհետև հանգույցները միավորվում են HA զույգի մեջ՝ նշանակելով ենթացանցեր Interlink կապերի համար:

Նախաստորագրման ավարտից հետո դուք կարող եք կառավարել զանգվածը ցանկացած հանգույցից:

Հաջորդը, մենք ստեղծում ենք անհրաժեշտ հատորները և դրանք հրապարակում հավելվածի սերվերներում:

Խստորեն խորհուրդ է տրվում Oracle ASM-ի համար մի քանի հատորներ ստեղծել, քանի որ դա կավելացնի սերվերների թիրախների թիվը, ինչը, ի վերջո, կբարելավի ընդհանուր կատարումը (ավելին` հերթերի մասին մեկ այլ տարբերակում): Հոդված).

Փորձարկման կոնֆիգուրացիա

Պահպանման ծավալի անվանումը
Volume չափը

Տվյալներ 01
200GB

Տվյալներ 02
200GB

Տվյալներ 03
200GB

Տվյալներ 04
200GB

Տվյալներ 05
200GB

Տվյալներ 06
200GB

Տվյալներ 07
200GB

Տվյալներ 08
200GB

Տվյալներ 09
200GB

Տվյալներ 10
200GB

Ցանց 01
1GB

Ցանց 02
1GB

Ցանց 03
1GB

Ցանց 04
1GB

Ցանց 05
1GB

Ցանց 06
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 ֆայլին, այնուհետև վերագործարկել բազմուղի ծառայությունը:

Թաքնված տեքստսարքեր {
սարք {
վաճառող «AStor»
path_grouping_policy «group_by_prio»
path_selector «հերթի երկարությունը 0»
path_checker «tur»
հատկանիշներ «0»
hardware_handler «0»
պրիո «կոնստ»
անհապաղ ձախողում
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names այո
detect_prio այո
rr_min_io_rq 1
no_path_retry 0
}
}

Հաջորդը, որպեսզի ASM-ն աշխատի MPIO-ի հետ ASMLib-ի միջոցով, դուք պետք է փոխեք /etc/sysconfig/oracleasm ֆայլը և գործարկեք /etc/init.d/oracleasm scandisks-ը:

Թաքնված տեքստ

# ORACLEASM_SCANORDER. Համապատասխան նախշեր՝ սկավառակի սկանավորում պատվիրելու համար
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE. Համապատասխան նախշեր՝ սկավառակները սկանավորումից բացառելու համար
ORACLEASM_SCANEXCLUDE="sd"

Նշում

Եթե ​​դուք չեք ցանկանում օգտագործել ASMLib, կարող եք օգտագործել UDEV կանոնները, որոնք հիմք են հանդիսանում ASMLib-ի համար:

Սկսած Oracle Database-ի 12.1.0.2 տարբերակից, տարբերակը հասանելի է տեղադրման համար որպես ASMFD ծրագրաշարի մաս:

Հրամայական է ապահովել, որ Oracle ASM-ի համար ստեղծված սկավառակները համընկնում են բլոկի չափի հետ, որով զանգվածը ֆիզիկապես աշխատում է (4K): Հակառակ դեպքում կարող են առաջանալ աշխատանքի հետ կապված խնդիրներ: Ուստի անհրաժեշտ է համապատասխան պարամետրերով ծավալներ ստեղծել.

բաժանված /dev/mapper/device-name mklabel gpt mkpart առաջնային 2048s 100% հավասարեցում-ստուգում օպտիմալ 1

Տվյալների բազաների բաշխում ստեղծված ծավալների վրա մեր թեստային կազմաձևման համար

Պահպանման ծավալի անվանումը
Volume չափը
Ծավալի LUN-ների քարտեզագրում
ASM Volume Device Detail
Հատկացման միավորի չափը

Տվյալներ 01
200GB
Քարտեզագրեք պահեստավորման բոլոր ծավալները պահեստավորման համակարգի բոլոր տվյալների նավահանգիստներին
Ավելորդություն: Նորմալ
Անունը՝ DGDATA
Նպատակը: Տվյալների ֆայլեր

4MB

Տվյալներ 02
200GB

Տվյալներ 03
200GB

Տվյալներ 04
200GB

Տվյալներ 05
200GB

Տվյալներ 06
200GB

Տվյալներ 07
200GB

Տվյալներ 08
200GB

Տվյալներ 09
200GB

Տվյալներ 10
200GB

Ցանց 01
1GB
Ավելորդություն: Նորմալ
Անունը՝ DGGRID1
Նպատակը. Ցանց՝ CRS և քվեարկություն

4MB

Ցանց 02
1GB

Ցանց 03
1GB

Ցանց 04
1GB
Ավելորդություն: Նորմալ
Անունը՝ DGGRID2
Նպատակը. Ցանց՝ CRS և քվեարկություն

4MB

Ցանց 05
1GB

Ցանց 06
1GB

Redo01
100GB
Ավելորդություն: Նորմալ
Անունը՝ DGREDO1
Նպատակը. Կրկնել թելի մատյանը 1

4MB

Redo02
100GB

Redo03
100GB

Redo04
100GB

Redo05
100GB

Redo06
100GB
Ավելորդություն: Նորմալ
Անունը՝ DGREDO2
Նպատակը. Կրկնել թելի մատյանը 2

4MB

Redo07
100GB

Redo08
100GB

Redo09
100GB

Redo10
100GB

Տվյալների բազայի կարգավորումներ

• Բլոկի չափը = 8K
• Փոխանակման տարածք = 16 ԳԲ
• Անջատել AMM (Հիշողության ավտոմատ կառավարում)
• Անջատել թափանցիկ հսկայական էջերը

Այլ կարգավորումներ

# 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
✓ ցանցի կոշտ կույտ 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
✓ փափուկ memlock 120795954
✓ կոշտ memlock 120795954

sqlplus «/as sysdba»
փոխել համակարգի հավաքածուի գործընթացները=2000 շրջանակ=spfile;
փոխել համակարգի հավաքածուն open_cursors=2000 scope=spfile;
փոխել համակարգի հավաքածուն session_cached_cursors=300 scope=spfile;
փոխել համակարգի հավաքածուն db_files=8192 scope=spfile;

Անհաջողության թեստ

Ցուցադրական նպատակների համար HammerDB-ն օգտագործվել է OLTP բեռը ընդօրինակելու համար: HammerDB կոնֆիգուրացիա.

Պահեստների քանակը
256

Ընդհանուր գործարքներ մեկ օգտատիրոջ համար
1000000000000

Վիրտուալ օգտվողներ
256

Արդյունքը եղավ 2.1M TPM, որը հեռու է զանգվածի կատարողականի սահմանաչափից H710, բայց հանդիսանում է «առաստաղ» սերվերների ընթացիկ ապարատային կազմաձևման համար (հիմնականում պրոցեսորների շնորհիվ) և դրանց քանակի համար։ Այս թեստի նպատակն է դեռ ցույց տալ լուծույթի սխալ հանդուրժողականությունը որպես ամբողջություն, և ոչ թե հասնել առավելագույն արդյունավետության: Հետեւաբար, մենք պարզապես կկառուցենք այս ցուցանիշը:

Հանգույցներից մեկի ձախողման փորձարկում

Տանտերերը կորցրել են դեպի պահեստ տանող ուղիների մի մասը՝ շարունակելով աշխատել մնացածների միջով երկրորդ հանգույցով։ Կատարումը մի քանի վայրկյանով ընկել է արահետների վերակառուցման պատճառով, այնուհետև վերադարձել է նորմալ: Ծառայության ընդհատում չի եղել.

Կաբինետի ձախողման փորձարկում բոլոր սարքավորումներով

Այս դեպքում կատարողականությունը նույնպես մի քանի վայրկյանով ընկել է ուղիների վերակառուցման պատճառով, այնուհետև վերադարձել սկզբնական արժեքի կեսին: Արդյունքը կրկնակի կրճատվել է սկզբնականից՝ մեկ հավելվածի սերվերի գործարկումից բացառելու պատճառով։ Սպասարկման ընդհատում նույնպես չի եղել։

Եթե ​​կարիք կա Oracle-ի համար ողջամիտ գնով և փոքր տեղակայման/վարչարարության ջանքերով ներդնելու անսարքությունների հանդուրժող Cross-Rack աղետների վերականգնման լուծում, ապա Oracle RAC-ը և ճարտարապետությունը միասին են աշխատում: AccelStor Համօգտագործված-Ոչինչ կլինի լավագույն տարբերակներից մեկը: Oracle RAC-ի փոխարեն կարող է լինել ցանկացած այլ ծրագրակազմ, որն ապահովում է կլաստերավորում, օրինակ՝ նույն DBMS կամ վիրտուալացման համակարգեր: Լուծման կառուցման սկզբունքը կմնա նույնը. Իսկ RTO-ի և RPO-ի համար վերջնագիծը զրո է:

Source: www.habr.com