Sawetara aplikasi Enterprise lan sistem virtualisasi duwe mekanisme dhewe kanggo mbangun solusi sing tahan kesalahan. Khusus, Oracle RAC (Oracle Real Application Cluster) minangka klompok saka loro utawa luwih server database Oracle sing makarya bebarengan kanggo ngimbangi beban lan menehi toleransi kesalahan ing tingkat server / aplikasi. Kanggo nggarap mode iki, sampeyan butuh panyimpenan sing dienggo bareng, sing biasane minangka sistem panyimpenan.
Minangka kita wis rembugan ing salah siji kita , Sistem panyimpenan dhewe, senadyan ana komponen duplikat (kalebu pengontrol), isih nduweni titik kegagalan - utamane ing wangun data siji. Mulane, kanggo mbangun solusi Oracle kanthi syarat linuwih, skema "N server - siji sistem panyimpenan" kudu rumit.
Kaping pisanan, mesthine, kita kudu mutusake risiko apa sing arep diasuransiake. Ing artikel iki, kita ora bakal nimbang perlindungan saka ancaman kaya "meteorit wis teka." Dadi mbangun solusi pemulihan bencana sing kasebar sacara geografis bakal tetep dadi topik kanggo salah sawijining artikel ing ngisor iki. Kene kita bakal katon ing dadi-disebut Cross-Rack solusi Recovery bilai, nalika pangayoman dibangun ing tingkat lemantun server. Lemari dhewe bisa dumunung ing kamar sing padha utawa ing macem-macem, nanging biasane ing bangunan sing padha.
Kabinet iki kudu ngemot kabeh peralatan lan piranti lunak sing dibutuhake sing bakal ngidini operasi database Oracle preduli saka kahanan "petangga". Kanthi tembung liyane, nggunakake solusi pemulihan bencana Cross-Rack, kita ngilangi risiko kegagalan:
- Server Aplikasi Oracle
- Sistem panyimpenan
- Sistem switching
- Gagal lengkap kabeh peralatan ing kabinet:
- Daya nolak
- Gagal sistem pendinginan
- Faktor eksternal (manungsa, alam, lsp)
Duplikasi server Oracle nyebabake prinsip operasi Oracle RAC lan dileksanakake liwat aplikasi. Duplikasi fasilitas switching uga ora dadi masalah. Nanging kanthi duplikasi sistem panyimpenan, kabeh ora gampang.
Pilihan sing paling gampang yaiku replikasi data saka sistem panyimpenan utama menyang cadangan. Sinkron utawa asinkron, gumantung saka kemampuan sistem panyimpenan. Kanthi replikasi asinkron, pitakonan langsung muncul kanggo njamin konsistensi data ing hubungane karo Oracle. Nanging sanajan ana integrasi piranti lunak karo aplikasi kasebut, ing kasus apa wae, yen gagal ing sistem panyimpenan utama, intervensi manual dening pangurus bakal dibutuhake kanggo ngalih kluster menyang panyimpenan serep.
Pilihan sing luwih rumit yaiku "virtualizer" panyimpenan piranti lunak lan / utawa hardware sing bakal ngilangi masalah konsistensi lan intervensi manual. Nanging kerumitan panyebaran lan administrasi sakteruse, uga biaya solusi sing ora sopan banget, akeh sing wedi.
Solusi array AccelStor NeoSapphire™ All Flash sampurna kanggo skenario kayata Recovery bencana Cross-Rack nggunakake arsitektur Shared-Nothing. Model iki minangka sistem panyimpenan rong simpul sing nggunakake teknologi FlexiRemap® eksklusif kanggo nggarap flash drive. Matur nuwun kanggo NeoSapphire™ H710 bisa menehi kinerja nganti 600K IOPS@4K nulis acak lan 1M+ IOPS@4K maca acak, sing ora bisa digayuh nalika nggunakake sistem panyimpenan basis RAID klasik.
Nanging fitur utama NeoSapphire ™ H710 yaiku eksekusi rong simpul ing wangun kasus sing kapisah, sing saben duwe salinan data dhewe. Sinkronisasi simpul ditindakake liwat antarmuka InfiniBand eksternal. Thanks kanggo arsitektur iki, bisa nyebarake simpul menyang macem-macem lokasi kanthi jarak nganti 100m, saéngga nyedhiyakake solusi pemulihan bencana Cross-Rack. Loro-lorone simpul beroperasi kanthi sinkron. Saka sisih host, H710 katon kaya sistem panyimpenan dual-controller biasa. Mulane, ora perlu nindakake opsi piranti lunak utawa hardware tambahan utawa setelan sing rumit.
Yen mbandhingake kabeh solusi pemulihan bencana Cross-Rack sing diterangake ing ndhuwur, mula pilihan saka AccelStor katon nyata saka liyane:
AccelStor NeoSapphire™ Shared Nothing Architecture
Piranti lunak utawa hardware "virtualizer" sistem panyimpenan
Solusi adhedhasar replikasi
Kasedhiyan
Gagal server
Ora Downtime
Ora Downtime
Ora Downtime
Gagal ngalih
Ora Downtime
Ora Downtime
Ora Downtime
Gagal sistem panyimpenan
Ora Downtime
Ora Downtime
Downtime
Gagal kabeh kabinet
Ora Downtime
Ora Downtime
Downtime
Biaya lan kerumitan
Biaya solusi
sedheng*
Wigati
Wigati
Kerumitan panyebaran
Kurang
Wigati
Wigati
*AccelStor NeoSapphire™ isih dadi array Kabeh Flash, sing miturut definisi ora biaya "3 kopecks," utamane amarga duwe cadangan kapasitas kaping pindho. Nanging, nalika mbandhingake biaya pungkasan saka solusi adhedhasar karo sing padha saka vendor liyane, biaya bisa dianggep kurang.
Topologi kanggo nyambungake server aplikasi lan Kabeh simpul larik Flash bakal katon kaya iki:
Nalika ngrancang topologi, uga dianjurake kanggo nggawe duplikat switch manajemen lan server interconnect.
Ing kene lan sabanjure kita bakal ngomong babagan nyambungake liwat Fiber Channel. Yen sampeyan nggunakake iSCSI, kabeh bakal padha, diatur kanggo jinis ngalih digunakake lan setelan Uploaded rada beda.
Preparatory work ing array
Piranti lan piranti lunak sing digunakake
Spesifikasi Server lan Switch
Komponen
Description
Server Oracle Database 11g
Loro
Sistem operasi server
oracle linux
Versi database Oracle
11 g (RAC)
Prosesor saben server
Loro 16 inti Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
Memori fisik saben server
128GB
jaringan FC
16Gb/s FC karo multipathing
FC HBA
Emulex Lpe-16002B
Port 1GbE umum khusus kanggo manajemen kluster
Intel ethernet adaptor RJ45
16Gb/s FC ngalih
Brokat 6505
Port 10GbE pribadi khusus kanggo sinkonisasi data
Intel X520
Spesifikasi AccelStor NeoSapphire™ All Flash Array
Komponen
Description
Sistem panyimpenan
NeoSapphire™ model kasedhiyan dhuwur: H710
Versi gambar
4.0.1
Jumlah total drive
48
Ukuran drive
1.92TB
Tipe Drive
SSD
Port target FC
16x 16Gb port (8 saben simpul)
port Manajemen
Kabel ethernet 1GbE nyambung menyang host liwat switch ethernet
Port detak jantung
Kabel ethernet 1GbE nyambungake antarane rong node panyimpenan
Port sinkronisasi data
Kabel InfiniBand 56Gb/s
Sadurunge sampeyan bisa nggunakake array, sampeyan kudu miwiti. Kanthi gawan, alamat kontrol loro simpul padha (192.168.1.1). Sampeyan kudu nyambungake menyang wong siji lan nyetel anyar (wis beda) alamat Manajemen lan nyetel sinkronisasi wektu, sawise kang bandar Manajemen bisa disambungake menyang jaringan siji. Banjur, simpul digabungake dadi pasangan HA kanthi menehi subnet kanggo sambungan Interlink.
Sawise initialization rampung, sampeyan bisa ngatur array saka sembarang simpul.
Sabanjure, kita nggawe volume sing dibutuhake lan nerbitake menyang server aplikasi.
Disaranake nggawe pirang-pirang volume kanggo Oracle ASM amarga iki bakal nambah jumlah target kanggo server, sing pungkasane bakal nambah kinerja sakabèhé (luwih akeh babagan antrian ing liyane. ).
Konfigurasi tes
Jeneng Volume Panyimpenan
Ukuran Volume
Dhata01
200GB
Dhata02
200GB
Dhata03
200GB
Dhata04
200GB
Dhata05
200GB
Dhata06
200GB
Dhata07
200GB
Dhata08
200GB
Dhata09
200GB
Dhata10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Gawe maneh01
100GB
Gawe maneh02
100GB
Gawe maneh03
100GB
Gawe maneh04
100GB
Gawe maneh05
100GB
Gawe maneh06
100GB
Gawe maneh07
100GB
Gawe maneh08
100GB
Gawe maneh09
100GB
Gawe maneh10
100GB
Sawetara panjelasan babagan mode operasi array lan proses sing kedadeyan ing kahanan darurat
Set data saben simpul duwe parameter "nomer versi". Sawise initialization dhisikan, iku padha lan padha karo 1. Yen sakperangan alesan nomer versi beda, banjur data tansah diselarasake saka versi lawas kanggo luwih enom, sawise kang nomer versi enom didadekake siji, i.e. iki tegese salinan padha. Alesan kenapa versi bisa beda:
- Dijadwalake urip maneh salah sawijining simpul
- Kacilakan ing salah sawijining simpul amarga mati dadakan (sumber daya, panas banget, lsp).
- Sambungan InfiniBand ilang kanthi ora bisa nyinkronake
- Kacilakan ing salah sawijining simpul amarga korupsi data. Kene sampeyan kudu nggawe grup HA anyar lan sinkronisasi lengkap saka pesawat data.
Ing kasus apa wae, simpul sing tetep online nambah nomer versi siji supaya bisa nyinkronake set data sawise sambungan karo pasangan dibalekake.
Yen sambungan liwat link Ethernet ilang, Heartbeat sementara ngalih menyang InfiniBand lan bali maneh ing 10 detik nalika dibalèkaké.
Nyetel sarwa dumadi
Kanggo mesthekake toleransi fault lan nambah kinerja, sampeyan kudu ngaktifake support MPIO kanggo Uploaded. Kanggo nindakake iki, sampeyan kudu nambah baris menyang file /etc/multipath.conf, banjur miwiti maneh layanan multipath.
Teks sing didhelikakepiranti {
piranti {
vendor "AStor"
path_grouping_policy "group_by_prio"
path_selector "dawa antrian 0"
path_checker "tur"
fitur "0"
hardware_handler "0"
sadurunge "const"
failback langsung
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names ya
detect_prio ya
rr_min_io_rq 1
no_path_retry 0
}
}
Sabanjure, supaya ASM bisa nggarap MPIO liwat ASMLib, sampeyan kudu ngganti file /etc/sysconfig/oracleasm banjur mbukak /etc/init.d/oracleasm scandisks
Teks sing didhelikake
# ORACLEASM_SCANORDER: Pola sing cocog kanggo pesen scan disk
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Pola sing cocog kanggo ngilangi disk saka pindai
ORACLEASM_SCANEXCLUDE="sd"
komentar
Yen sampeyan ora pengin nggunakake ASMLib, sampeyan bisa nggunakake aturan UDEV, kang basis kanggo ASMLib.
Miwiti karo versi 12.1.0.2 Oracle Database, pilihan kasedhiya kanggo instalasi minangka bagéan saka piranti lunak ASMFD.
Penting kanggo mesthekake yen disk sing digawe kanggo Oracle ASM selaras karo ukuran blok sing dioperasikake kanthi fisik (4K). Yen ora, masalah kinerja bisa kedadeyan. Mulane, perlu nggawe volume kanthi paramèter sing cocog:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Distribusi basis data ing volume sing digawe kanggo konfigurasi tes kita
Jeneng Volume Panyimpenan
Ukuran Volume
Pemetaan volume LUN
Detail Piranti Volume ASM
Ukuran Unit Alokasi
Dhata01
200GB
Peta kabeh volume panyimpenan menyang sistem panyimpenan kabeh port data
Redundansi: Normal
Jeneng: DGDATA
Tujuan: File data
4MB
Dhata02
200GB
Dhata03
200GB
Dhata04
200GB
Dhata05
200GB
Dhata06
200GB
Dhata07
200GB
Dhata08
200GB
Dhata09
200GB
Dhata10
200GB
Grid01
1GB
Redundansi: Normal
Jeneng: DGGRID1
Tujuan: Grid: CRS lan Voting
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundansi: Normal
Jeneng: DGGRID2
Tujuan: Grid: CRS lan Voting
4MB
Grid05
1GB
Grid06
1GB
Gawe maneh01
100GB
Redundansi: Normal
Jeneng: DGREDO1
Tujuan: Nggawe maneh log thread 1
4MB
Gawe maneh02
100GB
Gawe maneh03
100GB
Gawe maneh04
100GB
Gawe maneh05
100GB
Gawe maneh06
100GB
Redundansi: Normal
Jeneng: DGREDO2
Tujuan: Nggawe maneh log thread 2
4MB
Gawe maneh07
100GB
Gawe maneh08
100GB
Gawe maneh09
100GB
Gawe maneh10
100GB
Setelan Database
- Ukuran blok = 8K
- Swap spasi = 16GB
- Pateni AMM (Manajemen Memori Otomatis)
- Pateni Kaca Ageng Transparan
Setelan liyane
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-maks = 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 # aja nyetel iki yen sampeyan nggunakake Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugpages = 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
✓ tumpukan hard grid 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
✓ memlock hard 120795954
sqlplus "/ minangka sysdba"
ngowahi proses set sistem = 2000 ruang lingkup = 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;
Tes gagal
Kanggo tujuan demonstrasi, HammerDB digunakake kanggo niru beban OLTP. Konfigurasi HammerDB:
Jumlah Gudang
256
Total Transaksi saben pangguna
1000000000000
Pangguna Virtual
256
Asil ana 2.1M TPM, kang adoh saka watesan kinerja Uploaded , nanging minangka "langit-langit" kanggo konfigurasi hardware saiki server (utamane amarga prosesor) lan nomer. Tujuan saka tes iki isih kanggo nduduhake toleransi fault saka solusi minangka kabèh, lan ora kanggo entuk kinerja maksimum. Mulane, kita mung bakal mbangun tokoh iki.
Tes kanggo kegagalan salah sawijining simpul
Tuan rumah ilang bagean saka dalan menyang panyimpenan, terus nggarap sing isih ana karo simpul kapindho. Kinerja mudhun sawetara detik amarga dalan sing dibangun maneh, banjur bali menyang normal. Ora ana gangguan ing layanan.
Tes kegagalan kabinet karo kabeh peralatan
Ing kasus iki, kinerja uga dropped kanggo sawetara detik amarga di toto maneh saka dalan, lan banjur bali menyang setengah Nilai asli. Asil dikurangi setengah saka wiwitan amarga ora ana siji server aplikasi saka operasi. Ora ana gangguan ing layanan uga.
Yen ana kabutuhan kanggo ngleksanakake solusi pemulihan bencana Cross-Rack sing toleran kanggo Oracle kanthi biaya sing cukup lan kanthi upaya penyebaran / administrasi sing sithik, banjur Oracle RAC lan arsitektur bisa kerja bareng. bakal dadi salah sawijining pilihan sing paling apik. Tinimbang Oracle RAC, bisa uga ana piranti lunak liyane sing nyedhiyakake clustering, DBMS utawa sistem virtualisasi sing padha, contone. Prinsip mbangun solusi bakal tetep padha. Lan ing ngisor iki nol kanggo RTO lan RPO.
Source: www.habr.com