النسخ الاحتياطي لنظام التشغيل Linux ، أو كيفية إنشاء لقطة

مرحبا بالجميع! أعمل في Veeam على مشروع Veeam Agent لـ Linux. باستخدام هذا المنتج ، يمكنك عمل نسخة احتياطية من جهاز Linux. يعني "الوكيل" في الاسم أن البرنامج يسمح لك بعمل نسخة احتياطية من الأجهزة المادية. Virtualalkans أيضا النسخ الاحتياطي ، ولكنه يقع على نظام التشغيل الضيف.

كان مصدر إلهامي لهذه المقالة تقريري في مؤتمر Linux Piter ، الذي قررت إصداره كمقال لجميع المهتمين بـ habragiteli.

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

جميع المهتمين يرجى طلب قطع!

القليل من النظرية في البداية

تاريخيًا ، هناك طريقتان لإنشاء نسخ احتياطية: النسخ الاحتياطي للملف والنسخ الاحتياطي لوحدة التخزين. في الحالة الأولى ، نقوم بنسخ كل ملف ككائن منفصل ، وفي الحالة الثانية ، نقوم بنسخ محتويات المجلد بالكامل كنوع من الصورة.

كلتا الطريقتين لها الكثير من المزايا والعيوب ، لكننا سننظر فيها من خلال منظور التعافي من الفشل:

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

من الواضح أنه في حالة النسخ الاحتياطي لوحدة التخزين ، يمكنك استعادة النظام بشكل أسرع ، وهذه ميزة مهمة للنظام . لذلك ، لأنفسنا ، نلاحظ النسخ الاحتياطي لوحدة التخزين كخيار مفضل.

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

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

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

BTRFS و ZFS تجعل من الممكن إنشاء لقطات من الهياكل الفرعية لنظام الملفات ، وهو أمر رائع جدًا ، ولكن في الوقت الحالي حصتها على الخوادم صغيرة ، ونحن نحاول إنشاء حل عالمي.

افترض أن هناك EXT عاديا على جهاز الحظر لدينا. في هذه الحالة ، يمكننا استخدام dm-snap (بالمناسبة ، dm-bow يتم تطويره الآن) ، ولكن هنا فارق بسيط. يجب أن يكون لديك جهاز حظر مجاني جاهز حتى تتمكن من إسقاط بيانات اللقطة حيث.
مع الانتباه إلى حلول النسخ الاحتياطي البديلة ، لاحظنا ، كقاعدة عامة ، أنهم يستخدمون وحدة kernel الخاصة بهم لإنشاء لقطات من أجهزة الحظر. قررنا أن نسير على هذا النحو ، كتابة وحدتنا. تقرر توزيعه بموجب ترخيص GPL ، بحيث يكون متاحًا للجميع على github .

كيف يعمل - من الناحية النظرية

لقطة المجهر

لذا ، سننظر الآن في المبدأ العام لتشغيل الوحدة ونتناول المسائل الرئيسية بمزيد من التفصيل.

في الواقع ، veeamsnap (كما أطلقنا على وحدة kernel الخاصة بنا) هو مرشح برنامج تشغيل جهاز كتلة.



تتمثل وظيفته في اعتراض الطلبات لبرنامج تشغيل جهاز كتلة.

بعد اعتراض طلب كتابة ، تقوم الوحدة بنسخ البيانات من جهاز الكتلة الأصلي إلى منطقة بيانات اللقطة. نسمي هذه المنطقة snapstore.



وما هي اللقطة نفسها؟ هذا جهاز كتلة افتراضي ، نسخة من الجهاز الأصلي في وقت معين. عند الوصول إلى كتل البيانات على هذا الجهاز ، يمكن قراءتها إما من الأداة الإضافية أو من الجهاز الأصلي.

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

على سبيل المثال ، يمكننا الحصول على خريطة للكتل المشغولة من نظام الملفات. أسهل طريقة للقيام بذلك هي استخدام ioctl GETFSMAP .
تسمح لك البيانات الموجودة على الكتل المشغولة بقراءة أحدث البيانات فقط من لقطة.

يمكنك أيضًا استبعاد بعض الملفات. حسنًا ، إجراء اختياري تمامًا: قم بفهرسة الملفات التي تقع في النسخة الاحتياطية ، لإمكانية إنشاء مطعم حبيبي في المستقبل.

CoW مقابل RoW

دعنا نتحدث قليلاً عن اختيار خوارزمية اللقطة. الاختيار هنا ليس واسع النطاق: نسخ عند الكتابة أو إعادة توجيه عند الكتابة .

إعادة التوجيه عند الكتابة عند اعتراض طلب كتابة سيعيد توجيهه إلى المفاجئة ، وبعد ذلك ستذهب جميع طلبات قراءة هذه الكتلة أيضًا. خوارزمية رائعة لأنظمة التخزين مبنية على أساس أشجار B + ، مثل BTRFS و ZFS و Thin Provisioning. التكنولوجيا قديمة قدم العالم ، لكنها تتجلى بشكل جيد بشكل خاص في برامج مراقبة الأجهزة الافتراضية ، حيث يمكنك إنشاء ملف جديد وكتابة كتل جديدة هناك طوال مدة اللقطة. الأداء ممتاز مقارنة ب CoW. ولكن هناك نقصًا في الدهون - يتغير هيكل الجهاز الأصلي ، وعند إزالة اللقطة ، تحتاج إلى نسخ جميع الكتل من اللقطة إلى الموقع الأصلي.

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

نظرًا لأن سلامة البيانات هي أولويتنا القصوى ، فقد ركزنا على CoW.

حتى الآن ، يبدو كل شيء بسيطًا ، لذلك دعونا نتناول مشاكل الحياة الواقعية.

كيف يعمل - في الممارسة

حالة متسقة

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

لكننا نعيش في القرن الواحد والعشرين! هناك آليات تسجيل تحمي من مثل هذه المشاكل! الحقيقة هي أن هناك "لكن" مهم: هذه الحماية ليست من الفشل ، ولكن من عواقبها. عند الاستعادة إلى حالة متسقة وفقًا للسجل ، سيتم تجاهل العمليات غير المكتملة ، مما يعني أنها ستفقد. لذلك ، من المهم تحويل الأولوية للحماية من السبب ، بدلاً من معالجة العواقب.

يمكن تحذير النظام من أنه سيتم إنشاء لقطة الآن. لهذا ، النواة لها وظائف freeze_bdev و thaw_bdev . يسحبون وظائف نظام الملفات freeze_fs و unfreeze_fs. عند استدعاء الأول ، يجب على النظام إعادة تعيين ذاكرة التخزين المؤقت ، وتعليق إنشاء الطلبات الجديدة إلى جهاز الحظر وانتظار اكتمال جميع الطلبات التي تم إنشاؤها مسبقًا. وعندما يتم استدعاء Unfreeze_fs ، يستعيد نظام الملفات وظيفته الطبيعية.

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

أين تضع المفاجئة؟

هذه هي المشكلة الثانية التي تقف في طريقنا. للوهلة الأولى ، المشكلة ليست واضحة ، ولكن بعد قليل من الفهم ، نرى أن هذا لا يزال منشقًا.

بالطبع ، الحل الأسهل هو وضع الأداة في ذاكرة الوصول العشوائي. بالنسبة للمطور ، الخيار رائع! كل شيء سريع ومناسب للغاية للقيام بتصحيح الأخطاء ، ولكن هناك دعامة: ذاكرة الوصول العشوائي هي مورد قيم ، ولن يمنحنا أحد فرصة كبيرة هناك.

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

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

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

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

هناك مكالمة نظام خاطئة تسمح لك بإنشاء ملف فارغ بالحجم المطلوب. ومع ذلك ، في الواقع ، يتم إنشاء بيانات التعريف فقط على نظام الملفات الذي يصف موقع الملف على وحدة التخزين. و ioctl FIEMAP يسمح لنا بالحصول على خريطة لموقع كتل الملفات.

و voila: نقوم بإنشاء ملف تحت المفاجئة باستخدام Fallocate ، يمنحنا FIEMAP خريطة لموقع كتل هذا الملف ، والتي يمكننا نقلها للعمل في وحدة veeamsnap الخاصة بنا. علاوة على ذلك ، عند الوصول إلى snapstor ، تقوم الوحدة بعمل الطلبات مباشرة إلى جهاز الحظر في كتل معروفة لنا ، ولا توجد جمود.

ولكن هناك فارق بسيط. يتم دعم استدعاء النظام الخاطئ فقط بواسطة XFS و EXT4 و BTRFS. بالنسبة لأنظمة الملفات الأخرى مثل EXT3 ، يجب عليك كتابتها بالكامل لتخصيص الملف. تتأثر الوظيفة بزيادة الوقت لإعداد snappads ، ولكن لا يوجد خيار. مرة أخرى ، يجب أن تكون قادرًا على العمل على ما هو.

ماذا لو لم يتم دعم ioctl FIEMAP؟ هذه هي حقيقة NTFS و FAT32 ، حيث لا يوجد حتى دعم لـ FIBMAP القديم. اضطررت إلى تنفيذ خوارزمية عامة معينة ، لا يعتمد تشغيلها على ميزات نظام الملفات. باختصار ، الخوارزمية هي:

1. تقوم الخدمة بإنشاء ملف وتبدأ في كتابة نمط معين له.
2. تعترض الوحدة طلبات الكتابة ، وتتحقق من البيانات التي تتم كتابتها.
3. إذا كانت بيانات الكتلة مطابقة للنمط المحدد ، فسيتم وضع علامة على الكتلة على أنها تنتمي إلى الأداة الإضافية.

نعم ، صعب ، نعم ، ببطء ، لكن أفضل من لا شيء. يتم استخدامه في حالات نادرة لأنظمة الملفات دون دعم FIEMAP و FIBMAP.

تجاوز اللقطة

بدلا من ذلك ، ينتهي المكان الذي خصصناه تحت متجر سنابور. جوهر المشكلة هو أنه لا يوجد مكان لتجاهل البيانات الجديدة ، مما يعني أن اللقطة تصبح غير قابلة للاستخدام.
ما يجب القيام به

من الواضح أنك بحاجة إلى زيادة حجم snappants. بكم؟ أسهل طريقة لتعيين حجم snappants هي تحديد النسبة المئوية للمساحة الحرة على وحدة التخزين (كما هو الحال في VSS). بالنسبة لوحدة التخزين التي تبلغ 20 تيرابايت ، فإن 10٪ ستكون 2 تيرابايت - وهي كمية كبيرة لخادم غير محمل. بالنسبة إلى سعة تخزين تبلغ 200 غيغابايت ، فإن 10٪ هي 20 غيغابايت ، والتي قد تكون قليلة جدًا على خادم يقوم بتحديث بياناته بشكل مكثف. ولا تزال هناك أحجام رقيقة ...

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

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



مرة أخرى ، باختصار الخوارزمية:

1. قبل إنشاء لقطة ، يتم إنشاء الجزء الأول من اللقطة وإعطائه للوحدة النمطية.
2. عندما يتم إنشاء اللقطة ، سيبدأ الجزء بالامتلاء.
3. بمجرد اكتمال نصف الجزء ، يتم إرسال طلب إلى الخدمة لإنشاء جزء جديد.
4. تقوم الخدمة بإنشائه ، وتعطي البيانات للوحدة النمطية.
5. تبدأ الوحدة بتعبئة الدفعة التالية.
6. يتم تكرار الخوارزمية حتى اكتمال النسخ الاحتياطي ، أو حتى نصل إلى الحد الأقصى لاستخدام مساحة القرص الحرة.

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

ماذا تفعل في حالات أخرى؟ نحن نحاول تخمين الحجم المطلوب وإنشاء snappast بالكامل. ولكن وفقًا لإحصاءاتنا ، فإن الغالبية العظمى من خوادم Linux تستخدم الآن EXT4 و XFS. تم العثور على EXT3 على الأجهزة القديمة. ولكن في SLES / openSUSE يمكنك أن تتعثر في BTRFS.

تغيير تتبع الكتلة (CBT)

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



الكثير منهم لديهم خبرة خاصة بهم في هذا المجال. على سبيل المثال ، في VMware vSphere ، كانت هذه الميزة متاحة منذ الإصدار 4 في عام 2009. في Hyper-V ، تم تقديم الدعم مع Windows Server 2016 ، ولدعم الإصدارات السابقة ، تم تطوير برنامج تشغيل VeeamFCT الخاص به مرة أخرى في عام 2012. لذلك ، بالنسبة للوحدة النمطية الخاصة بنا ، لم نصبح أصلاً وخوارزميات تعمل بالفعل.
حول كيفية عملها.



يتم تقسيم الحجم المتتبع بالكامل إلى كتل. تتبع الوحدة ببساطة جميع طلبات الكتابة ، مع وضع علامة على الكتل المتغيرة في الجدول. في الواقع ، جدول CBT عبارة عن صفيف من البايت ، حيث يتوافق كل بايت مع كتلة ويحتوي على عدد اللقطة التي تم تغييرها فيها.
أثناء النسخ الاحتياطي ، يتم تسجيل رقم اللقطة في البيانات الوصفية للنسخ الاحتياطي. وبالتالي ، معرفة عدد اللقطة الحالية والنسخة التي تم عمل النسخ الاحتياطي الناجح السابق منها ، يمكنك حساب خريطة موقع الكتل المتغيرة.

هناك نوعان من الفروق الدقيقة.

كما قلت ، يتم تخصيص بايت واحد لرقم اللقطة في جدول CBT ، مما يعني أن الحد الأقصى لطول السلسلة الإضافية لا يمكن أن يكون أكثر من 255. عند الوصول إلى هذا الحد ، يتم إعادة تعيين الجدول ويحدث نسخ احتياطي كامل. قد يبدو الأمر غير مريح ، ولكن في الواقع ، فإن سلسلة من 255 زيادة هي أبعد ما تكون عن الحل الأفضل عند إنشاء خطة احتياطية.
الميزة الثانية هي تخزين جدول CBT في ذاكرة الوصول العشوائي فقط. لذلك ، عند إعادة تشغيل الجهاز الهدف أو إلغاء تحميل الوحدة النمطية ، سيتم إعادة تعيينها ، ومرة ​​أخرى ، ستحتاج إلى إنشاء نسخة احتياطية كاملة. يسمح هذا الحل بعدم حل مشكلة بدء تشغيل الوحدة عند بدء تشغيل النظام. بالإضافة إلى ذلك ، ليست هناك حاجة لحفظ جداول CBT عند إيقاف تشغيل النظام.

مشكلة في الأداء

النسخ الاحتياطي هو دائمًا حمل جيد على IO الخاص بمعداتك. إذا كانت هناك بالفعل مهام نشطة كافية عليه ، فيمكن لعملية النسخ الاحتياطي أن تحول نظامك إلى نوع من الكسل .
دعونا نرى لماذا.

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

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



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

خنق

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



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

طريق مسدود

أعتقد أننا بحاجة إلى شرح ما هو أكثر تفصيلاً.

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

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



في هذه الحالة ، عند اعتراض طلب كتابة ، سترسل الوحدة النمطية ، التي تنسخ البيانات إلى الأداة الإضافية ، طلب الكتابة إلى وحدة تخزين LVM. سيعيد مخطط الجهاز توجيه هذا الطلب إلى جهاز الحظر. سيتم اعتراض الطلب من مخطط الجهاز مرة أخرى بواسطة الوحدة. ولكن لا يمكن معالجة طلب جديد حتى تتم معالجة الطلب السابق. ونتيجة لذلك ، يتم حظر معالجة الطلب ، ويتم الترحيب بك من خلال طريق مسدود.

لمنع حدوث هذا الموقف ، توفر وحدة kernel نفسها مهلة لتشغيل نسخ البيانات إلى الأداة الإضافية. هذا يسمح لك باكتشاف الجمود والنسخ الاحتياطي التعطل. المنطق هنا هو نفسه: من الأفضل عدم النسخ الاحتياطي بدلاً من تعليق الخادم.

قاعدة بيانات روبن جولة

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



بطبيعة الحال ، قمنا بتغيير الخوارزمية. الآن يتم تقسيم وحدة التخزين إلى كتل ، ويتم نسخ البيانات إلى كتلة المفاجئة. إذا تم نسخ الكتلة بالفعل مرة واحدة ، فلن تتكرر هذه العملية.

اختيار حجم الكتلة

الآن ، عندما يتم تقسيم snapstrap إلى كتل ، يطرح السؤال: ما هو ، في الواقع ، حجم الكتل التي يتم إنشاؤها لكسر snapplugs؟

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



من الواضح أنه كلما صغر حجم الكتلة ، زادت النسبة المئوية للبيانات المفيدة المرسلة إلى snapstore ، ولكن كيف ستصل إلى الأداء؟

لقد بحثوا عن الحقيقة تجريبيًا وخرجوا بـ 16 كيلوبايت. لاحظ أيضًا أن Windows VSS يستخدم أيضًا 16 كتلة KiB.

بدلا من الاستنتاج

هذا كل شيء الآن. سأترك الكثير من المشاكل الأخرى ، التي لا تقل إثارة للاهتمام ، مثل الاعتماد على إصدارات kernel ، واختيار خيارات توزيع الوحدة ، وتوافق kabi ، والعمل في ظروف المنفذ الخلفي ، وما إلى ذلك. تبين أن المقال ضخم ، لذلك قررت أن أتناول المشاكل الأكثر إثارة للاهتمام.

الآن نحن نستعد للإصدار 3.0 ، رمز الوحدة النمطية على github ، ويمكن لأي شخص استخدامه بموجب ترخيص GPL.