Sejumlah besar aplikasi Perusahaan dan sistem virtualisasi memiliki mekanismenya sendiri untuk membangun solusi yang toleran terhadap kesalahan. Secara khusus, Oracle RAC (Oracle Real Application Cluster) adalah sekelompok dua atau lebih server database Oracle yang bekerja bersama untuk menyeimbangkan beban dan memberikan toleransi kesalahan di tingkat server/aplikasi. Untuk bekerja dalam mode ini, Anda memerlukan penyimpanan bersama, yang biasanya berupa sistem penyimpanan.
Seperti yang telah kita bahas di salah satu artikel kami , sistem penyimpanan itu sendiri, meskipun terdapat komponen duplikat (termasuk pengontrol), masih memiliki titik kegagalan - terutama dalam bentuk kumpulan data tunggal. Oleh karena itu, untuk membangun solusi Oracle dengan persyaratan keandalan yang meningkat, skema “N server - satu sistem penyimpanan” perlu diperumit.
Pertama, tentu saja, kita perlu memutuskan risiko apa yang ingin kita 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 dalam salah satu artikel berikut. Di sini kita akan melihat apa yang disebut solusi pemulihan bencana Cross-Rack, ketika perlindungan dibangun di tingkat kabinet server. Lemari itu sendiri dapat ditempatkan di ruangan yang sama atau di ruangan yang berbeda, tetapi biasanya di dalam gedung yang sama.
Lemari ini harus berisi seluruh rangkaian peralatan dan perangkat lunak yang diperlukan yang memungkinkan database Oracle berfungsi terlepas dari kondisi "tetangganya". Dengan kata lain, dengan menggunakan solusi pemulihan bencana Cross-Rack, kami menghilangkan risiko kegagalan:
- Server Aplikasi Oracle
- Sistem penyimpanan
- Peralihan sistem
- Kegagalan total semua peralatan di kabinet:
- Masalah listrik
- Kegagalan sistem pendingin
- Faktor eksternal (manusia, alam, dll)
Duplikasi server Oracle menyiratkan prinsip operasi Oracle RAC dan diimplementasikan melalui sebuah aplikasi. Duplikasi fasilitas switching juga tidak menjadi masalah. Namun dengan duplikasi sistem penyimpanan, semuanya tidak sesederhana itu.
Pilihan paling sederhana adalah replikasi data dari sistem penyimpanan utama ke sistem cadangan. Sinkron atau asinkron, tergantung kemampuan sistem penyimpanan. Dengan replikasi asinkron, pertanyaan yang segera muncul adalah memastikan konsistensi data dalam kaitannya dengan Oracle. Tetapi bahkan jika ada integrasi perangkat lunak dengan aplikasi, jika terjadi kegagalan pada sistem penyimpanan utama, intervensi manual oleh administrator akan diperlukan untuk mengalihkan cluster ke penyimpanan cadangan.
Pilihan yang lebih kompleks adalah “virtualizer” penyimpanan perangkat lunak dan/atau perangkat keras yang akan menghilangkan masalah konsistensi dan intervensi manual. Namun kerumitan penerapan dan administrasi selanjutnya, serta biaya yang sangat mahal dari solusi semacam itu, membuat banyak orang takut.
Solusi AccelStor NeoSapphire™ All Flash array sempurna untuk skenario seperti pemulihan bencana Cross-Rack menggunakan arsitektur Shared-Nothing. Model ini adalah sistem penyimpanan dua node yang menggunakan teknologi eksklusif FlexiRemap® untuk bekerja dengan flash drive. Terimakasih untuk NeoSapphire™ H710 mampu memberikan kinerja hingga 600K IOPS@4K random write dan 1M+ IOPS@4K random read, yang tidak dapat dicapai bila menggunakan sistem penyimpanan berbasis RAID klasik.
Namun fitur utama NeoSapphire™ H710 adalah eksekusi dua node dalam bentuk kasus terpisah, yang masing-masing memiliki salinan datanya sendiri. Sinkronisasi node dilakukan melalui antarmuka InfiniBand eksternal. Berkat arsitektur ini, dimungkinkan untuk mendistribusikan node ke lokasi berbeda pada jarak hingga 100m, sehingga memberikan solusi pemulihan bencana Cross-Rack. Kedua node beroperasi sepenuhnya secara sinkron. Dari sisi host, H710 tampak seperti sistem penyimpanan pengontrol ganda biasa. Oleh karena itu, tidak perlu melakukan opsi perangkat lunak atau perangkat keras tambahan atau pengaturan yang rumit.
Jika kita membandingkan semua solusi pemulihan bencana Cross-Rack yang dijelaskan di atas, maka opsi dari AccelStor terlihat menonjol dari yang lain:
AccelStor NeoSapphire™ Tidak Membagikan Arsitektur Apa pun
Sistem penyimpanan “virtualizer” perangkat lunak atau perangkat keras
Solusi berbasis replikasi
Ketersediaan
Kegagalan server
Tanpa Downtime
Tanpa Downtime
Tanpa Downtime
Beralih kegagalan
Tanpa Downtime
Tanpa Downtime
Tanpa Downtime
Kegagalan sistem penyimpanan
Tanpa Downtime
Tanpa Downtime
Penghentian
Kegagalan seluruh kabinet
Tanpa Downtime
Tanpa Downtime
Penghentian
Biaya dan kompleksitas
Biaya solusi
Rendah*
Tinggi
Tinggi
Kompleksitas penerapan
Rendah
Tinggi
Tinggi
*AccelStor NeoSapphire™ masih merupakan rangkaian All Flash, yang menurut definisinya tidak memerlukan biaya “3 kopeck”, terutama karena memiliki cadangan kapasitas ganda. Namun, ketika membandingkan biaya akhir dari suatu solusi berdasarkan solusi tersebut dengan solusi serupa dari vendor lain, biaya tersebut dapat dianggap rendah.
Topologi untuk menghubungkan server aplikasi dan node Semua array Flash akan terlihat seperti ini:
Saat merencanakan topologi, sangat disarankan juga untuk menduplikasi sakelar manajemen dan interkoneksi server.
Di sini dan selanjutnya kita akan berbicara tentang koneksi melalui Fibre Channel. Jika menggunakan iSCSI, semuanya akan sama, disesuaikan dengan jenis switch yang digunakan dan pengaturan arraynya sedikit berbeda.
Pekerjaan persiapan pada array
Peralatan dan perangkat lunak yang digunakan
Spesifikasi Server dan Switch
Komponen
Описание
Server Oracle Basis Data 11g
Dua
Sistem operasi server
Oracle Linux
Versi basis data Oracle
11g (RAC)
Prosesor per server
Dua 16 core Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
Memori fisik per server
128GB
jaringan FC
16 Gb/s FC dengan multipati
FC HBA
Emulex Lpe-16002B
Port 1GbE publik khusus untuk manajemen cluster
Adaptor ethernet Intel RJ45
Sakelar FC 16 Gb/dtk
Brokat 6505
Port 10GbE pribadi khusus untuk sinkronisasi data
Intel X520
AccelStor NeoSapphire™ Semua Spesifikasi Flash Array
Komponen
Описание
Sistem penyimpanan
Model ketersediaan tinggi NeoSapphire™: H710
Versi gambar
4.0.1
Jumlah total drive
48
Ukuran drive
1.92TB
Tipe drive
SSD
Port target FC
16x port 16Gb (8 per node)
Port manajemen
Kabel ethernet 1GbE terhubung ke host melalui switch ethernet
Pelabuhan detak jantung
Kabel ethernet 1GbE menghubungkan antara dua node penyimpanan
Port sinkronisasi data
Kabel InfiniBand 56 Gb/dtk
Sebelum Anda dapat menggunakan array, Anda harus menginisialisasinya. Secara default, alamat kontrol kedua node adalah sama (192.168.1.1). Anda perlu menyambungkannya satu per satu dan menetapkan alamat manajemen baru (yang sudah berbeda) dan mengatur sinkronisasi waktu, setelah itu port Manajemen dapat dihubungkan ke satu jaringan. Setelah itu, node digabungkan menjadi pasangan HA dengan menetapkan subnet untuk koneksi Interlink.
Setelah inisialisasi selesai, Anda dapat mengelola array dari node mana pun.
Selanjutnya, kami membuat volume yang diperlukan dan mempublikasikannya ke server aplikasi.
Sangat disarankan untuk membuat beberapa volume untuk Oracle ASM karena ini akan meningkatkan jumlah target untuk server, yang pada akhirnya akan meningkatkan kinerja secara keseluruhan (lebih lanjut tentang antrian di volume 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
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Ulangi01
100GB
Ulangi02
100GB
Ulangi03
100GB
Ulangi04
100GB
Ulangi05
100GB
Ulangi06
100GB
Ulangi07
100GB
Ulangi08
100GB
Ulangi09
100GB
Ulangi10
100GB
Beberapa penjelasan tentang mode pengoperasian array dan proses yang terjadi dalam situasi darurat
Kumpulan data setiap node memiliki parameter “nomor versi”. Setelah inisialisasi awal sama dan sama dengan 1. Jika karena alasan tertentu nomor versi berbeda, maka data selalu disinkronkan dari versi lama ke versi lebih muda, setelah itu nomor versi yang lebih muda disejajarkan, yaitu. ini berarti salinannya identik. Alasan mengapa versinya mungkin berbeda:
- Reboot terjadwal dari salah satu node
- Kecelakaan pada salah satu node karena pemadaman mendadak (catu daya, panas berlebih, dll).
- Koneksi InfiniBand hilang karena ketidakmampuan melakukan sinkronisasi
- Kerusakan pada salah satu node karena kerusakan data. Di sini Anda perlu membuat grup HA baru dan menyelesaikan sinkronisasi kumpulan data.
Bagaimanapun, node yang tetap online menambah nomor versinya sebanyak satu untuk menyinkronkan kumpulan datanya setelah koneksi dengan pasangan dipulihkan.
Jika koneksi melalui tautan Ethernet terputus, Heartbeat untuk sementara beralih ke InfiniBand dan kembali lagi dalam waktu 10 detik setelah dipulihkan.
Menyiapkan host
Untuk memastikan toleransi kesalahan dan meningkatkan kinerja, Anda harus mengaktifkan dukungan MPIO untuk array. Untuk melakukannya, Anda perlu menambahkan baris ke file /etc/multipath.conf, lalu memulai ulang layanan multipath
Teks tersembunyiperangkat {
perangkat {
penjual "AStor"
path_grouping_policy "grup_menurut_prio"
path_selector "panjang antrian 0"
path_checker "tur"
fitur "0"
perangkat keras_handler "0"
sebelumnya "konstan"
failback segera
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names ya
deteksi_prio ya
rr_min_io_rq 1
no_path_coba lagi 0
}
}
Selanjutnya agar ASM dapat bekerja dengan MPIO melalui ASMLib, Anda perlu mengubah file /etc/sysconfig/Oracleasm lalu jalankan /etc/init.d/Oracleasm scandisks
Teks tersembunyi
# ORACLEASM_SCANORDER: Mencocokkan pola untuk memesan pemindaian disk
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Mencocokkan pola untuk mengecualikan disk dari pemindaian
ORACLEASM_SCANEXCLUDE="sd"
Catatan
Jika Anda tidak ingin menggunakan ASMLib, Anda dapat menggunakan aturan UDEV yang menjadi dasar ASMLib.
Dimulai dengan Oracle Database versi 12.1.0.2, opsi tersedia untuk instalasi sebagai bagian dari perangkat lunak ASMFD.
Sangat penting untuk memastikan bahwa disk yang dibuat untuk Oracle ASM selaras dengan ukuran blok yang dioperasikan secara fisik oleh array (4K). Jika tidak, masalah kinerja mungkin terjadi. Oleh karena itu, perlu dibuat volume dengan parameter yang sesuai:
parted /dev/mapper/nama-perangkat mklabel gpt mkpart primer 2048s 100% align-check optimal 1
Distribusi database di seluruh volume yang dibuat untuk konfigurasi pengujian kami
Nama Volume Penyimpanan
Ukuran Volume
Pemetaan volume LUN
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
Grid01
1GB
Redundansi: Normal
Nama : DGGRID1
Tujuan: Grid: CRS dan Voting
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundansi: Normal
Nama : DGGRID2
Tujuan: Grid: CRS dan Voting
4MB
Grid05
1GB
Grid06
1GB
Ulangi01
100GB
Redundansi: Normal
Nama: DGREDO1
Tujuan: Mengulang log thread 1
4MB
Ulangi02
100GB
Ulangi03
100GB
Ulangi04
100GB
Ulangi05
100GB
Ulangi06
100GB
Redundansi: Normal
Nama: DGREDO2
Tujuan: Mengulang log thread 2
4MB
Ulangi07
100GB
Ulangi08
100GB
Ulangi09
100GB
Ulangi10
100GB
Pengaturan Basis Data
- Ukuran blok = 8K
- Ruang pertukaran = 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 setel 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
✓ grid soft nofile 1024
✓ grid keras nofile 65536
✓ tumpukan lunak jaringan 10240
✓ tumpukan keras kisi 32768
✓ Oracle lunak nproc 2047
✓ oracle keras nproc 16384
✓ Oracle lunak nofile 1024
✓ oracle keras nofile 65536
✓ tumpukan lunak Oracle 10240
✓ tumpukan keras oracle 32768
✓ memlock lunak 120795954
✓ memlock keras 120795954
sqlplus “/sebagai sysdba”
mengubah proses set sistem=2000 scope=spfile;
mengubah set sistem open_cursors=2000 scope=spfile;
mengubah set sistem session_cached_cursors=300 scope=spfile;
mengubah set sistem db_files=8192 scope=spfile;
Tes kegagalan
Untuk tujuan demonstrasi, HammerDB digunakan untuk meniru beban OLTP. Konfigurasi HammerDB:
Jumlah Gudang
256
Total Transaksi per Pengguna
1000000000000
Pengguna Virtual
256
Hasilnya adalah TPM 2.1 juta, yang jauh dari batas performa array , tetapi merupakan "batas atas" untuk konfigurasi perangkat keras server saat ini (terutama karena prosesor) dan jumlahnya. Tujuan dari pengujian ini masih untuk menunjukkan toleransi kesalahan solusi secara keseluruhan, dan bukan untuk mencapai kinerja maksimal. Oleh karena itu, kami hanya akan melanjutkan dari angka ini.
Uji kegagalan salah satu node
Host kehilangan sebagian jalur menuju penyimpanan, terus mengerjakan jalur yang tersisa dengan node kedua. Kinerja turun selama beberapa detik karena jalur sedang dibangun kembali, dan kemudian kembali normal. Tidak ada gangguan dalam layanan.
Uji kegagalan kabinet dengan semua peralatan
Dalam hal ini, kinerja juga turun selama beberapa detik karena restrukturisasi jalur, dan kemudian kembali ke setengah nilai aslinya. Hasilnya berkurang setengahnya dari hasil awal karena pengecualian satu server aplikasi dari operasi. Pelayanan juga tidak terganggu.
Jika terdapat kebutuhan untuk mengimplementasikan solusi pemulihan bencana Cross-Rack yang toleran terhadap kesalahan untuk Oracle dengan biaya yang masuk akal dan dengan sedikit upaya penerapan/administrasi, maka Oracle RAC dan arsitektur akan bekerja sama akan menjadi salah satu pilihan terbaik. Selain Oracle RAC, mungkin ada perangkat lunak lain yang menyediakan clustering, DBMS atau sistem virtualisasi yang sama, misalnya. Prinsip membangun solusi akan tetap sama. Dan intinya adalah nol untuk RTO dan RPO.
Sumber: www.habr.com