Saya sedang mempertimbangkan untuk menggunakan pengaturan RAID0 untuk salah satu kluster SQL Server kami. Saya akan menguraikan situasi dan mencari mengapa ini mungkin ide yang buruk. Juga jika seseorang yang pernah menggunakan kasing, kertas putih, atau dokumentasi lain yang bisa Anda tunjukkan pada topik ini, itu akan bagus.
Kami memiliki 3 server di 2 pusat data yang merupakan bagian dari kluster SQL. Mereka semua menjalankan SQL Server di Grup Ketersediaan. Primer memiliki replika duduk tepat di sebelahnya dan yang lain di pusat data lainnya. Mereka menjalankan replikasi sinkron dengan failover otomatis. Semua drive adalah SSD kelas perusahaan. Mereka akan menjalankan SQL Server 2017 atau 2019.
Saya berpikir bahwa akan ada banyak manfaat untuk menjalankannya pada array RAID0 atas metode lain dengan sedikit, jika ada, kelemahan nyata. Satu-satunya negatif yang saya lihat saat ini adalah kurangnya redundansi pada server utama, sehingga gagal meningkat. Sebagai pro:
Jika drive gagal, alih-alih berjalan dalam keadaan melambat, terdegradasi hingga seseorang menerima pemberitahuan dan bertindak secara manual di atasnya, server akan segera gagal ke sekunder yang mempertahankan kemampuan operasional penuh. Ini akan memiliki manfaat tambahan dengan memberi tahu kami tentang kegagalan, sehingga kami dapat menyelidiki penyebabnya lebih cepat.
Ini mengurangi kemungkinan kegagalan keseluruhan per kapasitas TB. Karena kita tidak memerlukan paritas atau mirror drive, kami mengurangi jumlah drive per array. Dengan drive yang lebih sedikit, kemungkinan kegagalan drive lebih sedikit.
Itu lebih murah. Membutuhkan lebih sedikit drive untuk kapasitas yang diperlukan jelas lebih murah.
Saya tahu ini bukan pemikiran bisnis konvensional, tetapi apakah ada sesuatu yang tidak saya pertimbangkan? Saya suka masukan apa pun baik pro atau kontra.
Saya tidak mencoba melakukan ini untuk mendapatkan kinerja permintaan, meskipun jika ada yang bermakna jangan ragu untuk menunjukkannya. Kekhawatiran utama saya adalah gagal untuk mempertimbangkan atau mengatasi masalah keandalan atau redundansi yang belum saya pikirkan.
OS berada di drive cermin terpisah, sehingga server itu sendiri harus tetap terjaga. Salah satu drive tersebut dapat diganti dan dicerminkan lagi. Ini kecil dan tidak ada file database selain sistem DB di dalamnya. Saya tidak bisa membayangkannya butuh lebih dari beberapa menit. Jika salah satu array data gagal, kami mengganti drive, membangun kembali array, mengembalikan dan menyinkronkan kembali dengan AG. Dalam pengalaman pribadi saya, memulihkan jauh lebih cepat daripada membangun kembali drive RAID5. Saya belum pernah mengalami kegagalan RAID1, jadi saya tidak tahu apakah pembangunan kembali itu akan lebih cepat atau tidak. Pemulihan akan datang dari cadangan dan bergulir ke depan untuk mencocokkan primer, sehingga peningkatan beban pada server primer harus sangat minimal hanya menyinkronkan beberapa menit terakhir log dengan replika yang dipulihkan.
sumber
Jawaban:
Ada satu aspek yang sangat penting yang menurut saya tidak ada dalam penilaian Anda:
Bagaimana Anda berencana untuk pulih?
Ketika raid5 kehilangan drive, itu akan berjalan dalam kondisi terdegradasi sampai pulih secara otomatis. (Setidaknya jika Anda memiliki cadangan panas di tangan.)
Ketika raid0 kehilangan drive, itu tidak akan pernah bisa pulih sama sekali. Ini berarti Anda telah kehilangan redundansi, dan untuk memulihkannya, Anda perlu membangun kembali raid0 Anda, dan menyalin semua data (bukan hanya data pada drive yang rusak) kembali dari sekunder yang sekarang di bawah beban produksi. Artinya, alih-alih array raid5 terdegradasi tunggal, sekarang seluruh pengaturan produksi Anda yang mendapatkan kinerja yang baik.
Jika raid5 (atau raid6) penalti kinerja negara yang terdegradasi bukanlah sesuatu yang dapat Anda atasi, Anda mungkin harus melakukan raid 1 + 0 sebagai gantinya . Ya, biayanya lebih tinggi, tetapi harga disk menjadi seperti itu, itu akan menghabiskan uang dengan baik.
Mungkin "secara aktif memonitor keadaan raid5, dan mentransfer beban dari primary ketika drive gagal" adalah solusi yang memberi Anda sebagian besar manfaat tanpa kekurangan? (Terlepas dari kehilangan faktor kesejukan dari menjalankan tanpa redundansi lokal, tentu saja.) Jika pemulihan drive raid5 Anda memakan waktu lebih lama daripada sinkronisasi data database lengkap, baik perangkat lunak serangan Anda bertindak aneh, atau Anda memiliki disk yang sangat besar, Saya akan berpikir.
sumber
Kegagalan drive harus dipertimbangkan di sini.
Bayangkan sejenak bahwa drive kami pada hari tertentu memiliki tingkat kegagalan 1/1000. Bayangkan kemudian bahwa kita memiliki 20 drive di masing-masing dari 3 array kita.
Oleh karena itu peluang satu drive gagal dalam array adalah 20/1000 = 1/50. Kemungkinan dua drive gagal dalam array yang sama adalah sesuatu yang mendekati 20/1000 * 20/1000 / 2 = 200/1000000 = 1/5000. Jadi dengan beralih dari RAID 0 ke RAID 5, kita sudah cenderung membunuh salah satu dari array kita.
Jadi kita bisa mengambil ini lebih jauh - jika kemungkinan array gagal pada hari adalah 1/50, maka kemungkinan dua array gagal dalam sehari adalah 1 / (50 * 50) = 1/2500. Peluang dua array RAID 0 yang identik gagal dua kali lipat dari satu array RAID 5 yang gagal, dengan asumsi set disk yang sama. Peningkatan eksponensial dalam kemungkinan kegagalan ini harus Anda perhatikan, karena secara besar-besaran meningkatkan peluang lebih dari satu array gagal sekaligus.
Karena cakram-cakram ini cenderung memiliki masa pakai yang lama, Anda mungkin dapat menjalankan angka-angka seperti di atas dan secara langsung melihat apa dampaknya terhadap keandalan - jika Anda dapat memposting spesifikasi penggerak, saya dapat menambahkan perhitungan itu ke kiriman ini. Apakah risikonya dapat diterima atau tidak, apakah organisasi Anda yang akan memutuskan.
Hal lain yang perlu diperhatikan adalah kemungkinan kerusakan drive dapat ditingkatkan dengan memanfaatkan SSD yang diproduksi dalam batch yang sama (pabrik yang sama, waktu yang sama). Jika Anda tidak berhati-hati, Anda bisa berakhir dengan semua 3 node turun karena masalah ini.
Penafian: Perhitungan di atas telah disederhanakan - mereka masih relatif akurat.
sumber
Ini adalah konfigurasi yang cukup umum ketika menjalankan AG dengan drive penyimpanan internal / terpasang langsung. Terutama dengan NVMe atau perangkat penyimpanan flash berbasis PCI lainnya.
Ini sama dengan mengobati kegagalan drive seperti kegagalan server. Dengan sejumlah kecil solid state drive Anda tidak benar-benar memiliki MTBF yang jauh lebih rendah untuk drive daripada yang Anda lakukan untuk komponen solid-state server, dan jadi Anda cukup memperlakukan setiap drive sebagai titik kegagalan untuk server, dan ganti / bangun kembali server jika terjadi kegagalan drive.
sumber
Saya tertarik dengan apa yang ingin Anda capai? Anda menyebut diri Anda bahwa Anda tidak berusaha mendapatkan keuntungan kinerja dari pengaturan ini, jadi keuntungan apa yang Anda coba dapatkan?
Catatan tentang masalah kinerja: jika Anda menjalankan SSD Kelas Perusahaan, apakah perhitungan RAID Anda benar-benar menjadi hambatan yang Anda perlukan untuk memperbaikinya?
Mengambil 3 pro Anda, saya pikir Anda tidak cukup memikirkannya:
Apakah SQL failover langsung? Apa yang akan menyebabkan kegagalan untuk memicu secara otomatis? Apakah server akan mengambil drive offline segera setelah seseorang menabraknya? Bagaimana jika ini hanya bad sector pada satu disk? Jika SQL tidak mengenai bad sector, apakah akan gagal? Saya tidak 100% yakin akan hal itu.
Apakah ini mengurangi kemungkinan kegagalan secara keseluruhan per kapasitas TB? Pemikiran Anda tampaknya semakin sedikit disk berarti lebih sedikit poin kegagalan, tapi saya pikir itu tidak benar. Peluang dari 1 disk gagal tetap sama jika Anda memiliki 1 disk atau 10 disk (atau 100 disk), tetapi dengan RAID 0 itu juga berarti itu adalah kegagalan katastropik.
Apakah satu SSD tambahan akan memakan biaya terlalu banyak bagi Anda untuk mendapatkan RAID5? Saya mengerti bagaimana RAID1 ATAU 1 + 0 dapat menghancurkan anggaran, tetapi 1 disk tambahan?
Tanpa redundansi, jika disk gagal dan RAID menjadi offline, simpul itu akan offline sampai Anda membangun kembali RAID dan mengembalikan semua database Anda dari awal. Proses apa yang akan Anda ambil untuk mewujudkannya? Anda tidak dapat menghapus database dari Grup Ketersediaan karena itu akan menghentikan replikasi ke DR, tetapi jika Anda tidak mengambil tindakan maka dua server lain tidak akan dapat memotong file log mereka. Apakah itu oke? Apa yang terjadi jika gagal pada Jumat malam di akhir pekan yang panjang? Apakah itu masih baik-baik saja? Bisakah sekunder Anda mengatasi jumlah data yang menumpuk?
Pertanyaan terakhir saya adalah sekitar waktu pembangunan kembali yang Anda sebutkan akan lebih cepat. Apakah Anda 100% yakin itu akan lebih cepat? Seberapa cepat?
Pengaturan server Brent Ozar masih menjadi panduan saya untuk mengatur instance SQL baru. Poin pertama dalam panduan ini adalah memvalidasi bahwa Anda tidak menggunakan RAID0 untuk semua drive.
==== UPDATE ====
Satu pemikiran tambahan, apa yang terjadi ketika server sekunder Anda tidak sinkron dengan server utama Anda? Bahkan dengan Synchronous Replication, secondaries Anda masih dapat secara otomatis kembali ke async, dan sekali itu Anda kehilangan kemampuan untuk auto-failover karena setiap failover akan mengakibatkan hilangnya data. Beberapa contoh kapan ini bisa terjadi:
Mereka adalah kasus tepi, tetapi bisa menjadi bencana tergantung pada apa yang hilang selama masa itu.
sumber