Sejumlah besar aplikasi Enterprise dan sistem virtualisasi memiliki mekanisme sendiri untuk membangun solusi toleran kesalahan. Secara khusus, Oracle RAC (Oracle Real Application Cluster) adalah sekelompok dua atau lebih server basis data Oracle yang bekerja bersama untuk menyeimbangkan beban dan memberikan toleransi kesalahan pada tingkat server / aplikasi. Untuk bekerja dalam mode ini, diperlukan penyimpanan yang umum, yang perannya biasanya penyimpanan.
Seperti yang telah kita bahas di salah satu artikel kami, dengan sendirinya, terlepas dari adanya komponen duplikat (termasuk pengontrol), sistem penyimpanan masih memiliki titik kegagalan - terutama dalam bentuk satu set data tunggal. Oleh karena itu, untuk membangun solusi Oracle dengan persyaratan keandalan yang meningkat, skema “N server - satu penyimpanan” harus rumit.
Pertama, tentu saja, Anda perlu memutuskan risiko apa yang ingin kami asuransikan. Dalam artikel ini, kami tidak akan mempertimbangkan perlindungan terhadap ancaman seperti meteorit telah tiba. Jadi membangun solusi pemulihan bencana yang tersebar secara geografis akan tetap menjadi topik untuk salah satu artikel berikut. Di sini kita melihat apa yang disebut solusi pemulihan bencana Cross-Rack, ketika perlindungan dibangun di tingkat lemari server. Lemari sendiri dapat terletak di ruangan yang sama, atau berbeda, tetapi biasanya di dalam gedung yang sama.
Kabinet ini harus berisi semua set peralatan dan perangkat lunak yang diperlukan yang akan memastikan operasi database Oracle terlepas dari keadaan "tetangga". Dengan kata lain, menggunakan solusi pemulihan bencana Cross-Rack, kami menghilangkan risiko kegagalan:
- Server Aplikasi Oracle
- Sistem penyimpanan
- Sistem switching
- Kegagalan total semua peralatan di kabinet:
- Kegagalan daya
- Kegagalan sistem pendingin
- Faktor eksternal (manusia, alam, dll.)
Duplikasi server Oracle menyiratkan prinsip Oracle RAC dan diimplementasikan melalui aplikasi. Duplikasi alat switching juga tidak masalah. Tetapi dengan duplikasi sistem penyimpanan, semuanya tidak begitu sederhana.
Opsi termudah adalah mereplikasi data dari penyimpanan utama ke cadangan. Sinkron atau asinkron, tergantung pada kemampuan penyimpanan. Replikasi asinkron segera menimbulkan pertanyaan untuk memastikan konsistensi data dengan Oracle. Tetapi bahkan jika ada integrasi perangkat lunak dengan aplikasi, dalam hal apa pun, dalam hal terjadi kecelakaan pada sistem penyimpanan utama, intervensi manual oleh administrator akan diperlukan untuk mengalihkan cluster ke penyimpanan cadangan.
Opsi yang lebih kompleks adalah "virtualisator" perangkat lunak dan / atau perangkat keras dari sistem penyimpanan, yang akan menghilangkan masalah dengan konsistensi dan intervensi manual. Tetapi kompleksitas penyebaran dan administrasi selanjutnya, serta biaya yang sangat tidak senonoh dari solusi semacam itu, membuat takut banyak orang.
Hanya untuk skenario seperti pemulihan bencana Cross-Rack, semua Flash AccelStor NeoSapphire ™ H710 menggunakan arsitektur Shared-Nothing yang sempurna . Model ini adalah sistem penyimpanan dua-tunggal yang menggunakan teknologi FlexiRemap® sendiri untuk bekerja dengan flash drive. Berkat FlexiRemap® NeoSapphire ™ H710, ini dapat menghasilkan hingga 600K IOPS @ 4K penulisan acak dan 1M + IOPS @ 4K pembacaan acak, yang tidak dapat dicapai dengan penyimpanan berbasis RAID klasik.
Tetapi fitur utama dari NeoSapphire ™ H710 adalah eksekusi dua node sebagai lampiran terpisah, yang masing-masing memiliki salinan data sendiri. Sinkronisasi simpul dilakukan melalui antarmuka InfiniBand eksternal. Berkat arsitektur ini, node dapat tersebar di lokasi yang berbeda dengan jarak hingga 100m, sehingga memberikan solusi pemulihan bencana Cross-Rack. Kedua node bekerja sepenuhnya dalam mode sinkron. Dari sisi host, H710 terlihat seperti penyimpanan dual-controller biasa. Oleh karena itu, tidak ada opsi perangkat lunak dan perangkat keras tambahan dan pengaturan rumit yang perlu dilakukan.
Jika Anda membandingkan semua solusi pemulihan bencana Cross-Rack yang dijelaskan di atas, versi AccelStor menonjol dari yang lain:
| AccelStor NeoSapphire ™ Shared Nothing Architecture | Perangkat lunak atau "virtualizer" penyimpanan | Solusi replikasi |
|---|
| Ketersediaan |
| Kegagalan Server | Tidak ada downtime | Tidak ada downtime | Tidak ada downtime |
| Alihkan Kegagalan | Tidak ada downtime | Tidak ada downtime | Tidak ada downtime |
| Kegagalan Penyimpanan | Tidak ada downtime | Tidak ada downtime | Downtime |
| Kegagalan seluruh kabinet | Tidak ada downtime | Tidak ada downtime | Downtime |
| Biaya dan kerumitan |
| Biaya solusi | Rendah * | Tinggi | Tinggi |
| Kesulitan Penempatan | Rendah | Tinggi | Tinggi |
* AccelStor NeoSapphire ™ masih merupakan array All Flash, yang menurut definisi tidak memerlukan biaya "3 kopecks," terutama karena ia memiliki cadangan kapasitas ganda. Namun, membandingkan total biaya solusi berdasarkan solusi tersebut dengan yang serupa dari vendor lain, biayanya dapat dianggap rendah.
Topologi untuk menghubungkan server aplikasi dan Semua node array Flash akan terlihat seperti ini:
Saat merencanakan topologi, Anda juga sangat disarankan untuk menduplikasi switch manajemen dan interkoneksi server.
Selanjutnya, kita akan berbicara tentang menghubungkan melalui Fibre Channel. Dalam hal menggunakan iSCSI, semuanya akan sama, disesuaikan untuk jenis switch yang digunakan dan pengaturan array yang sedikit berbeda.
Pekerjaan persiapan pada array
Perangkat keras dan lunak bekasSpesifikasi Server dan Switch
| Komponen | Deskripsi |
|---|
| Oracle Database 11g server | Dua |
| Sistem operasi server | Oracle Linux |
| Versi database Oracle | 11g (RAC) |
| Prosesor per server | Dua 16 core Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz |
| Memori fisik per server | 128GB |
| Jaringan fc | 16Gb / s FC dengan multipathing |
| FC HBA | Emulex Lpe-16002B |
| Port 1GbE publik khusus untuk manajemen cluster | Adaptor ethernet Intel rj45 |
| 16Gb / s FC switch | Brokat 6505 |
| Port 10GbE pribadi khusus untuk sinkronisasi data | Intel X520 |
AccelStor NeoSapphhire ™ Semua Spesifikasi Array Flash
| Komponen | Deskripsi |
|---|
| Sistem penyimpanan | Model ketersediaan tinggi NeoSapphire ™: H710 |
| Versi gambar | 4.0.1 |
| Jumlah total drive | 48 |
| Ukuran drive | 1.92TB |
| Jenis drive | SSD |
| Port target FC | Port 16x16Gb (8 per node) |
| Port manajemen | Kabel ethernet 1GbE menghubungkan ke host melalui switch ethernet |
| Port detak jantung | Kabel ethernet 1GbE menghubungkan antara dua simpul penyimpanan |
| Port sinkronisasi data | Kabel InfiniBand 56Gb / s |
Sebelum Anda mulai menggunakan array, Anda harus menginisialisasi itu. Secara default, alamat kontrol kedua node adalah sama (192.168.1.1). Anda perlu menyambungkannya satu per satu dan menetapkan alamat manajemen yang baru (sudah berbeda) dan mengonfigurasi sinkronisasi waktu, setelah itu port Manajemen dapat dihubungkan ke satu jaringan. Setelah itu, node-node tersebut digabungkan menjadi sepasang HA dengan menetapkan subnet ke koneksi Interlink.
Setelah inisialisasi selesai, Anda dapat mengontrol array dari sembarang node.
Selanjutnya, buat volume yang diperlukan dan publikasikan untuk server aplikasi.
Sangat disarankan agar Anda membuat beberapa volume untuk Oracle ASM, karena ini akan meningkatkan jumlah target untuk server, yang pada akhirnya akan meningkatkan kinerja keseluruhan (lebih lanjut tentang antrian di artikel lain).
Konfigurasi tes| Nama volume penyimpanan | Ukuran volume |
|---|
| Data01 | 200GB |
| Data02 | 200GB |
| Data03 | 200GB |
| Data04 | 200GB |
| Data05 | 200GB |
| Data06 | 200GB |
| Data07 | 200GB |
| Data08 | 200GB |
| Data09 | 200GB |
| Data10 | 200GB |
| Kisi01 | 1GB |
| Kisi02 | 1GB |
| Kisi03 | 1GB |
| Kisi04 | 1GB |
| Kisi05 | 1GB |
| Kisi06 | 1GB |
| Redo01 | 100GB |
| Ulangi02 | 100GB |
| Ulang03 | 100GB |
| Ulang04 | 100GB |
| Ulangi05 | 100GB |
| Ulang06 | 100GB |
| Ulang07 | 100GB |
| Ulangi08 | 100GB |
| Ulang09 | 100GB |
| Ulang 10 | 100GB |
Beberapa penjelasan tentang mode operasi array dan proses yang terjadi dalam situasi darurat
Setiap dataset simpul memiliki parameter "nomor versi". Setelah inisialisasi awal, itu sama dan sama dengan 1. Jika karena alasan tertentu nomor versi berbeda, maka selalu ada sinkronisasi data dari versi yang lebih lama ke versi yang lebih muda, setelah itu nomor tersebut disejajarkan dengan versi yang lebih muda, mis. ini berarti bahwa salinannya identik. Alasan mengapa versi dapat bervariasi:
- Reboot terjadwal dari salah satu node
- Kecelakaan di salah satu node karena shutdown mendadak (listrik, panas berlebih, dll.).
- Koneksi InfiniBand rusak dengan ketidakmampuan untuk melakukan sinkronisasi
- Gangguan pada salah satu node karena korupsi data. Ini akan membutuhkan pembuatan grup HA baru dan sinkronisasi lengkap set data.
Bagaimanapun, simpul yang tersisa online meningkatkan nomor versinya satu, sehingga setelah tersambung kembali dengan pasangan, menyinkronkan kumpulan datanya.
Jika koneksi terputus melalui tautan Ethernet, maka Heartbeat sementara beralih ke InfiniBand dan kembali dalam 10 detik ketika dipulihkan.
Konfigurasi Host
Untuk memastikan toleransi kesalahan dan meningkatkan kinerja, Anda harus mengaktifkan dukungan MPIO untuk array. Untuk melakukan ini, tambahkan baris ke file /etc/multipath.conf, lalu muat ulang layanan multipath
Teks tersembunyiperangkat {
perangkat {
vendor "AStor"
path_grouping_policy "group_by_prio"
path_selector "panjang antrian 0"
path_checker "tur"
fitur "0"
hardware_handler "0"
prio "const"
segera failback
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
}
}
Selanjutnya, agar ASM dapat bekerja dengan MPIO melalui ASMLib, Anda perlu memodifikasi file / etc / sysconfig / oracleasm dan kemudian jalankan /etc/init.d/oracleasm scandisks
Teks tersembunyi# ORACLEASM_SCANORDER: Pola yang cocok untuk memesan pemindaian disk
ORACLEASM_SCANORDER = "dm"
# ORACLEASM_SCANEXCLUDE: Mencocokkan pola untuk mengeluarkan disk dari pemindaian
ORACLEASM_SCANEXCLUDE = "sd"
Catatan
Jika Anda tidak ingin menggunakan ASMLib, Anda dapat menggunakan aturan UDEV, yang merupakan dasar untuk ASMLib.
Dimulai dengan versi 12.1.0.2 Oracle Database, opsi tersedia untuk instalasi sebagai bagian dari perangkat lunak ASMFD.
Pastikan untuk memastikan bahwa disk yang dibuat untuk Oracle ASM sejajar dengan ukuran blok tempat array bekerja secara fisik (4K). Jika tidak, masalah kinerja dapat terjadi. Karena itu, Anda harus membuat volume dengan parameter yang sesuai:
berpisah / dev / mapper / nama perangkat mklabel gpt mkpart primer 2048s 100% menyelaraskan-periksa optimal 1
Distribusi database pada volume yang dibuat untuk konfigurasi pengujian kami
| Nama volume penyimpanan | Ukuran volume | Pemetaan Volume LUNs | Detail Perangkat Volume ASM | Ukuran Unit Alokasi |
|---|
| Data01 | 200GB | Petakan semua volume penyimpanan ke sistem penyimpanan semua port data | Redundansi: normal
Nama: DGDATA
Tujuan: File data
| 4MB |
| Data02 | 200GB |
| Data03 | 200GB |
| Data04 | 200GB |
| Data05 | 200GB |
| Data06 | 200GB |
| Data07 | 200GB |
| Data08 | 200GB |
| Data09 | 200GB |
| Data10 | 200GB |
| Kisi01 | 1GB | Redundansi: normal
Nama: DGGRID1
Tujuan: Kotak: CRS dan Voting
| 4MB |
| Kisi02 | 1GB |
| Kisi03 | 1GB |
| Kisi04 | 1GB | Redundansi: normal
Nama: DGGRID2
Tujuan: Kotak: CRS dan Voting
| 4MB |
| Kisi05 | 1GB |
| Kisi06 | 1GB |
| Redo01 | 100GB | Redundansi: normal
Nama: DGREDO1
Tujuan: Mengulang log utas 1
| 4MB |
| Ulangi02 | 100GB |
| Ulang03 | 100GB |
| Ulang04 | 100GB |
| Ulangi05 | 100GB |
| Ulang06 | 100GB | Redundansi: normal
Nama: DGREDO2
Tujuan: Mengulang log utas 2
| 4MB |
| Ulang07 | 100GB |
| Ulangi08 | 100GB |
| Ulang09 | 100GB |
| Ulang 10 | 100GB |
Pengaturan basis data- Ukuran blok = 8K
- Swap space = 16GB
- Nonaktifkan AMM (Manajemen Memori Otomatis)
- Nonaktifkan Halaman Besar Transparan
Pengaturan lainnya# 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 # jangan atur ini jika Anda menggunakan Linux x86
✓ vm.vfs_cache_pressure = 200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ jaringan lunak nproc 2047
✓ jaringan keras nproc 16384
✓ kisi lunak nofile 1024
✓ jaringan keras nofile 65536
✓ tumpukan soft grid 10240
✓ jaringan hard stack 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ oracle hard nofile 65536
✓ tumpukan lunak oracle 10240
✓ stack keras oracle 32768
✓ memlock lunak 120795954
✓ memlock keras 120795954
sqlplus “/ as sysdba”
ubah proses set sistem = 2000 scope = spfile;
ubah set sistem open_cursors = 2000 scope = spfile;
ubah set sistem session_cached_cursors = 300 scope = spfile;
ubah set sistem db_files = 8192 scope = spfile;
Tes toleransi kesalahan
Untuk tujuan demonstrasi, HammerDB digunakan untuk meniru beban OLTP. Konfigurasi HammerDB:
| Jumlah Gudang | 256 |
| Total Transaksi per Pengguna | 1000000000000 |
| Pengguna virtual | 256 |
Hasilnya, indikator TPM 2.1M diperoleh, yang jauh dari batas kinerja array H710 , tetapi ini adalah "langit-langit" untuk konfigurasi perangkat keras server saat ini (terutama karena prosesor) dan jumlahnya. Tujuan dari tes ini adalah untuk menunjukkan toleransi kesalahan dari solusi secara keseluruhan, dan bukan untuk mencapai kinerja maksimum. Oleh karena itu, kami hanya akan membangun di atas angka ini.
Tes untuk kegagalan salah satu node
Host kehilangan beberapa jalur ke toko, terus bekerja melalui yang tersisa dengan simpul kedua. Kinerja turun selama beberapa detik karena restrukturisasi jalur, dan kemudian kembali normal. Tidak ada gangguan layanan yang terjadi.
Uji kegagalan kabinet dengan semua peralatan
Dalam hal ini, kinerja juga turun selama beberapa detik karena restrukturisasi jalur, dan kemudian kembali ke setengah nilai dari indikator asli. Hasilnya dibelah dua dari yang asli karena pengecualian dari operasi satu server aplikasi. Gangguan layanan juga tidak terjadi.
Jika Anda perlu menerapkan solusi pemulihan bencana Cross-Rack yang toleran terhadap Oracle dengan biaya yang masuk akal dan dengan sedikit upaya penyebaran / administrasi, maka bekerja bersama dengan arsitektur Oracle RAC dan AccelStor Shared-Nothing akan menjadi salah satu pilihan terbaik. Alih-alih Oracle RAC, mungkin ada perangkat lunak lain yang menyediakan untuk clustering, DBMS atau sistem virtualisasi yang sama, misalnya. Prinsip membangun solusi akan tetap sama. Dan skor akhir adalah nol untuk RTO dan RPO.