Membina penyelesaian toleran kesalahan berdasarkan seni bina Oracle RAC dan AccelStor Shared-Nothing

Sebilangan besar aplikasi Perusahaan dan sistem virtualisasi mempunyai mekanisme tersendiri untuk membina penyelesaian toleran kesalahan. Secara khusus, Oracle RAC (Oracle Real Application Cluster) ialah sekumpulan dua atau lebih pelayan pangkalan data Oracle yang bekerja bersama untuk mengimbangi beban dan memberikan toleransi kesalahan pada peringkat pelayan/aplikasi. Untuk bekerja dalam mod ini, anda memerlukan storan kongsi, yang biasanya merupakan sistem storan.

Seperti yang telah kita bincangkan dalam salah satu daripada kami Perkara, sistem storan itu sendiri, walaupun terdapat komponen pendua (termasuk pengawal), masih mempunyai titik kegagalan - terutamanya dalam bentuk satu set data. Oleh itu, untuk membina penyelesaian Oracle dengan keperluan kebolehpercayaan yang lebih tinggi, skema "pelayan N - satu sistem storan" perlu rumit.

Pertama, sudah tentu, kita perlu memutuskan risiko apa yang kita cuba untuk menginsuranskan. Dalam artikel ini, kami tidak akan mempertimbangkan perlindungan terhadap ancaman seperti "meteorit telah tiba." Jadi membina penyelesaian pemulihan bencana yang tersebar secara geografi akan kekal sebagai topik untuk salah satu artikel berikut. Di sini kita akan melihat penyelesaian pemulihan bencana Cross-Rack yang dipanggil, apabila perlindungan dibina pada tahap kabinet pelayan. Kabinet itu sendiri boleh diletakkan di dalam bilik yang sama atau di dalam bilik yang berbeza, tetapi biasanya dalam bangunan yang sama.

Kabinet ini mesti mengandungi keseluruhan set peralatan dan perisian yang diperlukan, yang akan memastikan operasi pangkalan data Oracle tanpa mengira keadaan "jiran". Dengan kata lain, menggunakan penyelesaian pemulihan bencana Cross-Rack, kami menghapuskan risiko kegagalan:

• Pelayan Aplikasi Oracle
• Sistem penyimpanan
• Sistem pensuisan
• Kegagalan sepenuhnya semua peralatan dalam kabinet:
  • Penolakan kuasa
  • Kegagalan sistem penyejukan
  • Faktor luaran (manusia, alam semula jadi, dll.)

Penduaan pelayan Oracle membayangkan prinsip operasi Oracle RAC dan dilaksanakan melalui aplikasi. Penduaan kemudahan pensuisan juga tidak menjadi masalah. Tetapi dengan pertindihan sistem storan, semuanya tidak begitu mudah.

Pilihan paling mudah ialah replikasi data daripada sistem storan utama kepada sistem sandaran. Segerak atau tak segerak, bergantung pada keupayaan sistem storan. Dengan replikasi tak segerak, persoalan segera timbul untuk memastikan konsistensi data berhubung dengan Oracle. Tetapi walaupun terdapat integrasi perisian dengan aplikasi, dalam apa jua keadaan, jika terdapat kegagalan pada sistem storan utama, campur tangan manual oleh pentadbir akan diperlukan untuk menukar kluster kepada storan sandaran.

Pilihan yang lebih kompleks ialah "penyimpan maya" perisian dan/atau perkakasan yang akan menghapuskan masalah konsistensi dan campur tangan manual. Tetapi kerumitan penggunaan dan pentadbiran seterusnya, serta kos penyelesaian sedemikian yang sangat tidak senonoh, menakutkan ramai orang.

Penyelesaian tatasusunan AccelStor NeoSapphire™ All Flash sesuai untuk senario seperti pemulihan bencana Cross-Rack H710 menggunakan seni bina Shared-Nothing. Model ini ialah sistem storan dua nod yang menggunakan teknologi FlexiRemap® proprietari untuk berfungsi dengan pemacu kilat. Terima kasih kepada FlexiRemap® NeoSapphire™ H710 mampu menyampaikan prestasi sehingga 600K IOPS@4K penulisan rawak dan 1M+ IOPS@4K bacaan rawak, yang tidak boleh dicapai apabila menggunakan sistem storan berasaskan RAID klasik.

Tetapi ciri utama NeoSapphire™ H710 ialah pelaksanaan dua nod dalam bentuk kes berasingan, setiap satunya mempunyai salinan datanya sendiri. Penyegerakan nod dijalankan melalui antara muka InfiniBand luaran. Terima kasih kepada seni bina ini, adalah mungkin untuk mengedarkan nod ke lokasi yang berbeza pada jarak sehingga 100m, dengan itu menyediakan penyelesaian pemulihan bencana Cross-Rack. Kedua-dua nod beroperasi secara serentak. Dari sisi hos, H710 kelihatan seperti sistem storan dwi-pengawal biasa. Oleh itu, tidak perlu melakukan sebarang pilihan perisian atau perkakasan tambahan atau tetapan yang rumit.

Jika kita membandingkan semua penyelesaian pemulihan bencana Cross-Rack yang diterangkan di atas, maka pilihan daripada AccelStor menonjol dengan ketara daripada yang lain:

AccelStor NeoSapphire™ Shared Nothing Architecture
Sistem storan "virtualizer" perisian atau perkakasan
Penyelesaian berasaskan replikasi

Ketersediaan

Kegagalan pelayan
Tiada Waktu Henti
Tiada Waktu Henti
Tiada Waktu Henti

Kegagalan suis
Tiada Waktu Henti
Tiada Waktu Henti
Tiada Waktu Henti

Kegagalan sistem storan
Tiada Waktu Henti
Tiada Waktu Henti
Masalah

Kegagalan kabinet keseluruhan
Tiada Waktu Henti
Tiada Waktu Henti
Masalah

Kos dan kerumitan

Kos penyelesaian
rendah*
Tinggi
Tinggi

Kerumitan penggunaan
Rendah
Tinggi
Tinggi

*AccelStor NeoSapphire™ masih merupakan tatasusunan Semua Flash, yang mengikut definisi tidak berharga "3 kopecks," terutamanya kerana ia mempunyai rizab kapasiti dua kali. Walau bagaimanapun, apabila membandingkan kos akhir penyelesaian berdasarkannya dengan yang serupa daripada vendor lain, kos boleh dianggap rendah.

Topologi untuk menyambungkan pelayan aplikasi dan Semua nod tatasusunan Flash akan kelihatan seperti ini:

Apabila merancang topologi, ia juga amat disyorkan untuk menduplikasi suis pengurusan dan pelayan antara sambungan.

Di sini dan seterusnya kita akan bercakap tentang menyambung melalui Saluran Fiber. Jika anda menggunakan iSCSI, semuanya akan sama, diselaraskan untuk jenis suis yang digunakan dan tetapan tatasusunan yang sedikit berbeza.

Kerja persediaan pada tatasusunan

Peralatan dan perisian yang digunakan

Spesifikasi Pelayan dan Suis

Komponen
Описание

Pelayan 11g Pangkalan Data Oracle
Dua

Sistem pengendalian pelayan
Oracle Linux

Versi pangkalan data Oracle
11g (RAC)

Pemproses setiap pelayan
Dua 16 teras Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz

Memori fizikal setiap pelayan
128GB

Rangkaian FC
16Gb/s FC dengan berbilang laluan

FC HBA
Emulex Lpe-16002B

Port 1GbE awam khusus untuk pengurusan kluster
Penyesuai ethernet Intel RJ45

Suis FC 16Gb/s
Brokat 6505

Port 10GbE peribadi khusus untuk penyegerakan data
Intel X520

Spesifikasi Tatasusunan Denyar Semua AccelStor NeoSapphire™

Komponen
Описание

Sistem simpanan
Model ketersediaan tinggi NeoSapphire™: H710

Versi imej
4.0.1

Jumlah bilangan pemacu
48

Saiz pemacu
1.92TB

Jenis pemacu
SSD

Pelabuhan sasaran FC
Port 16x 16Gb (8 setiap nod)

Pelabuhan pengurusan
Kabel ethernet 1GbE yang menyambung kepada hos melalui suis ethernet

Pelabuhan degupan jantung
Kabel ethernet 1GbE yang menghubungkan antara dua nod storan

Port penyegerakan data
Kabel InfiniBand 56Gb/s

Sebelum anda boleh menggunakan tatasusunan, anda mesti memulakannya. Secara lalai, alamat kawalan kedua-dua nod adalah sama (192.168.1.1). Anda perlu menyambung kepada mereka satu demi satu dan menetapkan alamat pengurusan baharu (sudah berbeza) dan menyediakan penyegerakan masa, selepas itu port Pengurusan boleh disambungkan ke rangkaian tunggal. Selepas itu, nod digabungkan menjadi pasangan HA dengan menetapkan subnet untuk sambungan Interlink.

Selepas permulaan selesai, anda boleh menguruskan tatasusunan daripada mana-mana nod.

Seterusnya, kami mencipta jilid yang diperlukan dan menerbitkannya ke pelayan aplikasi.

Adalah sangat disyorkan untuk mencipta berbilang volum untuk Oracle ASM kerana ini akan meningkatkan bilangan sasaran untuk pelayan, yang akhirnya akan meningkatkan prestasi keseluruhan (lebih lanjut mengenai baris gilir dalam yang lain. artikel).

Konfigurasi ujian

Nama Kelantangan Storan
Saiz Kelantangan

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

Buat semula01
100GB

Buat semula02
100GB

Buat semula03
100GB

Buat semula04
100GB

Buat semula05
100GB

Buat semula06
100GB

Buat semula07
100GB

Buat semula08
100GB

Buat semula09
100GB

Buat semula10
100GB

Beberapa penjelasan tentang mod pengendalian tatasusunan dan proses yang berlaku dalam situasi kecemasan

Set data setiap nod mempunyai parameter "nombor versi". Selepas pemulaan awal, ia adalah sama dan sama dengan 1. Jika atas sebab tertentu nombor versi berbeza, maka data sentiasa disegerakkan daripada versi lama kepada versi yang lebih muda, selepas itu nombor versi yang lebih muda diselaraskan, i.e. ini bermakna bahawa salinan adalah sama. Sebab mengapa versi mungkin berbeza:

• But semula berjadual salah satu nod
• Kemalangan pada salah satu nod akibat penutupan mendadak (bekalan kuasa, terlalu panas, dsb.).
• Sambungan InfiniBand hilang dengan ketidakupayaan untuk menyegerak
• Ranap sistem pada salah satu nod disebabkan oleh kerosakan data. Di sini anda perlu membuat kumpulan HA baharu dan penyegerakan lengkap set data.

Walau apa pun, nod yang kekal dalam talian meningkatkan nombor versinya sebanyak satu untuk menyegerakkan set datanya selepas sambungan dengan pasangan itu dipulihkan.

Jika sambungan melalui pautan Ethernet terputus, Degupan Jantung beralih kepada InfiniBand buat sementara waktu dan kembali semula dalam masa 10 saat apabila ia dipulihkan.

Menyediakan hos

Untuk memastikan toleransi kesalahan dan meningkatkan prestasi, anda mesti mendayakan sokongan MPIO untuk tatasusunan. Untuk melakukan ini, anda perlu menambah baris pada fail /etc/multipath.conf, dan kemudian mulakan semula perkhidmatan berbilang laluan

Teks tersembunyiperanti {
peranti {
vendor "AStor"
path_grouping_policy "group_by_prio"
pemilih laluan "panjang gilir 0"
path_checker "tur"
ciri "0"
pengendali_perkakasan "0"
sebelum "const"
failback segera
fast_io_fail_tmo 5
dev_loss_tmo 60
nama_mesra_pengguna ya
detect_prio ya
rr_min_io_rq 1
tiada_laluan_cuba semula 0
}
}

Seterusnya, untuk membolehkan ASM berfungsi dengan MPIO melalui ASMLib, anda perlu menukar fail /etc/sysconfig/oracleasm dan kemudian jalankan /etc/init.d/oracleasm scandisks

Teks tersembunyi

# ORACLEASM_SCANORDER: Memadankan corak untuk memesan pengimbasan cakera
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: Corak yang sepadan untuk mengecualikan cakera daripada imbasan
ORACLEASM_SCANEXCLUDE="sd"

Nota

Jika anda tidak mahu menggunakan ASMLib, anda boleh menggunakan peraturan UDEV, yang merupakan asas untuk ASMLib.

Bermula dengan versi 12.1.0.2 Pangkalan Data Oracle, pilihan tersedia untuk pemasangan sebagai sebahagian daripada perisian ASMFD.

Adalah penting untuk memastikan bahawa cakera yang dicipta untuk Oracle ASM diselaraskan dengan saiz blok yang tatasusunan beroperasi secara fizikal dengan (4K). Jika tidak, masalah prestasi mungkin berlaku. Oleh itu, adalah perlu untuk membuat volum dengan parameter yang sesuai:

parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimum 1

Pengagihan pangkalan data merentas volum yang dicipta untuk konfigurasi ujian kami

Nama Kelantangan Storan
Saiz Kelantangan
Pemetaan LUN volum
Butiran Peranti Kelantangan ASM
Saiz Unit Peruntukan

Data01
200GB
Petakan semua volum storan ke sistem storan semua port data
Lebihan: Normal
Nama:DGDATA
Tujuan: Fail data

4MB

Data02
200GB

Data03
200GB

Data04
200GB

Data05
200GB

Data06
200GB

Data07
200GB

Data08
200GB

Data09
200GB

Data10
200GB

Grid01
1GB
Lebihan: Normal
Nama: DGGRID1
Tujuan:Grid: CRS dan Pengundian

4MB

Grid02
1GB

Grid03
1GB

Grid04
1GB
Lebihan: Normal
Nama: DGGRID2
Tujuan:Grid: CRS dan Pengundian

4MB

Grid05
1GB

Grid06
1GB

Buat semula01
100GB
Lebihan: Normal
Nama: DGREDO1
Tujuan: Buat semula log benang 1

4MB

Buat semula02
100GB

Buat semula03
100GB

Buat semula04
100GB

Buat semula05
100GB

Buat semula06
100GB
Lebihan: Normal
Nama: DGREDO2
Tujuan: Buat semula log benang 2

4MB

Buat semula07
100GB

Buat semula08
100GB

Buat semula09
100GB

Buat semula10
100GB

Tetapan Pangkalan Data

• Saiz blok = 8K
• Ruang tukar = 16GB
• Lumpuhkan AMM (Pengurusan Memori Automatik)
• Lumpuhkan Halaman Besar Telus

Tetapan lain

# 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 # jangan tetapkan ini jika anda menggunakan Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000

# vi /etc/security/limits.conf
✓ grid nproc lembut 2047
✓ grid keras nproc 16384
✓ grid lembut nofile 1024
✓ grid hard nofile 65536
✓ susunan lembut grid 10240
✓ susunan keras grid 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ oracle hard nofile 65536
✓ timbunan lembut oracle 10240
✓ timbunan keras oracle 32768
✓ memlock lembut 120795954
✓ memlock keras 120795954

sqlplus “/as sysdba”
mengubah proses set sistem=2000 skop=spfile;
ubah set sistem open_cursors=2000 skop=spfile;
ubah set sistem session_cached_cursors=300 skop=spfile;
ubah set sistem db_files=8192 skop=spfile;

Ujian kegagalan

Untuk tujuan demonstrasi, HammerDB digunakan untuk meniru beban OLTP. Konfigurasi HammerDB:

Bilangan Gudang
256

Jumlah Transaksi bagi setiap Pengguna
1000000000000

Pengguna Maya
256

Hasilnya ialah TPM 2.1M, yang jauh daripada had prestasi tatasusunan H710, tetapi merupakan "siling" untuk konfigurasi perkakasan semasa pelayan (terutamanya disebabkan oleh pemproses) dan nombor mereka. Tujuan ujian ini masih untuk menunjukkan toleransi kesalahan penyelesaian secara keseluruhan, dan bukan untuk mencapai prestasi maksimum. Oleh itu, kami hanya akan membina angka ini.

Uji kegagalan salah satu nod

Hos kehilangan sebahagian daripada laluan ke storan, terus bekerja melalui yang selebihnya dengan nod kedua. Prestasi menurun selama beberapa saat kerana laluan sedang dibina semula, dan kemudian kembali kepada normal. Tiada gangguan dalam perkhidmatan.

Ujian kegagalan kabinet dengan semua peralatan

Dalam kes ini, prestasi juga menurun selama beberapa saat disebabkan oleh penstrukturan semula laluan, dan kemudian kembali kepada separuh nilai asal. Hasilnya dikurangkan separuh daripada yang awal kerana pengecualian satu pelayan aplikasi daripada operasi. Tiada gangguan dalam perkhidmatan juga.

Jika terdapat keperluan untuk melaksanakan penyelesaian pemulihan bencana Cross-Rack yang bertolak ansur dengan kesalahan untuk Oracle pada kos yang berpatutan dan dengan sedikit usaha penempatan/pentadbiran, maka Oracle RAC dan seni bina bekerjasama AccelStor Shared-Nothing akan menjadi salah satu pilihan terbaik. Daripada Oracle RAC, boleh ada mana-mana perisian lain yang menyediakan pengelompokan, DBMS atau sistem virtualisasi yang sama, contohnya. Prinsip membina penyelesaian akan tetap sama. Dan garis bawah adalah sifar untuk RTO dan RPO.

Sumber: www.habr.com