RAID 10 للتخزين في VPS: شرح المزايا وإعادة البناء

ما هو RAID 10 ولماذا تستخدمه مضيفات VPS

RAID 10 هو تخطيط التخزين الذي تستخدمه معظم مضيفات VPS مع محركات NVMe الافتراضية (non-volatile memory express). في تخطيطه التقليدي ذي النسختين، يعكس كل محرك على محرك آخر، ثم يوزّع البيانات على أزواج المحركات المنعكسة. يمكن أن يتعطل محرك واحد من دون توقف المصفوفة، ويكون إصلاحها مجرد نسخ من المحرك الشريك السليم، بدلاً من إعادة حساب البيانات بقراءة كل محرك آخر في المجموعة.

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

يكرر RAID عمليات الكتابة التي تنفذها. rm -rf /srv هي عملية كتابة. يُحذف الدليل من نصفي النسخة المطابقة في المللي ثانية نفسها، ومع ذلك تظل المصفوفة تبلغ عن أنها سليمة بعد ذلك.

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

المستويات التي يواجهها مشتري الاستضافة فعلياً: 1 و5 و6 و10

تذكر صفحة الخطة رقماً وتتوقف عند ذلك. يجيب الرقم عن سؤالين: كم محركاً يمكن أن يتعطل، وما تكلفة كل عملية كتابة.

RAID 1 هو النسخ المتطابق. يحتفظ محركان بكتل متطابقة. تُنفَّذ كل عملية كتابة على كليهما. ويمكن لأي محرك منهما تلبية عملية قراءة. يمكن أن يتعطل محرك واحد من دون فقدان البيانات، ويكون نصف السعة الخام قابلاً للاستخدام. لا توجد parity لحسابها، لذلك يكون مسار الكتابة قصيراً.

RAID 5 هو توزيع البيانات مع كتلة parity واحدة لكل شريط. مع n من المحركات، تحصل على سعة تعادل سعة n-1 منها، وتتحمل المصفوفة عطلاً واحداً بالضبط. لا توجد parity على محرك مخصص واحد. بل تتناوب عبر جميع المحركات، لذلك يحمل كل محرك البيانات وparity معاً.

يضيف RAID 6 كتلة parity ثانية مستقلة إلى كل شريط، وتُكتب عادةً باسمَي P وQ. ويتحمل تعطل أي محركين في الوقت نفسه. وهذا أهم مما يبدو، لأن العطل الثاني يحدث غالباً أثناء إصلاح العطل الأول.

RAID 10 هو توزيع لمرايا. تُنسخ المحركات في أزواج، وتُوزَّع البيانات عبر هذه الأزواج. وتساوي السعة القابلة للاستخدام نصف الإجمالي الخام، مثل RAID 1، مع إضافة التوازي الذي يوفّره توزيع البيانات.

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

Linux حالة خاصة تستحق المعرفة. إن raid10 في kernel هو personality واحدة، وليس طبقتين متراكبتين، لذلك يعمل على عدد فردي من المحركات، ويحتوي على تخطيطات (near وfar وoffset) لا يمكن لإعداد متداخل التعبير عنها. لذلك يذكر سطر الحالة على جهاز Linux قيمة 2 near-copies بدلاً من تسمية مصفوفتين.

[
  {
    "label": "RAID 1 (eight copies)",
    "usable_tb": 1,
    "worst_case_drives_lost": 7,
    "best_case_drives_lost": 7
  },
  {
    "label": "RAID 5",
    "usable_tb": 7,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 1
  },
  {
    "label": "RAID 6",
    "usable_tb": 6,
    "worst_case_drives_lost": 2,
    "best_case_drives_lost": 2
  },
  {
    "label": "RAID 10",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  }
]

توفر ثمانية محركات بسعة 1 TB 7 TB من المساحة القابلة للاستخدام في RAID 5، و4 TB في RAID 10. هذا الفرق يعني تكلفة فعلية، ولذلك يستمر اقتراح parity. يتحمل RAID 6 عدد 2 من الأعطال مهما كان نمطها. ولا يضمن RAID 10 سوى 1، لأن العطل الثاني الخطير هو الذي يصيب شريك المحرك الذي تعطل أولاً. ويمكنه تحمل ما يصل إلى 4 عندما لا يشترك أي عطلين في زوج واحد، لكن ذلك حظ وليس خاصية تصميمية.

تكلفة كل مستوى عند كل عملية كتابة

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

في نمط read-modify-write، يقرأ المتحكم البيانات القديمة وparity القديمة أولاً. لذلك تتحول عملية الكتابة فوق كتلة واحدة، من دون استخدام cache، على RAID 5 إلى: قراءة، قراءة، كتابة، كتابة. يحتفظ RAID 6 بكتلتي parity، لذلك تتحول عملية read-modify-write إلى: قراءة، قراءة، قراءة، كتابة، كتابة، كتابة. ويستخدم Linux أيضاً نمط reconstruct-write، إذ يقرأ البيانات التي لم تتغير لحساب parity. على RAID 5 مكوّن من ثلاثة أقراص، قد تتطلب هذه الكتابة قراءة بيانات واحدة وعمليتي كتابة؛ وعلى RAID 6 مكوّن من أربعة أقراص، قد تتطلب قراءة بيانات واحدة وثلاث عمليات كتابة. العددان أربعة وستة هما عدد عمليات read-modify-write، وليسا تكلفة ثابتة لكل عملية كتابة عشوائية صغيرة.

[
  {
    "label": "RAID 1 (2 drives)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  },
  {
    "label": "RAID 5 (8 drives)",
    "write_ops_per_host_write": 4,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 6 (8 drives)",
    "write_ops_per_host_write": 6,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 10 (8 drives, fixed mirror pairs)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  }
]

تتطلب عملية read-modify-write غير المخزنة مؤقتاً لكتلة واحدة 6 من عمليات الأجهزة على RAID 6، مقابل 2 للعملية نفسها على RAID 10 ذي النسختين. لكن هذه الأعداد لا تُظهر الفرق الكامل في زمن الاستجابة. تُرسل عمليتا الكتابة إلى المرآة بالتوازي، لذلك ينتظر الضيف العملية الأبطأ منهما. أما مسار read-modify-write فيتضمن قراءة يجب أن تكتمل قبل حساب parity الجديدة، لذلك ينتظر الضيف القراءة ثم الكتابة بالتتابع. وعلى خادم مشغول، تنتظر تلك القراءة خلف عمليات الإدخال والإخراج الخاصة بالجميع.

يوجد استثناء مهم. لا تحتاج الكتابة الكبيرة بما يكفي لملء شريط كامل إلى قراءة البيانات القديمة، لأن كل كتلة في الشريط تُستبدل. يُحسب parity من البيانات الموجودة بالفعل في الذاكرة، وتنخفض الكلفة إلى كتابة parity واحدة لكل شريط على RAID 5 أو كتابتين على RAID 6، من دون قراءات مسبقة. لهذا يبدو RAID 5 جيداً في اختبار أداء تسلسلي، لكنه يتصرف بشكل سيئ تحت حمل مختلط يتضمن كتابات صغيرة من عدة مستأجرين. اختبر النمط الذي تستخدمه فعلياً: يعني إجراء اختبار أداء قرص VPS بطريقة صحيحة استخدام إدخال وإخراج عشوائي عند عمق قائمة انتظار واقعي، وليس dd واحداً كبيراً.

الجزء الأخطر هو إعادة البناء

تحتاج إعادة بناء RAID 5 كاملة إلى إعادة إنشاء القرص المفقود من جميع الأقراص الأخرى، ولذلك تقرأ 7 أقراص سليمة من أول كتلة إلى آخرها في المثال ذي الأقراص الثمانية. أما مع أزواج النسخ المتطابقة الثابتة، فتقرأ إعادة بناء RAID 10 1: شريك النسخة المتطابقة للقرص المعطّل، ولا شيء آخر. وتوزّع تخطيطات Linux RAID10 الأخرى النسخ بطريقة مختلفة؛ إذ تقرأ إعادة بناء عضو في التخطيط القريب ذي الأجهزة الثلاثة العضوين السليمين كليهما.

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

يوجد خطر متعلق بسلامة البيانات خلال النافذة الزمنية نفسها. لا يملك مصفوف RAID 5 الذي يحتوي على قرص معطّل أي تكرار متبقٍ، ولذلك يصبح أي قطاع يتعذر قراءته على قرص سليم غير قابل للاسترداد. إعادة البناء هي العملية الوحيدة التي تقرأ كل قطاع، بما في ذلك القطاعات التي لم يلمسها أحد خلال سنة. تضع أرقام أوراق البيانات المنشورة محرك الأقراص الصلبة الاستهلاكي قريباً من خطأ قراءة واحد غير قابل للاسترداد لكل 10^14 بت مقروءة، ومحرك NVMe للمؤسسات عند خطأ واحد لكل 10^17 بت أو أفضل. هذه مواصفات مورّدين وليست قياسات، لكن النسبة تفسّر سبب ارتباط التحذير القديم من فشل إعادة بناء RAID 5 بالأقراص الدوّارة الكبيرة، وسبب ضعف انطباقه كثيراً على NVMe. وينطبق استدلال الحمل على أي وسيط تخزين.

اكتشف الأخطاء الكامنة قبل أن تفعل إعادة البناء ذلك، وذلك بإجراء scrub. تُضمّن Debian وUbuntu آلية scrub دورية لمصفوفات md، وتختلف الآلية بين الإصدارات، لذا تحقّق من الآلية الموجودة لديك ثم شغّل مروراً يدوياً.

systemctl list-timers --all | grep -i mdcheck
ls -l /etc/cron.d/mdadm
echo check | sudo tee /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cnt

sync_action يعود إلى idle عند انتهاء المرور، ويجب أن يقرأ mismatch_cnt القيمة 0. تشير قيمة أكبر من الصفر في النسخة المتطابقة إلى اختلاف نصفيها، ولا يستطيع kernel تحديد أيهما صحيح، لأن أياً من النسختين لا يحتوي على checksum. بعض حالات عدم التطابق غير ضارة، وتكون أقسام swap مصدرها المعتاد؛ فقد يكتب kernel صفحة تتغير تحته. أما ارتفاع العدد في مصفوفة بيانات فيتطلب التحقيق؛ فالعدد وحده لا يحدد القرص الذي يجب استبداله.

لماذا يوحّد مزوّدو VPS استخدام RAID 10 مع NVMe

لا يشغّل عقدة الـhypervisor عبء عمل واحداً. فهي تشغّل عشرات الضيوف غير المرتبطين، وتصل عمليات الإدخال والإخراج الخاصة بهم متداخلةً في صورة تدفق من عمليات الكتابة الصغيرة من دون محلية بينها. هذا هو النمط الذي تكون فيه كلفة دورة القراءة والتعديل والكتابة الخاصة بالتكافؤ أعلى ما يمكن، وهو النمط الذي تتعامل معه العقدة المشتركة طوال اليوم.

أضف إلى ذلك سلوك إعادة البناء، وستصبح نتيجة الاختيار واضحة. يؤدي تعطل محرك أقراص في عقدة تستخدم التكافؤ إلى إضافة عمل إعادة بناء عبر محركات الأقراص السليمة. أما مع أزواج النسخ المتطابقة الثابتة، فيؤدي تعطل محرك أقراص في عقدة RAID 10 إلى إضافة عمليات إدخال وإخراج لإعادة البناء إلى زوج واحد، كما يبطئ Linux MD عملية الاسترداد عند حدوث نشاط آخر. يبيع المزوّدون زمناً استجابة لا يرتفع فجأة، ولذلك يشترونه بالسعة: يذهب نصف سعة NVMe الخام إلى النسخة المتطابقة.

وتدفع أحجام محركات الأقراص في الاتجاه نفسه. فكلما كبرت محركات الأقراص طالَت فترة إعادة البناء، وفي RAID 5 تكون هذه الفترة هي التي تضيف فيها عملية إعادة البناء حملاً ولا تبقى فيها أي وفرة؛ بينما يحتفظ RAID 6 بالحماية من تعطل محرك أقراص إضافي. وهذا هو السبب نفسه الذي يجعل عمليات نشر ZFS الافتراضية تستخدم تجمعات من vdevs متطابقة بدلاً من raidz عريض: إذ تنسخ عملية resilver للنسخة المتطابقة الكتل المستخدمة فعلياً فقط، وعلى زوج واحد.

لا يعني أي من ذلك أن RAID 10 هو الخيار الصحيح في كل مكان. يُكتب هدف النسخ الاحتياطي في عمليات متسلسلة طويلة، ولا يُقرأ إلا نادراً، ولذلك يكون RAID 6 صفقة أفضل هناك. فهو يتحمل تعطلي محركي أقراص ويعيد معظم السعة. يحدد عبء العمل الخيار، لا العدد. وبالنسبة إلى خطة تختارها اليوم، تكون الوسيطة عادةً أهم من التخطيط الموضوع فوقها، كما أن الانتقال من SATA SSD إلى NVMe أكبر من أي فرق بين مستويات RAID على أي منهما.

كيفية قراءة ‎/proc/mdstat

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

cat /proc/mdstat
sudo mdadm --detail /dev/md0
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS

تطبع مصفوفة RAID 10 سليمة تضم أربعة محركات شيئاً قريباً من ذلك.

Personalities : [raid1] [raid10]
md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>

كل جزء من هذه المخرجات يحمل معلومات.

• Personalities يسرد وحدات md التي حمّلها kernel قيد التشغيل. يعني ظهور raid10 هناك أن الشيفرة متاحة، ولا يعني أكثر من ذلك.
• md0 : active raid10 هو جهاز المصفوفة وحالتها ومستواها.
• الأسماء التي تليه هي الأعضاء. الرقم بين القوسين المعقوفين هو فهرس الجهاز في بيانات تعريف المصفوفة، وليس موضعه في السطر، وليس بالضرورة خانته.
• بعد استبدال محرك، يحتفظ العضو الجديد عادةً بفهرس أعلى من الخانة التي يملؤها، لذلك قد يكون nvme4n1p3[4] موجوداً في الخانة 2. يطبع mdadm --detail الخانة الفعلية في العمود RaidDevice، لذا استخدمه عندما يكون الفرق مهماً.
• تعني (F) بعد اسم عضو أن العضو معطوب. وتعني (S) أنه احتياطي: موجود، لكنه خامل وينتظر حدوث عطل.
• تعرض 3906764800 blocks super 1.2 الحجم القابل للاستخدام بوحدات كتل حجمها 1 KiB، ثم تنسيق بيانات التعريف.
• تعرض 512K chunks 2 near-copies حجم قطعة الشريط وتخطيط RAID 10، الذي يحتفظ هنا بنسختين من كل كتلة متجاورتين.
• تعرض [4/4] عدد الأعضاء المتوقع في المصفوفة، ثم عدد الأعضاء المتزامنة حالياً.
• تعرض [UUUU] حرفاً واحداً لكل خانة، بترتيب الخانات. تعني U أن الخانة قيد التشغيل ومتزامنة. وتعني _ أن الخانة لا يوجد فيها شيء يعمل.
• bitmap: هي خريطة نية الكتابة. تسجل المناطق التي كانت قيد الكتابة، بحيث يعيد العضو الذي ينقطع ثم يعود مزامنة تلك المناطق بدلاً من محرك التخزين بأكمله.

ماذا تعني [4/3] و[UU_U] عند حدوث مشكلة

تبدو المصفوفة المتدهورة هكذا.

md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2](F) nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]

اقرأ القوسين معاً. تشير [4/3] إلى أن إحدى الخانات الأربع لا تساهم في المصفوفة. وتوضح [UU_U] أي خانة هي، لأن الشرطة السفلية هي الحرف الثالث ولأن الخانات تبدأ بالترقيم من الصفر، لذلك تكون الخانة 2 متوقفة. يحدد المؤشر (F) الجهاز فقط ما دام المحرك المعطوب متصلاً. أخرجه من الجهاز، فيختفي الاسم من السطر، بينما تبقى الشرطة السفلية.

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

grep -i mailaddr /etc/mdadm/mdadm.conf
sudo mdadm --monitor --scan --oneshot --test
systemctl list-units --all | grep -i md

تثبّت الحزمة mdadm خدمة مراقبة تقرأ MAILADDR من /etc/mdadm/mdadm.conf. وقد تغيّر اسم الوحدة بين الإصدارات، لذا اعثر عليه باستخدام الأمر الأخير بدلاً من التخمين. يرسل التشغيل --test رسالة واحدة لكل مصفوفة فوراً. ويعني بقاء صندوق الوارد فارغاً بعد ذلك أن مسار البريد معطّل، ولذلك كانت الرسالة التي تهمك فعلياً ستُفقد بالطريقة نفسها.

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

md0 : active raid10 nvme4n1p3[4] nvme3n1p3[3] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]
      [==>..................]  recovery = 12.4% (242012928/1953382400) finish=63.1min speed=452000K/sec

تعني recovery إعادة البناء على محرك بديل. وتعني resync فحص الاتساق، بما في ذلك الفحص الأولي والاسترداد بعد إيقاف تشغيل غير سليم. وتعني check عملية الفحص التي شغّلتها أعلاه. يوضح الزوج بين قوسين التقدم بوحدات كتل حجمها 1 KiB مقارنةً بالإجمالي لكل جهاز، ويمثل finish تقدير kernel للوقت المتبقي بالسرعة الحالية. يستخدم Linux MD كلاً من /proc/sys/dev/raid/speed_limit_min وspeed_limit_max كهدفين لسرعة الاسترداد، مع إمكانية تجاوزهما لكل مصفوفة في sync_speed_min وsync_speed_max. الحد الأقصى الافتراضي للهدف هو 200,000 KiB/s لكل جهاز؛ وتتيح هذه الأهداف خفض أولوية الاسترداد أمام عمليات الإدخال والإخراج الإنتاجية، وليست حدوداً صارمة للسرعة.

/dev/md0:
           Version : 1.2
     Creation Time : Tue Mar 10 09:14:22 2026
        Raid Level : raid10
        Array Size : 3906764800 (3.64 TiB 4.00 TB)
     Used Dev Size : 1953382400 (1.82 TiB 2.00 TB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Wed Aug  5 11:02:41 2026
             State : clean, degraded, recovering
    Active Devices : 3
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 1

            Layout : near=2
        Chunk Size : 512K

    Rebuild Status : 12% complete

              Name : storage:0
            Events : 4184

    Number   Major   Minor   RaidDevice State
       0     259        3        0      active sync set-A   /dev/nvme0n1p3
       1     259        7        1      active sync set-B   /dev/nvme1n1p3
       4     259       11        2      spare rebuilding    /dev/nvme4n1p3
       3     259       15        3      active sync set-B   /dev/nvme3n1p3

يتطلب استبدال محرك في مصفوفة تملكها أربعة أوامر، والأمر الأخير هو أمر التحقق.

sudo mdadm --manage /dev/md0 --fail /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --remove /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --add /dev/nvme4n1p3
cat /proc/mdstat

ينبغي أن يظهر سطر الاسترداد خلال ثانية أو ثانيتين. يجب أن يكون قسم الاستبدال كبيراً بقدر Used Dev Size على الأقل كما هو موضح في mdadm --detail، ويُرفض القسم الأصغر ولو قليلاً برسالة من الشكل not large enough to join array. قسّم المحرك الجديد ليتطابق مع المحرك القديم قبل إضافته.

ما الذي يمكنك وما لا يمكنك رؤيته من داخل VPS

لا يستطيع معظم الضيوف رؤية RAID الخاص بالمضيف، وهذا مقصود. يقدّم لك برنامج hypervisor قرصاً افتراضياً واحداً. وسواء كان هذا القرص مقتطعاً من مجموعة RAID 10 مكوّنة من أقراص NVMe أو موجوداً على قرص واحد، فهذه خاصية تخص المضيف ولا تظهر داخل الضيف.

systemd-detect-virt
lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /proc/mdstat

تطبع systemd-detect-virt القيمة kvm على ضيف KVM، ونوع حاوية مثل lxc على حاوية، وnone على خادم bare metal. على ضيف KVM، سترى عادةً vda أو sda واحداً في lsblk، ولن ترى أي مصفوفات في /proc/mdstat، لأنها غير موجودة داخل الضيف.

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

يمكنك من الداخل التحقق من سلوك القرص المقدم لك. يشرح التحقق مما إذا كان قرص VPS الخاص بك هو NVMe فعلاً الأوامر التي تعرض معلومات حقيقية، بينما يشرح ما الذي يتضمنه VPS المزود بقرص SSD فعلياً ما الذي يدّعيه الاسم في صفحة الخطة.

هل ينبغي تشغيل RAID داخل VPS؟

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

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

ما الذي لا يحميك منه RAID

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

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

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

FAQ

هل يعني RAID 10 أنني لا أحتاج إلى نسخ احتياطية؟

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

لماذا يختار موفرو VPS ‏RAID 10 بدلاً من RAID 5 أو RAID 6؟

هناك سببان، وكلاهما يتعلق بعمليات الكتابة العشوائية الصغيرة. تتطلب عملية القراءة-التعديل-الكتابة غير المخزنة لكتلة واحدة قراءة البيانات القديمة والتكافؤ قبل حساب التكافؤ الجديد، ما يكلّف 4 عمليات في RAID 5 و6 في RAID 6، مقابل 2 في نسخة متطابقة من نسختين. تستخدم عملية إعادة البناء-الكتابة البيانات التي لم تتغير بدلاً من ذلك، ولا تحتاج عمليات الكتابة على الشريط الكامل إلى قراءة مسبقة للبيانات القديمة أو التكافؤ القديم. بعد ذلك، تقرأ عملية إعادة بناء RAID 5 الكاملة كل محرك أقراص سليم من بدايته إلى نهايته، بينما تنسخ RAID 10 التقليدية ذات أزواج النسخ المتطابقة الثابتة من الشريك السليم؛ وتستخدم تخطيطات Linux RAID10 الأخرى عدة أعضاء مصدر. يحدّ Linux MD من سرعة الاسترداد عند حدوث نشاط آخر. ويدفع الموفرون تكلفة ذلك من السعة: نصف سعة NVMe الخام.

ماذا تعني [U_] أو [UU_U] في /proc/mdstat؟

يمثل كل محرف خانة واحدة في المصفوفة، وفق ترتيب الخانات، مع محرف واحد لكل خانة. U يعني أن الخانة تحتوي على عضو يعمل ومتزامن. _ يعني أن الخانة لا تحتوي على شيء يعمل فيها. ويعني [U_] في نسخة متطابقة من محركي أقراص أن الخانة الثانية متوقفة ولم تعد هناك أي زيادة عن الحاجة. اقرأ ذلك مع الزوج الموجود قبله، حيث يوضح [4/3] أن المصفوفة تتوقع أربعة أعضاء وأن لديها ثلاثة. يتطابق ترتيب الخانات مع العمود RaidDevice في mdadm --detail، وليس مع الترتيب الذي تظهر به أسماء الأجهزة في السطر.

كم عدد محركات الأقراص التي يمكن لمصفوفة RAID 10 فقدانها؟

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

هل ينبغي أن أنشئ نسخة متطابقة من وحدتي تخزين داخل VPS باستخدام mdadm؟

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