لقد خرج OpenZFS 2.1 – دعنا نتحدث عن DRAID vdevs الجديد

بعد ظهر الجمعة ، مشروع OpenZFS واسع الإصدار 2.1.0 لنظام الملفات المفضل لدينا “إنه معقد ولكنه يستحق كل هذا العناء”. الإصدار الجديد متوافق مع FreeBSD 12.2-RELEASE والإصدارات الأحدث ، ونواة Linux 3.10-5.13. يقدم هذا الإصدار عددًا من تحسينات الأداء العامة ، بالإضافة إلى بعض الميزات الجديدة تمامًا – وأبرزها استهداف حالات الاستخدام المتقدمة الأخرى في المؤسسات.

سنركز اليوم بلا شك على أكبر ميزة يقدمها OpenZFS 2.1.0 – طوبولوجيا dRAID vdev. كان dRAID قيد التطوير النشط منذ عام 2015 على الأقل ، ووصل إلى الإصدار التجريبي عندما مندمجة إلى OpenZFS Manager في نوفمبر 2020. ومنذ ذلك الحين تم اختباره بشكل مكثف في العديد من متاجر تطوير OpenZFS الكبيرة – مما يعني أن إصدار اليوم “جديد” لفئة الإنتاج ، وليس “جديدًا” لأنه لم يتم اختباره.

مراجعة RAID الموزعة (dRAID)

إذا كنت تعتقد بالفعل أن طوبولوجيا ZFS عبارة عن ملف مجمع الموضوع ، استعد لعقلك. RAID الموزع (dRAID) هو هيكل vdev جديد تمامًا واجهناه في عرض تقديمي في قمة DevZFS Dev عام 2016.

عند إنشاء DRAID vdev ، يحدد مسؤول النظام عددًا من مقاطع البيانات والعلاقات ونقطة الاتصال لكل شريط. لا تعتمد هذه الأرقام على العدد الفعلي للأقراص في vdev. يمكننا أن نرى هذا عمليًا في المثال التالي ، الذي تمت إزالته من المفاهيم الأساسية لـ DRAID توثيق:

root@box:~# zpool create mypool draid2:4d:1s:11c wwn-0 wwn-1 wwn-2 ... wwn-A
root@box:~# zpool status mypool

  pool: mypool
 state: ONLINE
config:

        NAME                  STATE     READ WRITE CKSUM
        tank                  ONLINE       0     0     0
          draid2:4d:11c:1s-0  ONLINE       0     0     0
            wwn-0             ONLINE       0     0     0
            wwn-1             ONLINE       0     0     0
            wwn-2             ONLINE       0     0     0
            wwn-3             ONLINE       0     0     0
            wwn-4             ONLINE       0     0     0
            wwn-5             ONLINE       0     0     0
            wwn-6             ONLINE       0     0     0
            wwn-7             ONLINE       0     0     0
            wwn-8             ONLINE       0     0     0
            wwn-9             ONLINE       0     0     0
            wwn-A             ONLINE       0     0     0
        spares
          draid2-0-0          AVAIL

طوبولوجيا DRAID

في المثال أعلاه لدينا أحد عشر قرصًا: wwn-0 طريق wwn-A. أنشأنا VDEV واحدًا من DRAID مع جهازي إقران و 4 أجهزة بيانات وجهاز احتياطي واحد لكل شريط – بلغة مركزة ، draid2:4:1.

على الرغم من أن لدينا أحد عشر قرصًا في المجموع draid2:4:1، يتم استخدام ستة فقط في كل شريط بيانات – وواحد في كل شريط جسدي – بدني شريط. في عالم من المكانس الكهربائية المثالية ، والأسطح الخالية من الاحتكاك والدجاج الكروية المنتشرة على قرص draid2:4:1 سيبدو مثل هذا:

في الواقع ، يأخذ DRAID مفهوم RAID “الاقتران المائل” خطوة أخرى إلى الأمام. لم تكن طوبولوجيا اقتران RAID الأول هي RAID5 – بل كانت RAID3 ، حيث كان الاقتران على محرك أقراص ثابت ، بدلاً من توزيعه في جميع أنحاء المصفوفة.

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

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

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

ولكن عندما نتحمل ، فإننا نفعل ذلك بالقدرة الاحتياطية المحفوظة مسبقًا:

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

ومن الجدير بالذكر أيضًا أن DRAID يتطلب عرض نطاق ثابت – وليس عروض ديناميكية مدعومة من RAIDz1 و RAIDz2 vdevs التقليديين. إذا استخدمنا أقراص 4kn ، فإن أ draid2:4:1 سيتطلب vdev مثل الموضح أعلاه 24 كيلو بايت على القرص لكل كتلة بيانات وصفية ، حيث يحتاج RAIDz2 vdev التقليدي ذو الستة اتجاهات إلى 12 كيلو بايت فقط. هذه الفجوة تزداد سوءًا كلما ارتفعت قيم d+p يحصل draid2:8:1 سيتطلب 40 كيلوبايت ضخمًا لكتلة البيانات الوصفية هذه!

لهذا السبب ، e special يعد تعيين Vdev مفيدًا جدًا في المجمعات باستخدام DRAID vdevs – عند التجميع مع draid2:8:1 وثلاثة واسعة special تحتاج إلى تخزين كتلة البيانات الوصفية 4KiB ، فهي تفعل ذلك فقط عند 12 كيلوبايت specialبدلاً من 40 كيلوبايت في draid2:8:1.

أداء DRAID والتسامح مع الخطأ والاسترداد

في أغلب الأحيان ، سيعمل vdev الخاص بـ DRAID بشكل مشابه لمجموعة مكافئة من vdevs التقليدية – على سبيل المثال ، draid1:2:0 على تسعة أقراص سيعادل أداء ما يقرب من مجموعة من ثلاثة RAIDz1 vdevs 3 واسعة. تحمل الأخطاء متشابه أيضًا – نضمن لك النجاة من فشل واحد معها p=1مثلك تمامًا مع vdevs RAIDz1.

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

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

لتقليل التسامح مع الخطأ بشكل طفيف يتم تعويضه عن أوقات المتانة السريعة بشكل كبير. في الرسم التخطيطي في الجزء العلوي من هذا القسم ، يمكننا أن نرى أنه في مجموعة من تسعين قرصًا بحجم 16 تيرابايت ، تم تجديدها على جهاز تقليدي ودائم spare يستغرق الأمر حوالي ثلاثين ساعة بغض النظر عن كيفية إعدادنا لـ dRAID vdev – ولكن إعادة تعيين السعة الموزعة الموزعة قد تستغرق حوالي ساعة واحدة فقط.

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

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

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

استنتاجات

تم تصميم أجهزة RAID vdev الموزعة بشكل أساسي لخوادم التخزين الكبيرة – OpenZFS draid تمحور التصميم والاختبار بشكل أساسي حول أنظمة سعة 90 قرصًا. على نطاق أصغر ، التقليدية و vdevs spares ابق مفيدًا كما لم تكن كذلك.

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

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