Zfs: Permintaan Fitur - klon split online

Sepertinya zfs promote mungkin sudah melakukan apa yang Anda butuhkan.

       zfs promote clone-filesystem

           Promotes a clone file system to no longer be dependent on its "ori
           gin"  snapshot.  This  makes it possible to destroy the file system
           that the clone was created from. The clone parent-child  dependency
           relationship  is reversed, so that the origin file system becomes a
           clone of the specified file system.

           The snapshot that was cloned, and any snapshots  previous  to  this
           snapshot,  are  now owned by the promoted clone. The space they use
           moves from the origin file system to the promoted clone, so  enough
           space  must  be  available  to  accommodate these snapshots. No new
           space is consumed by this operation, but the  space  accounting  is
           adjusted. The promoted clone must not have any conflicting snapshot
           names of its own. The rename subcommand can be used to  rename  any
           conflicting snapshots.

Saya melihat zfs promotion, tetapi ini tampaknya hanya membalikkan hubungan orang tua-anak ...

apa yang saya pikirkan adalah keadaan akhir di mana kedua sistem file sepenuhnya independen satu sama lain ...

beberapa kasus penggunaan untuk ini bisa jadi
mengkloning template VM - memiliki gambar dasar yang diklon untuk membuat VM lain, yang kemudian dipisahkan dari template sehingga template dapat diperbarui / dihancurkan / dibuat ulang
klon basis data - kloning prod db untuk dev yang akan mengalami banyak perubahan dan yang pada gilirannya mungkin menjadi basis untuk klon pengujian itu sendiri, dalam kasus ini akan bagus untuk memisahkan dev dari prod karena snapshot dasar mungkin tumbuh lebih besar daripada memiliki sistem file independen untuk dev

Setelah Anda mengkloning @ snapshot asli, Anda dapat mengubah kumpulan data dan mengkloning secara bebas, keduanya tidak akan saling mempengaruhi kecuali bahwa keduanya berbagi data yang masih umum untuk keduanya pada disk.

Jika Anda ingin menghancurkan / membuat ulang template (asli) Anda cukup menghancurkan semua snapshot di atasnya (kecuali yang digunakan sebagai asal klon), zfs mengganti nama asli dan zfs membuat yang baru dengan nama yang sama (properti asal dari klon tidak terikat pada nama kumpulan data asli, jadi Anda dapat mengganti nama keduanya dengan bebas).

Satu-satunya downside adalah bahwa semua data _unique_ yang disimpan dalam @ snapshot asli (= basis klon) tidak dapat dirilis kecuali Anda bersedia untuk menghancurkan klon atau (setelah mempromosikan klon) yang asli.

@ greg-hydrogen pada akhirnya apakah Anda menentukan apakah zfs promote memenuhi kebutuhan Anda? Atau apakah masih ada kemungkinan permintaan fitur di sini.

Untuk mengomentari hal ini, alangkah baiknya jika akan ada fungsi untuk mengubah hubungan asal-klon menjadi jenis yang dihapus: menghapus tautan logis yang menjaga kumpulan data agar tidak dihancurkan sesuka hati - sambil mempertahankan hanya satu salinan dari yang masih dibagikan data.

@behlendorf : hampir pasti tidak memenuhi kebutuhan.
http://jrs-s.net/2017/03/15/zfs-clones-probably-not-what-you-really-want/
menjelaskan masalahnya dengan baik.

Inilah yang saya coba lakukan secara konseptual:

pengguna @ backup :

1. menghasilkan snapshot berbasis tanggal
2. kirimkan dari cadangan untuk diuji sebagai cermin

zfs snapshot backup/prod<strong i="11">@20170901</strong>
zfs send -R backup/prod<strong i="12">@20170901</strong> | ssh test zfs recv ... test/mirror

pengguna @ tes :

1. buat tempat untuk membersihkan cermin
2. membersihkannya
3. potret itu
4. mengkloning versi yang sudah dibersihkan untuk digunakan
5. Gunakan

zfs clone test/mirror<strong i="23">@20170901</strong> test/sanitizing
sanitize sanitizing
zfs snapshot test/sanitizing<strong i="24">@sanitized</strong>
zfs clone test/sanitizing<strong i="25">@sanitized</strong> test/test
dirty test/test

pengguna @ backup :

1. setelah menggunakan produksi lebih lanjut ...
2. buat snapshot yang diperbarui
3. kirim perubahan tambahan dari prod ke pengujian
4. hapus penanda inkremental sebelumnya (yang dalam kasus saya membebaskan 70GB)

dirty prod/prod
zfs snapshot backup/prod<strong i="35">@20170908</strong>
zfs send -I backup/prod<strong i="36">@20170901</strong> backup/prod<strong i="37">@20170908</strong> | ssh test zfs recv test/mirror
zfs destroy backup/prod<strong i="38">@20170901</strong>

pengguna @ tes :

• di sinilah masalah muncul.
• dengan sejumlah bujukan, seseorang dapat menghancurkan volume sanitasi.
• Tapi, saya memiliki test/mirror@20170901 yang merupakan asal dari dua hal yang tersisa: test/mirror@20170908 dan test/test .
• Saya dapat menghancurkan mirror yang diperbarui ( test/mirror@20170908 ) jika saya mau, tetapi itu tidak ada gunanya bagi saya (karena tujuan saya adalah menggunakan data itu).

Agar saya bisa membuat kemajuan, saya benar-benar harus menjalankan melalui sanitasi, menghentikan hal yang menggunakan tes, menghancurkan tes (sepenuhnya), mengkloning cermin sebagai tes, memulai ulang hal itu menggunakan tes, dan akhirnya saya bisa mencoba untuk menghancurkan aslinya foto. Atau, saya dapat memutuskan bahwa saya akan mengambil langkah, memicu snapshot baru pada backup nanti, dan mengirimkan kenaikannya, menghapus snapshot yang tidak pernah dicerminkan untuk diuji, dan coba lagi.

Fwiw, untuk mencicipi ini ...:

zfs list -t all -o used,refer,name,origin -r test/mirror test/test
 USED   REFER  NAME                              ORIGIN
 161G   1.57M  test/mirror                       -
  65G   82.8G  test/mirror<strong i="54">@2017081710</strong>            -
    0   82.4G  test/mirror<strong i="55">@201709141737</strong>          -
3.25G   82.8G  test/test                         test/mirror<strong i="56">@2017081710</strong>

(angkanya benar-benar salah, saya sebenarnya memiliki 1 volume dengan 4 volume yang terkandung, karenanya tanda rekursif ...)

Sekarang, saya mengerti bahwa saya dapat menggunakan zfs send | zfs recv untuk memutus dependensi, dan untuk hal-hal kecil tidak masalah. Tetapi bagian dari kolam saya ini kira-kira dua kali dari ruang yang tersedia di kolam, dan satu setengahnya mungkin lebih besar dari itu, yang berarti melakukan operasi itu bermasalah. Ini juga merupakan sejumlah besar byte untuk diproses ulang. Harapan saya dalam menggunakan snapshot adalah untuk mendapatkan keuntungan dari KK, tetapi sebaliknya, saya dikenai biaya untuk KK karena titik cabang yang pada akhirnya akan memiliki data yang digunakan oleh kedua sisi pohon percabangan saya masih harus dibayar.

@behlendorf Hai, ada kemajuan dalam hal ini? Memisahkan klon dari sistem file aslinya akan sangat bagus untuk template VM dan / atau pemulihan tingkat file yang besar. Lihat tautan @jsoref yang ditempel di atas untuk contoh praktis.

@kpande : tujuannya adalah untuk membayar (dalam ruang dan transfer data) untuk apa yang telah berubah (COW), bukan untuk seluruh kumpulan data (setiap kali operasi ini terjadi).

Jika saya memiliki kumpulan data bergerak 10TB, dan variasi dari kumpulan data yang ingin saya buat, tentu, saya dapat menyalin 10TB, menerapkan variasi, dan membayar 20TB (jika saya memiliki 20TB tersedia). Tapi, jika variasi saya benar-benar hanya 10MB berbeda dari 10TB asli, mengapa saya tidak bisa membayar 10TB + 10MB? - snapshots + clone beri aku itu. Hingga 10TB bergerak cukup sehingga saya sekarang membayar 10TB (snapshot langsung + 10TB + 10TB berbeda) dan variasi 10MB saya bergerak sehingga sekarang menjadi 10TB sendiri (berbeda dari live dan snapshot). Untuk sementara, untuk "memperbaiki" masalah 30TB saya, saya harus mengeluarkan 10TB lagi (= 40TB - melalui zfs send + zfs recv). Itu tidak ideal. Tentu, ini akan "berfungsi", tetapi tidak "cepat" atau juga tidak hemat ruang.

Kirim / terima yang disunting terdengar menarik (karena kurang lebih cocok dengan kasus penggunaan saya) - tetapi meskipun saya dapat menemukannya disebutkan di banyak tempat, saya tidak dapat menemukan penjelasan yang berguna tentang apa yang sebenarnya disunting.

Fwiw, untuk sistem kami, saya beralih sehingga sanitasi terjadi di sisi pengirim (yang juga lebih baik dari perspektif privasi), yang sebagian besar membuat kami keluar dari masalah.

Ini adalah contoh di mana variasi datanya tidak "disunting" dan di mana sistem memiliki sumber daya untuk snapshot zfs + pengiriman zfs tetapi tidak benar-benar ingin mengalokasikan sumber daya untuk menghosting database kedua untuk melakukan "mutasi" - dan tidak ingin membayar untuk mengirim seluruh volume antara primer dan sekunder (yaitu lebih suka mengirim snapshot inkremental ke sistem yang sudah memiliki snapshot sebelumnya).

Ya, saya sadar saya bisa menggunakan dedup. Kami membayar cpus / ram kami, jadi mendedikasikan cpu + ram konstan untuk membuat tugas langka (refresh mutated clone) dengan cepat terasa seperti pertukaran yang buruk (saya lebih suka membayar sedikit lebih banyak ruang disk).

@kpande tautan ini cukup jelas menunjukkan masalah dengan klon saat ini. Lagi pula, jika klon menyimpang begitu banyak dari snapshot dasar, relasi permanen orang tua-> anak antara keduanya akan menjadi sumber kebingungan. Memisahkan klon akan menjadi indikasi yang jelas bahwa mereka sangat menyimpang sehingga tidak dianggap terikat lagi.

Tapi izinkan saya melakukan contoh yang lebih praktis.

Misalkan kvm/vmimages menjadi wadah datastore untuk beberapa gambar disk virtual, dengan snapshot diambil setiap hari. Saya tahu jawaban defaultnya adalah "gunakan kumpulan data untuk setiap disk", tetapi kumpulan libvirt tidak cocok dengan itu. Jadi kami memiliki sesuatu sebagai:

kvm/vmimages
kvm/vmimages<strong i="11">@snap1</strong>
kvm/vmimages<strong i="12">@snap2</strong>
kvm/vmimages<strong i="13">@snap3</strong>

Pada titik tertentu, sesuatu yang buruk terjadi pada vm disk (yaitu: kerusakan sistem file tamu yang serius), tetapi sementara itu pengguna lain secara aktif menyimpan data baru yang penting pada disk lain. Anda pada dasarnya memiliki beberapa persyaratan kontras: a) untuk kembali ke data lama yang tidak rusak dari kemarin, b) untuk menyimpan data baru yang diunggah, yang tidak ditemukan dalam snapshot manapun dan c) untuk menyebabkan gangguan layanan minimal.

Klon muncul dalam pikiran sebagai solusi yang mungkin: Anda dapat mengkloning kvm/vmimages@snap3 sebagai kvm/restored untuk segera memulihkan layanan untuk VM yang terpengaruh. Jadi, Anda sekarang memiliki:

kvm/vmimages
kvm/vmimages<strong i="20">@snap1</strong>
kvm/vmimages<strong i="21">@snap2</strong>
kvm/vmimages<strong i="22">@snap3</strong>
kvm/restored   # it is a clone of snap3
kvm/restored<strong i="23">@snap1</strong>
...

VM yang terpengaruh berjalan dari kvm/restored , sementara yang lainnya tetap pada kvm/vmimages . Pada tahap ini, Anda menghapus semua disk tambahan dari kvm/restored dan disk asli yang rusak dari kvm/vmimages . Semua tampak baik-baik saja, sampai Anda menyadari bahwa gambar disk lama yang rusak masih menggunakan ruang disk yang sebenarnya, dan setiap penimpaan dalam kvm/restored menghabiskan ruang tambahan karena gambar lama yang tidak dapat dihapus kvm/vmimages@snap3 . Anda tidak dapat menghapus snapshot lama ini tanpa menghapus klon Anda juga, dan Anda tidak dapat begitu saja mempromosikan kvm/restored dan menghapus kvm/vmimages karena ini bukan satu-satunya sumber data "otoritatif" yang sebenarnya (yaitu: data nyata adalah disimpan di dalam kedua dataset).

Memisahkan klon dari sumbernya akan menyelesaikan masalah di atas sepenuhnya. Tidak jelas bagi saya bagaimana cara mengirim / menerima yang disunting akan membantu dalam kasus ini.

@kpande dulu, terima kasih telah membagikan pandangan dan solusi Anda (yang menarik!). Saya sangat setuju bahwa konfigurasi tamu yang cermat, dan sangat spesifik (dan pohon kumpulan data host) dapat menghindari masalah yang terungkap di atas.

Meskipun demikian, libvirt (dan penerapan kolam penyimpanan) tidak berfungsi dengan baik dengan pendekatan ini, terutama saat mengelola lingkungan campuran dengan mesin virtual Windows. Terlebih lagi, ini hanya satu contoh. Klon yang dapat dipisahkan akan sangat berguna, misalnya, jika digunakan untuk membuat "master emas / gambar dasar", yang dapat digunakan sesuka hati untuk membuat mesin virtual "nyata".

Dengan keadaan saat ini, melakukan itu akan sangat membebani Anda dalam ruang yang dialokasikan, karena Anda tidak akan pernah bisa menghapus snapshot asli yang berpotensi usang. Yang mengejutkan saya adalah, sebagai ZFS sistem file Kontrak Karya, ini harus menjadi operasi yang relatif sederhana: ketika menghapus snapshot asli, "cukup" tandai sebagai bebas dari blok non-referensi dan hapus relasi induk / anak. Dengan kata lain, jadikanlah tiruan sebuah sistem file nyata, yang dipisahkan dari snapshot sumber mana pun.

Perhatikan bahwa saya menggunakan dunia "hanya" di dalam tanda kutip: meskipun ini memang operasi logis sederhana, saya tidak yakin apakah / seberapa baik itu memetakan ke sistem file zfs yang mendasarinya.

@kpande ok, cukup adil - jika ada masalah teknis nyata, saya harus menerimanya. Tetapi ini berbeda dengan menyatakan bahwa kasus penggunaan tertentu tidak valid.

Jika pandangan ini (yaitu: ketidakmungkinan untuk memisahkan klon dari snapshot induk aslinya tanpa melibatkan BPR "mistis") dibagikan oleh pengembang zfs, saya pikir FR ini dapat ditutup.

Terima kasih.

+1 tentang membutuhkan fitur ini. Ya, send / recv dapat digunakan, tetapi itu akan membutuhkan waktu henti apa pun yang menggunakan kumpulan data itu untuk beralih dari kumpulan data lama (klon) ke kumpulan data baru.

Saya telah mengalami situasi dengan LXD di mana kontainer disalin (dikloning), tetapi itu menyebabkan masalah dengan snapshotting saya yang dikelola secara terpisah.

@kpande : sekali lagi, kasus penggunaan saya menjadikan seluruh dataset menjadi database, dan beberapa variasi database.

Dari apa yang saya lihat, tampaknya overlayfs tidak berfungsi dengan baik w / zfs sebagai sistem file (tampaknya senang w / zvols dan ext4 / xfs menurut catatan Anda). Ini _sounds_ seperti pendekatan ini akan mencakup sebagian besar kasus, dalam hal ini dokumentasi yang menjelaskan cara menyiapkan overlayfs w / ext4 / xfs akan diterima.

Meskipun demikian, beberapa dari kita menggunakan zfs tidak hanya untuk manajemen volume tetapi juga untuk perilaku acl / allow / snapshot / browsing, dan ingin dapat menggunakan overlayfs w / zfs daripada ext4 / xfs, jadi jika itu bukan tidak mungkin, apakah ada bug untuk itu? Jika ada, alangkah baiknya jika itu disorot (dari sini), jika tidak, jika Anda mendukung pendekatan overlayfs, mungkin Anda dapat mengajukannya (jika Anda bersikeras, saya mungkin dapat menulisnya, tetapi saya tidak ' Saya tidak tahu apa-apa tentang overlayf, dan itu sepertinya teknologi utama dalam artikel ini).

Dari apa yang saya lihat, tampaknya overlayfs tidak berfungsi dengan baik w / zfs sebagai sistem file (tampaknya senang w / zvols dan ext4 / xfs menurut catatan Anda). Ini _sounds_ seperti pendekatan ini akan mencakup sebagian besar kasus, dalam hal ini dokumentasi yang menjelaskan cara menyiapkan overlayfs w / ext4 / xfs akan diterima.

Pendekatan overlayfs tidak akan bekerja untuk kasus penggunaan yang sangat penting dan umum: mengkloning gambar virtual mulai dari yang lain (atau template "master emas"). Dalam kasus seperti itu, memisahkan klon akan menjadi kunci untuk menghindari ruang yang terbuang percuma karena gambar asli / klon berbeda.

@ ptx0 ini hanya berfungsi jika OS tamu mendukung overlayfs (jadi tidak ada dukungan VM Windows) dan jika pengguna akhir (yaitu: pelanggan kami) bersedia mengubah penyediaan / instalasi gambar VM mereka secara signifikan. Sebagai catatan tambahan, meskipun saya sepenuhnya memahami - dan menerima - PR ini ditutup atas dasar teknis (misalnya: jika melibatkan BPR), cukup menjengkelkan untuk memiliki kasus pengguna yang sah dicap sebagai "tidak valid". Jika itu bukan kasus penggunaan Anda, baiklah. Tapi tolong jangan anggap tidak ada orang yang memiliki kasus penggunaan yang valid untuk fitur ini.

Windows tidak memerlukan overlayf, ia telah membangun pengalihan folder dan profil roaming.

Pengalihan folder, sementara ada sejak NT, tidak selalu berfungsi dengan baik karena ada perangkat lunak yang (untuk alasan yang tidak jelas) tidak menangani folder yang dialihkan dengan benar dan hanya gagal ketika dihadapkan dengan Desktop atau Dokumen yang dialihkan. Selain itu, klon instalasi Windows menyimpang, dengan sendirinya, secara masif dan cukup cepat dari asalnya, berkat Pembaruan Windows - memiliki pengguna yang berbeda masuk dan keluar hanya mempercepat ini.