لقد ناقشنا بالفعل هذا الربيع بعض الموضوعات التمهيدية ، على سبيل المثال ، и . في الثاني منها ، وعدنا بمواصلة دراسة أداء الهياكل متعددة الأقراص في ZFS. هذا هو الجيل التالي من نظام الملفات الذي يتم تنفيذه الآن في كل مكان: from إلى .
حسنًا ، اليوم هو أفضل يوم للتعرف على القراء الفضوليين ZFS. فقط اعلم أنه في الرأي المتواضع لمطور OpenZFS Matt Ahrens ، "إنه صعب حقًا."
ولكن قبل أن نصل إلى الأرقام - وسيفعلون ذلك ، أعدك - بالنسبة لجميع الخيارات الخاصة بتكوين ZFS المكون من ثمانية أقراص ، نحتاج إلى التحدث عن كيف بشكل عام ، يقوم ZFS بتخزين البيانات على القرص.
Zpool و vdev والجهاز
يتضمن مخطط التجمع الكامل هذا ثلاثة vdevs مساعدة ، واحدة من كل فئة ، وأربعة لـ RAIDz2
عادة لا يوجد سبب لإنشاء مجموعة من أنواع وأحجام vdev غير المتطابقة - ولكن لا يوجد ما يمنعك من القيام بذلك إذا كنت ترغب في ذلك.
لفهم نظام ملفات ZFS حقًا ، تحتاج إلى إلقاء نظرة فاحصة على هيكله الفعلي. أولاً ، يوحد ZFS المستويات التقليدية لإدارة نظام الحجم والملفات. ثانيًا ، يستخدم آلية نسخ عند الكتابة للمعاملات. تعني هذه الميزات أن النظام مختلف جدًا من الناحية الهيكلية عن أنظمة الملفات التقليدية ومصفوفات RAID. المجموعة الأولى من اللبنات الأساسية التي يجب فهمها هي مجموعة التخزين (zpool) ، والجهاز الظاهري (vdev) ، والجهاز الحقيقي (الجهاز).
zpool
تجمع تخزين zpool هو أعلى هيكل ZFS. يحتوي كل تجمع على جهاز افتراضي واحد أو أكثر. في المقابل ، يحتوي كل منهم على جهاز حقيقي واحد أو أكثر (جهاز). التجمعات الافتراضية هي كتل قائمة بذاتها. يمكن أن يحتوي جهاز كمبيوتر مادي واحد على مجموعتين منفصلتين أو أكثر ، لكن كل واحدة مستقلة تمامًا عن الأخرى. لا يمكن للتجمعات مشاركة الأجهزة الافتراضية.
يتم تكرار ZFS على مستوى الجهاز الظاهري ، وليس على مستوى التجمع. لا يوجد أي تكرار على الإطلاق على مستوى التجمع - في حالة فقد أي محرك أقراص vdev أو vdev خاص ، فسيتم فقد التجمع بأكمله معه.
يمكن أن تنجو تجمعات التخزين الحديثة من فقدان ذاكرة التخزين المؤقت أو سجل الجهاز الظاهري - على الرغم من أنها يمكن أن تفقد قدرًا صغيرًا من البيانات القذرة إذا فقدت سجل vdev أثناء انقطاع التيار الكهربائي أو تعطل النظام.
هناك اعتقاد خاطئ شائع بأن "خطوط بيانات" ZFS مكتوبة عبر المجموعة بأكملها. هذا ليس صحيحا. Zpool ليس مضحكًا RAID0 على الإطلاق ، إنه مضحك إلى حد ما مع آلية توزيع متغيرة معقدة.
بالنسبة للجزء الأكبر ، يتم توزيع الإدخالات على الأجهزة الافتراضية المتاحة وفقًا للمساحة الخالية المتاحة ، لذلك من الناحية النظرية سيتم ملؤها جميعًا في نفس الوقت. في الإصدارات الأحدث من ZFS ، يتم أخذ استخدام vdev الحالي (الاستخدام) في الاعتبار - إذا كان أحد الأجهزة الافتراضية أكثر انشغالًا من الآخر (على سبيل المثال ، بسبب حمل القراءة) ، فسيتم تخطيه مؤقتًا للكتابة ، على الرغم من وجود أعلى مستوى مجاني نسبة الفضاء.
يمكن لآلية اكتشاف الاستخدام المضمنة في أساليب تخصيص الكتابة ZFS الحديثة أن تقلل من زمن الوصول وتزيد الإنتاجية خلال فترات الحمل العالي بشكل غير عادي - لكنها لا تفعل ذلك تفويض مطلق على الخلط غير الطوعي لمحركات الأقراص الثابتة البطيئة ومحركات الأقراص الثابتة السريعة في مجموعة واحدة. سيظل هذا التجمع غير المتكافئ يعمل بسرعة أبطأ جهاز ، أي كما لو كان مكونًا بالكامل من مثل هذه الأجهزة.
com.vdev
يتكون كل تجمع تخزين من جهاز ظاهري واحد أو أكثر (جهاز افتراضي ، vdev). في المقابل ، يحتوي كل vdev على جهاز حقيقي واحد أو أكثر. تُستخدم معظم الأجهزة الافتراضية لتخزين البيانات البسيط ، ولكن هناك العديد من فئات مساعد vdev ، بما في ذلك CACHE و LOG و SPECIAL. يمكن أن يكون لكل نوع من أنواع vdev هذه واحدة من خمسة طبولوجيا: جهاز واحد (جهاز واحد) أو RAIDz1 أو RAIDz2 أو RAIDz3 أو مرآة (مرآة).
RAIDz1 و RAIDz2 و RAIDz3 هي أنواع خاصة لما يسميه الموقتون القدامى RAID مزدوج (قطري). تشير 1 و 2 و 3 إلى عدد كتل التكافؤ المخصصة لكل شريط بيانات. بدلاً من الأقراص المنفصلة للتكافؤ ، تقوم أجهزة RAIDz الافتراضية بتوزيع هذا التكافؤ بشكل شبه متساوٍ عبر الأقراص. يمكن أن تفقد مصفوفة RAIDz عددًا من الأقراص مثلها مثل كتل تماثل ؛ إذا فقدت واحدة أخرى ، فسوف تتعطل وتأخذ مجموعة التخزين معها.
في الأجهزة الافتراضية المنعكسة (مرآة vdev) ، يتم تخزين كل كتلة على كل جهاز في vdev. على الرغم من أن المرايا ذات العريضتين هي الأكثر شيوعًا ، إلا أن أي عدد تعسفي من الأجهزة يمكن أن يكون في المرآة - غالبًا ما يتم استخدام ثلاثة أضعاف في التركيبات الكبيرة لتحسين أداء القراءة والتسامح مع الأخطاء. يمكن أن تنجو مرآة vdev من أي فشل طالما استمر جهاز واحد على الأقل في vdev في العمل.
تعد vdevs المنفردة خطيرة بطبيعتها. مثل هذا الجهاز الظاهري لن ينجو من فشل واحد - وإذا تم استخدامه كمخزن أو vdev خاص ، فإن فشله سيؤدي إلى تدمير التجمع بأكمله. كن حذرًا جدًا هنا.
يمكن إنشاء CACHE و LOG و SPECIAL VAs باستخدام أي من الهياكل المذكورة أعلاه - ولكن تذكر أن فقدان SPECIAL VA يعني فقدان التجمع ، لذلك يوصى بشدة باستخدام طوبولوجيا زائدة عن الحاجة.
جهاز
ربما يكون هذا هو أسهل مصطلح يمكن فهمه في ZFS - إنه حرفياً جهاز وصول عشوائي للكتل. تذكر أن الأجهزة الافتراضية تتكون من أجهزة فردية ، بينما تتكون المجموعة من أجهزة افتراضية.
الأقراص - سواء كانت مغناطيسية أو صلبة - هي أجهزة الكتلة الأكثر شيوعًا التي تُستخدم كوحدات بناء لـ vdev. ومع ذلك ، فإن أي جهاز به واصف في / dev سيفعل ذلك ، لذلك يمكن استخدام مصفوفات RAID للأجهزة بالكامل كأجهزة منفصلة.
يعد الملف الخام البسيط أحد أهم أجهزة البلوك البديلة التي يمكن إنشاء vdev منها. حمامات الاختبار من هي طريقة سهلة للغاية للتحقق من أوامر التجمع ومعرفة مقدار المساحة المتوفرة في مجموعة أو جهاز افتراضي لطوبولوجيا معينة.
يمكنك إنشاء مجموعة اختبار من الملفات المتفرقة في ثوانٍ قليلة - ولكن لا تنس حذف المجموعة بأكملها ومكوناتها بعد ذلك
لنفترض أنك تريد وضع خادم على ثمانية أقراص وتخطط لاستخدام أقراص سعة 10 تيرابايت (حوالي 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 ^ التحولإذا كان يحتوي على بيانات وصفية أو ملف صغير.
نحن حقا حقا لا أمزح بشأن عقوبة الأداء الضخمة إذا وضعت رمادًا صغيرًا جدًا
في تجمع ZFS ، يتم تخزين جميع البيانات ، بما في ذلك البيانات الوصفية ، في كتل. يتم تحديد الحد الأقصى لحجم الكتلة لكل مجموعة بيانات في الخاصية recordsize (حجم التسجيل). يمكن تغيير حجم السجل ، لكن هذا لن يغير حجم أو موقع أي كتل تمت كتابتها بالفعل إلى مجموعة البيانات - إنه يؤثر فقط على الكتل الجديدة أثناء كتابتها.
حجم السجل الافتراضي الحالي هو 128 كيلوبايت ، ما لم يُنص على خلاف ذلك. إنها نوعًا من المقايضة الصعبة حيث لا يكون الأداء مثاليًا ، ولكنها ليست سيئة في معظم الحالات أيضًا. Recordsize يمكن ضبطه على أي قيمة من 4K إلى 1M (مع الإعدادات المتقدمة recordsize يمكنك تثبيت المزيد ، ولكن نادرًا ما تكون هذه فكرة جيدة).
تشير أي كتلة إلى بيانات ملف واحد فقط - لا يمكنك حشر ملفين مختلفين في كتلة واحدة. يتكون كل ملف من كتلة واحدة أو أكثر ، حسب الحجم. إذا كان حجم الملف أصغر من حجم التسجيل ، فسيتم تخزينه في حجم كتلة أصغر - على سبيل المثال ، ستشغل الكتلة التي تحتوي على ملف 2 كيلوبايت قطاعًا واحدًا بحجم 4 كيلوبايت على القرص.
إذا كان الملف كبيرًا بما يكفي ويتطلب عدة كتل ، فسيكون حجم جميع السجلات التي تحتوي على هذا الملف recordsize - بما في ذلك الإدخال الأخير ، الذي قد يكون الجزء الرئيسي منه .
لا تملك zvols ممتلكات recordsize - بدلاً من ذلك لديهم خاصية مكافئة volblocksize.
القطاعات
العنصر الأساسي الأخير هو القطاع. إنها أصغر وحدة مادية يمكن كتابتها أو قراءتها من الجهاز الأساسي. لعدة عقود ، استخدمت معظم الأقراص قطاعات 512 بايت. في الآونة الأخيرة ، تم تكوين معظم الأقراص لـ 4 قطاعات KiB ، وبعضها - خاصة محركات أقراص الحالة الصلبة - بها 8 قطاعات KiB أو أكثر.
يحتوي نظام ZFS على خاصية تسمح لك بتعيين حجم القطاع يدويًا. هذا العقار ashift. المربك إلى حد ما ، الرماد هو قوة اثنين. على سبيل المثال، ashift=9 يعني حجم مقطع 2 ^ 9 أو 512 بايت.
يستعلم ZFS نظام التشغيل للحصول على معلومات مفصلة حول كل جهاز كتلة عند إضافته إلى vdev جديد ، ومن الناحية النظرية يقوم تلقائيًا بتثبيت ashift بشكل صحيح بناءً على تلك المعلومات. لسوء الحظ ، تكذب العديد من محركات الأقراص حول حجم قطاعها من أجل الحفاظ على التوافق مع نظام التشغيل Windows XP (الذي لم يكن قادرًا على فهم محركات الأقراص ذات أحجام القطاعات الأخرى).
هذا يعني أنه ينصح بشدة مسؤول ZFS بمعرفة حجم القطاع الفعلي لأجهزته وتعيينه يدويًا ashift. إذا تم ضبط ashift على مستوى منخفض جدًا ، فسيزيد عدد عمليات القراءة / الكتابة بشكل فلكي. لذا ، فإن كتابة "قطاعات" بحجم 512 بايت في قطاع حقيقي بحجم 4 كيلوبايت يعني الحاجة إلى كتابة "القطاع" الأول ، ثم قراءة قطاع 4 كيلوبايت ، وتعديله باستخدام "قطاع" ثاني بحجم 512 بايت ، وإعادة كتابته مرة أخرى إلى المقطع الجديد. 4 قطاع KiB ، وما إلى ذلك. لكل إدخال.
في العالم الحقيقي ، مثل هذه العقوبة تصل إلى Samsung EVO SSDs ، والتي من أجلها ashift=13، ولكن محركات أقراص الحالة الثابتة هذه تكمن في حجم قطاعها ، وبالتالي يتم تعيين الإعداد الافتراضي على ashift=9. إذا لم يغير مسؤول النظام ذو الخبرة هذا الإعداد ، فعندئذٍ يعمل SSD هذا أبطأ الأقراص الصلبة المغناطيسية التقليدية.
للمقارنة ، لحجم كبير جدا ashift لا يوجد عمليا أي عقوبة. لا توجد عقوبة أداء حقيقية ، والزيادة في المساحة غير المستخدمة هي متناهية الصغر (أو صفر مع تمكين الضغط). لذلك ، نوصي بشدة بتثبيت حتى تلك المحركات التي تستخدم قطاعات 512 بايت ashift=12 أو حتى ashift=13لمواجهة المستقبل بثقة.
ممتلكات ashift تم تعيينه لكل جهاز افتراضي vdev ، و ليس للمسبح، كما يعتقد الكثيرون عن طريق الخطأ - ولا يتغير بعد التثبيت. إذا ضربت بطريق الخطأ ashift عندما تضيف vdev جديدًا إلى تجمع ، فإنك تلوث هذا التجمع بشكل لا رجعة فيه بجهاز منخفض الأداء ولا يوجد عادة خيار آخر سوى تدمير التجمع والبدء من جديد. حتى إزالة vdev لن يحميك من التكوين المعطل ashift!
آلية النسخ عند الكتابة
إذا احتاج نظام الملفات العادي إلى الكتابة فوق البيانات ، فإنه يغير كل كتلة في مكانها
يكتب نظام ملفات النسخ عند الكتابة نسخة كتلة جديدة ثم يفتح الإصدار القديم
باختصار ، إذا تجاهلنا الموقع الفعلي الفعلي للكتل ، فسيتم تبسيط "مذنب البيانات" إلى "دودة بيانات" تنتقل من اليسار إلى اليمين عبر خريطة المساحة المتاحة
يمكننا الآن الحصول على فكرة جيدة عن كيفية عمل لقطات النسخ عند الكتابة - يمكن امتلاك كل كتلة بلقطات متعددة ، وستظل قائمة حتى يتم إتلاف جميع اللقطات المرتبطة
آلية النسخ على الكتابة (CoW) هي الأساس الأساسي لما يجعل ZFS نظامًا رائعًا. المفهوم الأساسي بسيط - إذا طلبت من نظام ملفات تقليدي تغيير ملف ، فسيفعل ما طلبته بالضبط. إذا طلبت من نظام ملفات النسخ عند الكتابة أن يفعل الشيء نفسه ، فسيقول "حسنًا" ولكنه يكذب عليك.
بدلاً من ذلك ، يكتب نظام ملفات النسخ عند الكتابة إصدارًا جديدًا من الكتلة المعدلة ثم يقوم بتحديث البيانات الوصفية للملف لإلغاء ربط الكتلة القديمة وإقران الكتلة الجديدة التي كتبتها للتو.
يتم فصل الكتلة القديمة وربط الكتلة الجديدة في عملية واحدة ، لذلك لا يمكن مقاطعتها - إذا قمت بإيقاف التشغيل بعد حدوث ذلك ، فلديك نسخة جديدة من الملف ، وإذا قمت بإيقاف التشغيل مبكرًا ، فلديك الإصدار القديم . في أي حال ، لن يكون هناك تعارض في نظام الملفات.
لا يحدث النسخ عند الكتابة في ZFS فقط على مستوى نظام الملفات ، ولكن أيضًا على مستوى إدارة القرص. هذا يعني أن ZFS لا يتأثر بالمسافة البيضاء () - ظاهرة عندما كان لدى الشريط وقت للتسجيل جزئيًا فقط قبل تعطل النظام ، مع تلف المصفوفة بعد إعادة التشغيل. هنا يتم كتابة الشريط بشكل ذري ، و vdev دائمًا متسلسل ، و .
ZIL: سجل نية ZFS
يتعامل نظام ZFS مع عمليات الكتابة المتزامنة بطريقة خاصة - فهو مؤقتًا ولكنه يخزنها على الفور في ZIL قبل كتابتها بشكل دائم لاحقًا مع عمليات الكتابة غير المتزامنة.
عادةً ، لا تتم قراءة البيانات المكتوبة إلى ZIL مرة أخرى. لكن هذا ممكن بعد تعطل النظام
SLOG ، أو جهاز LOG الثانوي ، هو مجرد vdev خاص - ويفضل أن يكون سريعًا جدًا - حيث يمكن تخزين ZIL بشكل منفصل عن وحدة التخزين الرئيسية
بعد الانهيار ، يتم إعادة تشغيل جميع البيانات القذرة في ZIL - في هذه الحالة ، يتم تشغيل ZIL على SLOG ، لذلك يتم إعادة تشغيلها من هناك
هناك فئتان رئيسيتان من عمليات الكتابة - متزامن (متزامن) وغير متزامن (غير متزامن). بالنسبة لمعظم أعباء العمل ، تكون الغالبية العظمى من عمليات الكتابة غير متزامنة - يسمح نظام الملفات بتجميعها وإصدارها على دفعات ، مما يقلل من التجزئة ويزيد الإنتاجية بشكل كبير.
التسجيلات المتزامنة هي مسألة مختلفة تمامًا. عندما يطلب أحد التطبيقات كتابة متزامنة ، فإنه يخبر نظام الملفات: "تحتاج إلى الالتزام بهذا في ذاكرة غير متطايرة في الوقت الحاليحتى ذلك الحين ، لا يمكنني فعل أي شيء آخر ". لذلك ، يجب أن تلتزم عمليات الكتابة المتزامنة بالقرص على الفور - وإذا أدى ذلك إلى زيادة التجزئة أو تقليل الإنتاجية ، فليكن الأمر كذلك.
يتعامل ZFS مع الكتابة المتزامنة بشكل مختلف عن أنظمة الملفات العادية - بدلاً من إلزامها على الفور بالتخزين العادي ، تلزمها ZFS بمنطقة تخزين خاصة تسمى ZFS Intent Log أو ZIL. الحيلة هي أن هذه السجلات أيضا تظل في الذاكرة ، حيث يتم تجميعها جنبًا إلى جنب مع طلبات الكتابة العادية غير المتزامنة ، ليتم مسحها لاحقًا للتخزين كمجموعات TXG طبيعية تمامًا (مجموعات المعاملات).
في التشغيل العادي ، تتم كتابة ZIL إلى ولا تتم قراءته مرة أخرى أبدًا. عندما تلتزم السجلات من ZIL ، بعد لحظات قليلة ، بوحدة التخزين الرئيسية في TXGs العادية من ذاكرة الوصول العشوائي ، يتم فصلها عن ZIL. المرة الوحيدة التي يتم فيها قراءة شيء ما من ZIL هي عندما يتم استيراد التجمع.
إذا فشل ZFS - تعطل نظام التشغيل أو انقطاع التيار الكهربائي - أثناء وجود بيانات في ZIL ، ستتم قراءة هذه البيانات أثناء استيراد المجموعة التالي (على سبيل المثال ، عند إعادة تشغيل نظام الطوارئ). ستتم قراءة أي شيء في ZIL ، وتجميعه في TXGs ، والتزامه بالتخزين الرئيسي ، ثم فصله عن ZIL أثناء عملية الاستيراد.
تسمى إحدى فئات مساعد vdev LOG أو SLOG ، الجهاز الثانوي لـ LOG. له غرض واحد - تزويد المسبح بـ vdev منفصل ، ويفضل أن يكون أسرع بكثير ، ومقاوم للكتابة لتخزين ZIL ، بدلاً من تخزين ZIL في متجر vdev الرئيسي. يتصرف ZIL نفسه بنفس الطريقة بغض النظر عن مكان تخزينه ، ولكن إذا كان LOG vdev لديه أداء كتابة عالي جدًا ، فستكون عمليات الكتابة المتزامنة أسرع.
لا تعمل إضافة 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.
عندما يتم تحجيم صورة VM ، فإن مشاكل rsync تتوسع معها. 1,9 TiB ليس بهذا الحجم لصورة VM حديثة - لكنه كبير بما يكفي لأن تكرار ZFS أسرع 1148 مرة من rsync ، حتى مع rsync's - inplace
بمجرد فهم كيفية عمل اللقطات ، يجب أن يكون من السهل فهم جوهر النسخ المتماثل. نظرًا لأن اللقطة هي مجرد شجرة مؤشرات للسجلات ، فسيترتب على ذلك إذا فعلنا ذلك zfs send snapshot ، ثم نرسل كل من هذه الشجرة وجميع السجلات المرتبطة بها. عندما نرسل هذا 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 كيلوبايت ، وفي هذا المكان على القرص ، يتم حجز قطاع واحد فقط.
لا توجد هذه المشكلة في ZFS ، حيث تتم دائمًا كتابة السجلات المعدلة في مساحة غير مستخدمة - تشغل الكتلة الأصلية قطاعًا واحدًا بسعة 4 كيلوبايت ، وسيشغل السجل الجديد 256 ، ولكن هذه ليست مشكلة - جزء تم تعديله مؤخرًا من " mid "من الملف إلى مساحة غير مستخدمة بغض النظر عما إذا كان حجمه قد تغير أم لا ، لذلك بالنسبة لـ ZFS يعد هذا وضعًا عاديًا تمامًا.
يتم تعطيل ضغط ZFS الأصلي افتراضيًا ، ويقدم النظام خوارزميات قابلة للتوصيل — حاليًا LZ4 و gzip (1-9) و LZJB و ZLE.
- LZ4 هي خوارزمية دفق توفر ضغطًا وإلغاء ضغطًا سريعًا للغاية ومزايا أداء لمعظم حالات الاستخدام - حتى على وحدات المعالجة المركزية البطيئة إلى حد ما.
- GZIP هي خوارزمية محترمة يعرفها ويحبها جميع مستخدمي يونكس. يمكن تنفيذه بمستويات الضغط من 1 إلى 9 ، مع زيادة نسبة الضغط واستخدام وحدة المعالجة المركزية مع اقترابها من المستوى 9. تعد الخوارزمية مناسبة تمامًا لجميع حالات استخدام النص (أو غيرها من حالات الانضغاط العالية) ، ولكنها غالبًا ما تسبب مشكلات في وحدة المعالجة المركزية - استخدمها بحذر ، خاصة في المستويات الأعلى.
- LZJB هي الخوارزمية الأصلية في ZFS. لقد تم إهمالها ويجب عدم استخدامها بعد الآن ، حيث تتفوق LZ4 عليها بكل الطرق.
- ZLE - ترميز المستوى الصفري ، ترميز المستوى الصفري. إنه لا يمس البيانات العادية على الإطلاق ، ولكنه يضغط تسلسلات كبيرة من الأصفار. مفيد لمجموعات البيانات غير القابلة للضغط تمامًا (مثل JPEG أو MP4 أو التنسيقات الأخرى المضغوطة بالفعل) لأنه يتجاهل البيانات غير القابلة للضغط ولكنه يضغط المساحة غير المستخدمة في السجلات الناتجة.
نوصي باستخدام ضغط LZ4 لجميع حالات الاستخدام تقريبًا ؛ تكون عقوبة الأداء عند مواجهة بيانات غير قابلة للضغط صغيرة جدًا ، و نمو أداء البيانات النموذجية مهم. نسخ صورة جهاز ظاهري لتثبيت جديد لنظام التشغيل Windows (نظام تشغيل تم تثبيته حديثًا ، لا توجد بيانات بالداخل حتى الآن) باستخدام compression=lz4 مرت 27٪ أسرع من مع compression=noneفي .
ARC - ذاكرة التخزين المؤقت للاستبدال التكيفي
ZFS هو نظام الملفات الحديث الوحيد الذي نعرفه ويستخدم آلية التخزين المؤقت للقراءة الخاصة به ، بدلاً من الاعتماد على ذاكرة التخزين المؤقت لصفحة نظام التشغيل لتخزين نسخ من الكتل التي تمت قراءتها مؤخرًا في ذاكرة الوصول العشوائي.
على الرغم من أن ذاكرة التخزين المؤقت الأصلية لا تخلو من مشاكلها - لا يمكن لـ ZFS الاستجابة لطلبات تخصيص الذاكرة الجديدة بسرعة kernel ، لذا فإن التحدي الجديد malloc() عند تخصيص الذاكرة قد تفشل إذا كانت بحاجة إلى ذاكرة الوصول العشوائي التي تشغلها ARC حاليًا. ولكن هناك أسباب وجيهة لاستخدام ذاكرة التخزين المؤقت الخاصة بك ، على الأقل في الوقت الحالي.
تستخدم جميع أنظمة التشغيل الحديثة المعروفة ، بما في ذلك MacOS و Windows و Linux و BSD ، خوارزمية LRU (الأقل استخدامًا مؤخرًا) لتنفيذ ذاكرة التخزين المؤقت للصفحة. هذه خوارزمية بدائية تدفع الكتلة المخزنة مؤقتًا "لأعلى في قائمة الانتظار" بعد كل قراءة ، وتدفع الكتل "أسفل قائمة الانتظار" حسب الحاجة لإضافة أخطاء ذاكرة تخزين مؤقت جديدة (الكتل التي كان يجب قراءتها من القرص ، وليس من ذاكرة التخزين المؤقت) أعلى.
عادةً ما تعمل الخوارزمية بشكل جيد ، ولكن في الأنظمة التي تحتوي على مجموعات بيانات كبيرة تعمل ، تؤدي LRU بسهولة إلى التعثر - حيث يتم التخلص من الكتل المطلوبة بشكل متكرر لإفساح المجال للكتل التي لن تتم قراءتها مطلقًا من ذاكرة التخزين المؤقت مرة أخرى.
هي خوارزمية أقل سذاجة ويمكن اعتبارها ذاكرة تخزين مؤقت "مرجحة". في كل مرة تتم فيها قراءة كتلة مخبأة ، تصبح "أثقل" قليلاً ويصعب إخراجها - وحتى بعد طرد الكتلة متعقبة خلال فترة زمنية معينة. الكتلة التي تم إخلاؤها ولكن يلزم إعادة قراءتها في ذاكرة التخزين المؤقت ستصبح أيضًا "أثقل".
النتيجة النهائية لكل هذا هي ذاكرة تخزين مؤقت ذات نسبة دخول أعلى بكثير ، والنسبة بين مرات الوصول إلى ذاكرة التخزين المؤقت (القراءات التي يتم إجراؤها من ذاكرة التخزين المؤقت) وذاكرة التخزين المؤقت المفقودة (يقرأ من القرص). هذه إحصائية مهمة للغاية - ليس فقط أن ذاكرة التخزين المؤقت نفسها تقدم طلبات الحجم بشكل أسرع ، بل يمكن أيضًا تقديم أخطاء ذاكرة التخزين المؤقت بشكل أسرع ، نظرًا لأنه كلما زاد عدد مرات الوصول إلى ذاكرة التخزين المؤقت ، قل عدد طلبات القرص المتزامنة وانخفاض وقت الاستجابة لتلك الأخطاء المتبقية التي يجب يتم تقديمه مع القرص.
اختتام
بعد تعلم الدلالات الأساسية لـ ZFS - كيف يعمل النسخ عند الكتابة ، بالإضافة إلى العلاقات بين مجموعات التخزين ، والأجهزة الافتراضية ، والكتل ، والقطاعات ، والملفات - نحن على استعداد لمناقشة أداء العالم الحقيقي بأرقام حقيقية.
في الجزء التالي ، سنلقي نظرة على الأداء الفعلي للمجموعات ذات vdevs و RAIDz معكوسة ، مقابل بعضها البعض ، وأيضًا مقابل طبولوجيا Linux kernel RAID التقليدية التي اكتشفناها. .
في البداية ، أردنا تغطية الأساسيات فقط - طبولوجيا ZFS نفسها - ولكن بعد ذلك مثل هذا دعنا نستعد للحديث عن إعداد وضبط أكثر تقدمًا لـ ZFS ، بما في ذلك استخدام أنواع vdev المساعدة مثل L2ARC و SLOG و Special Allocation.
المصدر: www.habr.com