Zfs: طلب ميزة - استنساخ مقسم عبر الإنترنت

يبدو أن zfs promote قد يفعل ما تحتاجه بالفعل.

       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.

كنت أبحث عن ترويج zfs ، لكن يبدو أن هذا يقلب العلاقة بين الوالدين والطفل ...

ما كنت أفكر فيه كان حالة نهائية حيث يكون كلا نظامي الملفات مستقلين تمامًا عن بعضهما البعض ...

يمكن أن تكون بعض حالات الاستخدام لهذا
استنساخ قوالب VM - وجود صورة أساسية مستنسخة لإنشاء أجهزة افتراضية أخرى ، والتي بدورها تنفصل عن القالب بحيث يمكن تحديث / إتلاف / إعادة إنشاء القالب
استنساخ قاعدة البيانات - استنساخ prod db للمطور الذي سيخضع للعديد من التغييرات والذي بدوره قد يكون أساسًا لنسخة اختبار نفسها ، في حالة أنه سيكون من الجيد فصل dev من prod لأن اللقطة الأساسية قد تكبر من وجود نظام ملفات مستقل لـ dev

بعد استنساخ @ snapshot الأصلي ، يمكنك تعديل كل من مجموعة البيانات والاستنساخ بحرية ، ولن يؤثر كل منهما على الآخر باستثناء أنهما يشتركان في البيانات التي لا تزال شائعة على القرصين.

إذا كنت تريد تدمير / إعادة إنشاء القالب (الأصلي) ، يمكنك ببساطة تدمير كل اللقطات الموجودة عليه (باستثناء تلك المستخدمة كأصول للنسخ المستنسخة) ، وإعادة تسمية zfs بالنموذج الأصلي وإنشاء zfs جديدة بنفس الاسم (خاصية الأصل من المستنسخات ليس مرتبطًا باسم مجموعة البيانات الأصلية ، لذا يمكنك إعادة تسمية كليهما بحرية).

الجانب السلبي الوحيد لذلك هو أن جميع _unique_ البيانات المحفوظة في اللقطة @ الأصلية (= قاعدة الاستنساخ) لا يمكن تحريرها إلا إذا كنت على استعداد لتدمير النسخة (النسخ) أو (بعد الترويج للنسخة) الأصلية.

@ greg-hydrogen في النهاية هل حددت ما إذا كان zfs promote يلبي احتياجاتك؟ أم أنه لا يزال هناك طلب ميزة محتمل هنا.

للتعليق على هذا ، سيكون من الجيد أن تكون هناك وظيفة لتحويل علاقات استنساخ الأصل إلى نوع مُستبعد: إزالة الروابط المنطقية التي تمنع مجموعات البيانات من التدمير الفردي حسب الرغبة - مع الاحتفاظ بنسخة واحدة فقط من الملفات التي لا تزال مشتركة البيانات.

behlendorf : يكاد يكون من المؤكد أنه لا يلبي الحاجة.
http://jrs-s.net/2017/03/15/zfs-clones-probably-not-what-you-really-want/
يقوم بعمل جيد في شرح المشكلة.

هذا ما أحاول فعله من الناحية المفاهيمية:

مستخدم @ النسخ الاحتياطي :

1. إنشاء لقطة على أساس التاريخ
2. أرسلها من نسخة احتياطية لاختبارها كمرآة

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

user @ test :

1. إنشاء مكان لتعقيم المرآة
2. عقمها
3. التقطه
4. استنساخ النسخة المعقمة للاستخدام
5. استخدمه

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

مستخدم @ النسخ الاحتياطي :

1. بعد استخدام الإنتاج بشكل أكبر ...
2. إنشاء لقطة محدثة
3. إرسال التغييرات المتزايدة من prod إلى الاختبار
4. حذف العلامة المتزايدة السابقة (والتي في حالتي تحرر 70 غيغابايت)

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>

user @ test :

• هنا تظهر المشاكل.
• مع قدر من التملق ، يمكن للمرء أن يدمر أحجام التعقيم.
• ولكن ، بقي لديّ test/mirror@20170901 وهو أصل الشيئين المتبقيين: test/mirror@20170908 و test/test .
• يمكنني تدمير النسخة المتطابقة المحدثة ( test/mirror@20170908 ) إذا أردت ، لكن هذا لا يفيدني (لأن هدفي هو استخدام تلك البيانات).

لكي أحقق تقدمًا ، يجب أن أجري عملية التعقيم ، وإيقاف الشيء الذي يستخدم الاختبار ، وتدمير الاختبار (تمامًا) ، واستنساخ المرآة كاختبار ، وإعادة تشغيل الشيء باستخدام الاختبار ، وبعد ذلك يمكنني أخيرًا محاولة تدمير الأصل لمحة. أو يمكنني أن أقرر أنني سأقوم بإجراء تمريرة ، وأطلق لقطة جديدة على نسخة احتياطية لاحقًا ، وأرسل الزيادة مرة أخرى ، واحذف اللقطة التي لم يتم نسخها مطلقًا للاختبار ، وحاول مرة أخرى.

Fwiw ، لتتذوق هذا ...:

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>

(الأرقام خاطئة حقًا ، لدي بالفعل مجلد واحد يحتوي على 4 مجلدات ، ومن ثم العلامات العودية ...)

الآن ، أفهم أنه يمكنني استخدام zfs send | zfs recv لكسر التبعيات ، ولا بأس بذلك بالنسبة للأشياء الصغيرة. لكن هذا الجزء من حوض السباحة الخاص بي هو ضعف المساحة المتاحة في المسبح تقريبًا ، وربما يكون النصف الآخر أكبر من ذلك ، مما يعني أن إجراء هذه العملية يمثل مشكلة. إنها أيضًا كمية هائلة من البايت لإعادة معالجتها. كان أملي في استخدام اللقطات هو أن أكون قادرًا على الاستفادة من COW ، ولكن بدلاً من ذلك ، يتم محاسبتي على COW لأن نقطة الفرع التي ستحتوي في النهاية على بيانات يستخدمها أي من جانبي الشجرة المتفرعة الخاصة بي لا يزال يتعين دفع ثمنها.

behlendorf مرحبا ، أي تقدم في هذا؟ سيكون تقسيم النسخ من نظام الملفات الأصلي أمرًا رائعًا حقًا لقوالب VM و / أو استعادة مستوى الملف الكبير. راجع الرابط jsoref الذي تم لصقه أعلاه للحصول على مثال عملي.

kpande : الهدف هو الدفع (في الفضاء ونقل البيانات) مقابل ما تغير (COW) ، وليس لمجموعة البيانات بأكملها (في كل مرة تحدث هذه العملية).

إذا كان لدي مجموعة بيانات متحركة بسعة 10 تيرابايت ، ومجموعة بيانات أخرى أرغب في إنشائها ، فبالتأكيد يمكنني نسخ 10 تيرابايت وتطبيق التباين ودفع 20 تيرابايت (إذا كان لدي 20 تيرابايت متاحًا). ولكن ، إذا كان الاختلاف الخاص بي يختلف حقًا عن 10 تيرابايت الأصلي ، فلماذا لا يمكنني الدفع مقابل 10 تيرابايت + 10 ميجابايت؟ - لقطات + المستنسخات أعطني ذلك. حتى يتحرك 10 تيرابايت بشكل كافٍ لدرجة أنني أدفع الآن مقابل 10 تيرابايت (لقطة مباشرة + 10 تيرابايت متباينة + 10 تيرابايت متباينة) ويتحرك التباين الخاص بي البالغ 10 ميجابايت بحيث أصبح الآن 10 تيرابايت الخاصة به (تباعدت عن البث المباشر واللقطات) في غضون ذلك ، من أجل "إصلاح" مشكلة 30 تيرابايت الخاصة بي ، يجب أن أنفق 10 تيرابايت أخرى (= 40 تيرابايت - عبر zfs أرسل + zfs recv). هذا ليس مثاليًا. بالتأكيد ، سوف "تعمل" ، لكنها ليست "سريعة" ولا موفرة للمساحة عن بعد.

يبدو الإرسال / الاستلام المنقح مثيرًا للاهتمام (نظرًا لأنه يتطابق بشكل أو بآخر مع حالة الاستخدام الخاصة بي) - ولكن بينما يمكنني العثور عليه مذكورًا في مجموعة من الأماكن ، لا يمكنني العثور على أي تفسير مفيد لما يتم تنقيحه بالفعل.

Fwiw ، بالنسبة لنظامنا ، قمت بالتبديل بحيث يحدث التعقيم على جانب الإرسال (وهو أيضًا أفضل من منظور الخصوصية) ، والذي أخرجنا في الغالب من الغابة.

هذه هي الحالات التي لا يكون فيها تباين البيانات "تنقيحًا" وحيث يكون لدى النظام الموارد اللازمة لإرسال zfs snapshot + zfs ولكنه لا يريد حقًا تخصيص الموارد لاستضافة قاعدة بيانات ثانية لإجراء "الطفرة" - و لا تريد أن تضطر إلى الدفع لإرسال الحجم الكامل بين الأساسي والثانوي (أي أنها تفضل إرسال لقطة إضافية إلى نظام يحتوي بالفعل على اللقطة السابقة).

نعم ، أعلم أنه يمكنني استخدام dedup. نحن ندفع ثمن وحدة المعالجة المركزية / ذاكرة الوصول العشوائي الخاصة بنا ، لذا فإن تخصيص وحدة المعالجة المركزية الثابتة + ذاكرة الوصول العشوائي لإجراء مهمة نادرة (استنساخ متحور) سريعًا بدا وكأنه مقايضة سيئة (أفضل الدفع مقابل مساحة قرص أكبر قليلاً)

kpande يظهر هذا الرابط بوضوح مشكلة النسخ الحالية. بعد كل شيء ، إذا تباعدت النسخة كثيرًا عن اللقطة الأساسية ، فإن العلاقة الأبوية> الأبناء الدائمة بين الاثنين هي مصدر ارتباك. قد يكون تقسيم النسخة المستنسخة مؤشرًا واضحًا على أنها تباعدت كثيرًا حتى لا تعتبر مرتبطة بعد الآن.

لكن اسمحوا لي أن أقدم مثالاً عمليًا أكثر.

اجعل kvm/vmimages حاوية مخزن بيانات للعديد من صور الأقراص الافتراضية ، مع لقطات يتم التقاطها على أساس يومي. أعلم أن الإجابة الافتراضية ستكون "استخدام مجموعة بيانات لكل قرص" ، لكن مجموعات libvirt لا تعمل بشكل جيد مع ذلك. لذلك لدينا شيء مثل:

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

في مرحلة ما ، يحدث شيء سيء للقرص vm (على سبيل المثال: تلف خطير في نظام ملفات الضيف) ، ولكن في هذه الأثناء يقوم مستخدمون آخرون بتخزين بيانات جديدة ومهمة على الأقراص الأخرى. لديك في الأساس بعض المتطلبات المتناقضة: أ) العودة إلى البيانات القديمة غير التالفة بالأمس ، ب) للاحتفاظ بأي بيانات جديدة تم تحميلها ، والتي لا توجد في أي لقطات و ج) للتسبب في الحد الأدنى من انقطاع الخدمة.

يتبادر إلى الذهن الاستنساخ كحل ممكن: يمكنك استنساخ kvm/vmimages@snap3 كـ kvm/restored لاستعادة الخدمة على الفور لجهاز VM المتأثر. إذن لديك الآن:

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

يعمل الجهاز الظاهري المتأثر من kvm/restored ، بينما تبقى جميع الأجهزة الأخرى على kvm/vmimages . في هذه المرحلة ، تقوم بحذف كافة الأقراص الإضافية من kvm/restored والقرص الأصلي التالف من kvm/vmimages . يبدو كل شيء على ما يرام ، حتى تدرك أن صورة القرص التالفة القديمة لا تزال تستخدم مساحة القرص الحقيقية ، وأي الكتابة فوق kvm/restored تستهلك مساحة إضافية بسبب القديم غير القابل للإزالة kvm/vmimages@snap3 . لا يمكنك إزالة هذه اللقطة القديمة دون إزالة نسختك أيضًا ، ولا يمكنك ببساطة ترقية kvm/restored وحذف kvm/vmimages لأنه ليس مصدر البيانات الحقيقي الوحيد "الموثوق" (أي: البيانات الحقيقية هي تخزينها داخل كل من مجموعة البيانات).

سيؤدي فصل الاستنساخ عن مصدره إلى حل المشكلة أعلاه تمامًا. ليس من الواضح بالنسبة لي كيف سيساعد الإرسال / الاستلام المنقح في هذه الحالة.

kpande أولاً ، شكرًا قدمته (وهو أمر مثير للاهتمام!). أوافق تمامًا على أن تكوين الضيف الدقيق والمحدد للغاية (وشجرة مجموعة البيانات المضيفة) يمكن أن يتجنب المشكلة الموضحة أعلاه.

ومع ذلك ، فإن libvirt (وتنفيذها لتجمعات التخزين) لا تعمل بشكل جيد مع هذا النهج ، خاصة عند إدارة البيئات المختلطة مع أجهزة Windows الافتراضية. أكثر من ذلك ، كان هذا مثالًا واحدًا فقط. قد تكون النسخ القابلة للتقسيم مفيدة جدًا ، على سبيل المثال ، عند استخدامها لإنشاء "صورة رئيسية / أساسية ذهبية" ، والتي يمكن تثبيتها حسب الرغبة لإنشاء آلات افتراضية "حقيقية".

مع الوضع الحالي للقضية، والقيام من شأنها أن الضريبة التي بكثافة في المكان المخصص، كما أنك لن تكون قادرة على إزالة أي وقت مضى الأصلي، وربما عفا عليها الزمن، لقطة. ما أدهشني هو أنه لكون ZFS نظام ملفات CoW ، يجب أن تكون هذه عملية بسيطة نسبيًا: عند حذف اللقطة الأصلية ، ضع علامة "ببساطة" على أي كتلة غير مرجعية خالية وإزالة العلاقة الأب / الطفل. بمعنى آخر ، لنكن نظام ملفات حقيقيًا غير متشابك من أي لقطة مصدر.

لاحظ أنني استخدمت العالم "ببساطة" علامات الاقتباس الداخلية: بينما هي بالفعل عملية منطقية بسيطة ، فأنا لست متأكدًا مما إذا كانت / كيف يتم تعيينها بشكل جيد لنظام ملفات zfs الأساسي.

kpande حسنًا ، عادل بما يكفي - إذا كانت هناك مشكلة تقنية حقيقية ، يجب أن أقبلها. لكن هذا يختلف عن التصريح بأن حالة استخدام معينة غير صالحة.

إذا تمت مشاركة هذا العرض (أي: استحالة فصل نسخة من اللقطة الأصلية الأصلية دون تضمين BPR "الأسطوري") بواسطة مطوري zfs ، أعتقد أنه يمكن إغلاق هذا FR.

شكر.

+1 على الحاجة إلى هذه الميزة. نعم ، يمكن استخدام الإرسال / الاستلام ، ولكن هذا سيتطلب وقتًا تعطلًا لأي شيء يستخدم مجموعة البيانات هذه للتبديل من مجموعة البيانات القديمة (استنساخ) إلى مجموعة البيانات الجديدة.

لقد واجهت مواقف مع LXD حيث يتم نسخ حاوية (مستنسخة) ، ولكن هذا يسبب مشاكل في اللقطات المُدارة بشكل منفصل.

kpande : مرة أخرى ، تشتمل حالة الاستخدام الخاصة بي على مجموعة البيانات بأكملها الأشكال المختلفة لقاعدة البيانات.

مما رأيته ، لا يبدو أن التراكب يلعب بشكل جيد مع نظام الملفات (يبدو سعيدًا مع w / zvols و ext4 / xfs وفقًا لملاحظاتك). يبدو أن هذا الأسلوب سيغطي معظم الحالات ، وفي هذه الحالة سيكون التوثيق الذي يشرح كيفية إعداد overlayfs w / ext4 / xfs موضع ترحيب.

ومع ذلك ، فإن البعض منا يستخدم zfs ليس فقط لإدارة وحدة التخزين ولكن أيضًا لسلوك / استعراض acl / allow / snapshot ، ويود أن يكون قادرًا على استخدام overlayfs w / zfs بدلاً من ext4 / xfs ، لذلك إذا لم يكن ذلك ممكن ، هل هناك خطأ في ذلك؟ إذا كان هناك ، فسيكون من الجيد إذا تم إبراز ذلك (من هنا) ، وإذا لم يكن كذلك ، إذا كنت تؤيد نهج التراكبات ، فربما يمكنك تقديمه (إذا أصررت ، ربما يمكنني كتابته ، لكنني لا أفعل لا أعرف أي شيء عن التراكبات ، ويبدو أنها تقنية رئيسية في الكتابة).

مما رأيته ، لا يبدو أن التراكب يلعب بشكل جيد مع نظام الملفات (يبدو سعيدًا مع w / zvols و ext4 / xfs وفقًا لملاحظاتك). يبدو أن هذا الأسلوب سيغطي معظم الحالات ، وفي هذه الحالة سيكون التوثيق الذي يشرح كيفية إعداد overlayfs w / ext4 / xfs موضع ترحيب.

و overlayfs نهج لن تعمل لغاية الأهمية، والمشتركة، واستخدام القضية: استنساخ صورة افتراضية بدءا من بعضها البعض (أو "الذهب سيد" قالب). في مثل هذه الحالة ، سيكون تقسيم النسخة المستنسخة مفتاحًا لتجنب المساحة الضائعة حيث تتباعد الصور الأصلية / المستنسخة.

@ ptx0 يعمل هذا فقط إذا كان يدعم نظام التشغيل الضيف overlayfs (حتى لا دعم ويندوز نظام رصد السفن) وإذا كان المستخدم النهائي (أي: عملائنا) على استعداد لتغيير كبير الصور VM من المخصصات / التثبيت. كملاحظة جانبية ، بينما أفهم تمامًا - وأقبل - إغلاق العلاقات العامة هذا على أساس تقني (على سبيل المثال: إذا كان يتضمن BPR) ، فإنه أمر محبط للغاية أن يتم ختم حالة مستخدم شرعية على أنها "غير صالحة". إذا لم تكن حالة الاستخدام الخاصة بك ، فلا بأس. لكن من فضلك لا تفترض أنه لا أحد لديه حالة استخدام صالحة لهذه الميزة.

لا يحتاج Windows إلى تراكبات ، فقد تم تضمينه في إعادة توجيه المجلدات وملفات التعريف المتجولة.

على الرغم من وجود إعادة توجيه المجلد ، على الرغم من وجوده منذ NT ، إلا أنه لا يعمل دائمًا بشكل موثوق حيث يوجد برنامج (لأسباب غامضة) لا يتعامل مع المجلدات المعاد توجيهها بشكل صحيح ويفشل ببساطة عند مواجهة سطح المكتب أو المستندات المعاد توجيهه. بصرف النظر عن ذلك ، تتباعد نسخ تثبيتات Windows ، كل ذلك من تلقاء نفسها ، بشكل كبير وسريع جدًا عن الأصل ، بفضل Windows Update - وجود مستخدمين مختلفين يقومون بتسجيل الدخول والخروج من البرنامج يؤدي فقط إلى تسريع هذا الأمر.