Apa LVM yang lebih baik pada RAID atau RAID pada LVM?


42

Saat ini saya memiliki LVM pada perangkat lunak RAID, tetapi saya ingin bertanya kepada Anda apa yang menurut Anda solusi yang lebih baik, mungkin pro dan kontra?

Sunting: Ini tentang serangan perangkat lunak pada lvm atau lvm pada serangan perangkat lunak. Saya tahu daripada serangan perangkat keras lebih baik jika kita berpikir tentang kinerja.


9
lvm saat raid. serangan pada LVM adalah pekerjaan iblis. - tidak ada alasan.
Sirex

yah, hw raid tidak perlu lebih baik dari sw raid. Itu tergantung pada beberapa faktor. Jika itu bukan yang high-end biasanya lebih buruk dari linux raid (alias mdadm). Mengenai manajemen, stabilitas dan kinerja.
cstamas

@cstamas: Saya setuju, karena yang murah biasanya sebenarnya razia perangkat lunak.
Ency

Jawaban:


45

Setup Anda saat ini seperti ini:

| / | /var | /usr | /home  |
 --------------------------
|       LVM Volume         |
 --------------------------
|       RAID Volume        |
 --------------------------
| Disk 1 | Disk 2 | Disk 3 | 

Ini adalah pengaturan yang jauh lebih sederhana dengan lebih banyak fleksibilitas. Anda dapat menggunakan semua disk dalam volume dan slice RAID dan memotongnya dengan cara apa pun yang Anda suka dengan LVM. Cara lain bahkan tidak layak untuk dipikirkan - sangat rumit dan Anda kehilangan manfaat LVM di tingkat filesystem.

Jika Anda mencoba RAID LVM volume, Anda akan dibiarkan dengan perangkat normal tanpa manfaat volume LVM (mis. Menumbuhkan sistem file, dll.)


4

Ini adalah pertanyaan lama, teknologi telah maju dan pengaturan yang disarankan adalah menggunakan dukungan RAID bawaan dari LVM (lihat di sini untuk pengaturan https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/ Logical_Volume_Manager_Administration / raid_volumes.html ), terutama jika Anda menggunakan SSD. Red Hat tidak merekomendasikan penggunaan RAID 1/5/6/10 dengan SSD karena mdadm akan menulis partisi lengkap untuk memastikan berfungsinya checksum. Hal ini dapat menyebabkan degradasi SSD lebih cepat, seperti yang dinyatakan di sini https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Storage_Administration_Guide/index.html#ssddloy


1
PENGGUNA irwinr menyarankan: Diedit 4 Februari 2018: Saya tidak dapat menemukan referensi apa pun ke RedHat merekomendasikan LVM RAID melalui mdadm RAID atau peringatan untuk menggunakan RAID dengan SSD. Bahkan tag #ssddeploy bahkan tidak muncul di HTML untuk halaman yang terhubung ke-2. ---- Terima kasih irwinr, sepertinya RedHat memperbarui dokumentasi mereka. Masih mdadm menyinkronkan seluruh partisi, sementara LVM "pintar" tidak, karena itu menulis disk yang tidak perlu, maka umur yang lebih lama untuk SSD Anda.
Pozzo-Balbi

Hanya sebuah pemikiran: meskipun Anda memiliki ide dasar dalam komentar, Anda mungkin ingin mengeditnya menjadi jawaban mungkin bahkan dengan penafian; artinya mengatakan bahwa Anda harus memiliki semacam peringatan yang mengatakan dalam keadaan apa Anda menyarankan metode Anda.
Pryftan

3

Pengaturan Anda saat ini baik-baik saja. Ini adalah cara yang disarankan untuk melakukannya.

Raid berhubungan dengan menjaga bit tetap aman / berlebihan / cepat / apa pun dan LVM membantu Anda menyajikannya dengan cara yang mudah digunakan.


2

memiliki serangan perangkat keras dan Anda dapat memiliki lvm di atas - kombinasi terbaik.


Solusi perusahaan yang bagus, tetapi saran yang buruk untuk homelab! Anda memerlukan kontrak layanan dengan pemasok perangkat keras atau Anda berada dalam masalah besar jika perangkat keras RAID Anda memiliki kesalahan - Anda perlu mencari perangkat keras berpemilik yang kompatibel untuk menggantinya.
Gareth Davidson

0

Saya berasumsi maksud Anda Hardware RAID dengan LVM di Atas, vs LVM dan RAID Perangkat Lunak di atas LVM. Jika demikian, saya selalu menyarankan untuk memilih RAID berbasis perangkat keras terlebih dahulu. RAID Perangkat Lunak hanya itu, sementara overhead kecil, kinerja perangkat keras RAID akan lebih baik 9 dari 10 kali. Tentu saja, metodologinya akan sangat tergantung pada tujuan akhir Anda. Apa yang ingin Anda capai (kinerja, perlindungan, dll., Dll.)


1
"LVM dan serangan perangkat lunak di atas LVM" - Nah, itu pengaturan yang eksotis!
Sirex

-3

Saya pikir masuk akal untuk menggunakan RAID lebih dari LVM jika Anda ingin membagi disk Anda antara volume RAID 0 dan volume RAID 1.

Dengan ini, Anda tidak dapat merealokasi ruang antara RAID0 dan RAID1

| / | /var | /usr | /home  |
 --------------------------
|       LVM Volume 2       |
 --------------------------
|    RAID 0   |   Raid 1   |
 --------------------------
| Disk 1 | Disk 2 | Disk 3 |

Dengan ini kamu bisa

| / | /var | /usr | /home  |
 --------------------------
|       LVM Volume 2       |
 --------------------------
|    RAID 0   |   Raid 1   |
 --------------------------
|       LVM Volume 1       |
 --------------------------
| Disk 1 | Disk 2 | Disk 3 | 

hal baiknya adalah Anda juga masih bisa memindahkan volume logis Volume 2 LVM antara raid 0 et dan raid 1 volume, dengan menggunakan perintah pvmove

yang buruk adalah bahwa pengaturannya rumit. Akan lebih baik jika LVM memiliki integrasi yang lebih baik dari fitur serangan perangkat lunak.


6
Saya tidak tahu cukup barang penyimpanan untuk mengatakan mengapa ini adalah ide yang buruk, tapi itu membuat saya cukup gelisah dan perasaan takut yang berbeda.
Scott Pack

2
Jika "RAID" di sini adalah RAID 1/5 / bentuk lain dari redundant RAID, Anda tidak akan mendapatkan redundansi apa pun. Jika ada disk di bawah LVM Volume 1 gagal, Anda akan kehilangan kedua volume RAID, karena volume LVM akan mati (OK, Anda bisa memaksanya online masih dengan asumsi itu tidak striping, tetapi sejumlah besar data sekarang akan hilang, dan ontop RAID dari volume LVM yang gagal mungkin tidak akan dapat pulih ...). Saya tidak tahu mengapa Anda melakukan ini, tetapi tidak.
BSchlinker

2
Scott, tampaknya ketakutanmu dibenarkan. Saya menggunakan mdadm RAID melalui LVM2 dan membuat saya kesulitan - serverfault.com/questions/826479/… - biarkan pengalaman saya menjadi peringatan bagi orang lain.
Ghostrider
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.