RAID0 bukannya RAID1 atau 5, apakah ini gila?


14

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:

  1. 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.

  2. 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.

  3. 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.


1
Diskusi tentang pertanyaan ini telah dipindahkan ke obrolan .
Paul White 9

Jawaban:


19

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.


16

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.


Percakapan pada jawaban ini telah dipindahkan ke obrolan .
Paul White 9

13

Saya berpikir bahwa akan ada banyak manfaat untuk menjalankannya pada array RAID0 atas metode lain dengan sedikit, jika ada, kelemahan nyata.

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.


2

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:

  1. 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.

  2. 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.

  3. 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:

  1. Membangun kembali indeks yang sangat besar - replikasi mungkin tertinggal pada salah satu atau kedua dari yang kedua
  2. Kegagalan disk pada RAID0 saat menambal sekunder. Server yang Anda tambal mungkin tidak dapat kembali online karena yang utama sedang offline.

Mereka adalah kasus tepi, tetapi bisa menjadi bencana tergantung pada apa yang hilang selama masa itu.


Menambah poin Anda pada # 3, jika biaya disk tambahan (atau tiga) adalah apa yang membuat atau merusak anggaran, lalu dari mana uang akan datang untuk menggantinya ketika satu disk gagal?
CVn

@ Greg Fakta bahwa saya mungkin tidak memikirkan semuanya adalah mengapa saya menanyakan pertanyaan ini. Saya kira saya akan mengatakan saya melihat di mana saya dapat meningkatkan efisiensi secara keseluruhan. Untuk menjawab pertanyaan Anda: 1. Ya. Kegagalan array akan segera menyebabkan AG gagal ke node yang berbeda. Sektor buruk bergantung pada apakah itu kesalahan bit yang dapat dipulihkan atau tidak, tetapi ini akan menyebabkan kegagalan apakah disk itu dalam bentuk RAID apa pun atau tidak. 2. Lebih sedikit disk akan mengurangi kemungkinan kegagalan dalam array. RAID0 akan meningkatkan kemungkinan kegagalan OF array. 3. Tidak, tabungan adalah uang.
zsqlman

@ Greg, Baik pertanyaan tindak lanjut dan beberapa saya belum sepenuhnya menyempurnakan. Ada banyak lapisan redundansi dengan server menjadi tiga. Memulihkan semua basis data dapat dengan mudah dituliskan. Jika sebuah node gagal, kami akan menendang replika itu dari AG menghapus masalah backlog Tlog dan bahkan jika kami tidak menghapus node, kami memiliki banyak ruang untuk menampung beberapa hari pertumbuhan log. Mengenai waktu pemulihan, saya hanya memiliki satu titik data dan tidak memiliki lebih banyak perangkat keras cadangan untuk diuji. Kami hanya memiliki 1 kegagalan RAID dan butuh 2+ hari untuk pulih dan kami dapat mengembalikannya dalam 8 jam.
zsqlman

@zsqlman - Saya telah menambahkan waktu ekstra saat Anda mungkin kehilangan data karena Anda tidak memiliki RAID. Juga, logika yang Anda terapkan untuk mengurangi kegagalan saya pikir masih cacat. Peluang satu disk gagal dengan lebih sedikit disk di RAID sama dengan 1 disk gagal dengan redundansi di RAID. Mengurangi jumlah disk tidak mengurangi risiko kegagalan satu disk - setiap disk mungkin juga gagal seperti disk lain.
Greg

Anda benar bahwa setiap disk memiliki peluang kegagalan yang sama. Lebih sedikit disk berarti lebih sedikit kemungkinan kegagalan.
zsqlman
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.