Apa implikasi kinerja menjalankan VM pada host ZFS?


11

Saya sedang mempertimbangkan migrasi dari ext3 ke ZFS untuk penyimpanan data di host Debian Linux saya, menggunakan ZFS di Linux . Salah satu fitur pembunuh ZFS yang saya inginkan adalah jaminan integritas datanya. Kemampuan untuk menumbuhkan penyimpanan yang sepele karena kebutuhan penyimpanan saya meningkat juga sesuatu yang saya harapkan.

Namun, saya juga menjalankan beberapa VM di host yang sama. (Meskipun secara normal, dalam kasus saya hanya satu VM yang berjalan pada host pada satu waktu.)

Mengingat data checksumming dan perilaku copy-on-write ZFS, bersama dengan fakta bahwa gambar disk VM adalah file yang relatif besar (file gambar disk VM utama saya saat ini duduk di 31 GB), apa implikasi kinerja dalam tamu VM seperti itu sebuah migrasi? Langkah apa yang dapat saya ambil untuk mengurangi kemungkinan dampak kinerja negatif?

Saya dapat hidup dengan lebih sedikit jaminan integritas data pada gambar disk VM jika perlu (saya tidak melakukan sesuatu yang benar-benar kritis di dalam salah satu VM) dan dapat dengan mudah memisahkannya dari sisa sistem file, tetapi akan lebih baik jika saya tidak harus (bahkan secara selektif) mematikan cukup banyak fitur yang paling membuat saya ingin bermigrasi ke sistem file yang berbeda.

Perangkat kerasnya cukup kokoh untuk sistem kelas workstation, tetapi tidak akan menampung banyak server high-end (RAM 32 GB dengan jarang> 10 GB digunakan, CPU 6-core 3,3 GHz, saat ini 2,6 TB dapat digunakan ruang disk sesuai dengan dfdan total sekitar 1,1 TB gratis; bermigrasi ke ZFS kemungkinan akan menambah lebih banyak ruang kosong ) dan saya tidak berencana menjalankan deduplikasi data (karena mengaktifkan dedup tidak akan menambah banyak dalam situasi saya). Rencananya adalah mulai dengan konfigurasi JBOD (jelas dengan cadangan yang baik) tapi saya mungkin akan pindah ke pengaturan mirror dua arah akhirnya jika kondisinya diperlukan.


Juga perlu diingat bahwa ZFS berkinerja lebih baik daripada RAID5 tradisional dalam hal IOPS . RAIDZ menulis berkinerja dengan kecepatan satu disk karena tidak menderita hukuman kinerja I / O yang mengganggu RAID5 / 6 tradisional.
Stefan Lasiewski

1
Terima kasih untuk semua yang telah menjawab wawasan Anda! Saya pasti akan kembali ke pertanyaan ini nanti.
CVn

Komentar Stefan adalah .. yah, itu hanya salah. Kinerja ZFS RAIDZ secara signifikan lebih buruk dari perspektif IOPS (apa yang biasanya Anda memiliki masalah dengan VM) daripada array RAID5 tradisional. Tolong jangan menganggap peningkatan kinerja menulis dengan pindah ke ZFS. Ini jarang terjadi. Keuntungan membaca akan tergantung pada RAM yang tersedia untuk ARC dan ukuran dan delta kerja Anda. Biasanya dengan VM, ZFS ARC akhirnya membantu dengan kinerja membaca keseluruhan dibandingkan dengan alternatif. Menulis biasanya menderita, bahkan di cermin, SELALU dengan raidz.
Nex7

@ Nex7 Bagaimana cara menulis tanpa RAID dari ZFS sama sekali tetapi dengan hanya satu perangkat penyimpanan, yang misalnya disediakan oleh beberapa mdraid? Apakah ZFS melakukan sebanding dengan sistem file lain karena tidak ada barang RAID mewah digunakan?
Thorsten Schöning

Jawaban:


4

Karena ZFS bekerja pada level blok, ukuran file tidak ada bedanya. ZFS membutuhkan lebih banyak memori dan CPU tetapi secara inheren tidak lebih lambat secara signifikan sebagai sistem file. Meskipun Anda perlu menyadari bahwa RAIDZ tidak setara dalam kecepatan ke RAID5. RAID10 baik-baik saja di mana kecepatan adalah prioritas.


4

ZFS pada perangkat keras yang layak (mis. Buff) kemungkinan akan lebih cepat daripada sistem file lainnya, Anda mungkin ingin membuat ZIL pada lokasi yang cepat (yaitu SSD). Ini pada dasarnya adalah lokasi untuk menulis cache (well, lebih seperti jurnal di ext3 / 4). Ini memungkinkan kotak ack menulis sebagai sedang ditulis ke disk sebelum spindel yang sebenarnya memiliki data.

Anda juga dapat membuat L2 ARC pada SSD untuk cache yang dibaca. Ini luar biasa dalam lingkungan VM di mana Anda dapat membawa disk fisik ke lutut dengan mem-boot beberapa VM secara bersamaan.

Drive masuk ke VDEVs, VDEV masuk ke zpools (harap gunakan seluruh disk sekaligus). Jika ini adalah sistem yang lebih kecil Anda mungkin ingin memiliki zpool tunggal dan (jika Anda tidak terlalu khawatir tentang kehilangan data) satu VDEV. VDEVs adalah tempat Anda memilih level RAID (walaupun Anda juga dapat MIRROR VDEVs jika Anda memiliki cukup disk). Disk paling lambat di VDEV menentukan seberapa cepat seluruh VDEV.

ZFS adalah semua tentang integritas data - alasan banyak alat tradisional untuk pemeliharaan sistem file tidak ada (seperti fsck) adalah masalah yang mereka pecahkan tidak dapat ada pada sistem file ZFS.

IMO kelemahan terbesar ZFS adalah bahwa jika sistem file Anda mendekati penuh (katakanlah 75% +) itu akan SANGAT lambat. Hanya saja, jangan pergi ke sana.


2

31GB sebenarnya tidak besar sama sekali ...

Bagaimanapun, tergantung pada sistem file yang sedang Anda gunakan, Anda mungkin menemukan ZFS sedikit lebih lambat tetapi mengingat spesifikasi perangkat keras Anda mungkin diabaikan.

Jelas ZFS akan menggunakan sejumlah besar RAM untuk caching yang dapat membuat VM Anda tampak 'lebih tajam' dalam penggunaan umum (Ketika tidak melakukan membaca atau menulis yang berat). Saya tidak yakin bagaimana ZFS disetel di Linux tetapi Anda mungkin perlu membatasi ARC-nya, jika mungkin, untuk menghentikannya dengan semua RAM Anda (Melihat bahwa Anda ingin sepotong yang layak tersisa untuk sistem host Anda dan VMs).

Saya akan mengaktifkan kompresi (saran hari ini adalah untuk mengaktifkannya kecuali Anda memiliki alasan bagus untuk tidak melakukannya). Ingat ini harus dilakukan sebelum meletakkan data pada sistem file. Kebanyakan orang terkejut mengetahui bahwa ini sebenarnya lebih cepat dengan itu, karena algoritma kompresi umumnya akan berjalan lebih cepat daripada IO disk. Saya ragu itu akan menyebabkan banyak masalah kinerja dengan prosesor 6 inti Anda. Saya tidak mengharapkan VMs untuk mengompres banyak, tetapi saya berhasil mengubah ~ 470GB data VM menjadi 304GB hanya dengan pengaturan kompresi standar.

Jangan repot-repot dengan dedupe, itu hanya akan kembali menghantui Anda nanti dan Anda akan menghabiskan waktu berminggu-minggu mengacak data untuk mencoba menyingkirkannya.

Jika Anda mengalami masalah kinerja maka jawaban yang jelas adalah menambahkan SSD sebagai ZIL / L2ARC atau bahkan keduanya. Ini tidak ideal untuk menggunakan satu perangkat untuk keduanya tetapi kemungkinan besar masih akan meningkatkan kinerja pada kumpulan yang berisi sejumlah kecil disk / vdev.

Untuk Menambahkan: Saya akan benar-benar mencoba dan memulai dengan konfigurasi yang berlebihan jika mungkin (idealnya mirror), atau mengkonversi ke mirror dari strip sesegera mungkin. Sementara ZFS akan memeriksa semua data dan mendeteksi kesalahan saat itu juga (atau selama scrub), ZFS tidak akan dapat melakukan apa-apa (tanpa menggunakan salinan = 2 yang akan menggandakan penggunaan disk). Anda hanya akan dibiarkan memberi tahu Anda ada kesalahan dalam file (mungkin gambar disk VM Anda) yang Anda tidak akan dapat melakukan banyak hal tanpa menghapus dan membuat kembali file-file tersebut.


"Kamu akan dibiarkan memberitahumu ada kesalahan dalam file ... yang tidak akan bisa kamu lakukan banyak tentang" Itu pendapat yang bagus, dan aku menghargainya. Yang mengatakan, di situlah backup malam saya masuk. Karena tidak ada yang berdiri di antara saya dan korupsi data diam, jadi bahkan jika ZFS menolak untuk membiarkan saya membaca file atau bagian dari itu sampai saya mengembalikannya dari (dikenal baik) ) cadangan, itu peningkatan besar dalam jaminan integritas data.
CVn

Sedangkan untuk ukuran file, tidak, 31 GB tidak terlalu besar secara objektif (meskipun masih ~ 1,2% dari total kapasitas penyimpanan sistem saya), tetapi kekhawatiran saya lebih pada garis bahwa SAP akan memiliki sistem menyalin semua data itu bolak-balik terus menerus, kesalahpahaman bahwa JamesRyan cepat diperbaiki .
CVn

1

Tergantung pada kasus penggunaan Anda dan VM saya akan mempertimbangkan Berikut ini. Biarkan sistem Operasi Host menangani file yang Anda Simpan di ZFS Volume.

Jika memungkinkan, buat hanya LUN untuk setiap VM, hanya berisi Sistem Operasi dan file biner yang diperlukan. Dan menghadirkan Storage stace untuk Data Individual sebagai bagian melalui NFS, samba, atau iSCSI (atau zvols seperti yang disebutkan dalam komentar). ZFS dapat melacak setiap file dengan checksumming, dan waktu akses dll. Tentu saja jika kecepatannya tidak begitu penting Anda juga dapat mengaktifkan kompresi pada beberapa Datastores. Keuntungannya adalah lapisan yang hilang dari Filesystem lain. Jika Anda ingin membuat LUN untuk Virtual Harddrive kedua dan membuat Sistem File NTFS di atasnya, ZFS harus menangani gumpalan Biner besar yang tidak mengetahui konten atau file apa pun, dan karenanya tidak dapat memanfaatkan cache ZIL atau ARC di dengan cara yang sama file pesawat bisa.

Menyebutkan ACL, ZFS dapat menggunakan ACL melalui NFSv4 atau Samba (jika diaktifkan). Saya harus mengakui bahwa saya menggunakan ZFS di FreeBSD, dan tidak dapat memastikan bagaimana mengaktifkan Sambas ACL yang kawin dengan volume ZFS. Tapi saya yakin ini bukan masalah besar.

Deduplikasi dalam kombinasi dengan cache Baca adalah keuntungan besar ketika datang untuk menghemat ruang dan meningkatkan pembacaan besar-besaran (Boot storm) karena semua VM mulai membaca blok yang sama.

Hal yang sama berlaku untuk snapshot ZFS untuk VM dan Datastores. Anda dapat membuat skrip shell sederhana, untuk membekukan VM, mengambil snapshot dari VM dan Datastore dan terus bekerja, atau hanya Datastore saja, dan mengkloning VM menyajikan Snapshot yang asli dan menguji beberapa hal.

Kemungkinannya tidak terbatas dengan ZFS;)

EDIT: Semoga saya sudah menjelaskannya sedikit lebih baik sekarang

EDIT2: Pendapat pribadi: Pertimbangkan untuk menggunakan RAIDZ2 (RAID6) karena Anda dapat menahan kegagalan disk ganda! Jika Anda memiliki satu disk cadangan yang tersisa, tidak akan pernah salah, tetapi dua kegagalan disk cukup untuk reaktion cepat. Saya baru saja memposting skrip saya untuk memonitor status disk di sini


Saya tidak yakin saya mengerti. Apakah Anda mengatakan saya harus menyimpan file yang digunakan oleh VMs sebagai file terpisah pada sistem file ZFS, daripada sebagai disk image? Bagaimana dengan hal-hal seperti partisi, sektor boot, atribut yang ZFS tidak ketahui, Windows ACL dalam konteks Linux, ...? Saya salah paham terhadap Anda, atau Anda menjawab sesuatu selain dari apa yang saya minta. Bisakah Anda membaca kembali pertanyaan dan mengedit jawaban Anda untuk mengklarifikasi bagaimana hal itu mengatasi masalah kinerja penyimpanan saya?
CVn

Mengenai snapshot: Mungkin tidak perlu untuk benar-benar membekukan VM. ZFS menggunakan Copy-on-Write (COW), yang berarti Snapshots bersifat instan dan akan memberi Anda gambar disk yang lengkap. Beberapa admin menggunakan ini untuk database MySQL & PostGRES tanpa membekukan database mereka (Misalnya Tidak ada downtime), meskipun yang lain melakukan flush pada tabel terlebih dahulu. Jika Anda perlu membekukan VM, mengambil snapshot ZFS hanya perlu beberapa detik.
Stefan Lasiewski

Michael Saya pikir Daywalker merujuk ke zvols di mana Anda dapat membuat file yang bertindak seperti perangkat blok. Saya akan menggunakan NFS bukan zvols individual untuk VM (nah dalam hal ini sepertinya semua file lokal jadi hanya dalam sistem file). Ya, zvols bisa keren tetapi mereka adalah lapisan komplikasi tambahan. Dan snapshot ZFS menurut definisi konsisten. Itu tidak berarti OS VM tahu itu perlu menyiram data ke disk tetapi Anda akan mendapatkan konsistensi sistem file dengan tingkat yang sama seolah-olah Anda kehilangan daya pada VM.
TheFiddlerWins

Dedup sangat intensif sumber daya. Menggunakan kompresi tidak dan (untuk VM) kemungkinan akan membuat Anda kembali banyak ruang karena spasi di sistem file VM.
TheFiddlerWins

@ MichaelKjörling Cukup sunting Kiriman saya, berharap pemahaman yang lebih baik (juga dengan komentar dari TheFiddlerWins dan Stefan Lasiewski
Daywalker
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.