في ربيع هذا العام، وقد سبق بعض المواضيع التمهيدية، مثل كما كيفية التحقق من سرعة الأقراص و ما RAID هو . في الثاني منها ، وعدنا بمواصلة دراسة أداء مختلف الهياكل المتعددة الأقراص في ZFS. هذا هو نظام ملفات الجيل التالي الذي يتم تطبيقه في كل مكان: من Apple إلى Ubuntu .

حسنًا ، اليوم هو أفضل يوم للتعرف على ZFS ، القراء الفضوليين. فقط كن على علم أنه ، وفقًا لتقييم محافظ من قبل مطور OpenZFS Matt Arens ، "الأمر معقد حقًا".

ولكن قبل أن نصل إلى الأرقام - وسوف أعدك - لجميع المتغيرات vosmidiskovoy ZFS التكوين ، تحتاج إلى الحديث عن كيفية القيام بتخزين البيانات ZFS على القرص.

Zpool و vdev والجهاز

يتضمن هذا الرسم التخطيطي الكامل للتجمع ثلاثة ملفات vdev مساعدة ، واحدة لكل فئة ، وأربعة لـ RAIDz2.

لا يوجد عادة سبب لإنشاء مجموعة من أنواع وأحجام vdev غير المناسبة - ولكن إذا أردت ، فلا شيء يمنعك من القيام بذلك.

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

zpool

تعتبر مجموعة تخزين zpool أعلى بنية ZFS. يحتوي كل تجمع على جهاز ظاهري واحد أو أكثر. في المقابل ، يحتوي كل واحد منهم على جهاز واحد أو أكثر (جهاز) حقيقي. التجمعات الافتراضية هي كتل مستقلة. قد يحتوي جهاز كمبيوتر فعلي على مجموعتين منفصلتين أو أكثر ، ولكن كل منهما مستقل تمامًا عن الآخرين. لا يمكن للتجمعات مشاركة الأجهزة الافتراضية.

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

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

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

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

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

vdev

يتكون كل تجمع تخزين من جهاز ظاهري واحد أو أكثر (جهاز ظاهري ، vdev). في المقابل ، يتضمن كل vdev جهازًا حقيقيًا أو أكثر. يتم استخدام معظم الأجهزة الافتراضية لتخزين البيانات بسهولة ، ولكن هناك العديد من فئات vdev المساعدة ، بما في ذلك CACHE و LOG و SPECIAL. يمكن أن يكون لكل نوع من أنواع vdev أحد خمسة طبولوجيا: جهاز واحد أو RAIDz1 أو RAIDz2 أو RAIDz3 أو مرآة.

RAIDz1 و RAIDz2 و RAIDz3 هي اختلافات خاصة لما يسميه كبار السن التكافؤ المزدوج (القطري). تشير 1 و 2 و 3 إلى عدد كتل التماثل المخصصة لكل نطاق بيانات. بدلاً من الأقراص المنفصلة للتماثل ، تقوم أجهزة RAIDz الافتراضية بتوزيع هذا التماثل بالتساوي عبر الأقراص. يمكن أن تفقد صفيف RAIDz العديد من الأقراص كما كتل التماثل؛ إذا فقد واحدًا آخر ، فسوف يفشل ويأخذ معه حوض التخزين.

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

vdevs واحدة خطيرة بطبيعتها. لن ينجو مثل هذا الجهاز الافتراضي من فشل واحد - وإذا تم استخدامه كمخزن أو vdev خاص ، فإن فشله سيؤدي إلى تدمير المجموعة بأكملها. كن حذرا جدا هنا.

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

جهاز

من المحتمل أن يكون هذا هو المصطلح الأسهل لفهمه في ZFS - فهو حرفياً جهاز وصول عشوائي عشوائي. تذكر أن الأجهزة الافتراضية تتكون من أجهزة فردية ، وتتكون المجموعة من أجهزة افتراضية.

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

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

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

لنفترض أنك تريد وضع خادم على ثمانية أقراص وتخطط لاستخدام 10 أقراص TB (~ 9300 غيغابايت) - ولكنك لست متأكدًا من طوبولوجيا يناسب احتياجاتك. في المثال أعلاه ، في غضون ثوانٍ ، نبني مجموعة اختبار من ملفات متفرقة - والآن نعلم أن RAIDz2 vdev من ثمانية محركات أقراص سعة 10 تيرابايت توفر سعة 50 تيرابايت مفيدة.

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

بعد الاتصال بـ vdev المتأثر ، يبدأ الجهاز الاحتياطي في تلقي نسخ أو إعادة بناء البيانات التي يجب أن تكون على الجهاز المفقود. في RAID التقليدي ، يسمى هذا إعادة البناء ، بينما في ZFS يطلق عليه "resilvering".

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

مجموعات البيانات والكتل والقطاعات

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

مجموعة البيانات

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

تعد Zvol في الغالب مجرد مجموعة بيانات ، خالية من طبقة نظام الملفات الخاصة بها ، والتي نستبدلها هنا

بنظام ملفات ext4 عادي تمامًا . مجموعة بيانات ZFS هي تقريبًا نفس نظام الملفات القياسي المثبت. مثل نظام الملفات العادي ، يبدو للوهلة الأولى أنه "مجرد مجلد آخر". ولكن أيضًا ، مثل أنظمة الملفات التقليدية المركبة ، تحتوي كل مجموعة بيانات ZFS على مجموعة خاصة بها من الخصائص الأساسية.

بادئ ذي بدء ، قد يكون لمجموعة البيانات حصة مخصصة. إذا تم التثبيتzfs set quota=100G poolname/datasetname، فلا يمكنك الكتابة إلى المجلد المحمّل/poolname/datasetnameأكثر من 100 غيغابايت.

هل تلاحظ وجود - وغياب - خطوط مائلة في بداية كل سطر؟ كل مجموعة بيانات لها مكانها الخاص في التسلسل الهرمي ZFS وفي التسلسل الهرمي لتركيب النظام. لا يوجد خط مائل أولي في التسلسل الهرمي لـ ZFS - تبدأ باسم التجمع ، ثم المسار من مجموعة بيانات إلى المجموعة التالية. على سبيل المثال ، pool/parent/childبالنسبة لمجموعة بيانات مسماة childضمن مجموعة البيانات الرئيسية parentفي تجمع باسم إبداعي pool.

افتراضيا، جبل ونقطة مجموعة البيانات معادلا لاسمها في التسلسل الهرمي ZFS، بخط مائل في البداية - والتجمع مع اسم poolشنت كما /pool، ومجموعة البيانات parentالتي شنت في /pool/parent، والطفل مجموعة البيانات هي التي شنت childفي /pool/parent/child. ومع ذلك ، يمكن تغيير نقطة تحميل النظام لمجموعة البيانات.

إذا أشرناzfs set mountpoint=/lol pool/parent/child، ثم يتم pool/parent/childتركيب مجموعة البيانات في النظام باسم /lol.

بالإضافة إلى مجموعات البيانات ، يجب أن نذكر المجلدات (zvols). تشبه وحدة التخزين تقريبًا مجموعة البيانات ، باستثناء أنها في الواقع لا تحتوي على نظام ملفات - فهي مجرد جهاز كتلة. يمكنك ، على سبيل المثال ، إنشاء zvolاسم mypool/myzvol، ثم تنسيقه باستخدام نظام الملفات ext4 ، ثم تحميل نظام الملفات هذا - الآن لديك نظام الملفات ext4 ، ولكن مع دعم جميع ميزات الأمان ZFS! قد يبدو هذا سخيفًا على جهاز كمبيوتر واحد ، ولكن من المنطقي أكثر أنه الواجهة الخلفية عند تصدير جهاز iSCSI.

كتل

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

نحن حقا، حقا هي لا يمزح حول الضرر أداء كبير إذا قمت بتثبيت ashift صغيرة جدا

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

ما لم يذكر خلاف ذلك ، يكون حجم التسجيل الحالي هو 128 كيلوبايت افتراضيًا. هذا نوع من الحلول الوسط الصعبة التي لن يكون الأداء فيها مثاليًا ، ولكن ليس رهيبًا في معظم الحالات. Recordsizeيمكن تعيينه على أي قيمة من 4K إلى 1M (مع إعدادات إضافية recordsizeيمكنك تعيين المزيد ، ولكن نادرًا ما تكون هذه فكرة جيدة).

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

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

لا تحتوي مجلدات Zvol على خاصية recordsize - بدلاً من ذلك لها خاصية مكافئة volblocksize.

القطاعات

القطاع الأخير هو لبنة البناء الأساسية. هذه أصغر وحدة مادية يمكن كتابتها أو قراءتها من الوحدة الأساسية. لعدة عقود ، استخدمت معظم الأقراص قطاعات 512 بايت. في الآونة الأخيرة ، تم تكوين معظم محركات الأقراص لقطاعات 4 KiB ، وفي بعض - خاصة SSDs - 8 قطاعات KiB أو أكثر.

ZFS لديه خاصية تسمح لك بتعيين حجم القطاع يدويًا. هذه ملكية ashift. من المربك إلى حد ما أن الرماد قوة من اثنين. على سبيل المثال ، هذا ashift=9يعني حجم قطاع 2 ^ 9 أو 512 بايت.

تطلب ZFS نظام التشغيل للحصول على معلومات تفصيلية حول كل جهاز كتلة عند إضافته إلى vdev الجديد ، ويقوم تلقائيًا نظريًا بتعيين ashift بشكل صحيح بناءً على هذه المعلومات. لسوء الحظ ، تكمن العديد من الأقراص حول حجم قطاعها من أجل الحفاظ على التوافق مع Windows XP (الذي كان غير قادر على فهم الأقراص ذات أحجام القطاعات الأخرى).

هذا يعني أن مسؤول ZFS ينصح بشدة بمعرفة حجم القطاع الفعلي لأجهزتهم وتثبيته يدويًاashift. إذا تم تعيين الرماد صغير جدًا ، فسيزداد عدد عمليات القراءة / الكتابة بشكل فلكي. لذا ، فإن كتابة "قطاعات" 512 بايت إلى قطاع 4 KiB الحقيقي يعني كتابة "القطاع" الأول ، ثم قراءة قطاع 4 KiB ، وتغييره مع "قطاع" 512 بايت الثاني ، وإعادة كتابته إلى قطاع 4 KiB الجديد ، وهكذا لكل دخول.

في العالم الحقيقي ، تتفوق مثل هذه العقوبة على أجهزة Samsung EVO ashift=13SSDs ، التي يجب أن تعمل من أجلها ، ولكن هذه الأقراص الصلبة تكمن حول حجم قطاعها ، وبالتالي يتم تعيينها افتراضيًا ashift=9. إذا لم يغير مسؤول النظام المتمرس هذا الإعداد ، فإن محرك الأقراص SSD هذا أبطأ من محرك الأقراص الثابتة المغناطيسي العادي.

للمقارنة ، لحجم كبير جداashiftلا توجد عقوبة تقريبا. لا يوجد انخفاض حقيقي في الإنتاجية ، وتكون الزيادة في المساحة غير المستخدمة صغيرة بشكل لا نهائي (أو تساوي الصفر مع تمكين الضغط). لذلك ، نوصي بشدة أن يتم تثبيت حتى محركات الأقراص التي تستخدم قطاعات 512 بايت بالفعل ashift=12أو حتى ashift=13للنظر بثقة في المستقبل.

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

— ,

, , « » « »,

, — , ,

النسخ على الكتابة (CoW) هو الأساس الأساسي لما يجعل ZFS رائعًا جدًا. المفهوم الأساسي بسيط - إذا طلبت من نظام الملفات التقليدي تعديل الملف ، فسيقوم بالضبط بما طلبته. إذا طلبت من نظام الملفات مع النسخ أثناء التسجيل أن يفعل الشيء نفسه ، فسوف يقول "جيد" - لكنه سيكذب عليك.

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

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

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

ZIL: ZFS Intent Log

ZFS — , ZIL,

, ZIL, .

SLOG, LOG-, — — , , — vdev, ZIL

ZIL — ZIL SLOG,

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

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

يعامل ZFS السجلات المتزامنة بشكل مختلف عن أنظمة الملفات العادية - بدلاً من تحميلها على الفور إلى التخزين العادي ، يسجلها ZFS في منطقة تخزين خاصة تسمى سجل intent ZFS - سجل Intent ZFS أو ZIL. الحيلة هي أن هذه السجلات تظل أيضًا في الذاكرة ، ويتم تجميعها جنبًا إلى جنب مع طلبات الكتابة غير المتزامنة العادية ، ليتم تفريغها لاحقًا في التخزين مثل TXGs العادية تمامًا (مجموعات المعاملات ، مجموعات المعاملات).

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

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

واحدة من فئات المساعد vdev تسمى LOG أو SLOG ، جهاز LOG الثانوي. لديه مهمة واحدة - لتزويد المجمع بمجموعة منفصلة ، ويفضل أن يكون أسرع بكثير ، مع مقاومة عالية للكتابة ، جهاز vdev لتخزين ZIL ، بدلاً من تخزين ZIL في تخزين vdev الرئيسي. تتصرف ZIL نفسها كما هي بغض النظر عن موقع التخزين ، ولكن إذا كان vdev مع LOG لديه أداء كتابة عالي جدًا ، فإن عمليات الكتابة المتزامنة ستكون أسرع.

لا يمكن أن تؤدي إضافة vdev مع LOG إلى التجمع إلى تحسين أداء الكتابة غير المتزامن - حتى إذا قمت بإجبار جميع عمليات الكتابة إلى ZIL باستخدام zfs set sync=always، فسيظلون مرتبطين بالمخزن الرئيسي في TXG بنفس الطريقة وبنفس السرعة كما هو الحال بدون سجل. تحسين الأداء المباشر الوحيد هو التأخير في التسجيل المتزامن (لأن سرعة السجل الأعلى تسرع العمليات sync).

ومع ذلك ، في بيئة تتطلب بالفعل عددًا كبيرًا من عمليات الكتابة المتزامنة ، يمكن لـ vdev LOG تسريع عمليات الكتابة غير المتزامنة والقراءات غير المتزامنة بشكل غير مباشر. إن تحميل سجلات ZIL إلى سجل vdev LOG منفصل يعني منافسة أقل على IOPS في التخزين الأساسي ، مما يحسن إلى حد ما أداء جميع عمليات القراءة والكتابة.

لقطات

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

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

تكرار

Steam 2015 158 126 927 . rsync — ZFS « » 750% .

40- Windows 7 — . ZFS 289 , rsync — «» 161 , , rsync --inplace.

, rsync . 1,9 — , ZFS 1148 , rsync, rsync --inplace

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

كل شيء يصبح أكثر إثارة للاهتمام في الثانية zfs send. الآن لدينا نظامان ، يحتوي كل منهما على poolname/datasetname@1لقطة جديدة poolname/datasetname@2. لذلك، في حوض السباحة مصدر لديك datasetname@1و datasetname@2، وفي التجمع هدف حتى الآن سوى لقطة الأولى datasetname@1.

نظرًا لأن لدينا لقطة مشتركة بين المصدر والهدفdatasetname@1، يمكننا أن نفعل تدريجية zfs send فوقها. عندما نخبر النظام zfs send -i poolname/datasetname@1 poolname/datasetname@2، يقارن بين شجرتين من مؤشرات المؤشر. من @2الواضح أن أي مؤشرات موجودة فقط في الكتل الجديدة تشير إلى كتل جديدة - لذا نحتاج إلى محتويات هذه الكتل.

على نظام بعيد ، تكون المعالجة الإضافية sendبنفس البساطة. أولاً ، نسجل جميع الإدخالات الجديدة المدرجة في الدفق send، ثم نضيف مؤشرات إلى هذه الكتل. فويلا ، في نظامنا @2الجديد!

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

ضغط مضمن

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

إذا كنت تفكر في جزء من البيانات في منتصف ملف يبدأ حياته كميغابايت من الأصفار من 0x00000000 وهكذا - فمن السهل جدًا ضغطه على قطاع واحد على القرص. ولكن ماذا يحدث إذا استبدلنا هذا الميغابايت من الأصفار بميغابايت من البيانات غير القابلة للضغط مثل JPEG أو الضوضاء العشوائية الزائفة؟ فجأة ، لن يتطلب هذا الميغابايت من البيانات واحدًا ، ولكن 256 قطاعًا من 4 KiB ، وفي هذا المكان على القرص ، يتم حجز قطاع واحد فقط.

لا يوجد لدى ZFS مثل هذه المشكلة ، حيث يتم دائمًا كتابة السجلات التي تم تغييرها إلى مساحة غير مستخدمة - تحتل الكتلة الأصلية مقطعًا واحدًا فقط من 4 كيلوبايت ، وسيستغرق السجل الجديد 256 ، ولكن هذه ليست مشكلة - سيتم كتابة جزء تم تغييره مؤخرًا من منتصف الملف في مساحة غير مستخدمة بغض النظر عما إذا كان حجمه قد تغير أم لا ، لذلك بالنسبة لـ ZFS فهذا وضع طبيعي.

يتم تعطيل ضغط ZFS المدمج افتراضيًا ، ويوفر النظام خوارزميات المكونات الإضافية - من بينها LZ4 و gzip (1-9) و LZJB و ZLE.

LZ4 هي خوارزمية دفق توفر ضغطًا وفك ضغطًا سريعًا للغاية ومكاسب في الأداء لمعظم حالات الاستخدام - حتى على وحدات المعالجة المركزية البطيئة إلى حد ما.
GZIP — , Unix-. 1-9, CPU 9. ( ) , c CPU — , .
LZJB — ZFS. , LZ4 .
ZLE - ترميز مستوى الصفر ، ترميز مستوى الصفر. لا يلمس البيانات العادية على الإطلاق ، ولكنه يضغط تسلسلات كبيرة من الأصفار. مفيد لمجموعات البيانات غير القابلة للضغط تمامًا (على سبيل المثال ، JPEG أو MP4 أو غيرها من التنسيقات المضغوطة بالفعل) ، لأنها تتجاهل البيانات غير القابلة للضغط ، ولكنها تضغط المساحة غير المستخدمة في السجلات الناتجة.

نوصي بضغط LZ4 لجميع حالات الاستخدام تقريبًا ؛ عقوبة الأداء لمواجهة البيانات غير القابلة للضغط صغيرة جدًا ، ومكاسب الأداء للبيانات النموذجية كبيرة. نسخ صورة آلة افتراضية لتثبيت جديد لنظام التشغيل Windows (نظام تشغيل مثبت حديثًا ، ولا توجد بيانات بداخله بعد) compression=lz4بنسبة 27٪ أسرع مما كانت عليه compression=noneفي اختبار 2015 هذا .

ARC - ذاكرة التخزين المؤقت البديلة التكيفية

ZFS هو نظام الملفات الحديث الوحيد المعروف لنا والذي يستخدم آلية التخزين المؤقت للقراءة الخاصة به ، ولا يعتمد على ذاكرة التخزين المؤقت لصفحة نظام التشغيل لتخزين نسخ من الكتل التي تم قراءتها مؤخرًا في ذاكرة الوصول العشوائي.

على الرغم من أن ذاكرة التخزين المؤقت الخاصة به لا تخلو من مشاكله - لا يمكن لـ ZFS الاستجابة لطلبات تخصيص الذاكرة الجديدة بسرعة kernel ، لذلك malloc()قد تفشل مكالمة تخصيص ذاكرة جديدة إذا كانت تحتاج إلى ذاكرة الوصول العشوائي المشغولة حاليًا بواسطة ARC. ولكن هناك أسباب جيدة لاستخدام ذاكرة التخزين المؤقت الخاصة بك ، على الأقل في الوقت الحالي.

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

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

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

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

استنتاج

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

في الجزء التالي ، سنلقي نظرة على الأداء الفعلي للمجمعات مع vdev المتطابق و RAIDz ، مقارنة مع بعضها البعض ، وكذلك بالمقارنة مع طوبولوجيا نواة RAID التقليدية لـ Linux kernel ، والتي درسناها سابقًا .

في البداية ، أردنا النظر فقط في الأساسيات - طبولوجيا ZFS نفسها - ولكن بعد ذلك سنكون على استعداد للحديث عن ضبط وضبط ZFS الأكثر تقدمًا ، بما في ذلك استخدام أنواع vdev الإضافية مثل L2ARC و SLOG و Special Allocation.

أساسيات ZFS: التخزين والأداء