Ang isang malaking bilang ng mga Enterprise application at virtualization system ay may sariling mga mekanismo para sa pagbuo ng fault-tolerant na solusyon. Sa partikular, ang Oracle RAC (Oracle Real Application Cluster) ay isang kumpol ng dalawa o higit pang Oracle database server na nagtutulungan upang balansehin ang pagkarga at magbigay ng fault tolerance sa antas ng server/application. Upang gumana sa mode na ito, kailangan mo ng nakabahaging storage, na karaniwang isang storage system.
Gaya ng napag-usapan na natin sa isa sa atin , ang sistema ng imbakan mismo, sa kabila ng pagkakaroon ng mga dobleng bahagi (kabilang ang mga controller), mayroon pa ring mga punto ng pagkabigo - pangunahin sa anyo ng isang solong hanay ng data. Samakatuwid, upang makabuo ng isang solusyon sa Oracle na may mas mataas na mga kinakailangan sa pagiging maaasahan, ang scheme ng "N server - isang sistema ng imbakan" ay kailangang kumplikado.
Una, siyempre, kailangan nating magpasya kung anong mga panganib ang sinusubukan nating i-insure laban. Sa artikulong ito, hindi natin isasaalang-alang ang proteksyon laban sa mga banta gaya ng “may dumating na meteorite.” Kaya't ang pagbuo ng isang geographically dispersed disaster recovery solution ay mananatiling paksa para sa isa sa mga sumusunod na artikulo. Dito ay titingnan natin ang tinatawag na Cross-Rack disaster recovery solution, kapag ang proteksyon ay binuo sa antas ng mga cabinet ng server. Ang mga cabinet mismo ay maaaring matatagpuan sa parehong silid o sa iba't ibang mga, ngunit kadalasan sa loob ng parehong gusali.
Ang mga cabinet na ito ay dapat maglaman ng buong kinakailangang hanay ng kagamitan at software na magpapahintulot sa pagpapatakbo ng mga database ng Oracle anuman ang estado ng "kapitbahay". Sa madaling salita, gamit ang Cross-Rack disaster recovery solution, inaalis namin ang mga panganib ng pagkabigo:
- Mga Server ng Oracle Application
- Mga sistema ng imbakan
- Mga switching system
- Kumpletong kabiguan ng lahat ng kagamitan sa cabinet:
- Pagtanggi sa kapangyarihan
- Pagkabigo ng sistema ng paglamig
- Mga panlabas na kadahilanan (tao, kalikasan, atbp.)
Ang pagdoble ng mga server ng Oracle ay nagpapahiwatig ng mismong prinsipyo ng pagpapatakbo ng Oracle RAC at ipinapatupad sa pamamagitan ng isang application. Hindi rin problema ang pagdoble ng mga switching facility. Ngunit sa pagdoble ng sistema ng imbakan, ang lahat ay hindi gaanong simple.
Ang pinakasimpleng opsyon ay ang pagtitiklop ng data mula sa pangunahing sistema ng imbakan hanggang sa backup. Synchronous o asynchronous, depende sa mga kakayahan ng storage system. Sa asynchronous na pagtitiklop, ang tanong ay agad na bumangon sa pagtiyak ng pagkakapare-pareho ng data na may kaugnayan sa Oracle. Ngunit kahit na mayroong pagsasama ng software sa application, sa anumang kaso, sa kaganapan ng isang pagkabigo sa pangunahing sistema ng imbakan, ang manu-manong interbensyon ng mga administrator ay kinakailangan upang mailipat ang kumpol sa backup na imbakan.
Ang isang mas kumplikadong opsyon ay ang software at/o hardware storage na "mga virtualizer" na mag-aalis ng mga problema sa pare-pareho at manu-manong interbensyon. Ngunit ang pagiging kumplikado ng deployment at kasunod na pangangasiwa, pati na rin ang napakababastos na halaga ng naturang mga solusyon, ay nakakatakot sa marami.
Ang AccelStor NeoSapphire™ All Flash array solution ay perpekto para sa mga sitwasyon tulad ng Cross-Rack disaster recovery gamit ang Shared-Nothing architecture. Ang modelong ito ay isang two-node storage system na gumagamit ng proprietary FlexiRemap® na teknolohiya upang gumana sa mga flash drive. Salamat kay Ang NeoSapphire™ H710 ay may kakayahang maghatid ng performance hanggang sa 600K IOPS@4K na random na pagsulat at 1M+ IOPS@4K na random na pagbabasa, na hindi matamo kapag gumagamit ng mga klasikong RAID-based na storage system.
Ngunit ang pangunahing tampok ng NeoSapphire™ H710 ay ang pagpapatupad ng dalawang node sa anyo ng magkahiwalay na mga kaso, bawat isa ay may sariling kopya ng data. Ang pag-synchronize ng mga node ay isinasagawa sa pamamagitan ng panlabas na interface ng InfiniBand. Salamat sa arkitektura na ito, posibleng ipamahagi ang mga node sa iba't ibang lokasyon sa layo na hanggang 100m, sa gayon ay nagbibigay ng Cross-Rack disaster recovery solution. Ang parehong mga node ay ganap na gumagana nang sabay-sabay. Mula sa panig ng host, ang H710 ay mukhang isang ordinaryong dual-controller storage system. Samakatuwid, hindi na kailangang magsagawa ng anumang karagdagang mga opsyon sa software o hardware o partikular na kumplikadong mga setting.
Kung ihahambing natin ang lahat ng Cross-Rack na solusyon sa pagbawi ng kalamidad na inilarawan sa itaas, kung gayon ang opsyon mula sa AccelStor ay kapansin-pansin mula sa iba:
Walang Ibinahagi na Arkitektura ang AccelStor NeoSapphire™
Sistema ng imbakan ng software o hardware na "virtualizer".
Replikasyon batay sa solusyon
Kakayahang magamit
Nabigo ang server
Walang Downtime
Walang Downtime
Walang Downtime
Pagkabigo ng switch
Walang Downtime
Walang Downtime
Walang Downtime
Pagkabigo ng sistema ng imbakan
Walang Downtime
Walang Downtime
Paghinto
Buong cabinet failure
Walang Downtime
Walang Downtime
Paghinto
Gastos at pagiging kumplikado
Gastos ng solusyon
mababa*
Mataas
Mataas
Pagiging kumplikado ng deployment
Mababang
Mataas
Mataas
*Ang AccelStor NeoSapphire™ ay isang All Flash array pa rin, na ayon sa kahulugan ay hindi nagkakahalaga ng “3 kopecks,” lalo na dahil mayroon itong double capacity na reserba. Gayunpaman, kapag inihambing ang panghuling halaga ng isang solusyon batay dito sa mga katulad na mula sa iba pang mga vendor, ang gastos ay maaaring ituring na mababa.
Ang topology para sa pagkonekta ng mga server ng application at Lahat ng Flash array node ay magiging ganito:
Kapag nagpaplano ng topology, lubos ding inirerekomenda na i-duplicate ang mga switch ng pamamahala at mga interconnect na server.
Dito at higit pa ay pag-uusapan natin ang tungkol sa pagkonekta sa pamamagitan ng Fiber Channel. Kung gagamit ka ng iSCSI, magiging pareho ang lahat, isasaayos para sa mga uri ng switch na ginamit at bahagyang magkakaibang mga setting ng array.
Paghahanda sa hanay
Kagamitan at software na ginamit
Mga Detalye ng Server at Switch
Piraso
Описание
Oracle Database 11g server
Dalawa
Operating system ng server
Oracle Linux
Bersyon ng database ng Oracle
11g (RAC)
Mga processor bawat server
Dalawang 16 core Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
Pisikal na memorya bawat server
128GB
FC network
16Gb/s FC na may multipathing
FC HBA
Emulex Lpe-16002B
Nakatuon sa pampublikong 1GbE port para sa pamamahala ng kumpol
Intel ethernet adapter RJ45
16Gb/s FC switch
Brocade 6505
Nakalaang pribadong 10GbE port para sa pag-synchonize ng data
Intel X520
AccelStor NeoSapphire™ Lahat ng Detalye ng Flash Array
Piraso
Описание
Sistema ng imbakan
NeoSapphire™ high availability model: H710
Bersyon ng larawan
4.0.1
Kabuuang bilang ng mga drive
48
Laki ng drive
1.92TB
Uri ng drive
SSD
Mga target na port ng FC
16x 16Gb port (8 bawat node)
Mga port ng pamamahala
Ang 1GbE ethernet cable na kumukonekta sa mga host sa pamamagitan ng ethernet switch
Port ng tibok ng puso
Ang 1GbE ethernet cable na kumukonekta sa pagitan ng dalawang storage node
Port ng pag-synchronize ng data
56Gb/s InfiniBand cable
Bago ka makagamit ng array, dapat mo itong simulan. Bilang default, ang control address ng parehong mga node ay pareho (192.168.1.1). Kailangan mong kumonekta sa kanila nang paisa-isa at magtakda ng mga bagong (naiiba na) mga address ng pamamahala at mag-set up ng pag-synchronize ng oras, pagkatapos nito ay maaaring ikonekta ang mga port ng Pamamahala sa isang network. Pagkatapos, ang mga node ay pinagsama sa isang pares ng HA sa pamamagitan ng pagtatalaga ng mga subnet para sa mga koneksyon sa Interlink.
Pagkatapos makumpleto ang pagsisimula, maaari mong pamahalaan ang array mula sa anumang node.
Susunod, gumawa kami ng mga kinakailangang volume at i-publish ang mga ito sa mga server ng application.
Lubos na inirerekomenda na lumikha ng maraming volume para sa Oracle ASM dahil madadagdagan nito ang bilang ng mga target para sa mga server, na sa huli ay mapapabuti ang pangkalahatang pagganap (higit pa sa mga pila sa iba ).
Pagsubok ng configuration
Pangalan ng Dami ng Imbakan
Laki ng Dami
Data01
200GB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Gawin muli01
100GB
Gawin muli02
100GB
Gawin muli03
100GB
Gawin muli04
100GB
Gawin muli05
100GB
Gawin muli06
100GB
Gawin muli07
100GB
Gawin muli08
100GB
Gawin muli09
100GB
Gawin muli10
100GB
Ilang paliwanag tungkol sa mga operating mode ng array at ang mga prosesong nagaganap sa mga emergency na sitwasyon
Ang set ng data ng bawat node ay may parameter na "numero ng bersyon". Pagkatapos ng paunang pagsisimula, ito ay pareho at katumbas ng 1. Kung sa ilang kadahilanan ay iba ang numero ng bersyon, kung gayon ang data ay palaging naka-synchronize mula sa mas lumang bersyon hanggang sa mas bata, pagkatapos kung saan ang bilang ng mas batang bersyon ay nakahanay, i.e. nangangahulugan ito na ang mga kopya ay magkapareho. Mga dahilan kung bakit maaaring magkaiba ang mga bersyon:
- Naka-iskedyul na pag-reboot ng isa sa mga node
- Isang aksidente sa isa sa mga node dahil sa biglaang pagsara (supply ng kuryente, sobrang init, atbp.).
- Nawala ang koneksyon ng InfiniBand na may kawalan ng kakayahang mag-synchronize
- Isang pag-crash sa isa sa mga node dahil sa data corruption. Dito kakailanganin mong lumikha ng bagong pangkat ng HA at kumpletuhin ang pag-synchronize ng set ng data.
Sa anumang kaso, ang node na nananatiling online ay tataas ang numero ng bersyon nito ng isa upang ma-synchronize ang set ng data nito pagkatapos maibalik ang koneksyon sa pares.
Kung nawala ang koneksyon sa Ethernet link, pansamantalang lilipat ang Heartbeat sa InfiniBand at babalik ito sa loob ng 10 segundo kapag naibalik ito.
Pagse-set up ng mga host
Para matiyak ang fault tolerance at pagbutihin ang performance, dapat mong paganahin ang suporta ng MPIO para sa array. Upang gawin ito, kailangan mong magdagdag ng mga linya sa /etc/multipath.conf file, at pagkatapos ay i-restart ang multipath na serbisyo
Nakatagong tekstomga device {
aparato {
vendor "AStor"
path_grouping_policy "group_by_prio"
path_selector "haba ng pila 0"
path_checker "tur"
mga tampok na "0"
hardware_handler "0"
prio "const"
failback kaagad
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names oo
detect_prio oo
rr_min_io_rq 1
no_path_retry 0
}
}
Susunod, para gumana ang ASM sa MPIO sa pamamagitan ng ASMLib, kailangan mong baguhin ang /etc/sysconfig/oracleasm file at pagkatapos ay patakbuhin ang /etc/init.d/oracleasm scandisks
Nakatagong teksto
# ORACLEASM_SCANORDER: Pagtutugma ng mga pattern upang mag-order ng disk scan
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Pagtutugma ng mga pattern upang ibukod ang mga disk mula sa pag-scan
ORACLEASM_SCANEXCLUDE="sd"
Nota
Kung ayaw mong gumamit ng ASMLib, maaari mong gamitin ang mga panuntunan ng UDEV, na siyang batayan para sa ASMLib.
Simula sa bersyon 12.1.0.2 ng Oracle Database, ang opsyon ay magagamit para sa pag-install bilang bahagi ng ASMFD software.
Kinakailangang tiyakin na ang mga disk na ginawa para sa Oracle ASM ay nakahanay sa laki ng bloke na pisikal na gumagana ng array (4K). Kung hindi, maaaring mangyari ang mga problema sa pagganap. Samakatuwid, kinakailangan upang lumikha ng mga volume na may naaangkop na mga parameter:
hati /dev/mapper/pangalan ng device mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Pamamahagi ng mga database sa mga nilikhang volume para sa aming pagsasaayos ng pagsubok
Pangalan ng Dami ng Imbakan
Laki ng Dami
Dami ng LUN na pagmamapa
Detalye ng ASM Volume Device
Laki ng Yunit ng Paglalaan
Data01
200GB
I-map ang lahat ng dami ng storage sa storage system lahat ng data port
Redundancy: Normal
Pangalan:DGDATA
Layunin: Mga file ng data
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redundancy: Normal
Pangalan: DGGRID1
Layunin:Grid: CRS at Pagboto
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundancy: Normal
Pangalan: DGGRID2
Layunin:Grid: CRS at Pagboto
4MB
Grid05
1GB
Grid06
1GB
Gawin muli01
100GB
Redundancy: Normal
Pangalan: DGREDO1
Layunin: I-redo ang log ng thread 1
4MB
Gawin muli02
100GB
Gawin muli03
100GB
Gawin muli04
100GB
Gawin muli05
100GB
Gawin muli06
100GB
Redundancy: Normal
Pangalan: DGREDO2
Layunin: I-redo ang log ng thread 2
4MB
Gawin muli07
100GB
Gawin muli08
100GB
Gawin muli09
100GB
Gawin muli10
100GB
Mga Setting ng Database
- Laki ng block = 8K
- Magpalit ng espasyo = 16GB
- Huwag paganahin ang AMM (Awtomatikong Pamamahala ng Memory)
- Huwag paganahin ang Transparent na Malaking Pahina
Iba pang mga setting
# 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 # huwag itakda ito kung gumagamit ka ng 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
✓ malambot memlock 120795954
✓ mahirap memlock 120795954
sqlplus “/as sysdba”
baguhin ang mga proseso ng set ng system=2000 saklaw=spfile;
baguhin ang set ng system open_cursors=2000 saklaw=spfile;
baguhin ang set ng system session_cached_cursors=300 saklaw=spfile;
baguhin ang set ng system db_files=8192 saklaw=spfile;
Pagsubok sa pagkabigo
Para sa mga layunin ng pagpapakita, ginamit ang HammerDB upang tularan ang isang OLTP load. Configuration ng HammerDB:
Bilang ng mga Warehouse
256
Kabuuang Mga Transaksyon bawat User
1000000000000
Mga Virtual na Gumagamit
256
Ang resulta ay isang 2.1M TPM, na malayo sa limitasyon ng pagganap ng array , ngunit ito ay isang "ceiling" para sa kasalukuyang configuration ng hardware ng mga server (pangunahin dahil sa mga processor) at ang kanilang numero. Ang layunin ng pagsubok na ito ay upang ipakita ang fault tolerance ng solusyon sa kabuuan, at hindi upang makamit ang pinakamataas na pagganap. Samakatuwid, bubuo lang kami sa figure na ito.
Subukan para sa pagkabigo ng isa sa mga node
Nawala ng mga host ang bahagi ng mga landas patungo sa imbakan, na patuloy na nagtatrabaho sa mga natitira gamit ang pangalawang node. Bumaba ang performance sa loob ng ilang segundo dahil sa muling itinayong mga landas, at pagkatapos ay bumalik sa normal. Walang pagkaantala sa serbisyo.
Pagsubok sa pagkabigo ng gabinete sa lahat ng kagamitan
Sa kasong ito, bumaba rin ang pagganap sa loob ng ilang segundo dahil sa muling pagsasaayos ng mga landas, at pagkatapos ay bumalik sa kalahati ng orihinal na halaga. Ang resulta ay nahati mula sa una dahil sa pagbubukod ng isang server ng application mula sa operasyon. Wala ring naantala sa serbisyo.
Kung may pangangailangan na ipatupad ang isang fault-tolerant Cross-Rack disaster recovery solution para sa Oracle sa isang makatwirang halaga at may kaunting pagsisikap sa pag-deploy/administrasyon, ang Oracle RAC at ang arkitektura ay nagtutulungan ay magiging isa sa mga pinakamahusay na pagpipilian. Sa halip na Oracle RAC, maaaring mayroong anumang iba pang software na nagbibigay ng clustering, ang parehong DBMS o virtualization system, halimbawa. Ang prinsipyo ng pagbuo ng solusyon ay mananatiling pareho. At ang ilalim na linya ay zero para sa RTO at RPO.
Pinagmulan: www.habr.com